InstanceAlreadyExistsException

[dsilcox69]

I am attempting to re-deploy an existing .ear file using a new context so that I can access via /firstinstance and /secondinstance on the same jboss server.

So far I am only changing the application.xml file...


<display-name>firstinstance</display-name>
firstinstance

firstinstance_ejb.jar



<web-uri>firstinstance.war</web-uri>
<context-root>/firstinstance</context-root>





<display-name>nextinstance</display-name>
nextinstance

nextinstance_ejb.jar



<web-uri>nextinstance.war</web-uri>
<context-root>/nextinstance</context-root>




Other than rebuilding the application using different names, all other deployment descriptors are the same.

I have successfully re-deployed the web portion of the app by commenting out the tags but am receiving the InstanceAlreadyExistsException on the ejb's.

Is it possible to re-deploy the same app twice? Which configuration files am I failing to change?

[adrian.brock]

Change the jndi names.

Regards,
Adrian

[dsilcox69]

Thanks for the reply. I was afraid someone was going to say that. Changing jndi names requires code changes each time the app is re-deployed and that is not an acceptable solution.

The problem here is that the jndi names for the EJB's are bound to the global context and not the application context. I wish I knew how to bind them differently...

There should never be any interaction between objects contained in seperate .ear deployments. I know from loads of experience that this is the case with .war files and believe the .ear spec has the same intent.

I'll submit as a bug to try to get resolution.

[juha]

you always look up from the private java:comp/env naming space, not from the global name space, there's no code changes involved, just changes in the descriptors

see the documentation of <ejb-ref> and <jndi-name> tags from ejb-jar.dtd and jboss.dtd

[dsilcox69]

Thanks Juha...that hit the spot. Posting the solution...

---------------------------------------------------------------------------------
Bad Dan...(before)

ejb-jar.xml
<ejb-jar>
<enterprise-beans>

<ejb-name>MySessionBean</ejb-name>
.
.

</enterprise-beans>
</ejb-jar>

jboss.xml

<enterprise-beans>

<ejb-name>MySessionBean</ejb-name
<jndi-name>MySessionBean</jndi-name>
.
.
.
java code...
InitialContext context = new InitialContext();
MySessionBeanHome home = (MySessionBeanHome) context.lookup("MySessionBean");

---------------------------------------------------------------------------------
Good Dan....(after)
Bad Dan...
ejb-jar.xml
<ejb-jar>
<enterprise-beans>

<ejb-name>MySessionBean</ejb-name>
<ejb-ref>
Use this reference to lookup instead
<ejb-ref-name>ejb/MySessionBean_InternalReference</ejb-ref-name>
<!-- not that I would really name it this way -->
<ejb-ref-type>Session</ejb-ref-type>
.
.

jboss.xml

<enterprise-beans>

<ejb-name>MySessionBean</ejb-name
<jndi-name>context1_MySessionBean</jndi-name>
<!-- I plan to start always adding the context to the jndi name here. -->
.
.
.

java code...
InitialContext context = new InitialContext();
MySessionBeanHome home = (MySessionBeanHome) context.lookup("java:comp/env/ejb/MySessionBean_InternalReference");

If you are accessing from the web layer inside the same vm you can cut and paste the <ejb-ref> from ejb-jar.xml into web.xml
and access via the same code.
------------------------------------------------------------------------------------.

Now to re-deploy the ear under a seperate context all you have to change is the jndi names in jboss.xml in addition to the changes to application.xml already noted.
jboss.xml

<enterprise-beans>

<ejb-name>MySessionBean</ejb-name
<jndi-name>context2_MySessionBean</jndi-name>

.
.

[sverker]

I've been searching the forums on this issue as I have a couple of applications packed in .ear files which shares some common ejb's but which needs to run with different configurations. I'm using xdoclet to generate the ejb deployment desctiptors from the source code so having to manually go through and edit the jboss.xml deployment descriptors would be a lot of work.

Obviously if I try to deploy two of my ear's into the same jboss instance I get an InstanceAlreadyExsistsException because the first deployed has already bound to the name in the global namespace. I find this behaviour and the solution to manualy having to prefix the name with the instance wrong, it should either be prefixed automatically with the name of the .ear or at least there should be an option to set jndi-context in the jboss-app.xml file that is prefixed automatically to all jndi names in the .ear-file.

