2:39 p.m.
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."
3:07 p.m.
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
3:42 a.m.
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
4:59 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
7:59 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:18 a.m.
On Wed, Nov 11, 2009 at 2:59 PM, Carlo de Wolf <cdewolf(a)redhat.com> 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
10:33 a.m.
On 11/11/2009 05:18 PM, Rémy Maucherat wrote:
On Wed, Nov 11, 2009 at 2:59 PM, Carlo de
Wolf<cdewolf(a)redhat.com> 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
10:37 a.m.
Rémy Maucherat wrote:
On Wed, Nov 11, 2009 at 2:59 PM, Carlo de Wolf
<cdewolf(a)redhat.com> 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
12:07 p.m.
On Wed, Nov 11, 2009 at 5:37 PM, Jason T. Greene
<jason.greene(a)redhat.com> 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(a)redhat.com> wrote:
Right, so we should always scan and index all annotations. The
actual
processing should become something optional.
Ah ok.
Rémy
3:47 p.m.
Rémy Maucherat wrote:
On Wed, Nov 11, 2009 at 5:37 PM, Jason T. Greene
<jason.greene(a)redhat.com> 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
7:30 a.m.
On Thu, Nov 12, 2009 at 10:47 PM, Jason T. Greene
<jason.greene(a)redhat.com> 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
5512
days inactive
5530
days old
jboss-development@lists.jboss.org
10 comments
6 participants
participants (6)
-
Carlo de Wolf -
David M. Lloyd -
Dimitris Andreadis -
Jason T. Greene -
Kabir Khan -
Rémy Maucherat