Tim,
Why is the annotation processor of ACC even looking for EJB annotations
and then logging messages when it finds them?
Sahoo
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?
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>