Papaki Annotation Scanning Requirements

[Dimitris Andreadis-2]

Please edit the wiki page and add your annotation scanning requirements/usecases:

http://www.jboss.org/community/wiki/PapakiAnnotationScanningRequirements

"Annotation scanning has a considerable impact in AS deployment and boot time performance.
There are several subsystems that need to process annotations, for example EJB3, JCA, Web
Services, JBoss Web, JPA, Seam, etc. and that often results either in inefficient annotation
scanning implementations, extraneous classloading and multiple passes over the same jar files.

The goal of the Papaki project (formerly JBoss Annotations) is to unify annotation scanning,
so that it can be performed efficiently and in one pass, with the various subsystem pulling
annotation information from the Papaki service, thus improving deployment and boot times.

The purpose of this page is to collect requirements from all the projects that would be
interested in plugging into this service, so that we can come up with a comprehensive API
that can serve all the major use cases."
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[David M. Lloyd-3]

On 10/29/2009 02:39 PM, Dimitris Andreadis wrote:
> Please edit the wiki page and add your annotation scanning requirements/usecases:

Well, the good news is, this is just what we need to get started.  The bad
news is by calling it "the Papaki project (formerly JBoss Annotations)",
and asking people who would be interested in using this project, you're
already leaking implementation considerations into a purely requirements
doc. :-)

What this document should really say is, "What projects need to read
annotation data, scan annotations to determine deployment information, or
in any other way use annotations at compile time OR run time, and what
exactly are the requirements for each project?"  And this should include
ALL of our projects which do annotation scanning, not just projects which
have a particular interest in the specific Papaki implementation (or any
other implementation), otherwise we're going to miss out on some use-case data.

- DML
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Dimitris Andreadis-2]

David, just tried to connect to the wiki and got a 502 error, so feel free to change the
wording, that was just a start to get the ball rolling ;-)

David M. Lloyd wrote:

> On 10/29/2009 02:39 PM, Dimitris Andreadis wrote:
>> Please edit the wiki page and add your annotation scanning
>> requirements/usecases:
>
> Well, the good news is, this is just what we need to get started.  The
> bad news is by calling it "the Papaki project (formerly JBoss
> Annotations)", and asking people who would be interested in using this
> project, you're already leaking implementation considerations into a
> purely requirements doc. :-)
>
> What this document should really say is, "What projects need to read
> annotation data, scan annotations to determine deployment information,
> or in any other way use annotations at compile time OR run time, and
> what exactly are the requirements for each project?"  And this should
> include ALL of our projects which do annotation scanning, not just
> projects which have a particular interest in the specific Papaki
> implementation (or any other implementation), otherwise we're going to
> miss out on some use-case data.
>
> - DML

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Kabir Khan]

I got a 503 error. I'm not sure if that is slightly better or worse  
than a 502? :-)
On 30 Oct 2009, at 08:42, Dimitris Andreadis wrote:

> David, just tried to connect to the wiki and got a 502 error, so  
> feel free to change the
> wording, that was just a start to get the ball rolling ;-)
>
> David M. Lloyd wrote:
>> On 10/29/2009 02:39 PM, Dimitris Andreadis wrote:
>>> Please edit the wiki page and add your annotation scanning
>>> requirements/usecases:
>>
>> Well, the good news is, this is just what we need to get started.  
>> The
>> bad news is by calling it "the Papaki project (formerly JBoss
>> Annotations)", and asking people who would be interested in using  
>> this
>> project, you're already leaking implementation considerations into a
>> purely requirements doc. :-)
>>
>> What this document should really say is, "What projects need to read
>> annotation data, scan annotations to determine deployment  
>> information,
>> or in any other way use annotations at compile time OR run time, and
>> what exactly are the requirements for each project?"  And this should
>> include ALL of our projects which do annotation scanning, not just
>> projects which have a particular interest in the specific Papaki
>> implementation (or any other implementation), otherwise we're going  
>> to
>> miss out on some use-case data.
>>
>> - DML
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Carlo de Wolf-2]

I haven't worded it yet for a definitive requirement.

There is a subtle difference between scanning & processing. What I don't want is unnecessary processing if a descriptor is metadata complete.
Note that this only goes for EJB annotations, other annotation processing is left beyond scope.

EJB 3.1-fr 20.5.2 .war Deployment Descriptor and Annotation Processing
Table 26 describes the requirements for determining when to process annotations on the enterprise bean classes of a .war. If the .war contains an ejb-jar.xml file the deployment tool will process annotations unless the ejb-jar.xml has been marked metadata-complete. If the .war does not contain an ejb-jar.xml file, the deployment tool will process annotations unless the web.xml is marked metadata-complete or its version is prior to web-app_2_5.

Table 26 .war Annotation Processing Requirements for enterprise beans

ejb-jar.xml	ejb-jar.xml metadata-complete?	web.xml	web.xml metadata-complete?	process annotations?
ejb-jar_3_x	Yes	N/A	N/A	No
ejb-jar_3_x	No	N/A	N/A	Yes
none	N/A	web-app_3_0 or web-app_2_5	Yes	No
none	N/A	web-app_3_0 or web-app_2_5	No	Yes
none	N/A	web-app_2_4 or earlier	N/A	No
none	N/A	none	N/A	Yes

Carlo

On 10/29/2009 08:39 PM, Dimitris Andreadis wrote:

Please edit the wiki page and add your annotation scanning requirements/usecases:

http://www.jboss.org/community/wiki/PapakiAnnotationScanningRequirements

"Annotation scanning has a considerable impact in AS deployment and boot time performance. 
There are several subsystems that need to process annotations, for example EJB3, JCA, Web 
Services, JBoss Web, JPA, Seam, etc. and that often results either in inefficient annotation 
scanning implementations, extraneous classloading and multiple passes over the same jar files.

