[openjms-developer] Embedding....

[Day, Jem BGI SF]

Probably a question for Tim....

I'm playing with the notion of embedding OpenJMS, i've been able
spin-up the EmbeddedServer implementation but the means of configuration
was a little confusing/inconsistant. I'd put this down to (the valid
point) that OpenJMS was designed as a standalone process.

I'm also interested in what (if any) changes are being made given that
OpenJMS is the provider of choice for Apache Geronimo (to the best of
my knowledge).

Suggestions...

- Adopt a similar approach to OpenEJB where an SPI layer is defined that
may be implemented by the containing process.

- An SPI to a DataSource/Connection provider (so that OpenJMS can leverage
any pooling provided directly by the container - don't assume JNDI).

- An SPI to a transaction manager.

Whilst (i think) i was able to run-up the process i still got quite a
few Exceptions thrown (ie i don't provide a Log4J config).

Notes:

I had to provide a <ServerConfiguration embeddedJNDI="true"/> entry but
my sense from the documentation was that this was 'implied by default'

I had to provide a dummy <AdminConfiguration script="c:/freddy"/> entry
as this is required in the config.. but i had no use for it.

Thoughts...

Jem...

[Tim Anderson]

Day, Jem BGI SF
Sent: Thursday, 11 March 2004 4:51 AM
To: openjms-developer
Subject: [openjms-developer] Embedding....
Probably a question for Tim....
I'm playing with the notion of embedding OpenJMS, i've been able
spin-up the EmbeddedServer implementation but the means of
configuration was a little confusing/inconsistant. I'd put this down
to (the valid
point) that OpenJMS was designed as a standalone process.

The EmbeddedJmsServer class is largely redundant. The JmsServer class
can be
used in its place. This will probably be deprecated in future.

I'm also interested in what (if any) changes are being made given that
OpenJMS is the provider of choice for Apache Geronimo (to the best of
my knowledge).

At the moment I'm working on refactoring the connectors. This will:
. improve performance for TCP/TCPS
. remove a lot of cruft
. make it easier to move to the JMS 1.1 API

I haven't done any work specifically for Geronimo as of yet.
Last I heard, they were planning on supporting different
JMS providers.

Suggestions...
- Adopt a similar approach to OpenEJB where an SPI layer is defined
that
may be implemented by the containing process.
- An SPI to a DataSource/Connection provider (so that OpenJMS can
leverage
any pooling provided directly by the container - don't assume JNDI).
- An SPI to a transaction manager.

+1.

Whilst (i think) i was able to run-up the process i still got quite a
few Exceptions thrown (ie i don't provide a Log4J config).
I had to provide a <ServerConfiguration embeddedJNDI="true"/> entry
but my sense from the documentation was that this was 'implied by
default'

It is, but only if you are configuring OpenJMS via a XML
config file. If you are constructing a Configuration
instance, you need to provide it.

I had to provide a dummy <AdminConfiguration script="c:/freddy"/>
entry as this is required in the config.. but i had no use for it.

Yes. Strictly speaking, its not required for embedded servers, but is
required for standalone ones. I want to separate the administration GUI
into its own codebase - the AdminConfiguration element will probably be
removed from the server configuration when this is complete.