Surely ACC can install appropriate annotation handlers to override the
behavior of annotation handlers used in server, can't it? I still don't
see how we can force users to package the app in one particular way.
Sahoo
Marina Vatkina wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>