just an idea I think it would make sense:
What about having something like a DriverFactory (just to not call it
ConnectionFactoryFactory)
it would be
DriverFactory
{
ConnectionFactory newConnectionFactory(ConnectionFactoryType, URI uri);
}
The URI method would then have things like host and any other
configuration for the connection factory through this URI approach.
I'm not sure if you have seen that HornetQ was donated to ActiveMQ and
we are refactoring both codebases as activemq6 now... and we have just
imported that mechanism to our connection factory. It works quite
generic for any case.
We could define common properties everyone is supposed to follow and
then users could then change more specific behaviour with any other
user defined property.
An examples would be
DriverFactory factory = new OracleDriverFactory();
factory.newConnectionFactory(ConnectionFactory,
"jms://user:password_at_localhost:3030?TTL=30000"); // just pretend TTL
was an Oracle property.
I'm not sure I like the name jms:// at the URI schema. on the activmq
case we have tcp, invm and udp. maybe we stick to jms and we could add
the medium and protocols as properties on the URI if the proposal
here goes forward.
On Mon, Mar 16, 2015 at 6:44 AM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> (Sorry for delay in replying)
>
> On 09/03/2015 22:32, Clebert Suconic wrote:
>>
>> I remember in the earlier days of JMS2 spec we talked about a common
>> way to instantiate a connection factory.
>
>
> That's right, we did. I originally logged
> https://java.net/jira/browse/JMS_SPEC-46.
>
> We did discuss these proposals at the time (as well as similar proposals for
> defining queue and topic objects), but we got a bit bogged down and I didn't
> see much enthusiasm for them, so I dropped them.
>
> I see I subsequently logged a simpler proposal as
> https://java.net/jira/browse/JMS_SPEC-89, though I'm not sure how much
> discussion that proposal had at the time.
>
> Your email (and others I have received) confirms the need for some kind of
> standard API, if only we could decide what it should be, so, yes, the issue
> remains on the list of issues to consider for JMS 2.1 (starting very soon, I
> promise)
>
> https://java.net/projects/jms-spec/pages/JMS21Planning#Major_issues_which_were_planned_for_JMS_2.0_but_which_couldn_t_be_completed_in_time.
>
> Looking at JMS_SPEC-89, I see there are three parts of my proposal:
>
> (1) a requirement for all connection factories to support a particular kind
> of constructor (taking a Properties object)
> ConnectionFactory cf = new com.acme.jms.AcmeConnectionFactory(properties
> props);
>
> (2) a *very* short set of standard property names
> (user,password,clientid,URL)
>
> (3) a new factory class which, though not strictly necessary, makes it
> easier to avoid hardcoding JMS provider classnames into the application.
>
> I also added that this API was not for use by Java EE applications, since
> the JCA spec covers that aspect already.
>
> I'd welcome other suggestions. For example, we could replace (1) with a
> simple requirement to support a no-arg constructor, and to allow properties
> to be set using javabeans setters and getters. What do you think?
>
> Nigel
>
>
>>
>> What was the result on that? was it rejected?
>>
>>
>> Can we revisit this? I just talked to one of the senior devs at the
>> app server and that would be very helpful on the application server
>> tooling and admin tools.
>>
>> This was wildfly / Jboss but I'm sure this would be helpful to anyone.
>>
>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com