It's a little archaic today;-) Even for SQL and JDBC most developers and
app servers prefer DataSource now.
JNDI which serves these (and also JMS of course) has one or the other
static factory class, too like NamingManager.
Aside from that many of the newer EE JSRs (from EE 6 on) provide a similar
accessor either as part of the public API or at least SPI. JMS has so far
only a single package name, so adding an SPI package does not seem to make
sense at this point. Btw. JSR 107 also has a Caching class as central,
singleton static factory to the Service Loader.
Werner
On Tue, Mar 17, 2015 at 4:16 PM, Clebert Suconic <clebert.suconic_at_gmail.com>
wrote:
> Users will just expect we do whatever they do with this class:
> http://docs.oracle.com/javase/7/docs/api/java/sql/Driver.html
>
>
> Why don't we just do what people have been doing with JDBC Driver for 10+
> years.
>
>
> jdbc.Driver driver = Class.forInstance("class_name").newInstance(); //
> whatever the API here
> driver.getConnectionFactory();
>
> or maybe we could do something new, and have this new class
> substituting the connection factory?
>
>
>
> The request I got is just to be able to make a standard way for admin
> tools. I'm just suggesting we copy the way JDBC is doing because
> that's what users would expect
>
>
>
>
> On Tue, Mar 17, 2015 at 11:05 AM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
> > No, IMHO the constructor would be private or at most protected.
> >
> > To be honest, I'm not sure, why Validation has a public constructor.
> Maybe
> > it's required by some DI frameworks (I know especially Spring often
> does;-)
> > so does the CDI class, but all such classes in JSR 354 like
> > javax.money.MonetaryAmounts have a private constructor and they're
> final. I
> > know, at least the CDI class is abstract and some implementations extend
> it.
> >
> > Werner
> >
> >
> >
> > On Tue, Mar 17, 2015 at 3:51 PM, Clebert Suconic <
> clebert.suconic_at_gmail.com>
> > wrote:
> >>
> >> I meant something instantiating it...
> >>
> >> but really I'm just proposing to do whatever javax.sql is doing. I
> >> remember you would get an instance of the driver and you would call
> >> the method on that instance.
> >>
> >> So you would need an empty constructor.
> >>
> >> The advantage I see is for people writing generic tools. It's actually
> >> the role of the guy who asked me about this.. he's writing tooling to
> >> configure ConnectionFactories for external VMs on a generic faction.
> >> having this standardized would help those kind of tools
> >>
> >>
> >>
> >> On Tue, Mar 17, 2015 at 10:29 AM, Nigel Deakin <nigel.deakin_at_oracle.com
> >
> >> wrote:
> >> > On 17/03/2015 12:21, Clebert wrote:
> >> >>
> >> >> I didn't propose a static method. I just proposed a factory similar
> to
> >> >> what Jdbc uses. You use the class loader to
> >> >> load the class and use it non statically. Just like Jdbc.
> >> >>
> >> >
> >> > You proposed
> >> >
> >> >>>> JMSDriver dirver = Class.forName("MyProvider");
> >> >>>> ConnectionFactory factory =
> >> >>>> driver.newConnectionFactory(connectionString
> >> >>>> / URI / something we all agree upon);
> >> >
> >> >
> >> > which means newConnectionFactory has to be a static method.
> >> >
> >> > All the methods on javax.sql.DriverManager are static.
> >> >
> >> > I'm not saying this is a bad thing, but I'd like to understand why we
> >> > need
> >> > to introduce another level of provider-specific factory. The main
> >> > benefit I
> >> > can see is that allows the provider to choose the connection factory
> >> > implementation class depending on the specified properties. Is that a
> >> > requirement?
> >> >
> >> > Nigel
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >> http://community.jboss.org/people/clebert.suconic@jboss.com
> >> http://clebertsuconic.blogspot.com
> >
> >
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com
>