You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metamodel.apache.org by "Hillyard, Robin C" <ro...@uhc.com> on 2013/10/08 15:51:18 UTC
RE: [jira] [Commented] (METAMODEL-27) Non-extensible
DataContextFactory
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:i.am.kasper.sorensen@gmail.com]
Sent: Thursday, September 12, 2013 3:25 PM
To: dev@metamodel.incubator.apache.org
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 <ro...@uhc.com>
> 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:jira@apache.org]
> Sent: Wednesday, September 11, 2013 2:59 PM
> To: dev@metamodel.incubator.apache.org
> 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.
RE: [jira] [Commented] (METAMODEL-27) Non-extensible
DataContextFactory
Posted by "Hillyard, Robin C" <ro...@uhc.com>.
Yes. I will work on it.
-----Original Message-----
From: Kasper Sørensen [mailto:i.am.kasper.sorensen@gmail.com]
Sent: Wednesday, October 09, 2013 3:36 AM
To: dev@metamodel.incubator.apache.org
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 <ro...@uhc.com>
> 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:i.am.kasper.sorensen@gmail.com]
> Sent: Thursday, September 12, 2013 3:25 PM
> To: dev@metamodel.incubator.apache.org
> 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 <ro...@uhc.com>
>
> > 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:jira@apache.org]
> > Sent: Wednesday, September 11, 2013 2:59 PM
> > To: dev@metamodel.incubator.apache.org
> > 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.
Re: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory
Posted by Kasper Sørensen <i....@gmail.com>.
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 <ro...@uhc.com>
> 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:i.am.kasper.sorensen@gmail.com]
> Sent: Thursday, September 12, 2013 3:25 PM
> To: dev@metamodel.incubator.apache.org
> 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 <ro...@uhc.com>
>
> > 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:jira@apache.org]
> > Sent: Wednesday, September 11, 2013 2:59 PM
> > To: dev@metamodel.incubator.apache.org
> > 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.
>
>