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=13764626#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. >