Since Jboss 3.0 there is a possibility to use the loader-repository tag to handle the classloading issue on deployment of different versions of an ejb in different .ear's but the jndi global namespace problem prevents different versions of the same .ear packaged application to run side by side.

I saw someone mentioning that Orion handles this issue properly eventhough I haven't had the opportunity to test it myself.

Have I missunderstood it or is this really the way things should work? I would be happy to assist in resolving the problem if someone can help pointing me in the right direction since as it works today it prevents me from running JBoss for real applications.

[sverker]

I've been searching the forums on this issue as I have a couple of applications packed in .ear files which shares some common ejb's but which needs to run with different configurations. I'm using xdoclet to generate the ejb deployment desctiptors from the source code so having to manually go through and edit the jboss.xml deployment descriptors would be a lot of work.

Obviously if I try to deploy two of my ear's into the same jboss instance I get an InstanceAlreadyExsistsException because the first deployed has already bound to the name in the global namespace. I find this behaviour and the solution to manualy having to prefix the name with the instance wrong, it should either be prefixed automatically with the name of the .ear or at least there should be an option to set jndi-context in the jboss-app.xml file that is prefixed automatically to all jndi names in the .ear-file.

Since Jboss 3.0 there is a possibility to use the loader-repository tag to handle the classloading issue on deployment of different versions of an ejb in different .ear's but the jndi global namespace problem prevents different versions of the same .ear packaged application to run side by side.

I saw someone mentioning that Orion handles this issue properly eventhough I haven't had the opportunity to test it myself.

Have I missunderstood it or is this really the way things should work? I would be happy to assist in resolving the problem if someone can help pointing me in the right direction since as it works today it prevents me from running JBoss for real applications.

[sverker]

I'm sorry if this message appears multiple times. For some reason it doesn't appear. New try:

I've been searching the forums on this issue as I have a couple of applications packed in .ear files which shares some common ejb's but which needs to run with different configurations. I'm using xdoclet to generate the ejb deployment desctiptors from the source code so having to manually go through and edit the jboss.xml deployment descriptors would be a lot of work.

Obviously if I try to deploy two of my ear's into the same jboss instance I get an InstanceAlreadyExsistsException because the first deployed has already bound to the name in the global namespace. I find this behaviour and the solution to manualy having to prefix the name with the instance wrong, it should either be prefixed automatically with the name of the .ear or at least there should be an option to set jndi-context in the jboss-app.xml file that is prefixed automatically to all jndi names in the .ear-file.

Since Jboss 3.0 there is a possibility to use the loader-repository tag to handle the classloading issue on deployment of different versions of an ejb in different .ear's but the jndi global namespace problem prevents different versions of the same .ear packaged application to run side by side.

I saw someone mentioning that Orion handles this issue properly eventhough I haven't had the opportunity to test it myself.

Have I missunderstood it or is this really the way things should work? I would be happy to assist in resolving the problem if someone can help pointing me in the right direction since as it works today it prevents me from running JBoss for real applications.

[sverker]

I've been searching the forums on this issue as I have a couple of applications packed in .ear files which shares some common ejb's but which needs to run with different configurations. I'm using xdoclet to generate the ejb deployment desctiptors from the source code so having to manually go through and edit the jboss.xml deployment descriptors would be a lot of work.

Obviously if I try to deploy two of my ear's into the same jboss instance I get an InstanceAlreadyExsistsException because the first deployed has already bound to the name in the global namespace. I find this behaviour and the solution to manualy having to prefix the name with the instance wrong, it should either be prefixed automatically with the name of the .ear or at least there should be an option to set jndi-context in the jboss-app.xml file that is prefixed automatically to all jndi names in the .ear-file.

Since Jboss 3.0 there is a possibility to use the loader-repository tag to handle the classloading issue on deployment of different versions of an ejb in different .ear's but the jndi global namespace problem prevents different versions of the same .ear packaged application to run side by side.

I saw someone mentioning that Orion handles this issue properly eventhough I haven't had the opportunity to test it myself.

Have I missunderstood it or is this really the way things should work? I would be happy to assist in resolving the problem if someone can help pointing me in the right direction since as it works today it prevents me from running JBoss for real applications.