Papaki Annotation Scanning Requirements
by Dimitris Andreadis
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."
15 years, 1 month
Disabling Bean Validation JNDI binder deployer in 5.2 Beta
by Stan Silvert
The simplest way to solve the issue below is to just disable the
ValidatorFactoryJndiBinderDeployer.
I've been thinking that using this deployer is probably the wrong way to
go. Originally, it was supposed to put a bean validator factory into
the deployment's java:comp context, as required by the JEE6 spec. But
when this deployer runs, that context isn't available yet. So the best
it could do was to bind it to global JNDI and hope that some later code
could bind it to the right place. But that "later code" can just as
easily get its reference from the DeploymentUnit.
So right now it creates a global JNDI reference for each deployment
under BeanValidatorFactories/<deployment simple name>. We know this is
wrong and I don't think anyone is relying on the global JNDI reference,
BUT IF YOU ARE PLEASE LET ME KNOW.
To be clear, the ValidatorFactoryDeployer that puts the factory into the
DeploymentUnit will still do its job. It's just that I want to get rid
of this failed attempt to satisfy the JNDI requirement. There are a
couple of ways to actually satisfy it, and I expect to do this post-beta.
Stan
Richard Opalka (JIRA) wrote:
> [ https://jira.jboss.org/jira/browse/JBAS-7384?page=com.atlassian.jira.plug... ]
>
> Richard Opalka reassigned JBAS-7384:
> ------------------------------------
>
> Assignee: Stan Silvert (was: Ales Justin)
>
>
> Reassigning to Stan (he's repsonsible for BV code)
>
>
>> org.jboss.test.webservice.endpoint.EndpointTestCase fails because of beanvalidation deployer
>> --------------------------------------------------------------------------------------------
>>
>> Key: JBAS-7384
>> URL: https://jira.jboss.org/jira/browse/JBAS-7384
>> Project: JBoss Application Server
>> Issue Type: Sub-task
>> Security Level: Public(Everyone can see)
>> Components: Web Services
>> Reporter: Shelly McGowan
>> Assignee: Stan Silvert
>> Fix For: JBossAS-5.2.0.Beta1
>>
>>
>> These newly added tests are failing. Filing to track.
>> testWSDLAccess:
>> javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: Unable to resolve imported document at 'http://localhost:8080/jaxws-endpoint?wsdl'.: java.io.FileNotFoundException: This file was not found: http://localhost:8080/jaxws-endpoint?wsdl
>> testClientAccess:
>> javax.xml.ws.WebServiceException: java.io.IOException: Could not transmit message
>> Caused by: org.jboss.ws.WSException: Invalid HTTP server response [404] - Not Found
>> testServletAccess:
>> java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8080/jaxws-endpoint-servlet?param=hello-world
>>
>
>
15 years, 1 month
m2eclipse issues
by Kabir Khan
AS trunk seems to have moved to using the m2eclipse plugin, and after
a few unsuccessful attempt it now works for me. However, the maven
console output show it to spend about 5 minutes trying to resolve the
org.codehaus.mojo:jboss-packaging-maven-plugin plugin?
10/23/09 3:38:22 PM BST: Updating index http://repo1.maven.org/maven2/
10/23/09 3:38:23 PM BST: Downloading central : nexus-maven-repository-
index.gz
10/23/09 3:39:51 PM BST: Refreshing [/build/pom.xml, /component-matrix/
pom.xml, /jboss-as-aspects/pom.xml, /jboss-as-cluster/pom.xml, /jboss-
as-connector/pom.xml, /jboss-as-console/pom.xml, /jboss-as-deployment/
pom.xml, /jboss-as-ejb3/pom.xml, /jboss-as-hibernate-int/pom.xml, /
jboss-as-iiop/pom.xml, /jboss-as-jbossas-jmx-remoting/pom.xml, /jboss-
as-jbossas-remoting/pom.xml, /jboss-as-jmx-remoting/pom.xml, /jboss-as-
main/pom.xml, /jboss-as-management/pom.xml, /jboss-as-messaging/
pom.xml, /jboss-as-profileservice/pom.xml, /jboss-as-security/
pom.xml, /jboss-as-server/pom.xml, /jboss-as-system/pom.xml, /jboss-as-
system-jmx/pom.xml, /jboss-as-tomcat/pom.xml, /jboss-as-varia/
pom.xml, /jboss-as-webservices/pom.xml, /testsuite/pom.xml, /tools/
pom.xml]
10/23/09 3:40:36 PM BST: Refreshing [/jboss-as-tomcat/pom.xml, /jboss-
as-varia/pom.xml, /jboss-as-webservices/pom.xml, /testsuite/pom.xml, /
tools/pom.xml]
10/23/09 3:40:37 PM BST: [INFO] Attempting to resolve a version for
plugin: org.codehaus.mojo:jboss-packaging-maven-plugin using meta-
version: LATEST
10/23/09 3:40:37 PM BST: [INFO] Using version: 2.1 of plugin:
org.codehaus.mojo:jboss-packaging-maven-plugin
10/23/09 3:40:43 PM BST: [INFO] Attempting to resolve a version for
plugin: org.codehaus.mojo:jboss-packaging-maven-plugin using meta-
version: LATEST
10/23/09 3:40:43 PM BST: [INFO] Using version: 2.1 of plugin:
org.codehaus.mojo:jboss-packaging-maven-plugin
<SNIP/>
10/23/09 3:45:01 PM BST: [INFO] Attempting to resolve a version for
plugin: org.codehaus.mojo:jboss-packaging-maven-plugin using meta-
version: LATEST
10/23/09 3:45:01 PM BST: [INFO] Using version: 2.1 of plugin:
org.codehaus.mojo:jboss-packaging-maven-plugin
10/23/09 3:45:02 PM BST: [INFO] Attempting to resolve a version for
plugin: org.codehaus.mojo:jboss-packaging-maven-plugin using meta-
version: LATEST
10/23/09 3:45:02 PM BST: [INFO] Using version: 2.1 of plugin:
org.codehaus.mojo:jboss-packaging-maven-plugin
10/23/09 3:45:03 PM BST: [INFO] Attempting to resolve a version for
plugin: org.codehaus.mojo:jboss-packaging-maven-plugin using meta-
version: LATEST
10/23/09 3:45:03 PM BST: [INFO] Using version: 2.1 of plugin:
org.codehaus.mojo:jboss-packaging-maven-plugin
15 years, 1 month
annotation scanning
by Ales Justin
Remy Maucherat wrote:
> On Wed, 2009-10-28 at 18:23 +0200, Dimitris Andreadis wrote:
>> - Papaki annotation scanning requirements/variants
I already integrated extracted working stuff into Deployers:
- http://anonsvn.jboss.org/repos/jbossas/projects/mc-ann/trunk/
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep...
> Ok. Indeed, I cannot use any form of optimized scanning for JARs which
> are in WARs at the moment. It works, but it is slower.
My guess would be that this slowness comes from the way Metadata project
uses this annotation scanning.
And afaik, you also went back to the old load-all-scan-all-classes approach.
> See AS trunk for the exact processing style (to summarize, I need to be
> able to scan and process annotations separately for classes
> in /WEB-INF/classes and in each individual JAR in /WEB-INF/lib).
This looks like an additional requirement on top of scan-all-in
deployment unit.
I would still try to scan it all - as that's the only proper way to
account for restrictions.
Then there could be an api that would group this annotations according
to source location.
15 years, 2 months
https://jira.jboss.org/jira/browse/JBPAPP-2941
by Scott Stark
Regarding the IPV6 issue in JBPAPP-2941, there was a change in JBNAME-25
to support an alternate syntax using '@' as the host/port separator:
"jnp://[3ffe:ffff:100:f101::1]@1099"
Does this not work for the EAP usage?
15 years, 2 months
jopr-embedded-jbas5.war corrupt
by Thomas Diesler
Branch_5_x does not seem to build because of a corrupt
jopr-embedded-jbas5.war
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 2 months
Re: [jboss-dev] Embedded Release Requirement for AS 5.2.0 Beta
by Shelly McGowan
Andrew,
The Embedded Integration tests Pass against Branch_5_x,
Revision: 95545. I'll run them again before tagging.
Shelly
----- Original Message -----
From: "Andrew Lee Rubinger" <andrew.rubinger(a)redhat.com>
To: jboss-development(a)lists.jboss.org
Sent: Friday, October 23, 2009 9:09:12 PM GMT -05:00 US/Canada Eastern
Subject: Re: [jboss-dev] Embedded Release Requirement for AS 5.2.0 Beta
As it stands, EmbeddedAS is a standalone project which depends upon AS.
To bring this into the AS build/testsuite is to introduce a cyclic
dependency.
The reasoning behind this structure was to decouple "EmbeddedAS", a
combined API for lifecycle/config/deployment from AS proper. We can
bring in the entire AS dependency chain transitively in one declaration,
thus making for a single entry point for users. In turn, this is how
the Embedded tests are set up/run.
If we need to rethink this relationship, now is the time and I welcome
all comments. To be honest I started developing outside in this little
sandbox for prototyping and it's stood since. Will sleep on it and post
more ideas to the list as they come.
S,
ALR
On 10/23/2009 11:25 AM, Bill Burke wrote:
> Why not? From my own experience, i suggest you make embedded a part of
> the AS testsuite run or you'll find it often broken.
>
> Andrew Lee Rubinger wrote:
>> Hi guys:
>>
>> Just want to note that before we tag AS, let's be sure to run the
>> EmbeddedAS TestSuite to ensure nothing's broken there in the interim.
>> This isn't covered by the AS TestSuite itself.
>>
>> S,
>> ALR
>>
>
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
15 years, 2 months
