On 09/27/2010 10:30 AM, Hong Zhang wrote:
> Hi, Jerome
>> well, it is certainly one way of understanding the spec. However, I
>> have to say that the fact we offer a --library is merely a glassfish
>> specific feature to avoid repackaging jars in multiple applications.
>> So it seems to me that we could very well classify the --libraries as
>> a reference (like a class-path attribute).
>>
>> I am not sure what you meant by unpractical but it is also obvious
>> that scanning --librairies jars which are loaded by a shared class
>> loader can lead to multiple issues, in particular, but not limited to :
>> - usage a global jndi name
>> - leakage between applications.
>> - static fields
> I was thinking the installed library jars more generally, for example
> the library jars installed in the domains/domain/lib directory. I
> don't think we want to scan all those jars for annotations as well?
> I guess we could treat the installed library jars specified through
> the --libraries option differently from the other installed libraries.
>> Having said that, there could be legitimate use of components inside
>> libraries referenced through --library. Maybe we should have a
>> flag/property at deployment to offer more flexibility to this
>> glassfish extension ?
> Yes, a flag/property sounds good. Will this flag/property only be used
> to turn off annotation processing for the installed library jars
> through --libraries or it will be used to turn off the annotation
> processing from the bundled libraries as well?
right, I think that we have so far treated domains/domain/lib and
--libraries as pure java libraries versus component libraries (which
would force annotation processing). I think it's worth spending some
time thinking if we need to either introduce :
- a flag to treat --libraries as component libraries
- a parameter to the deploy command --componentlibraries to
disambiguate
and should we apply such feature to the domains/domain/lib directory.
you might want to come up with a small proposal with appropriate
alternatives to asarch. My inclination would be to not touch
domains/domain/lib behaviour and add a --componentlibraries style of
parameter but it's worth the debate.
jerome
>
> Thanks,
>
> - Hong
>
>>
>>
>> On 09/27/2010 09:35 AM, Hong Zhang wrote:
>>> Hi, Sahoo
>>>
>>> Based on the EE spec, we only need to scan the annotations for the
>>> classes inside the application package. It will be impractical to
>>> scan all the classes on the classpath.
>>>
>>> EE.8.5.1Deploying a Stand-Alone Java EE Module
>>> 2. If the deployment descriptor is absent, or is present and is a
>>> Java EE 5 version descriptor and the metadata-complete attribute is
>>> not set to true, the deployment tool must examine all the class
>>> files in the application package.
>>>
>>> EE.8.5.2Deploying a Java EE Application
>>> 4. If the module deployment descriptor is absent, or is present and
>>> is a Java EE 5 or later version descriptor and the metadata-complete
>>> attribute is not set to true, the deployment tool must examine all
>>> the class files in the application package that can be used by the
>>> module (that is, all class files that are included in the .ear file
>>> and can be referenced by the module, such as the class files
>>> included in the module itself, class files referenced from the
>>> module by use of a Class-Path reference, class files included in the
>>> library directory, etc.).
>>>
>>> Thanks,
>>>
>>> - Hong
>>>
>>> On 9/27/2010 12:18 PM, Sanjeeb Sahoo wrote:
>>>> Are libraries mentioned via --libraries not parsed for annotations?
>>>> They must be, else it's a bug.
>>>>
>>>> Sahoo
>>>> On Monday 27 September 2010 08:56 PM, glassfish_at_javadesktop.org wrote:
>>>>> This parsing is for scanning annotations inside the library jars.
>>>>> No, there is currently no option to disable the parsing of the
>>>>> library jars. If your archive needs to reference a lot of library
>>>>> jars and you want to avoid parsing of these library jars, you
>>>>> could reference these library jars through the --libraries option
>>>>> instead of packagin them inside the archive.
>>>>> [Message sent by forum member 'hzhang_jn']
>>>>>
>>>>> http://forums.java.net/jive/thread.jspa?messageID=483780
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>