On Apr 1, 2009, at 3:43 PM, Martin Uhlir wrote:
David Blevins wrote:
On Apr 1, 2009, at 1:24 PM, Martin Uhlir wrote:
assume, I have two (very similar) web applications (let's call
them A and B) which uses EJB as backend. The question is, how I
can achieve, that the application A stores its data to a database
SchemaA, while the application B stores its data to database
SchemaB, while both applications use the same EJB module (storing
the data from A and B is done via the EJB)? I want to avoid
running (developing) two EJB modules with the same functionality.
So is it somehow possible to achieve this just with some kind of
configuration or is there any other way how to solve this?
Note that the web applications will run on one server, while the
EJB on a different one.
Hi Martin,
No way to do this as far as I know. Even assuming you did
something very low level like wrapped the factory that creates the
DataSources so that the DataSource you create depends on some kind
of thread state which you set on in coming requests from webapp A
or B, it still would quickly fall apart due to things like
connection pooling.
Is there some kind of overhead to deploying the application twice
that you'd like to avoid? Note with the right descriptors you
wouldn't need to modify the code at all. Might be some features we
can add there to eliminate any concerns.
-David
Hello David,
thank you for quick reply. Well, first my thought was, that it could
save resources on the server, because I expect to have even more
these similar web applications, so it seemed a bit pointless to me
to have 10 times exactly the same EJB module deployed on the server.
Well, now arise a question, is it possible to deploy the same EJB
module (the same classes, same packages) 2 times, 3 times, ..., 10
times onto one server?
Absolutely.
Won't the server be "confused" to have more the same classes
deployed on it? How can then the client applications A, B, C etc.
differentiate which particular EJB module (with the suitable
configuration files to access the proper db) they want to work with?
The default settings for ensuring things like JNDI names are unique
are geared toward simpler style apps, but it's easy to reconfigure
things for this kind scenario.
Here are the properties in question along with their defaults:
openejb.deploymentId.format = {ejbName}
openejb.jndiname.format = {deploymentId}
{interfaceType.annotationName}
You can set these as system properties to this:
openejb.deploymentId.format = {moduleId}/{ejbName}
openejb.jndiname.format = {deploymentId}
{interfaceType.annotationName}
See http://openejb.apache.org/3.0/jndi-names.html
There are even clever ways to hide the fact that things are in
different sections in JNDI. For example, if you have code now that
looks like this:
Context context = new InitialContext(properties);
MyLocal myLocal = context.lookup("MyLocal");
You can cleverly change it as so:
Context context = new InitialContext(properties);
context = (Context) context.lookup("myModule");
// now just use the second context in all your code
...
MyLocal myLocal = context.lookup("MyLocal");
If there is some relationship between the webapp name and the ejb
module name, you could even get the lookup of the module part taken
care of in a generic way as well. This page shows some other
interesting ways to design things for neat lookup capabilities: http://openejb.apache.org/3.0/service-locator.html
Probably the most cumbersome part will be remapping the data source
references. With the current code you'll need an openejb-jar.xml file
to explicitly link each reference to the datasource you want for that
module, but maybe there is a way we can improve the auto-config code
to somehow incorporate the module name as one of the auto-linking
strategies.
-David
