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. > >
