Sahoo,
The problem is that it's correct to complain if @PersistenceContext in the Main
class, and we shouldn't log this at fine level, but somehow skip processing of
the classes that we are not suppose to be processing at that time (like @Stateless).
Regards,
-marina
Sahoo wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>