Hi Adrian,
Just so I'm clear, are you referring to clients being in an SE environment,
with the JMS server running in a container, or that the JMS server is also
in a standalone SE environment?
In my opinion, an SE standardized bootable container will be very useful to
a number of people. In most places where I've implemented a JMS solution it
has been standalone in operation. Part of this would then need to include
some standard operations for finding topics/queues, currently in relies on
JNDI but JNDI may not be available if we're working in an SE environment
(though I suppose at a high level, it could be expected that a mini JNDI
provider be bundled to help look for connection factory, topics and queues).
John
On Fri, Jul 8, 2011 at 10:16 AM, Adrian Johnson <ad_at_tibco.com> wrote:
> **
> John,
>
>
> On 7/22/64 11:59 AM, John D. Ament wrote:
>
> There was a suggestion on the list to force all JMS implementations
>> run in plain Java SE. I don't think that's a good thing to require from all
>> providers, as they now can simply rely on a lot of their infrastructure.
>>
>> +1.
>>
>> I'm not too sure what this means to be honest. If the issue is that a
> JMS implementation should be bootable in an SE environment, then yes I think
> that should be included. What that actually boots (e.g. a full web
> container, EJB container, CDI container, etc) will vary.
>
>
>
> I was one of the proponents of the Java SE suggestion so maybe I should
> explain a bit. The majority of our customers use the JMS API outside of any
> sort of container. Tying the JMS 2.0 API to something outside of Java SE
> would not be well received by those customers. Requiring them to install,
> run and manage an App Server just so that their standalone apps can continue
> to work is not going to fly for them.
>
> I don't know what is involved in implementing Dependency Injection but if
> it can be done in a way such that folks can continue to write, build and run
> Java SE apps then that of course would be fine.
>
> Regards,
>
> Adrian.
> --
> Adrian Johnson
> TIBCO Software Inc
> ad_at_tibco.com
>