Is/Was there a way to specify EJB module library/Jars for Sun's AS8[12],
AS9[01] or Glassfish Servers within
the Sun/Glassfish Vendor Specific EJB deployment descriptor?
Was the use of the EJB jar manifest.mf file with some form of Class...
reference a proper way to specify
library Jars for EJB modules ?
thanks
gary
On 7/7/2011 6:18 PM, Hong Zhang wrote:
> Hi, Gary
>> please see http://netbeans.org/bugzilla/show_bug.cgi?id=195385
>> for history of this question on netbeans.
>>
>> Question --
>>
>> how are utility class jars suppose to be packaged in EJB modules, and
>> EAR modules ?
> The only portable way defined by the spec is through the ear lib
> libraries. However, I agree it's not desirable to have to create an
> ear to just include library jars for a standalone ejb module. The
> standalone ejb module should have a spec defined way to include the
> library jars just like standalone war. This feedback was provided to
> the EJB spec lead around v3 time and the spec lead agreed this is
> something we should think about in the next version of the spec.
> Unfortunately he left Sun later. Though this feedback was later
> provided to the current EJB spec lead, it was probably too late to
> incorporate. We should file a EJB spec issue to make sure this issue
> gets looked at in the next version of the spec.
>> is there a standard way this should be done ? or is support for this
>> need outside of the EE[456] specs ?
>>
>> the spec defines meta files such as ejb-jar.xml and application.xml
>> -- but there have always been
>> vendor specific files such as sun-ejb-jar.xml, sun-application.xml,
>> and sun-web.xml -- are these
>> files the proper place for meta data outside of the JavaEE Spec for
>> additional meta data
>> needed to successfully deploy a deployable unit on different vendors
>> EE servers?
> Yes, different vendors have different vendor specific deployment
> descriptors to complement the standard deployment descriptors. For
> GlassFish, it's glassfish-*.xml (the sun-*.xml are still supported for
> backward compatibility). These files can be packaged inside the
> archive (same directory as its corresponding standard deployment
> descriptor) or packaged as a deployment plan jar outside of the archive.
>
> Thanks,
>
> - Hong
>