JBoss removes JAR files when deploying EAR file

[aqtwrdnr]

I recently migrated from JBoss EAR 6.4.0 to 7.0.0. In my deployments folder, I have an EAR containing numerous JAR files of my project. When I unpack the file after building, all files are there as desired. They are also listed in the application.xml file as EJB modules.

But as soon as I start the server and the EAR file gets unpacked by JBoss, a couple of my project JARs vanish. The files are simply removed, so my server starts incompletely and my EJB client cannot connect ("No EJB receiver for handling...").

Is there any 'smart' mechanism in JBoss that may cause this behaviour?

My colleagues are working on the same project (but different IDE) with no problems.

[andey]

Hi,

What is the exception stack trace? paste it full exception stack trace.

[aqtwrdnr]

There is no exception, the server even starts up, but my JAR files vanish.

I even checked with a tool that monitors file creation and deletion in the deployments directory.

1. When I deploy, there is a EAR file that contains about 70 JAR files.

2. Now I start the server and a fraction of the JAR files are extracted.

3. A huge number of my JAR files does not even get unpacked, however. They are simply gone, even though they were part of the EAR file.

In the JBoss startup procedure, my files are not named once. Not even as part of any error message.

Where do they go?

// Edit: Started JBoss with DEBUG log level now and got a lot of these messages:

> Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address...

Don't know how to cope with them, though. Simply increasing the timeout does not help. The question is, why does it take so long in the first place?

// Edit 2: I've tried both, starting JBoss from Eclipse and in command line.

So deleting all breakpoints and not using debug mode, as suggested on StackOverflow, cannot be applied in my case.

[ctomc]

antivirus/antimalware software?

[aqtwrdnr]

We are running TrendMicro Office Scan.

But what strikes me is that my JAR files are not even mentioned in the log, when JBoss starts up. And as I said before, they get lost when the EAR is extracted to the file system (even though they were present within the EAR file after building). I monitored the deployments directory with a tool, but the JARs never get created when unpacking the EAR.

Is there a dedicated trigger to increase the log level of the deployment scanner / deployment phase? The JBoss log is not much of a help for me, even in TRACE mode. The name of my "lost" JARs does never appear in the console or server.log.

[andey]

>>No EJB receiver for handling...").

It can have several issues :

- connection: Connection broken

- security : user/pass invalid

- EJB missing: connected, but ejb is not there

- SSL

The EJBClientContext will keep all available receiver in a Map where the servers name is the key.

If there is more than one server with the same name these entries will be lost.

If it is inside of a server instance this instance will be preferred and all other instances with the same server name are hidden. It might be in this case no EJB will be accessible which is only available on such server.

The underlying ejb-client will be destroyed and close the connections if close() is called at the created InitialContext or, shown in the given code example, if the Context is destroyed from GC. This will call finialize and close connections and remove the EJBClientContext.

As there is no direct control, if and when the GarbageCollector runs, it will destroy the object. The client has no control over how long it will be able to invoke the server's business code, if the client has no reference to the InitialContext

Ensure that the jboss.node.name is unique for all instances.

The default is the machine name, so if you have two instances at the same physical system the name is not unique.

Use the ejb: protocol instead of remote: for the EJBs.

Or have the client hold a reference to the InitialContext object while the EJB proxies or UserTransaction are used and make sure you do not close the InitialContext object while EJB proxies or UserTransaction are being used.

If the connection is no longer needed, the InitialContext should be closed and the reference to it including all proxies should be set to NULL.

Note: It is recommended that you use the ejb-client library or the jboss-ejb-client.properties to have all the functionality for the ejb client.

https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI

https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+server+instance

[aqtwrdnr]

In my case, the EJBs are missing. They are packaged in the EAR file, but on server start-up they get lost.

I figured out, there is a pom.xml file in my META-INF directory and all entries that "get lost" have a systemPath set:

<systemPath>${foo.server}FooBar.jar</systemPath>

The foo.server variable ultimately leads to project.basedir. Maybe Maven uses a wrong path and the files are put somewhere in my file system, instead of the JBoss deployment directory?

Does anybody know how Maven is involved in the JBoss deployment process? Do I have to set additial environment variables?

With JBoss 6.4 my current setup works fine, there is no version-specific env variable set to JBoss 6.4 neither.

[ctomc]

aqtwrdnr aqtwrdnr wrote:

<systemPath>${foo.server}FooBar.jar</systemPath>

The foo.server variable ultimately leads to project.basedir. Maybe Maven uses a wrong path and the files are put somewhere in my file system, instead of the JBoss deployment directory?

Quite possibly. Using systemPath is always problematic.

aqtwrdnr aqtwrdnr wrote:

Does anybody know how Maven is involved in the JBoss deployment process?

It is *not*.