3:28 p.m.
I suggested this a year or two ago:
* You should have a AnnotationScanner deployer that scans jars for
annotations and puts an annotation database somewhere in memory that
other deployers can reference. (This might already exist, I don't know).
* If a file META-INF/no.scan exists in a jar, then don't scan the file.
This allows libraries to exclude themselves from scanning.
* If a file META-INF/scan.only exists it will contain a newline
delimited list of class names to scan. Only scan those class names.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:30 p.m.
Bill Burke wrote:
I suggested this a year or two ago:
* You should have a AnnotationScanner deployer that scans jars for
annotations and puts an annotation database somewhere in memory that
other deployers can reference. (This might already exist, I don't know).
* If a file META-INF/no.scan exists in a jar, then don't scan the
file. This allows libraries to exclude themselves from scanning.
This is good.
* If a file META-INF/scan.only exists it will contain a newline
delimited list of class names to scan. Only scan those class names.
Why not just
scan the jar with the presence of the file? It will become
cumbersome to list all the class names if they are many classes to be
scanned in a jar??
6:40 p.m.
Anil Saldhana wrote:
Bill Burke wrote:
> I suggested this a year or two ago:
>
> * You should have a AnnotationScanner deployer that scans jars for
> annotations and puts an annotation database somewhere in memory that
> other deployers can reference. (This might already exist, I don't know).
>
> * If a file META-INF/no.scan exists in a jar, then don't scan the
> file. This allows libraries to exclude themselves from scanning.
This is good.
> * If a file META-INF/scan.only exists it will contain a newline
> delimited list of class names to scan. Only scan those class names.
Why not just scan the jar with the presence of the file? It will become
cumbersome to list all the class names if they are many classes to be
scanned in a jar??
Or support listing of *packages* and not just class names...
-CB
7:15 p.m.
Chris Bredesen wrote:
Anil Saldhana wrote:
> Bill Burke wrote:
>> I suggested this a year or two ago:
>>
>> * You should have a AnnotationScanner deployer that scans jars for
>> annotations and puts an annotation database somewhere in memory that
>> other deployers can reference. (This might already exist, I don't
>> know).
>>
>> * If a file META-INF/no.scan exists in a jar, then don't scan the
>> file. This allows libraries to exclude themselves from scanning.
> This is good.
>> * If a file META-INF/scan.only exists it will contain a newline
>> delimited list of class names to scan. Only scan those class names.
> Why not just scan the jar with the presence of the file? It will
> become cumbersome to list all the class names if they are many classes
> to be scanned in a jar??
My interpretation of this is the absence of no.scan and scan.only means
scan the entire jar. Which is the default so end users don't have to
understand this stuff.
Or support listing of *packages* and not just class names...
+1
-CB
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
7:51 p.m.
Anil Saldhana wrote:
Bill Burke wrote:
> I suggested this a year or two ago:
>
> * You should have a AnnotationScanner deployer that scans jars for
> annotations and puts an annotation database somewhere in memory that
> other deployers can reference. (This might already exist, I don't know).
>
> * If a file META-INF/no.scan exists in a jar, then don't scan the
> file. This allows libraries to exclude themselves from scanning.
This is good.
> * If a file META-INF/scan.only exists it will contain a newline
> delimited list of class names to scan. Only scan those class names.
Why not just scan the jar with the presence of the file? It will become
cumbersome to list all the class names if they are many classes to be
scanned in a jar??
It would be an option, not a requirement. If there are 100 files in
jar, and you only need to scan 1...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:50 p.m.
Bill Burke wrote:
I suggested this a year or two ago:
* You should have a AnnotationScanner deployer that scans jars for
annotations and puts an annotation database somewhere in memory that
other deployers can reference. (This might already exist, I don't know).
This should be served by MDR (metadata repository) subproject of MC:
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-mdr/trunk/
...which as I understand is able to collect type information without the
need for classloading (via Javassist).
Something I'd discussed a bit with Ales awhile back is refactoring
jboss-metadata to instead of using reflection a la:
http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/j...
...to instead read from MDR. I admittedly haven't yet digged too much
here, but since you ask the question... ;)
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
6:59 p.m.
Andrew Lee Rubinger wrote:
Bill Burke wrote:
> I suggested this a year or two ago:
>
> * You should have a AnnotationScanner deployer that scans jars for
> annotations and puts an annotation database somewhere in memory that
> other deployers can reference. (This might already exist, I don't know).
This should be served by MDR (metadata repository) subproject of MC:
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-mdr/trunk/
...which as I understand is able to collect type information without the
need for classloading (via Javassist).
Something I'd discussed a bit with Ales awhile back is refactoring
jboss-metadata to instead of using reflection a la:
http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/j...
...to instead read from MDR. I admittedly haven't yet digged too much
here, but since you ask the question... ;)
The other important bit to mention about MDR is that it'll contain
information added by AOP, which we don't get from straight reflection.
There is currently a gap now in the object model as it doesn't account
for, for instance, annotations tacked on in *-aop.xml files.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
11:22 p.m.
Andrew Lee Rubinger wrote:
Bill Burke wrote:
> I suggested this a year or two ago:
>
> * You should have a AnnotationScanner deployer that scans jars for
> annotations and puts an annotation database somewhere in memory that
> other deployers can reference. (This might already exist, I don't
> know).
This should be served by MDR (metadata repository) subproject of MC:
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-mdr/trunk/
...which as I understand is able to collect type information without
the need for classloading (via Javassist).
Something I'd discussed a bit with Ales awhile back is refactoring
jboss-metadata to instead of using reflection a la:
http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/j...
...to instead read from MDR. I admittedly haven't yet digged too much
here, but since you ask the question... ;)
S,
ALR
At the end of the day MDR still does reflection, see
org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.
Performance wise it's even worse because it scans for methods / fields
and such to match a signature.
So what used to be fast with advisor.resolveAnnotation(method,
annotationType) is now horribly slow, because of MDR. Which is a bummer,
because almost every interceptor we've got does something like that.
Carlo
12:40 a.m.
Carlo de Wolf wrote:
Andrew Lee Rubinger wrote:
> Bill Burke wrote:
>> I suggested this a year or two ago:
>>
>> * You should have a AnnotationScanner deployer that scans jars for
>> annotations and puts an annotation database somewhere in memory that
>> other deployers can reference. (This might already exist, I don't
>> know).
>
> This should be served by MDR (metadata repository) subproject of MC:
>
> http://anonsvn.jboss.org/repos/jbossas/projects/jboss-mdr/trunk/
>
> ...which as I understand is able to collect type information without
> the need for classloading (via Javassist).
>
> Something I'd discussed a bit with Ales awhile back is refactoring
> jboss-metadata to instead of using reflection a la:
>
>
http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/j...
>
>
> ...to instead read from MDR. I admittedly haven't yet digged too much
> here, but since you ask the question... ;)
>
> S,
> ALR
At the end of the day MDR still does reflection, see
org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.
Performance wise it's even worse because it scans for methods / fields
and such to match a signature.
So what used to be fast with advisor.resolveAnnotation(method,
annotationType) is now horribly slow, because of MDR. Which is a bummer,
because almost every interceptor we've got does something like that.
So it actually loads each and every class and does reflection on it? It
is a very very bad idea...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:49 a.m.
All of this already exists. ;-)
* You should have a AnnotationScanner deployer that scans jars for
annotations and puts an annotation database somewhere in memory that
other deployers can reference. (This might already exist, I don't know).
It is called AnnotationEnvironment, and it's part of the deployment's
attachments.
It's already used to help Metadata get annotation info.
But how it's done in Metadata is bad/wrong.
* If a file META-INF/no.scan exists in a jar, then don't scan the
file.
This allows libraries to exclude themselves from scanning.
* If a file META-INF/scan.only exists it will contain a newline
delimited list of class names to scan. Only scan those class names.
This is called jboss-scanning.xml.
- http://www.jboss.org/community/wiki/JBoss5custommetadatafiles
We already exclude all of our boot.
See metadata-deployer-jboss-beans.xml:
-
http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/etc...
3:26 a.m.
Ales Justin wrote:
All of this already exists. ;-)
But in many cases is not being taken advantage of. :)
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
4:22 p.m.
Ales Justin wrote:
All of this already exists. ;-)
> * You should have a AnnotationScanner deployer that scans jars for
> annotations and puts an annotation database somewhere in memory that
> other deployers can reference. (This might already exist, I don't
> know).
It is called AnnotationEnvironment, and it's part of the deployment's
attachments.
It's already used to help Metadata get annotation info.
But how it's done in Metadata is bad/wrong.
> * If a file META-INF/no.scan exists in a jar, then don't scan the
> file. This allows libraries to exclude themselves from scanning.
>
> * If a file META-INF/scan.only exists it will contain a newline
> delimited list of class names to scan. Only scan those class names.
This is called jboss-scanning.xml.
- http://www.jboss.org/community/wiki/JBoss5custommetadatafiles
We already exclude all of our boot.
See metadata-deployer-jboss-beans.xml:
-
http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/etc...
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
I have a few questions, please help me out. If AnnotationEnvironment,
is a database of annotations, would it be possible to persist the
AnnotationEnvironment (so we don't have to rebuild it after every
boot)? If yes, is there a way we could handle invalidating entries in
the persisted AnnotationEnvironment database (either manually or
automatically when classes change)?
3:06 a.m.
>
I have a few questions, please help me out. If AnnotationEnvironment,
is a database of annotations, would it be possible to persist the
AnnotationEnvironment (so we don't have to rebuild it after every
boot)? If yes, is there a way we could handle invalidating entries in
the persisted AnnotationEnvironment database (either manually or
automatically when classes change)?
I would like to start putting together the "jboss-scanning.xml" files
that will exclude/include certain classes (as you mentioned here
http://www.jboss.org/community/wiki/JBoss5custommetadatafiles). Would
it be possible to have "trace" logging that would show classes that are
scanned and whether annotations were found? I enabled trace for
"AnnotationEnvironmentDeployer" but didn't see enough information.
Thanks,
Scott
12:57 p.m.
Would it be possible to have "trace" logging that would
show classes that are
scanned and whether annotations were found? I enabled trace for
"AnnotationEnvironmentDeployer" but didn't see enough information.
This is already there:
package org.jboss.deployers.plugins.annotations;
public class DefaultAnnotationEnvironment extends WeakClassLoaderHolder
implements AnnotationEnvironment, Serializable
void putAnnotation(Annotation annotation, ElementType type, String
className, Signature signature)
{
Class<? extends Annotation> annClass = annotation.annotationType();
if (log.isTraceEnabled())
log.trace("Adding annotation @" + annClass.getSimpleName() + "
for " + className + " at type " + type + ", signature: " +
signature);
1:57 p.m.
Ales Justin wrote:
> Would it be possible to have "trace" logging that would
show classes
> that are scanned and whether annotations were found? I enabled trace
> for "AnnotationEnvironmentDeployer" but didn't see enough information.
This is already there:
package org.jboss.deployers.plugins.annotations;
public class DefaultAnnotationEnvironment extends
WeakClassLoaderHolder implements AnnotationEnvironment, Serializable
void putAnnotation(Annotation annotation, ElementType type, String
className, Signature signature)
{
Class<? extends Annotation> annClass = annotation.annotationType();
if (log.isTraceEnabled())
log.trace("Adding annotation @" + annClass.getSimpleName() +
" for " + className + " at type " + type + ", signature: "
+ signature);
If trace is enabled, could we also show the classes that have no
annotations? Perhaps in GenericAnnotationResourceVisitor.visit()? This
will help me understand what should be in the list of includes and
excludes (to help build the jboss-scanning.xml**).
2:02 p.m.
If trace is enabled, could we also show the classes that have no
annotations? Perhaps in GenericAnnotationResourceVisitor.visit()? This
will help me understand what should be in the list of includes and
excludes (to help build the jboss-scanning.xml**).
Sure.
Feel free to add whatever trace logging you think is useful
to help you with determining your needs for jboss-scanning.xml.
12:50 p.m.
I have a few questions, please help me out. If
AnnotationEnvironment,
is a database of annotations, would it be possible to persist the
AnnotationEnvironment (so we don't have to rebuild it after every
boot)? If yes, is there a way we could handle invalidating entries in
the persisted AnnotationEnvironment database (either manually or
automatically when classes change)?
I don't think this makes any sense.
All of our boot deployments, except the new admin-console, don't make
any use of AE.
At least to my knowledge, they don't use any annotations based metadata.
Hence I'm able to exclude them all -> metadata-deployer-jboss-beans.xml .
The only use case would be user apps,
but they are subject to change after every restart.
Or why else would you restart? :-)
And my gut feeling tells me it would be even harder or pointless to have
to invalidate existing persisted AE.
3:29 p.m.
Ales Justin wrote:
> I have a few questions, please help me out. If
> AnnotationEnvironment, is a database of annotations, would it be
> possible to persist the AnnotationEnvironment (so we don't have to
> rebuild it after every boot)? If yes, is there a way we could handle
> invalidating entries in the persisted AnnotationEnvironment database
> (either manually or automatically when classes change)?
I don't think this makes any sense.
All of our boot deployments, except the new admin-console, don't make
any use of AE.
At least to my knowledge, they don't use any annotations based metadata.
Hence I'm able to exclude them all -> metadata-deployer-jboss-beans.xml .
The only use case would be user apps,
but they are subject to change after every restart.
Or why else would you restart? :-)
And my gut feeling tells me it would be even harder or pointless to
have to invalidate existing persisted AE.
Is there any way that we could persistently cache the results of
scanning for annotations? Putting aside the issue of how to invalidate
the cache (lets discuss that after), where would the caching logic need
to go (maybe near the code dealing with jboss-scanning.xml?)
Are there currently any plans to do persistent caching in the MC (or
some form of pre-compiling)?
10:21 p.m.
Is there any way that we could persistently cache the results of
scanning for annotations?
Why would you want to cache something like this in the first place?
You actually never explained this. ;-)
Putting aside the issue of how to invalidate
the cache (lets discuss that after), where would the caching logic need
to go (maybe near the code dealing with jboss-scanning.xml?)
Dunno, as I'm still not convinced this is something we should do.
Instead of any caching, I could see some easy-to-do predetermined
annotation info (X).
That would be far more efficient and easy to do, than "proper" caching.
Are there currently any plans to do persistent caching in the MC (or
some form of pre-compiling)?
No.
Pre-compiling?
I guess we could hack some tool that would know how to do (X).
Tattletale looks perfect for such things. ;-)
4:50 a.m.
Ales Justin wrote:
> Is there any way that we could persistently cache the results of
> scanning for annotations?
Why would you want to cache something like this in the first place?
You actually never explained this. ;-)
I wanted to explore caching as a possible way to reduce the cost of
scanning for annotations. I'm still planning on using the
jboss-scanning.xml support for excluding classes that don't have
annotations.
Question about jboss-scanning.xml, if I specify the "include" list but
leave the "exclude" list blank or missing. Will that exclude all
classes that aren't on the "include" list? If yes, that will make it
easier to build the jboss-scanning.xml.
> Putting aside the issue of how to invalidate the cache (lets
discuss
> that after), where would the caching logic need to go (maybe near the
> code dealing with jboss-scanning.xml?)
Dunno, as I'm still not convinced this is something we should do.
Instead of any caching, I could see some easy-to-do predetermined
annotation info (X).
That would be far more efficient and easy to do, than "proper" caching.
> Are there currently any plans to do persistent caching in the MC (or
> some form of pre-compiling)?
No.
Pre-compiling?
I guess we could hack some tool that would know how to do (X).
Tattletale looks perfect for such things. ;-)
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:30 p.m.
Question about jboss-scanning.xml, if I specify the
"include" list but
leave the "exclude" list blank or missing. Will that exclude all
classes that aren't on the "include" list? If yes, that will make it
easier to build the jboss-scanning.xml.
There are two ways to exclude resources:
(a) do not recurse into it
(b) explicit pckg exclude
For (a) see ScanningDeploymentUnitFilter::ScanningMetaDataRecurseFilter.
For (b) see ScanningMetaDataResourceFilter.
Looking at (b), the answer to your question is yes.
3:28 a.m.
Ales Justin wrote:
> Question about jboss-scanning.xml, if I specify the
"include" list
> but leave the "exclude" list blank or missing. Will that exclude all
> classes that aren't on the "include" list? If yes, that will make it
> easier to build the jboss-scanning.xml.
There are two ways to exclude resources:
(a) do not recurse into it
(b) explicit pckg exclude
For (a) see ScanningDeploymentUnitFilter::ScanningMetaDataRecurseFilter.
For (b) see ScanningMetaDataResourceFilter.
Looking at (b), the answer to your question is yes.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
I tried to limit the scanning for annotations of
/deploy/juddi-service.sar/juddi.jar but the scans are still occurring.
Do we need to juddi-service.sar to
server/target/etc/deployers/metadata-deployer-jboss-beans.xml? Other
service archives are listed there but not the UDDI service (only include
in the AS/server/all profile).
6:58 a.m.
I tried to limit the scanning for annotations of
/deploy/juddi-service.sar/juddi.jar but the scans are still occurring.
With jboss-scanning.xml?
Do we need to juddi-service.sar to
server/target/etc/deployers/metadata-deployer-jboss-beans.xml? Other
service archives are listed there but not the UDDI service (only include
in the AS/server/all profile).
Sure, as I doubt it uses any of the EJB3 annotations to describe its
services.
I didn't update that list for a while now.
I can check if you still have issues, just let me know.
8:40 a.m.
We should not rely on this single list, it gets outdated sooner or later.
The deployments should be self contained with proper jboss-scanning.xml (or whatever is
necessary)
Ales Justin wrote:
> I tried to limit the scanning for annotations of
> /deploy/juddi-service.sar/juddi.jar but the scans are still occurring.
With jboss-scanning.xml?
> Do we need to juddi-service.sar to
> server/target/etc/deployers/metadata-deployer-jboss-beans.xml? Other
> service archives are listed there but not the UDDI service (only
> include in the AS/server/all profile).
Sure, as I doubt it uses any of the EJB3 annotations to describe its
services.
I didn't update that list for a while now.
I can check if you still have issues, just let me know.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:30 p.m.
Dimitris Andreadis wrote:
We should not rely on this single list, it gets outdated sooner or
later.
The deployments should be self contained with proper
jboss-scanning.xml (or whatever is necessary)
I will create a jira for eliminating the list and replacing it with per
deployment style "whatever is necessary stuff".
Ales Justin wrote:
>> I tried to limit the scanning for annotations of
>> /deploy/juddi-service.sar/juddi.jar but the scans are still occurring.
>
> With jboss-scanning.xml?
>
>> Do we need to juddi-service.sar to
>> server/target/etc/deployers/metadata-deployer-jboss-beans.xml?
>> Other service archives are listed there but not the UDDI service
>> (only include in the AS/server/all profile).
>
> Sure, as I doubt it uses any of the EJB3 annotations to describe its
> services.
>
> I didn't update that list for a while now.
> I can check if you still have issues, just let me know.
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:04 p.m.
Ales Justin wrote:
> I tried to limit the scanning for annotations of
> /deploy/juddi-service.sar/juddi.jar but the scans are still occurring.
With jboss-scanning.xml?
Yes, with jboss-scanning.xml which has the following contents. I ended
up putting a copy of this file in almost every juddi-service.sar folder
but still see trace messages during boot, indicating that juddi.jar
classes are being scanned for annotation. The trick of including "noop"
seems to work at the moment (intention is to exclude scanning of all
classes in juddi.jar).
<scanning xmlns="urn:jboss:scanning:1.0">
<path name="juddi.jar">
<include name="noop"/>
</path>
<path name="juddi-saaj.jar">
<include name="noop"/>
</path>
<path name="juddi-service.jar">
<include name="noop"/>
</path>
<path name="scout.jar">
<include name="noop"/>
</path>
<path name="juddi-service.sar/juddi.war/WEB-INF/classes">
<include name="noop"/>
</path>
</scanning>
The important target to exclude above is "juddi.jar" as it contains the
classes that we seem to scan for annotations about 400 times (only when
starting the "all" profile).
> Do we need to juddi-service.sar to
> server/target/etc/deployers/metadata-deployer-jboss-beans.xml? Other
> service archives are listed there but not the UDDI service (only
> include in the AS/server/all profile).
Sure, as I doubt it uses any of the EJB3 annotations to describe its
services.
I didn't update that list for a while now.
I can check if you still have issues, just let me know.
Is there anything special that we have to do in the AS to enable
jboss-scanning.xml to prevent annotation scanning in a service archive
like "deploy/juddi-service.sar"?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:30 p.m.
Yes, with jboss-scanning.xml which has the following contents. I
ended
up putting a copy of this file in almost every juddi-service.sar folder
but still see trace messages during boot, indicating that juddi.jar
classes are being scanned for annotation. The trick of including "noop"
seems to work at the moment (intention is to exclude scanning of all
classes in juddi.jar).
<scanning xmlns="urn:jboss:scanning:1.0">
<path name="juddi.jar">
<include name="noop"/>
</path>
<path name="juddi-saaj.jar">
<include name="noop"/>
</path>
<path name="juddi-service.jar">
<include name="noop"/>
</path>
<path name="scout.jar">
<include name="noop"/>
</path>
<path name="juddi-service.sar/juddi.war/WEB-INF/classes">
<include name="noop"/>
</path>
</scanning>
The important target to exclude above is "juddi.jar" as it contains the
classes that we seem to scan for annotations about 400 times (only when
starting the "all" profile).
You could simply have just a single noop path.
>> Do we need to juddi-service.sar to
>> server/target/etc/deployers/metadata-deployer-jboss-beans.xml? Other
>> service archives are listed there but not the UDDI service (only
>> include in the AS/server/all profile).
>
> Sure, as I doubt it uses any of the EJB3 annotations to describe its
> services.
>
> I didn't update that list for a while now.
> I can check if you still have issues, just let me know.
Is there anything special that we have to do in the AS to enable
jboss-scanning.xml to prevent annotation scanning in a service archive
like "deploy/juddi-service.sar"?
No.
Why?
2:24 p.m.
Ales Justin wrote:
> Yes, with jboss-scanning.xml which has the following contents. I
> ended up putting a copy of this file in almost every
> juddi-service.sar folder but still see trace messages during boot,
> indicating that juddi.jar classes are being scanned for annotation.
> The trick of including "noop" seems to work at the moment (intention
> is to exclude scanning of all classes in juddi.jar).
> <scanning xmlns="urn:jboss:scanning:1.0">
> <path name="juddi.jar">
> <include name="noop"/>
> </path>
> <path name="juddi-saaj.jar">
> <include name="noop"/>
> </path>
> <path name="juddi-service.jar">
> <include name="noop"/>
> </path>
> <path name="scout.jar">
> <include name="noop"/>
> </path>
> <path name="juddi-service.sar/juddi.war/WEB-INF/classes">
> <include name="noop"/>
> </path>
> </scanning>
>
> The important target to exclude above is "juddi.jar" as it contains
> the classes that we seem to scan for annotations about 400 times
> (only when starting the "all" profile).
You could simply have just a single noop path.
>>> Do we need to juddi-service.sar to
>>> server/target/etc/deployers/metadata-deployer-jboss-beans.xml?
>>> Other service archives are listed there but not the UDDI service
>>> (only include in the AS/server/all profile).
>>
>> Sure, as I doubt it uses any of the EJB3 annotations to describe its
>> services.
>>
>> I didn't update that list for a while now.
>> I can check if you still have issues, just let me know.
>
> Is there anything special that we have to do in the AS to enable
> jboss-scanning.xml to prevent annotation scanning in a service
> archive like "deploy/juddi-service.sar"?
No.
Why?
I'm trying to understand what the possible reasons are for
jboss-scanning.xml not working for the juddi-service.sar. If this
should work, then I probably did something wrong. Are there any trace
messages that will tell me if the jboss-scanning.xml file is being read?
I don't see any indications that we read the jboss-scanning.xml for
juddi-service.sar. I do see log messages for other deployments:
"
2009-06-15 17:35:24,365 TRACE
[org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext]
(main) Found jboss-scanning.xml in WEB-INF
2009-06-15 17:35:24,365 DEBUG
[org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper] (main)
Parsing file:
FileHandler(a)23098803[path=httpha-invoker.sar/invoker.war/WEB-INF/jboss-scanning.xml
context=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/
real=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/httpha-invoker.sar/invoker.war/WEB-INF/jboss-scanning.xml]
for type: class
org.jboss.deployers.plugins.annotations.AbstractScanningMetaData
2009-06-15 17:35:24,379 DEBUG
[org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper] (main)
Parsed file:
FileHandler(a)23098803[path=httpha-invoker.sar/invoker.war/WEB-INF/jboss-scanning.xml
context=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/
real=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/httpha-invoker.sar/invoker.war/WEB-INF/jboss-scanning.xml]
to: org.jboss.deployers.plugins.annotations.AbstractScanningMetaData@8bed44
2009-06-15 17:35:24,805 TRACE
[org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext]
(main) Found jboss-scanning.xml in META-INF
2009-06-15 17:35:24,805 DEBUG
[org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper] (main)
Parsing file:
FileHandler(a)5516771[path=cluster/jboss-cache-manager.sar/META-INF/jboss-scanning.xml
context=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/
real=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-scanning.xml]
for type: class
org.jboss.deployers.plugins.annotations.AbstractScanningMetaData
2009-06-15 17:35:24,811 DEBUG
[org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper] (main)
Parsed file:
FileHandler(a)5516771[path=cluster/jboss-cache-manager.sar/META-INF/jboss-scanning.xml
context=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/
real=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-scanning.xml]
to: org.jboss.deployers.plugins.annotations.AbstractScanningMetaData@e77cbd
2009-06-15 17:35:24,843 TRACE
[org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext]
(main) Found jboss-scanning.xml in META-INF
2009-06-15 17:35:24,843 DEBUG
[org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper] (main)
Parsing file:
FileHandler(a)16176900[path=jbossweb.sar/META-INF/jboss-scanning.xml
context=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/
real=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/jbossweb.sar/META-INF/jboss-scanning.xml]
for type: class
org.jboss.deployers.plugins.annotations.AbstractScanningMetaData
2009-06-15 17:35:24,849 DEBUG
[org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper] (main)
Parsed file:
FileHandler(a)16176900[path=jbossweb.sar/META-INF/jboss-scanning.xml
context=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/
real=file:/work/as/trunk/build/output/jboss-6.0.0.Alpha1/server/all/deploy/jbossweb.sar/META-INF/jboss-scanning.xml]
to: org.jboss.deployers.plugins.annotations.AbstractScanningMetaData@144311c
"
Here are the contents of my currently hacked juddi-service.sar tree. I
do have jboss-scanning.xml in the juddi-service.sar/META-INF folder:
|-- META-INF
| |-- MANIFEST.MF
| |-- ddl
| | |-- juddi_create_db.ddl
| | |-- juddi_data.ddl
| | `-- juddi_drop_db.ddl
| |-- jboss-scanning.xml
| `-- jboss-service.xml
|-- jboss-scanning.xml
|-- juddi-saaj.jar
|-- juddi-service.jar
|-- juddi.jar
|-- juddi.war
| |-- WEB-INF
| | |-- classes
| | | `-- org
| | | `-- jboss
| | | `-- jaxr
| | | `-- juddi
| | | `-- JUDDIServlet.class
| | |-- jboss-scanning.xml
| | |-- jboss-web.xml
| | |-- juddi.properties
| | `-- web.xml
| |-- index.html
| `-- styles.css
`-- scout.jar
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:54 p.m.
I'm trying to understand what the possible reasons are for
jboss-scanning.xml not working for the juddi-service.sar. If this
should work, then I probably did something wrong. Are there any trace
messages that will tell me if the jboss-scanning.xml file is being read?
If you can hack a test case that's failing in Deployers that would be great.
I already have a fix for some Seam issue ready,
adding this (if it really exists) should be easy as well.
9:14 p.m.
Here are the contents of my currently hacked juddi-service.sar tree.
I do have jboss-scanning.xml in the juddi-service.sar/META-INF folder:
|-- META-INF
| |-- MANIFEST.MF
| |-- ddl
| | |-- juddi_create_db.ddl
| | |-- juddi_data.ddl
| | `-- juddi_drop_db.ddl
| |-- jboss-scanning.xml
| `-- jboss-service.xml
|-- jboss-scanning.xml
|-- juddi-saaj.jar
|-- juddi-service.jar
|-- juddi.jar
I needed to add the jboss-scanning.xml to juddi-saaj.jar,
juddi-service.jar, juddi.jar, scout.jar (META-INF folder),
jboss-scanning is working against uddi for me now.
I'm moving forward with hacking the other deployments in all and will
then create a Jira with the changes that seem to be needed.
|-- juddi.war
| |-- WEB-INF
| | |-- classes
| | | `-- org
| | | `-- jboss
| | | `-- jaxr
| | | `-- juddi
| | | `-- JUDDIServlet.class
| | |-- jboss-scanning.xml
| | |-- jboss-web.xml
| | |-- juddi.properties
| | `-- web.xml
| |-- index.html
| `-- styles.css
`-- scout.jar
2:34 p.m.
What are the defaults for an empty jboss-scanning.xml?
Ales Justin wrote:
> Yes, with jboss-scanning.xml which has the following contents. I
> ended up putting a copy of this file in almost every juddi-service.sar
> folder but still see trace messages during boot, indicating that
> juddi.jar classes are being scanned for annotation. The trick of
> including "noop" seems to work at the moment (intention is to exclude
> scanning of all classes in juddi.jar).
> <scanning xmlns="urn:jboss:scanning:1.0">
> <path name="juddi.jar">
> <include name="noop"/>
> </path>
> <path name="juddi-saaj.jar">
> <include name="noop"/>
> </path>
> <path name="juddi-service.jar">
> <include name="noop"/>
> </path>
> <path name="scout.jar">
> <include name="noop"/>
> </path>
> <path name="juddi-service.sar/juddi.war/WEB-INF/classes">
> <include name="noop"/>
> </path>
> </scanning>
>
> The important target to exclude above is "juddi.jar" as it contains
> the classes that we seem to scan for annotations about 400 times (only
> when starting the "all" profile).
You could simply have just a single noop path.
>>> Do we need to juddi-service.sar to
>>> server/target/etc/deployers/metadata-deployer-jboss-beans.xml?
>>> Other service archives are listed there but not the UDDI service
>>> (only include in the AS/server/all profile).
>>
>> Sure, as I doubt it uses any of the EJB3 annotations to describe its
>> services.
>>
>> I didn't update that list for a while now.
>> I can check if you still have issues, just let me know.
>
> Is there anything special that we have to do in the AS to enable
> jboss-scanning.xml to prevent annotation scanning in a service archive
> like "deploy/juddi-service.sar"?
No.
Why?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:50 p.m.
What are the defaults for an empty jboss-scanning.xml?
No scanning. ;-)
Ales Justin wrote:
>> Yes, with jboss-scanning.xml which has the following contents. I
>> ended up putting a copy of this file in almost every
>> juddi-service.sar folder but still see trace messages during boot,
>> indicating that juddi.jar classes are being scanned for annotation.
>> The trick of including "noop" seems to work at the moment (intention
>> is to exclude scanning of all classes in juddi.jar).
>> <scanning xmlns="urn:jboss:scanning:1.0">
>> <path name="juddi.jar">
>> <include name="noop"/>
>> </path>
>> <path name="juddi-saaj.jar">
>> <include name="noop"/>
>> </path>
>> <path name="juddi-service.jar">
>> <include name="noop"/>
>> </path>
>> <path name="scout.jar">
>> <include name="noop"/>
>> </path>
>> <path name="juddi-service.sar/juddi.war/WEB-INF/classes">
>> <include name="noop"/>
>> </path>
>> </scanning>
>>
>> The important target to exclude above is "juddi.jar" as it contains
>> the classes that we seem to scan for annotations about 400 times
>> (only when starting the "all" profile).
>
> You could simply have just a single noop path.
>
>>>> Do we need to juddi-service.sar to
>>>> server/target/etc/deployers/metadata-deployer-jboss-beans.xml?
>>>> Other service archives are listed there but not the UDDI service
>>>> (only include in the AS/server/all profile).
>>>
>>> Sure, as I doubt it uses any of the EJB3 annotations to describe its
>>> services.
>>>
>>> I didn't update that list for a while now.
>>> I can check if you still have issues, just let me know.
>>
>> Is there anything special that we have to do in the AS to enable
>> jboss-scanning.xml to prevent annotation scanning in a service
>> archive like "deploy/juddi-service.sar"?
>
> No.
> Why?
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:17 p.m.
> Do we need to juddi-service.sar to
> server/target/etc/deployers/metadata-deployer-jboss-beans.xml? Other
> service archives are listed there but not the UDDI service (only
> include in the AS/server/all profile).
Sure, as I doubt it uses any of the EJB3 annotations to describe its
services.
I didn't update that list for a while now.
I can check if you still have issues, just let me know.
It is true that juddi
doesn't use EJB3 annotations. What is the
metadata-deployer-jboss-beans.xml file for? Does that list deployments
that might contain EJB3 annotations?
Thank you! :)
Scott
1:34 p.m.
It is true that juddi doesn't use EJB3 annotations. What is the
metadata-deployer-jboss-beans.xml file for?
It mostly contains the merging deployers.
Afair, it also contains info about some top xml element to metadata mapping.
Does that list deployments that might contain EJB3 annotations?
No, just the opposite.
As currently the only user of AE is EJB3 and its Metadata Processors.
Hence we try to exclude all that don't have any EJB3 annotations.
Once we do more/better resources federation this list might not be a
proper solution.
10:42 p.m.
Ales Justin wrote:
All of this already exists. ;-)
> * You should have a AnnotationScanner deployer that scans jars for
> annotations and puts an annotation database somewhere in memory that
> other deployers can reference. (This might already exist, I don't
> know).
It is called AnnotationEnvironment, and it's part of the deployment's
attachments.
It's already used to help Metadata get annotation info.
But how it's done in Metadata is bad/wrong.
> * If a file META-INF/no.scan exists in a jar, then don't scan the
> file. This allows libraries to exclude themselves from scanning.
>
> * If a file META-INF/scan.only exists it will contain a newline
> delimited list of class names to scan. Only scan those class names.
This is called jboss-scanning.xml.
- http://www.jboss.org/community/wiki/JBoss5custommetadatafiles
I hacked my local
trunk (6) build to use jboss-scanning.xml and don't
see much of an impact on boot performance. Prior to the
jboss-scanning.xml changes, we were scanning about 600 classes for
annotations. After the changes, we scan zero classes for annotations
(as per trace logging in o.j.d.p.a.GenericAnnotationResourceVisitor).
My local timings are:
Before the change:
Started in 35s:304ms
Started in 33s:229ms
Started in 34s:445ms
After adding jboss-scanning.xml:
Started in 33s:324ms
Started in 34s:163ms
Started in 33s:957ms
We already exclude all of our boot.
See metadata-deployer-jboss-beans.xml:
-
http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/etc...
FYI, JBAS-7025 is about excluding our boot with separate
jboss-scanning.xml files, instead of using a central list
(metadata-deployer-jboss-beans.xml).
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11 p.m.
Scott Marlow wrote:
Ales Justin wrote:
> All of this already exists. ;-)
>
>> * You should have a AnnotationScanner deployer that scans jars for
>> annotations and puts an annotation database somewhere in memory that
>> other deployers can reference. (This might already exist, I don't
>> know).
>
> It is called AnnotationEnvironment, and it's part of the deployment's
> attachments.
>
> It's already used to help Metadata get annotation info.
> But how it's done in Metadata is bad/wrong.
>
>> * If a file META-INF/no.scan exists in a jar, then don't scan the
>> file. This allows libraries to exclude themselves from scanning.
>>
>> * If a file META-INF/scan.only exists it will contain a newline
>> delimited list of class names to scan. Only scan those class names.
>
> This is called jboss-scanning.xml.
> - http://www.jboss.org/community/wiki/JBoss5custommetadatafiles
I hacked my local trunk (6) build to use jboss-scanning.xml and don't
see much of an impact on boot performance. Prior to the
jboss-scanning.xml changes, we were scanning about 600 classes for
annotations. After the changes, we scan zero classes for annotations
(as per trace logging in o.j.d.p.a.GenericAnnotationResourceVisitor).
My local timings are:
Interesting findings. Although keep in mind we have a few other paths
where scanning occurs, usually post-classloading. Anything that uses the
MDR for example (AOP is one example)
--
Jason T. Greene
JBoss, a division of Red Hat
5436
days inactive
5447
days old
jboss-development@lists.jboss.org
36 comments
11 participants
participants (11)
-
Ales Justin -
Andrew Lee Rubinger -
Anil Saldhana -
Bill Burke -
Brian Stansberry -
Carlo de Wolf -
Chris Bredesen -
Dimitris Andreadis -
Jason T. Greene -
Scott Marlow -
Scott Marlow