A bit of clarification...
I think Vince was reacting to the earlier reference to adding the
"whole" EJB JAR to the client's Class-Path, saying that there's no known
way to add a "part" of a JAR to a Class-Path so it's either all or
nothing when it comes to adding library JARs.
Restating Marina's question, from my perspective at last, would be this:
Would NB automatically add the EJB module JAR to the client's
Class-Path?
Vince, the underlying point in the issue Marina pointed to is that a
sample app has the app client JAR referring directly to an EJB module.
In general, this technique gives a client visibility to the EJB
interface(s), which is all it should really need, but it also lets the
client see classes it should not see: the EJB implementation classes for
one thing. In particular, there is annotation processing that involves
the client and which must include JARs which the client references. In
this example there are annos in the EJB module which make no sense in
the client environment and that triggers log messages during anno
processing.
The better design we typically encourage is to collect the EJB interface
and any other shared bits into a library JAR on which both the client
and the EJB module can depend.
The main point of the question directed your way was to find out whether
NB automatically adds the EJB module to the client's Class-Path, for
example, if the developer adds annotated references to EJB.
Thanks.
- Tim
Marina Vatkina wrote:
> This causes this bug in v3:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(
>
> -marina
>
> vince kraemer wrote:
>> I am unaware of any method to add 'part' of a jar to a Class-Path in
>> the MANIFEST.MF
>>
>> vbk
>>
>> Marina Vatkina wrote:
>>
>>> Vince,
>>>
>>> Would NB add the whole EJB jar to the client's jar manifest?
>>>
>>> thanks,
>>> -marina
>>>
>>> Vince Kraemer wrote:
>>>
>>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>>
>>>>> [snip]
>>>>> My understanding was that the issue we're talking about only effects
>>>>> ear files. As I said above, I agree that having a way to set this
>>>>> property in the sun-application.xml file would be good.
>>>>>
>>>>> But I'm still interested in the details of when NetBeans packages jar
>>>>> files in the root of the ear file with the expectation that they'll
>>>>> be available to all modules in the ear file, and why the NetBeans
>>>>> developer who implemented it that way thought that was a good thing
>>>>> to do.
>>>>
>>>>
>>>>
>>>> I do not think NetBeans has ever packaged "jar files in the root of
>>>> the ear file with the expectation that they will be available to
>>>> all modules in the ear file".
>>>>
>>>> NetBeans has added Class-Path entries to the manifest of modules to
>>>> explicitly describe the references since NB 4.1, which shipped in
>>>> May 2005. That is the method described in J2EE 8.2, "Optional
>>>> Package Support". This method has also been described as part of
>>>> the spec for Java EE 5 and Java EE 6.
>>>>
>>>> vbk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>