Ejb clients are not included in the generated application.xml - JavaModule is confusing

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0, 2.1, 2.2
  • Fix Version/s: 2.3
  • Labels:
    None

Description

EJB clients are specified in an application.xml via

<module><java>pathTo.jar</java></module>

However the tests that use the "javaModule" element, do not generate the above entry as they should. In general the support for this is broken. Any jar with a "META-INF/application-client.xml" file should be added to the application.xml unless it is explicitly excluded via a <javaModule> entry with the <exclude>true</exclude> tag.

  1. Text File
    corrected-tests.patch
    05/Nov/06 6:47 PM
    2 kB
    David Blevins
  2. Text File
    usage.patch
    06/Nov/06 2:47 PM
    1.0 kB
    David Blevins

Issue Links

is depended upon by

New Feature - A new feature of the product, which has yet to be developed. MEAR-137 Support for JEE Application Clients

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MEAR-53 ejb-client dependencies should not be treated as J2EE application client modules

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

New Feature - A new feature of the product, which has yet to be developed. MEAR-40 Autodetect "Client Application" modules and "EJB3" modules.

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stéphane Nicoll added a comment -

Your patch makes no sense. Those are 3rd party libs, not ejb-clients

NOTE: ejb-clients have their own type "ejb-client". So nothing is broken. If you have an ejb-client artifact, name it properly.

Show
Stéphane Nicoll added a comment - Your patch makes no sense. Those are 3rd party libs, not ejb-clients NOTE: ejb-clients have their own type "ejb-client". So nothing is broken. If you have an ejb-client artifact, name it properly.
Hide
Permalink
David Blevins added a comment -

Hi Stephane,

I'm not sure I follow you. There is no "ejb-client" element in an application.xml. The <module><java></java></module> in an application.xml is for application clients (aka ejb clients). Are you saying you understand this but the plugin likes to use it's <javaModule> tag to deal with third party libs or are you saying something else?

Show
David Blevins added a comment - Hi Stephane, I'm not sure I follow you. There is no "ejb-client" element in an application.xml. The <module><java></java></module> in an application.xml is for application clients (aka ejb clients). Are you saying you understand this but the plugin likes to use it's <javaModule> tag to deal with third party libs or are you saying something else?
Hide
Permalink
Stéphane Nicoll added a comment -

Hi David,

Well. Let's take it the other way around.

The <module><java></java></module> in an application.xml is for application clients (aka ejb clients)

True but you are misunderstanding maven artifact's types and Ear module's types. At first, JavaModule was linked to the "jar" maven's artifact type and is subclassed by the EjbClientModule which is linked to the "ejb-client" maven's artifact type.

Some application servers such as JBoss allows to define 3rd party libs within a <java> module element. Even if it's not in the spec, lots of users are using it as a convenience method to handle EAR dependencies. It's disabled by default.

As a summary:

  • If you have an ejb-client, make it an ejb-client artifact (see the EJB plugin). If your dependency has type 'ejb-client' the EAR plugin will recognize it automatically and inject a <java> module element in the generated application.xml
  • JavaModule are the base class for any "jar" library
  • Regarding pure application clients (i.e. jar file with a META-INF/client-application.xml), there is a request to add extra logic in the EAR plugin so that it recognizes it out-of-the box (MEAR-40)

Your patch makes no sense because the dependencies are 3rd party libs, not ejb-clients. I will add an extra test right now to show you the difference with an ejb-client.

Show
Stéphane Nicoll added a comment - Hi David, Well. Let's take it the other way around.
The <module><java></java></module> in an application.xml is for application clients (aka ejb clients)
True but you are misunderstanding maven artifact's types and Ear module's types. At first, JavaModule was linked to the "jar" maven's artifact type and is subclassed by the EjbClientModule which is linked to the "ejb-client" maven's artifact type. Some application servers such as JBoss allows to define 3rd party libs within a <java> module element. Even if it's not in the spec, lots of users are using it as a convenience method to handle EAR dependencies. It's disabled by default. As a summary:
  • If you have an ejb-client, make it an ejb-client artifact (see the EJB plugin). If your dependency has type 'ejb-client' the EAR plugin will recognize it automatically and inject a <java> module element in the generated application.xml
  • JavaModule are the base class for any "jar" library
  • Regarding pure application clients (i.e. jar file with a META-INF/client-application.xml), there is a request to add extra logic in the EAR plugin so that it recognizes it out-of-the box (MEAR-40)
Your patch makes no sense because the dependencies are 3rd party libs, not ejb-clients. I will add an extra test right now to show you the difference with an ejb-client.
Hide
Permalink
Stéphane Nicoll added a comment -

Holy s****, I found a bug

Show
Stéphane Nicoll added a comment - Holy s****, I found a bug
Hide
Permalink
David Blevins added a comment -

Fair enough. I personally think it's a bit odd that the default behavior of the javaModule isn't to create a <module><java> element, but likely most people don't have j2ee application clients.

I've updated the doc to try and make it more clear that <javaModule> != <module><java>. It said something to this affect about jar dependencies and based on what you've explained that makes perfect sense now, but at the time it wasn't clear that you were favoring <javaModule> to refer to any dep of type jar ("java" isn't an artifact type after all so you can see the confusion). Strictly speaking, even the JavaModule.java is commented as being for j2ee application clients, but I get the duality of the <javaModule> usage you talk about.

One last fyi, it seems that the way the code is now even artifacts of type ejb-client will not be included in the application.xml buy default either.

Show
David Blevins added a comment - Fair enough. I personally think it's a bit odd that the default behavior of the javaModule isn't to create a <module><java> element, but likely most people don't have j2ee application clients. I've updated the doc to try and make it more clear that <javaModule> != <module><java>. It said something to this affect about jar dependencies and based on what you've explained that makes perfect sense now, but at the time it wasn't clear that you were favoring <javaModule> to refer to any dep of type jar ("java" isn't an artifact type after all so you can see the confusion). Strictly speaking, even the JavaModule.java is commented as being for j2ee application clients, but I get the duality of the <javaModule> usage you talk about. One last fyi, it seems that the way the code is now even artifacts of type ejb-client will not be included in the application.xml buy default either.
Hide
Permalink
David Blevins added a comment -

Sorry, didn't see your comment, thought it was just me holding this open.

Show
David Blevins added a comment - Sorry, didn't see your comment, thought it was just me holding this open.
Hide
Permalink
Stéphane Nicoll added a comment -

HEY, wait a minute, I am fixing it

Show
Stéphane Nicoll added a comment - HEY, wait a minute, I am fixing it
Hide
Permalink
Stéphane Nicoll added a comment -

And you're right regarding "JavaModule" it's really a weird behavior.

I'll deprecate it. What about renaming it to "JarModule". Does it sound better?

Show
Stéphane Nicoll added a comment - And you're right regarding "JavaModule" it's really a weird behavior. I'll deprecate it. What about renaming it to "JarModule". Does it sound better?
Hide
Permalink
Stéphane Nicoll added a comment -

Voila, it's done.

JavaModule has been renamed to JarModule, defaultJavaBundleDir to defaultLibDir. Updated documentation, tests, etc.

snapshot deployed on the snapshot repository.

Show
Stéphane Nicoll added a comment - Voila, it's done. JavaModule has been renamed to JarModule, defaultJavaBundleDir to defaultLibDir. Updated documentation, tests, etc. snapshot deployed on the snapshot repository.

People

  • Assignee:
    Stéphane Nicoll
    Reporter:
    David Blevins
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: