On 10/29/09 14:09, Tim Quinn wrote:
> 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?
Yes. NetBeans did do that until recently. It has done that for about 4
years. This is the first time that this issue has been raised.
Note: NB has also supported other J2EE and Java EE servers over that
time... and the J2EE and Java EE developers that target those servers
have not complained of difficulties in this area.
>
> 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.
OK. It seems like more work for very little payoff. I am not sure
developers will like restructuring their apps to create a three jars for
two logical modules... even if an IDE does it for them.
> 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