Yes. I will work on it. -----Original Message----- From: Kasper Sørensen [mailto:[email protected]] Sent: Wednesday, October 09, 2013 3:36 AM To: [email protected] Subject: Re: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory
Is this something you feel like spending time on doing? If you can propose a draft solution to begin with that would be great to get it going... 2013/10/8 Hillyard, Robin C <[email protected]> > Thanks for your comments. I only just saw your response today. > > I think your DataContextFactoryBean idea is a good one, probably a > more satisfactory solution than my interface suggestion, at least in > terms of generalizing the mechanism for constructing data contexts. > > I'm not sure if it would address the other aspect (but it might, > depending on the implementation). To wit, the unnecessary loading of > classes for data stores of no interest. If the proposed factory bean > loaded such classes on request (that is at configuration time) then it > would not be necessary for an application even to have available the > jar files for stores that it didn't need. > > -----Original Message----- > From: Kasper Sørensen [mailto:[email protected]] > Sent: Thursday, September 12, 2013 3:25 PM > To: [email protected] > Subject: Re: [jira] [Commented] (METAMODEL-27) Non-extensible > DataContextFactory > > I think I see what you are getting to, and probably the solution you > sketch would work. > > But I am not sure if it is really needed. In fact, as things are > today, you can simply just use the constructors of the individual > DataContext implementations. The role (today) of the > DataContextFactory is in that sense not to provide a > extensible/pluggable factory framework, but simply to provide a handy > set of pointers to the different types of DataContexts you can create > out of the box. In many cases though, I don't use the factory but just > use the constructor of whatever DataContext implementation I need. > > On the other hand, you idea got me thinking about a common issue I > have seen time and time again: That the constructors make > instantiation a bit unhandy in e.g. Spring XML files, where you don't > have any getter/setter based initializations or any spring > FactoryBeans or anything like that. I could imagine a generic > DataContextFactoryBean which would allow the developer to specify > DataContext type and configuration options as properties, and then > have the FactoryBean use those properties to construct a proper > DataContext. Sorry if this is hijacking your mail thread and turning > it into another type of solution... Just wanted to ask: Would this > solve the issue that you're trying to solve, also? Or else I am > probably still not really understanding why it is important to make a > pluggable factory pattern for DataContexts. > > > 2013/9/12 Hillyard, Robin C <[email protected]> > > > Not sure if this is what you had in mind for posting, but here goes: > > > > The problem I'm trying to solve is extensibility to other data > > sources (contexts). You have JDBC to cover basic SQL for relational > > databases, but all of the NoSQL datastores are somewhat different > > and thus handled separately. That's to say, there is a method in > > DataContextFactory to get a data context for MongoDB and another for > > CouchDB. Other NoSQL datastore would each have to have their own > implementation (and factory methods). > > This is somewhat (!) unwieldy. > > > > What I'm proposing is a more generic data context factory mechanism. > > > > First of all, I would define an interface: DataContextFactory with > > several signatures, something like these (the interface might be > > split into different types according to which type was appropriate): > > > > public abstract DataContext > > createCompositeDataContext(DataContext... delegates); // this would > > be implemented in an abstract base class > > > > And a subinterface FileDataContextFactory for dealing with files, > > such as a Xml, CSV or Excel context: > > > > public abstract DataContext createFileDataContext(File > > file, char separatorChar, char quoteChar, String encoding); // > > implemented by, for example a factory for CSV > > > > public abstract DataContext createFileDataContext (File > > file, char separatorChar, char quoteChar); // implemented by, for > > example a factory for CSV > > > > public abstract DataContext createFileDataContext (File > > file, Configuration configuration); // implemented by, for example a > > factory for CSV > > > > public abstract DataContext createFileDataContext (File > > file); // implemented by, for example a factory for CSV > > > > public abstract DataContext createFileDataContext (File > > file, InputStream stream); // implemented by, for example a factory > > for CSV > > > > etc. etc. > > > > And another subinterface JDBCContextFactory for dealing with JDBC > > connections > > > > public abstract DataContext > > createJDBCDataContext(Connection connection); > > > > and another subinterface CredentialedDataContextFactory for dealing > > with other client/server connections, such as Salesforce > > > > public abstract DataContext > > createCredentialedDataContext(Credentials credentials); // where > > Credentials encapsulates things like username, password, etc. > > > > and another subinterface NoSQLDataContextFactory for dealing with > > other client/server connections that need a server specification, > > such as MongoDB > > > > public abstract DataContext > > createNoSQLDataContext(Credentials > > credentials, ServerSpecification server); // where Credentials > > encapsulates things like username, password, etc. > > > > etc. etc. > > > > Second, I would create a (singleton) DataContextFactoryRegistry > > class with signatures something like this: > > > > registerDataContextFactory(Class<? Extends > > DataContextFactory> factoryClass, ClassLoader > > dataContextClassLoader) > > > > registerDataContextFactory(Class<? Extends > > DataContextFactory> factoryClass, URI dataContextJar) > > > > registerDataContextFactory(Class<? Extends > > DataContextFactory> > > factoryClass) // uses the classLoader for the > > DataContextFactoryRegistry class > > > > This design decouples the specific implementations of data context > > from the base system and allows data contexts to be plugged in > > dynamically (or at startup time). > > > > Third-party implementations of DataContextFactory (whether > > contributed or > > not) would simply implement the appropriate signatures, perhaps > > extending an abstract base type. > > > > Comments very welcome of course - and I would be happy to find that > > the DataContextFactory was not the proper place to solve it and that > > there was another pattern that was more appropriate. > > > > Robin > > > > > > -----Original Message----- > > From: Kasper Sørensen (JIRA) [mailto:[email protected]] > > Sent: Wednesday, September 11, 2013 2:59 PM > > To: [email protected] > > Subject: [jira] [Commented] (METAMODEL-27) Non-extensible > > DataContextFactory > > > > > > [ > > https://issues.apache.org/jira/browse/METAMODEL-27?page=com.atlassian. > > jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId= > > 13 > > 764626#comment-13764626] > > > > Kasper Sørensen commented on METAMODEL-27: > > ------------------------------------------ > > > > Hi there, > > > > I think it would be nice to have this issue and METAMODEL-28 > > discussed on the mailing lists. While reading the issues > > descriptions, I get the sense that you're trying to solve another > > problem than that which the DataContextFactory solves. > > > > Could you please post a mail about the problem as you percieve it, > > and maybe some sample or pseudo code of what you have in mind to solve it. > > I'd prefer taking it this way because I sense that you have some > > great and relevant points, but maybe the DCF isn't the proper place > > to solve > it? > > > > Kind regards, > > Kasper > > > > > Non-extensible DataContextFactory > > > --------------------------------- > > > > > > Key: METAMODEL-27 > > > URL: > https://issues.apache.org/jira/browse/METAMODEL-27 > > > Project: Metamodel > > > Issue Type: Wish > > > Reporter: Robin Hillyard > > > Priority: Trivial > > > Original Estimate: 1h > > > Remaining Estimate: 1h > > > > > > This is very trivial: developers cannot extend DataContextFactory > > because it has a private constructor, yet it is not marked final > > (nor should it be, IMO). The desired behavior (nobody can invoke the > > constructor) can also be satisfied by a protected constructor. > > > However, this is really part of a greater architectural issue > > > which I > > will write up separately under the name Pluggable Data Contexts. > > > > -- > > This message is automatically generated by JIRA. > > If you think it was sent incorrectly, please contact your JIRA > > administrators For more information on JIRA, see: > > http://www.atlassian.com/software/jira > > > > > > This e-mail, including attachments, may include confidential and/or > > proprietary information, and may be used only by the person or > > entity to which it is addressed. If the reader of this e-mail is not > > the intended recipient or his or her authorized agent, the reader is > > hereby notified that any dissemination, distribution or copying of > > this e-mail is prohibited. If you have received this e-mail in > > error, please notify the sender by replying to this message and > > delete this > e-mail immediately. > > > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity > to which it is addressed. If the reader of this e-mail is not the > intended recipient or his or her authorized agent, the reader is > hereby notified that any dissemination, distribution or copying of > this e-mail is prohibited. If you have received this e-mail in error, > please notify the sender by replying to this message and delete this e-mail > immediately. > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