The goal of the Papaki project (formerly JBoss Annotations) is to unify annotation scanning, 
so that it can be performed efficiently and in one pass, with the various subsystem pulling 
annotation information from the Papaki service, thus improving deployment and boot times.

The purpose of this page is to collect requirements from all the projects that would be 
interested in plugging into this service, so that we can come up with a comprehensive API 
that can serve all the major use cases."
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development
  

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Rémy Maucherat-3]

On Wed, Nov 11, 2009 at 2:59 PM, Carlo de Wolf <cdewolf@...> wrote:
>
> I haven't worded it yet for a definitive requirement.
>
> There is a subtle difference between scanning & processing. What I don't want is unnecessary processing if a descriptor is metadata complete.
> Note that this only goes for EJB annotations, other annotation processing is left beyond scope.

You may want things all you like, but it's not going to happen.
Metadata complete was changed in EE 6, and it's a lot less complete
than it was. The bottom line is if you use JSR 299, then the easiest
by far is to do scanning as before. Actually, I think it's the only
thing that is doable.

Rémy

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Carlo de Wolf-2]

On 11/11/2009 05:18 PM, Rémy Maucherat wrote:

> On Wed, Nov 11, 2009 at 2:59 PM, Carlo de Wolf<cdewolf@...>  wrote:
>    
>> I haven't worded it yet for a definitive requirement.
>>
>> There is a subtle difference between scanning&  processing. What I don't want is unnecessary processing if a descriptor is metadata complete.
>> Note that this only goes for EJB annotations, other annotation processing is left beyond scope.
>>      
> You may want things all you like, but it's not going to happen.
> Metadata complete was changed in EE 6, and it's a lot less complete
> than it was. The bottom line is if you use JSR 299, then the easiest
> by far is to do scanning as before. Actually, I think it's the only
> thing that is doable.
>
> Rémy
>
>    

Right, so we should always scan and index all annotations. The actual
processing should become something optional.

Carlo
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Jason T. Greene]

Rémy Maucherat wrote:

> On Wed, Nov 11, 2009 at 2:59 PM, Carlo de Wolf <cdewolf@...> wrote:
>> I haven't worded it yet for a definitive requirement.
>>
>> There is a subtle difference between scanning & processing. What I don't want is unnecessary processing if a descriptor is metadata complete.
>> Note that this only goes for EJB annotations, other annotation processing is left beyond scope.
>
> You may want things all you like, but it's not going to happen.
> Metadata complete was changed in EE 6, and it's a lot less complete
> than it was. The bottom line is if you use JSR 299, then the easiest
> by far is to do scanning as before. Actually, I think it's the only
> thing that is doable.

This, however, only happens when you have a beans.xml. If there is no
beans.xml, then 299 does no scanning.


--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Rémy Maucherat-3]

On Wed, Nov 11, 2009 at 5:37 PM, Jason T. Greene
<jason.greene@...> wrote:
> This, however, only happens when you have a beans.xml. If there is no
> beans.xml, then 299 does no scanning.

Are you sure ? In Servlet 3.0, the language to skip resource injection
in some cases is about managed beans (greatly expanded in JSR 299),
not if a particular object is enabled in JSR 299 (or whatever the spec
defines). So I would prefer scanning and processing annotations all
the time.

On Wed, Nov 11, 2009 at 5:33 PM, Carlo de Wolf <cdewolf@...> wrote:
> Right, so we should always scan and index all annotations. The actual
> processing should become something optional.

Ah ok.

Rémy

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Jason T. Greene]

Rémy Maucherat wrote:

> On Wed, Nov 11, 2009 at 5:37 PM, Jason T. Greene
> <jason.greene@...> wrote:
>> This, however, only happens when you have a beans.xml. If there is no
>> beans.xml, then 299 does no scanning.
>
> Are you sure ? In Servlet 3.0, the language to skip resource injection
> in some cases is about managed beans (greatly expanded in JSR 299),
> not if a particular object is enabled in JSR 299 (or whatever the spec
> defines). So I would prefer scanning and processing annotations all
> the time.

If there is no beans.xml, then no 299 specific types are searched for
(299 style managed beans, stereotypes, decorators, etc) in the deployment.

Servlets and EJBs in a deployment without a beans.xml can still use
injection; however, only beans which are in a deployment that  does
contain a beans.xml are injectable (and such deployments must be
"visible" [in the classpath via ear, web-inf/lib, etc]). There is one
exception which is @New, which just creates a new instance per injection
point, and that can be resolved lazily.

Stated differently, if there is no beans.xml, then only reflective
analysis of the EE component being instantiated need be done. This is
basically the same rules as EE injection. So if metadata-complete is
true in the ejb or war case, and there is no beans.xml, then no
searching needs to be done. Reflection will still need to be done on
each class specified in the descriptor.

--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

[Rémy Maucherat-3]

On Thu, Nov 12, 2009 at 10:47 PM, Jason T. Greene
<jason.greene@...> wrote:
> If there is no beans.xml, then no 299 specific types are searched for
> (299 style managed beans, stereotypes, decorators, etc) in the deployment.

Ok. It would be easier, I think, to scan everything anyway.

I did not mention it in the requirements yet, but can Papaki implement
the ServletContainerInitializer requirements ? I thought scanning for
types would be the exception rather the norm, but it is the opposite
actually :( The first thing the JSF 2 devs did is use a HandlesTypes,
so basically we have to scan everything, and if we aim at a single
scan strategy, then meeting the SCI requirements is needed. I've added
HandlesTypes to the wiki page ...

Rémy

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development