Unfortunately your test project does not reproduce your problem. I was able to get your example working simply by tweaking the ear project pom and fixing the JNDI names that you use.

{code:xml}         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-ear-plugin</artifactId>
            <version>2.7</version>
            <configuration>
               <version>6</version>
               <defaultLibBundleDir>lib</defaultLibBundleDir>
               <skinnyWars>true</skinnyWars>
               <modules>
                  <webModule>
                     <groupId>de.zeb.edu</groupId>
                     <artifactId>ejb3.war</artifactId>
                     <bundleFileName>ejb3.war.war</bundleFileName>
                     <contextRoot>/ejb3</contextRoot>
                  </webModule>
                  <ejbModule>
                     <groupId>de.zeb.edu</groupId>
                     <artifactId>ejb3.server</artifactId>
                     <bundleFileName>ejb3.server.jar</bundleFileName>
                  </ejbModule>
               </modules>
            </configuration>
         </plugin>{code}
 

and

{code:java}    private final static String JNDI_LOCAL  = "java:global/ejb3.ear/ejb3.server/BrainBean";
    private final static String JNDI_REMOTE = "java:global/ejb3.ear/ejb3.server/BrainBean!de.zeb.edu.ejb3.api.BrainBeanRemote";{code}
 

A couple of things to note:

1. setting the bundleFileName in each module gets rid of version numbers from your JNDI names
2. ejb3.api and joda-time are not jarModules. A jarModule is for standalone ejb client applications, not library jars

The "ear" files in the zip do not contain META-INF/application.xml files. So I don't think they are valid to start with.

Secondly, your two "ear" files will be loaded into isolated class loaders. Classes in one EAR are not made available to the other EAR.

swoeste wrote:

 

Hi,

 

on our test systems it starts without any problems and runs into the problem as descripted above.

 

...

Doesn't that statement contradict itself?

Your EAR files are not well formed.

Stephen Coy wrote:

 

The "ear" files in the zip do not contain META-INF/application.xml files. So I don't think they are valid to start with.

 

 

Just a FYI - JavaEE6 doesn't mandate the presence of application.xml files. It's optional.

jaikiran pai wrote:

 

Just a FYI - JavaEE6 doesn't mandate the presence of application.xml files. It's optional.

I thought that was the case, and then couldn't find the reference.

EE.8.1.2 says:

A Java EE application may consist of one or more Java EE modules and one Java EE application deployment descriptor.

which I've misinsterpreted.

EE.8.4.1 goes on to say:

(Optional) Create an XML deployment descriptor for the application. The deployment descriptor must be named application.xml...

Can't win em all I guess.

Sebastian, I will investigate further.

Sebastian,

I agree there's something wrong here. Are you experiencing this problem only with joda-time parameters or are there other types causing problems?

At the moment I suspect that the code that is marshalling the remote call is somehow picking up the org.joda.time.DateTimeZone class from the JBoss modules at some point, but it might not be because it's cloning objects and classes all over the shop.

I'm still chasing it down for my own edification right now.

(I've been testing on a week old trunk btw)

Based upon your sample I have constructed a maven project that demonstrates the issue. This makes it a bit easier to debug because the source is available for the client and server sides. Code is attached to AS7-4984

With a bit of luck I'll get a chance to do some debugging at the weekend.

Can you try again with jboss-marshalling 1.3.15.GA? This version works for me.