Sahoo wrote:
> Surely ACC can install appropriate annotation handlers to override the
> behavior of annotation handlers used in server, can't it?
The issue is not about on anno handling in the ACC; the issue regards
anno handling during deployment although some of the same questions can
arise with anno handling in the ACC.
If you look at the code you'll see that the implemented handlers are
already sensitive to the context in which the scanning occurs - for
instance, whether the scanning starts from an app client module vs. an
EJB module vs. something else. I think part of the problem is that the
scanners do not seem to distinguish between processing the original
module from processing JARs referenced by the module's Class-Path or
JARs in the EAR's library directory (or the transitive closure of those).
I think there is broad agreement that it's not working the way we want;
it's a question of deciding the best way to repair it.
> I still don't see how we can force users to package the app in one
> particular way.
I don't think anyone suggested that. If you're thinking about my note
to Vince earlier, I described an approach that's probably better from a
design and information hiding point of view. I did not say we should
impose that or any approach on users.
- Tim
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>