tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: 2 web apps - 1 ejb - 2 db?
Date Thu, 02 Apr 2009 02:46:33 GMT

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


Mime
View raw message