You should be able to do the same with EJBs. In GF, you would need to
disable non-portable GF-specific JNDI names (which use class names) in
glassfish-ejb-jar.xml:
<glassfish-ejb-jar>
<disable-nonportable-jndi-names>true</disable-nonportable-jndi-names>
</glassfish-ejb-jar>
-marina
On 5/4/13 3:52 PM, Witold Szczerba wrote:
> Hi,
> I am thinking about the subject of installing one JEE application
> multiple times in one server. An example would be to deploy 3 times:
> myapp-dev, myapp-test and myapp-demo. First one would be used by CI on
> every commit, to build, test, deploy, e2e. Second instance would be
> for our testers, they will decide when to deploy. Third one for our
> customer, so they can test it and give us feedback.
>
> As of now I am developing on TomEE and I failed to achieve this goal.
> I have ended up setting 3 distinct TomEE instances, it is pain and
> very inconvenient.
>
> This is all trivial when using Spring, because Spring apps lives their
> own lives on application server. They do have their own isolated
> contexts, they manage database connection pools, etc. When developing
> JEE application, this is not the case any more. For example, there is
> a datasource configuration in application server. One configures
> jdbc/myapp in app server and then reference it everywhere using
> @Resource(nape="jdbc/myapp"). This is cool sometimes, for example,
> when application is spread across several, separated modules/webapps,
> they all share single datasource. But what if I would like to start
> another instance, like app-demo? As far as I know, each AS has its own
> solutions for this (or does not have working solution). Glassfish has
> glassfish-web.xml file, which can include this:
>
> <resource-ref>
> <res-ref-name>jdbc/myapp</res-ref-name>
> <jndi-name>jdbc/myapp-demo</jndi-name>
> </resource-ref>
>
> Myapp-dev will have this file with:
> <resource-ref>
> <res-ref-name>jdbc/myapp</res-ref-name>
> <jndi-name>jdbc/myapp-dev</jndi-name>
> </resource-ref>
>
> So the same code with @Resource annotation will refer to
> jdbc/myapp-dev for development build and jdbc/myapp-demo for demo
> build.
>
> I did never test it though. Am I correct with the above? What about
> other JNDI stuff, like bean names? Are they going to register
> themselves in distinct locations for each application instance? How is
> it going to work when BeanOne injects BeanTwo, both of them registered
> three times by three instances of the same application?
>
> Do I need to prepare my app for this scenario or everything (expect
> for the resource-ref described above) will work out-of-the-box?
>
> Thanks in advance, for any hints, tips and tricks,
> Witold Szczerba
>
> On 17 April 2013 00:04, Kevin Schmidt <kevin_at_nextgate.com> wrote:
>> You can deploy the same WAR file multiple times with different names/context
>> roots to accomplish what you want. You would need to do something like
>> having the application look at its name/context root to load a different set
>> of properties or use a different data source name to connect to the
>> different database, but that is very straight forward.
>>
>> Note that this does in fact deploy the same code twice though. If you want
>> only a single deploy but to use multiple backend databases, you may just
>> need to make your app multi-tenant and have the logic in your code to
>> connect to different databases based on the user.
>>
>> From: Blake McBride <blake_at_arahant.com>
>> Reply-To: "users_at_glassfish.java.net" <users_at_glassfish.java.net>
>> Date: Tue, 16 Apr 2013 14:38:13 -0700
>> To: "users_at_glassfish.java.net" <users_at_glassfish.java.net>
>> Subject: Can I run multiple instances of one application
>>
>> Greetings,
>>
>> I have a web application that connects to a single database and serves X
>> number of simultaneous users without a problem.
>>
>> I would like to start up another instance of the same application that would
>> connect to a different database and serve Y simultaneous users from a
>> different URL.
>>
>> If this is possible with glassfish, presumably it would be able to use a
>> single copy of the code base with independent and isolated data spaces.
>>
>> All the applications instances (for now) would be run on the same machine.
>>
>> I know I can just copy the application code, reconfigure for another
>> database, and boot it as a separate application. The point is not have to
>> have multiple copies of the application on the disk or in memory. The only
>> things different between the instances would be the database it points to,
>> the URL to access it, and the memory it takes to support the runtime data.
>>
>> I need this because the application is very large (15,000+ classes). I want
>> to achieve the ability of creating many independent instances running
>> without the need to have multiple copies of the code both on disk and in
>> memory.
>>
>> Thanks.
>>
>> Blake McBride
>>
>>