Sorry, wrong, once more. ;-) The J2EE specification says that an EAR contains not only EJB, WAR, RAR and other modules, but also one or more Client Application Modules. When deploying the EAR on the server, it's the server's job to publish the client to the client machines. For example, SAS9 is using JNLP / WebStart to support this demand.
I want the EAR plugin to detect that a dependency is not an EJB, WAR or
RAR but such a Client Application Module (by inspecting whether the JAR
contains a /META-INF/application-client.xml file). Such a JAR is not
only to be contained in the EAR (is it is as any JAR is), but also add
an <java>xyz.jar</java> entry to the automatically generated
application.xml file that the EAR plugin creates and puts into the EAR
(as it does it with EJB, WAR or RAR modules already). In fact from the
view of the J2EE 1.4 specification, a client-application JAR is to be
treated as an EJB, WAR or RAR is treated: Detect that it is a module,
detect the type of the module, contain it in the EAR, add an entry to
the application.xml file. Everything is done by the EAR plugin correctly
but not the last step: The EAR plugin currently detects the type of
module (it needs to know the type to know what to write into the
application.xml) by mapping file extensions to module types. For EJB,
WAR or RAR this is sufficient. But to support client applications, the
EAR plugin must learn to differenciate between utility JARs and client
application JARs (since both share the extension of ".jar", so the type
detection is not possible).
To learn this, the work is easy: For each .jar file found in the
dependencies that is to be added to the EAR, check whether there is a
file called "/META-INF/application-client.xml" found inside of that JAR.
If true, the type of this jar is not "JAR" but "application-client", and
such an entry to the EAR's automatically generated application.xml file
has to be added using the "<java>" type of <module> tag. That's all to
be found inside of the J2EE specification, most of it in chapter 9, but
also in the chapter on the application.xml schema (look at the
declaration of <module> and you will find <java>).
So actually the EAR plugin can be extended to support this essential
part of J2EE 1.4 within one or two code lines. Can anybody please add
that? :-)
Thanks!
Markus
Alexander Sack wrote:
> I stand corrected. Never used this feature.
>
> Alright, but from reading the 1.4 spec, it seems that this jar is
> deployed
> outside the app server as a CLIENT. The client application.xml file is
> deployed within a JAR a read by another container than your main EAR
> application, no? So what do you expect the EAR plugin to do exactly?
>
> -aps
>
> On 9/16/06, Markus KARG <[EMAIL PROTECTED]> wrote:
>>
>> Alexander,
>>
>> please read J2EE 1.4 specification: The "J2EE Client Application
>> Descriptor" is a mandatory part of J2EE 1.4. It is no BEA invention.
>> Quoted from "Java(tm) 2 Platform Enterprise Edition Specification, v1.4"
>> chapter 9.7 "J2EE Application Client XML Schema":
>>
>> "J2EE.9.7 J2EE Application Client XML Schema
>> The XML grammar for a J2EE application client deployment descriptor is
>> defined
>> by the J2EE application-client schema. The root element of the
>> deployment
>> descriptor for an application client is application-client. The content
>> of the XML
>> elements is in general case sensitive. This means, for example, that
>> <res-
>> auth>Container</res-auth> must be used, rather than
>> <res-auth>container</
>> res-auth>.
>> All valid application-client deployment descriptors must conform to the
>> following XML Schema definition, or to a DTD definition from a previous
>> version
>> of this specification. (See Appendix J2EE.A, "Previous Version DTDs.")
>> The
>> deployment descriptor must be named META-INF/application-client.xml
>> in the
>> application client's .jar file. Note that this name is case-sensitive."
>>
>> So there is actually no room for interpretation. You might want to read
>> J2EE 1.4 spec chapter 9 "Application Clients".
>>
>> Markus
>>
>> Alexander Sack wrote:
>> > I'm pretty sure the "J2EE client application descriptor" you speak of
>> > is a
>> > BEA only primitive and not generic enough to be included in the EAR
>> > plugin
>> > (please correct me if I'm wrong, I don't remember ever seeing this in
>> the
>> > J2EE spec).
>> >
>> > With that said a light bult has sort of went off and perhaps the EAR
>> > plugin
>> > should have a PLATFORM identifier that can fine tune the packaging
>> > based on
>> > Java EE app server. As anyone who has worked with more than one app
>> > server
>> > knows, the spec has A LOT of room for interpretation and some
>> > platforms just
>> > aren't compliant (either they choose to be or are catching up).
>> >
>> > Good idea, bad idea?
>> >
>> > -aps
>> >
>> > On 9/15/06, Wayne Fay <[EMAIL PROTECTED]> wrote:
>> >>
>> >> If the current release of the EAR plugin does not support the
>> >> functionality you desire, you have a few options:
>> >>
>> >> 1. Complain about missing functionality on the Maven User list.
>> >> 2. File a JIRA Enhancement report and hope someone looks at your
>> issue
>> >> and decides it is worth spending some time to implement for you.
>> >> 3. Write the code yourself, then file a JIRA with your changes
>> >> attached and wait for it to be incorporated into the released code
>> >> which will take some time to actually land in a non-snapshot repo
>> >> (several weeks at a minimum).
>> >>
>> >> Pick one from above and do it. In the mean time, if you want
>> things to
>> >> work, you will need to be practical about things -- simply add the
>> >> entry into the application.xml (or whatever file, I'm not familiar
>> >> with J2EE Client Apps) manually or in the pom.xml and move on with
>> >> life.
>> >>
>> >> Wayne
>> >>
>> >> On 9/15/06, Markus KARG <[EMAIL PROTECTED]> wrote:
>> >> > No I do not mean ejb-client but "J2EE Client Application":
>> >> > What you mean is a JAR containing the interfaces of the EJBs, but
>> >> what I
>> >> > mean is a standalone ("Swing") application that is to be run inside
>> >> of a
>> >> > "J2EE Client Container".
>> >> >
>> >> > I have seen that EJB-JARs are enlistet in the EAR's application.xml
>> >> > automatically, and we want this to happen with the "J2EE Client
>> >> > Application" also, without adding it to the EAR's pom.xml manually.
>> >> This
>> >> > should be possible since a "J2EE Client Application" always
>> contains
>> a
>> >> > file named META-INF\client-application-xml, so the EAR task just
>> >> need to
>> >> > look into the JAR to find out about its type. I do not
>> understand why
>> >> > this has to be specified manually.
>> >> >
>> >> > Thanks
>> >> > Markus
>> >> >
>> >> > Stephane Nicoll schrieb:
>> >> >
>> >> > > you mean ejb-client? Your dependency should be 'ejb-client' not
>> >> 'jar'.
>> >> > >
>> >> > > Anyhow, if you want a jar to be included in the application.xml,
>> >> just
>> >> > > configure the plugin acccordingly (includeInApplicationXml) [1]
>> >> > >
>> >> > > Cheers,
>> >> > > Stéphane
>> >> > >
>> >> > > [1] http://maven.apache.org/plugins/maven-ear-plugin/howto.html
>> >> > >
>> >> > > On 9/15/06, Markus KARG <[EMAIL PROTECTED]> wrote:
>> >> > >
>> >> > >> I am using the EAR packaging to let Mvn2 create an .ear file
>> plus
>> >> > >> automatically create an application.xml inside of it.
>> >> > >> It detects all my EJB modules, but it doesn't detect that one of
>> >> the
>> >> > >> included JARs is not a utility JAR but in fact a "J2EE Client
>> >> > >> Application JAR".
>> >> > >> Maybe the packaging type I have used for that JAR is wrong (I
>> used
>> >> JAR
>> >> > >> since I thought the EAR packager will detect the contained
>> >> > >> client-application.xml file).
>> >> > >> So what is the correct way to specify "J2EE Client Application
>> JAR"
>> >> > >> packaging instead of simple utility "JAR" packaging?
>> >> > >>
>> >> > >> Thanks a lot!
>> >> > >> Markus
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>>
>>
>>
>>
>
>
smime.p7s
Description: S/MIME Cryptographic Signature
