3:26 p.m.
I've just updated the AS trunk with new Scanning lib.
It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
Apart from AnnotationRepository (which was already there with the old code),
I've also hacked around Hibernate's Scanner a bit, so it uses new scanning
lib's ScannerImpl.
(the hack is mostly in place due to some impl issues in Hibernate itself, Emmanuel is
working on it)
JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
And web can use ResourcesIndex from DeploymentUnit -- Remy.
WeldScanningPlugin is currently commented out.
We need to disable one of the deployers in plugin's favor.
Pete, let me know when the new Weld release is coming in,
and I'll enable the plugin + run a few tests.
All in all, if you spot any issues / regressions wrt this change,
let me know, and I'll try to fix the stuff asap.
3:29 p.m.
On 2 Jun 2010, at 14:26, Ales Justin wrote:
WeldScanningPlugin is currently commented out.
We need to disable one of the deployers in plugin's favor.
Pete, let me know when the new Weld release is coming in,
and I'll enable the plugin + run a few tests.
Marius is going to merge the weld-integration code into JBoss AS as a module, rather than
sub-project we import. He is going to do this for M4. Seems like a good time to add in
this new scanning stuff.
Pete
3:50 p.m.
> WeldScanningPlugin is currently commented out.
> We need to disable one of the deployers in plugin's favor.
> Pete, let me know when the new Weld release is coming in,
> and I'll enable the plugin + run a few tests.
Marius is going to merge the weld-integration code into JBoss AS as a module, rather than
sub-project we import. He is going to do this for M4. Seems like a good time to add in
this new scanning stuff.
I would only move the actual necessary integration pieces.
The other Kernel/IoC + Weld integration should be left where it is,
as it's completely optional and still work-in-progress.
5:35 p.m.
On 10-06-02 9:50 AM, Ales Justin wrote:
>> WeldScanningPlugin is currently commented out.
>> We need to disable one of the deployers in plugin's favor.
>> Pete, let me know when the new Weld release is coming in,
>> and I'll enable the plugin + run a few tests.
>>
> Marius is going to merge the weld-integration code into JBoss AS as a module, rather
than sub-project we import. He is going to do this for M4. Seems like a good time to add
in this new scanning stuff.
>
I would only move the actual necessary integration pieces.
The other Kernel/IoC + Weld integration should be left where it is,
as it's completely optional and still work-in-progress.
Fair enough. Only stuff that belongs to JBoss AS.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:52 p.m.
Ales,
I haven't updated yet but heard (on #jboss-dev) of a boot time
performance regression with this change of around 15%. I haven't
updated to this revision yet myself but am curious if others are seeing
any boot time performance differences with this change.
Scott
On Wed, 2010-06-02 at 15:26 +0200, Ales Justin wrote:
I've just updated the AS trunk with new Scanning lib.
It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
Apart from AnnotationRepository (which was already there with the old code),
I've also hacked around Hibernate's Scanner a bit, so it uses new scanning
lib's ScannerImpl.
(the hack is mostly in place due to some impl issues in Hibernate itself, Emmanuel is
working on it)
JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
And web can use ResourcesIndex from DeploymentUnit -- Remy.
WeldScanningPlugin is currently commented out.
We need to disable one of the deployers in plugin's favor.
Pete, let me know when the new Weld release is coming in,
and I'll enable the plugin + run a few tests.
All in all, if you spot any issues / regressions wrt this change,
let me know, and I'll try to fix the stuff asap.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
6:11 p.m.
For me it's just the opposite.
It used to boot in 17sec, now I can get it up in around 15,5.
But I'll definitely check for any potential bottleneck,
or any feedback is more than welcome.
On Jun 2, 2010, at 5:52 PM, Scott Marlow wrote:
Ales,
I haven't updated yet but heard (on #jboss-dev) of a boot time
performance regression with this change of around 15%. I haven't
updated to this revision yet myself but am curious if others are seeing
any boot time performance differences with this change.
Scott
On Wed, 2010-06-02 at 15:26 +0200, Ales Justin wrote:
> I've just updated the AS trunk with new Scanning lib.
> It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
>
> Apart from AnnotationRepository (which was already there with the old code),
> I've also hacked around Hibernate's Scanner a bit, so it uses new scanning
lib's ScannerImpl.
> (the hack is mostly in place due to some impl issues in Hibernate itself, Emmanuel is
working on it)
>
> JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>
> WeldScanningPlugin is currently commented out.
> We need to disable one of the deployers in plugin's favor.
> Pete, let me know when the new Weld release is coming in,
> and I'll enable the plugin + run a few tests.
>
> All in all, if you spot any issues / regressions wrt this change,
> let me know, and I'll try to fix the stuff asap.
>
>
> _______________________________________________
> 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
6:56 p.m.
If this is AS booting with the Javassist implementation of jboss-reflect (which IIRC is
the default in the reflect version Ales put in) then that is currently slower. I am
experimenting with a lower-level bytecode implementation that is a lot more lazy in what
it loads, and will have some results for that in a few days time.
On 2 Jun 2010, at 16:52, Scott Marlow wrote:
Ales,
I haven't updated yet but heard (on #jboss-dev) of a boot time
performance regression with this change of around 15%. I haven't
updated to this revision yet myself but am curious if others are seeing
any boot time performance differences with this change.
Scott
On Wed, 2010-06-02 at 15:26 +0200, Ales Justin wrote:
> I've just updated the AS trunk with new Scanning lib.
> It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
>
> Apart from AnnotationRepository (which was already there with the old code),
> I've also hacked around Hibernate's Scanner a bit, so it uses new scanning
lib's ScannerImpl.
> (the hack is mostly in place due to some impl issues in Hibernate itself, Emmanuel is
working on it)
>
> JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>
> WeldScanningPlugin is currently commented out.
> We need to disable one of the deployers in plugin's favor.
> Pete, let me know when the new Weld release is coming in,
> and I'll enable the plugin + run a few tests.
>
> All in all, if you spot any issues / regressions wrt this change,
> let me know, and I'll try to fix the stuff asap.
>
>
> _______________________________________________
> 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
7:02 p.m.
No, I'm explicity configuring Reflect back to Introspection in Main;
see the Embedded issue in this thread.
Sent from my iPod
On 2.6.2010, at 18:56, Kabir Khan <kabir.khan(a)jboss.com> wrote:
If this is AS booting with the Javassist implementation of jboss-
reflect (which IIRC is the default in the reflect version Ales put
in) then that is currently slower. I am experimenting with a lower-
level bytecode implementation that is a lot more lazy in what it
loads, and will have some results for that in a few days time.
On 2 Jun 2010, at 16:52, Scott Marlow wrote:
> Ales,
>
> I haven't updated yet but heard (on #jboss-dev) of a boot time
> performance regression with this change of around 15%. I haven't
> updated to this revision yet myself but am curious if others are
> seeing
> any boot time performance differences with this change.
>
> Scott
>
> On Wed, 2010-06-02 at 15:26 +0200, Ales Justin wrote:
>> I've just updated the AS trunk with new Scanning lib.
>> It also includes some other MC changes: Reflect, MDR, Kernel, CL,
>> Deployers.
>>
>> Apart from AnnotationRepository (which was already there with the
>> old code),
>> I've also hacked around Hibernate's Scanner a bit, so it uses new
>> scanning lib's ScannerImpl.
>> (the hack is mostly in place due to some impl issues in Hibernate
>> itself, Emmanuel is working on it)
>>
>> JSF can now use new JBossAnnotationProvider -- let me know how
>> that goes Stan.
>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>
>> WeldScanningPlugin is currently commented out.
>> We need to disable one of the deployers in plugin's favor.
>> Pete, let me know when the new Weld release is coming in,
>> and I'll enable the plugin + run a few tests.
>>
>> All in all, if you spot any issues / regressions wrt this change,
>> let me know, and I'll try to fix the stuff asap.
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
7:12 p.m.
I was referrring to the boot time of real AS :-) Unless that is configured to use
Introspection in run.sh
JAVA_OPTS="${JAVA_OPTS:+$JAVA_OPTS
-Dorg.jboss.reflect.spi.TypeInfoFactory=org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory}"
Locally, I get a 20% slower boot time. I never meant to commit the change using Javassist
as default :-(
On 2 Jun 2010, at 18:02, Ales Justin wrote:
No, I'm explicity configuring Reflect back to Introspection in
Main;
see the Embedded issue in this thread.
Sent from my iPod
On 2.6.2010, at 18:56, Kabir Khan <kabir.khan(a)jboss.com> wrote:
> If this is AS booting with the Javassist implementation of jboss-
> reflect (which IIRC is the default in the reflect version Ales put
> in) then that is currently slower. I am experimenting with a lower-
> level bytecode implementation that is a lot more lazy in what it
> loads, and will have some results for that in a few days time.
> On 2 Jun 2010, at 16:52, Scott Marlow wrote:
>
>> Ales,
>>
>> I haven't updated yet but heard (on #jboss-dev) of a boot time
>> performance regression with this change of around 15%. I haven't
>> updated to this revision yet myself but am curious if others are
>> seeing
>> any boot time performance differences with this change.
>>
>> Scott
>>
>> On Wed, 2010-06-02 at 15:26 +0200, Ales Justin wrote:
>>> I've just updated the AS trunk with new Scanning lib.
>>> It also includes some other MC changes: Reflect, MDR, Kernel, CL,
>>> Deployers.
>>>
>>> Apart from AnnotationRepository (which was already there with the
>>> old code),
>>> I've also hacked around Hibernate's Scanner a bit, so it uses new
>>> scanning lib's ScannerImpl.
>>> (the hack is mostly in place due to some impl issues in Hibernate
>>> itself, Emmanuel is working on it)
>>>
>>> JSF can now use new JBossAnnotationProvider -- let me know how
>>> that goes Stan.
>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>
>>> WeldScanningPlugin is currently commented out.
>>> We need to disable one of the deployers in plugin's favor.
>>> Pete, let me know when the new Weld release is coming in,
>>> and I'll enable the plugin + run a few tests.
>>>
>>> All in all, if you spot any issues / regressions wrt this change,
>>> let me know, and I'll try to fix the stuff asap.
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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
8:39 p.m.
I was referrring to the boot time of real AS :-) Unless that is
configured to use Introspection in run.sh
JAVA_OPTS="${JAVA_OPTS:+$JAVA_OPTS
-Dorg.jboss.reflect.spi.TypeInfoFactory=org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory}"
No, its hardcoded in Main. As temp hack/workaround.
Locally, I get a 20% slower boot time. I never meant to commit the
change using Javassist as default :-(
Yeah, that's why I configured Introspection as default,
but didn't want to do a new Reflect release -- which it looks like I'll actually
have to.
On 2 Jun 2010, at 18:02, Ales Justin wrote:
> No, I'm explicity configuring Reflect back to Introspection in Main;
> see the Embedded issue in this thread.
>
> Sent from my iPod
>
> On 2.6.2010, at 18:56, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>
>> If this is AS booting with the Javassist implementation of jboss-
>> reflect (which IIRC is the default in the reflect version Ales put
>> in) then that is currently slower. I am experimenting with a lower-
>> level bytecode implementation that is a lot more lazy in what it
>> loads, and will have some results for that in a few days time.
>> On 2 Jun 2010, at 16:52, Scott Marlow wrote:
>>
>>> Ales,
>>>
>>> I haven't updated yet but heard (on #jboss-dev) of a boot time
>>> performance regression with this change of around 15%. I haven't
>>> updated to this revision yet myself but am curious if others are
>>> seeing
>>> any boot time performance differences with this change.
>>>
>>> Scott
>>>
>>> On Wed, 2010-06-02 at 15:26 +0200, Ales Justin wrote:
>>>> I've just updated the AS trunk with new Scanning lib.
>>>> It also includes some other MC changes: Reflect, MDR, Kernel, CL,
>>>> Deployers.
>>>>
>>>> Apart from AnnotationRepository (which was already there with the
>>>> old code),
>>>> I've also hacked around Hibernate's Scanner a bit, so it uses new
>>>> scanning lib's ScannerImpl.
>>>> (the hack is mostly in place due to some impl issues in Hibernate
>>>> itself, Emmanuel is working on it)
>>>>
>>>> JSF can now use new JBossAnnotationProvider -- let me know how
>>>> that goes Stan.
>>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>>
>>>> WeldScanningPlugin is currently commented out.
>>>> We need to disable one of the deployers in plugin's favor.
>>>> Pete, let me know when the new Weld release is coming in,
>>>> and I'll enable the plugin + run a few tests.
>>>>
>>>> All in all, if you spot any issues / regressions wrt this change,
>>>> let me know, and I'll try to fix the stuff asap.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:39 p.m.
Ales Justin wrote:
JSF can now use new JBossAnnotationProvider -- let me know how that
goes Stan
The JBossAnnotationProvider is now integrated with JSF. I verified that
JBossAnnotationProvider is being loaded. Unfortunately, it didn't fix
the ZipException as we had hoped.
If you try to deploy the WAR attached to
https://jira.jboss.org/browse/RF-8598 you will see the bug.
Stan
9:43 a.m.
> JSF can now use new JBossAnnotationProvider -- let me know how
that goes Stan
The JBossAnnotationProvider is now integrated with JSF. I verified that
JBossAnnotationProvider is being loaded. Unfortunately, it didn't fix the
ZipException as we had hoped.
Being loaded is not an issue, that's a simple service lookup.
The question is, does the usage of AnnotationIndex kick in?
Or does it fall back to old / default JSF annotation scanner?
Which would explain the ZipException.
If you try to deploy the WAR attached to
https://jira.jboss.org/browse/RF-8598 you will see the bug.
Old bug or something new?
Can you please attach the stack trace to the forums.
2:48 p.m.
Ales Justin wrote:
Old bug or something new?
Can you please attach the stack trace to the forums.
Done.
https://community.jboss.org/message/546040#546040
3:01 p.m.
I'm just debugging it myself. :-)
But I don't see our JBossAP being used -- see stack trace.
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/com.sun.faces.spi.annotationprovider
Shouldn't the last one be AnnotationProvider instead of all low level chars?
btw, in which jar is this services lookup file?
------------------
14:51:23,395 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] :
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method) [:1.6.0_20]
at java.util.zip.ZipFile.<init>(ZipFile.java:114) [:1.6.0_20]
at java.util.jar.JarFile.<init>(JarFile.java:135) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:67) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:214) [:1.6.0_20]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:198) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:50) [:1.6.0_20]
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70) [:1.6.0_20]
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
[:1.6.0_20]
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
[:1.6.0_20]
at com.sun.faces.config.AnnotationScanner.processClasspath(AnnotationScanner.java:290)
[:2.0.2-FCS]
at com.sun.faces.config.AnnotationScanner.getAnnotatedClasses(AnnotationScanner.java:215)
[:2.0.2-FCS]
// HERE --- JBP?
at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:765)
[:2.0.2-FCS]
at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:736)
[:2.0.2-FCS]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:329) [:2.0.2-FCS]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:223)
[:2.0.2-FCS]
at
org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:72)
[:1.0.0-SNAPSHOT]
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3409)
[:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3872) [:]
at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:309)
[:6.0.0-SNAPSHOT]
at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:144)
[:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
[:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116) [:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
[:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271)
[:6.0.0.Beta5]
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
[:2.2.0.Alpha10]
at $Proxy41.start(Unknown Source) at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53)
[:2.2.0.Alpha10]
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41)
[:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301)
[:2.2.0.Alpha10]
On Jun 3, 2010, at 2:48 PM, Stan Silvert wrote:
Ales Justin wrote:
> Old bug or something new?
> Can you please attach the stack trace to the forums.
Done.
https://community.jboss.org/message/546040#546040
3:08 p.m.
That seemed strange to me too. But I figured that just because it
wasn't in the stack trace doesn't mean it was never called. I did
verify that the class was loaded shortly before the exception, so
Mojarra was referring to it somehow.
The lookup file is in jsf.deployer/Mojarra-2.0/jsf-libs/jboss-faces.jar
Ales Justin wrote:
I'm just debugging it myself. :-)
But I don't see our JBossAP being used -- see stack trace.
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/com.sun.faces.spi.annotationprovider
Shouldn't the last one be AnnotationProvider instead of all low level chars?
btw, in which jar is this services lookup file?
------------------
14:51:23,395 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] :
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method) [:1.6.0_20]
at java.util.zip.ZipFile.<init>(ZipFile.java:114) [:1.6.0_20]
at java.util.jar.JarFile.<init>(JarFile.java:135) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:67) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:214) [:1.6.0_20]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:198) [:1.6.0_20]
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:50) [:1.6.0_20]
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70) [:1.6.0_20]
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
[:1.6.0_20]
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
[:1.6.0_20]
at com.sun.faces.config.AnnotationScanner.processClasspath(AnnotationScanner.java:290)
[:2.0.2-FCS]
at
com.sun.faces.config.AnnotationScanner.getAnnotatedClasses(AnnotationScanner.java:215)
[:2.0.2-FCS]
// HERE --- JBP?
at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:765)
[:2.0.2-FCS]
at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:736)
[:2.0.2-FCS]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:329) [:2.0.2-FCS]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:223)
[:2.0.2-FCS]
at
org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:72)
[:1.0.0-SNAPSHOT]
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3409)
[:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3872) [:]
at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:309)
[:6.0.0-SNAPSHOT]
at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:144)
[:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
[:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116) [:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
[:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271)
[:6.0.0.Beta5]
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
[:2.2.0.Alpha10]
at $Proxy41.start(Unknown Source) at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53)
[:2.2.0.Alpha10]
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41)
[:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
[jboss-dependency.jar:2.2.0.Alpha10]
at
org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301)
[:2.2.0.Alpha10]
On Jun 3, 2010, at 2:48 PM, Stan Silvert wrote:
> Ales Justin wrote:
>
>> Old bug or something new?
>> Can you please attach the stack trace to the forums.
>>
> Done.
>
> https://community.jboss.org/message/546040#546040
>
>
3:19 p.m.
The way that ServiceLoader would look it up is as a resource, so if the
target path is case-insensitive (like a JAR file) then it should work
regardless of how the case is in the file. On the filesystem it'd be a
different story though.
That said, it doesn't look like Mojarra is using ServiceLoader (they
probably want to retain 1.5 compat, at least for now?) so I guess you'd
have to look at the source, which I don't currently have on hand.
On 06/03/2010 08:08 AM, Stan Silvert wrote:
That seemed strange to me too. But I figured that just because it
wasn't in the stack trace doesn't mean it was never called. I did
verify that the class was loaded shortly before the exception, so
Mojarra was referring to it somehow.
The lookup file is in jsf.deployer/Mojarra-2.0/jsf-libs/jboss-faces.jar
Ales Justin wrote:
> I'm just debugging it myself. :-)
> But I don't see our JBossAP being used -- see stack trace.
>
> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/
> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/
> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/
>
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/com.sun.faces.spi.annotationprovider
>
> Shouldn't the last one be AnnotationProvider instead of all low level chars?
> btw, in which jar is this services lookup file?
>
> ------------------
>
> 14:51:23,395 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] :
java.util.zip.ZipException: error in opening zip file
> at java.util.zip.ZipFile.open(Native Method) [:1.6.0_20]
> at java.util.zip.ZipFile.<init>(ZipFile.java:114) [:1.6.0_20]
> at java.util.jar.JarFile.<init>(JarFile.java:135) [:1.6.0_20]
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:67) [:1.6.0_20]
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:214) [:1.6.0_20]
> at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20]
> at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:198) [:1.6.0_20]
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:50) [:1.6.0_20]
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70) [:1.6.0_20]
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
[:1.6.0_20]
> at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
[:1.6.0_20]
> at
com.sun.faces.config.AnnotationScanner.processClasspath(AnnotationScanner.java:290)
[:2.0.2-FCS]
> at
com.sun.faces.config.AnnotationScanner.getAnnotatedClasses(AnnotationScanner.java:215)
[:2.0.2-FCS]
> // HERE --- JBP?
> at
com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:765)
[:2.0.2-FCS]
> at
com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:736)
[:2.0.2-FCS]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:329)
[:2.0.2-FCS]
> at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:223)
[:2.0.2-FCS]
> at
org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:72)
[:1.0.0-SNAPSHOT]
> at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3409)
[:]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3872) [:]
> at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:309)
[:6.0.0-SNAPSHOT]
> at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:144)
[:6.0.0-SNAPSHOT]
> at
org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
[:6.0.0-SNAPSHOT]
> at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
[:6.0.0-SNAPSHOT]
> at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0-SNAPSHOT]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_20]
> at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_20]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
[:6.0.0.Beta5]
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271)
[:6.0.0.Beta5]
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670)
[:6.0.0.Beta5]
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
[:2.2.0.Alpha10]
> at $Proxy41.start(Unknown Source) at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53)
[:2.2.0.Alpha10]
> at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41)
[:2.2.0.Alpha10]
> at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
[jboss-dependency.jar:2.2.0.Alpha10]
> at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
[jboss-dependency.jar:2.2.0.Alpha10]
> at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
[jboss-dependency.jar:2.2.0.Alpha10]
> at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
[jboss-dependency.jar:2.2.0.Alpha10]
> at
org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301)
[:2.2.0.Alpha10]
>
>
>
> On Jun 3, 2010, at 2:48 PM, Stan Silvert wrote:
>
>
>> Ales Justin wrote:
>>
>>> Old bug or something new?
>>> Can you please attach the stack trace to the forums.
>>>
>> Done.
>>
>> https://community.jboss.org/message/546040#546040
>>
>>
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
- DML ☍
3:26 p.m.
This is what they use:
static String[] getServiceEntries(String key)
{
List< String > results = null;
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
return EMPTY_ARRAY;
}
Enumeration< URL > urls = null;
String serviceName = "META-INF/services/" + key;
try {
urls = loader.getResources(serviceName);
} catch (IOException ioe) {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.log(Level.SEVERE,
ioe.toString(),
ioe);
}
}
if (urls != null) {
InputStream input = null;
BufferedReader reader = null;
while (urls.hasMoreElements()) {
try {
if (results == null) {
results = new ArrayList< String >();
}
URL url = urls.nextElement();
URLConnection conn = url.openConnection();
conn.setUseCaches(false);
input = conn.getInputStream();
if (input != null) {
try {
reader =
new BufferedReader(new InputStreamReader(input,
"UTF-8"));
} catch (Exception e) {
reader =
new BufferedReader(new InputStreamReader(input));
}
for (String line = reader.readLine();
line != null;
line = reader.readLine()) {
results.add(line.trim());
}
}
} catch (Exception e) {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.log(Level.SEVERE,
"jsf.spi.provider.cannot_read_service",
new Object[]{serviceName});
LOGGER.log(Level.SEVERE,
e.toString(),
e);
}
} finally {
if (input != null) {
try {
input.close();
} catch (Exception ignored) {
}
}
if (reader != null) {
try {
reader.close();
} catch (Exception ignored) {
}
}
}
}
}
return ((results != null && !results.isEmpty())
? results.toArray(new String[results.size()])
: EMPTY_ARRAY);
}
On Jun 3, 2010, at 3:19 PM, David M. Lloyd wrote:
The way that ServiceLoader would look it up is as a resource, so if
the
target path is case-insensitive (like a JAR file) then it should work
regardless of how the case is in the file. On the filesystem it'd be a
different story though.
That said, it doesn't look like Mojarra is using ServiceLoader (they
probably want to retain 1.5 compat, at least for now?) so I guess you'd
have to look at the source, which I don't currently have on hand.
On 06/03/2010 08:08 AM, Stan Silvert wrote:
> That seemed strange to me too. But I figured that just because it
> wasn't in the stack trace doesn't mean it was never called. I did
> verify that the class was loaded shortly before the exception, so
> Mojarra was referring to it somehow.
>
> The lookup file is in jsf.deployer/Mojarra-2.0/jsf-libs/jboss-faces.jar
>
>
> Ales Justin wrote:
>> I'm just debugging it myself. :-)
>> But I don't see our JBossAP being used -- see stack trace.
>>
>> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/
>> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/
>> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/
>>
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/com.sun.faces.spi.annotationprovider
>>
>> Shouldn't the last one be AnnotationProvider instead of all low level chars?
>> btw, in which jar is this services lookup file?
>>
>> ------------------
>>
>> 14:51:23,395 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] :
java.util.zip.ZipException: error in opening zip file
>> at java.util.zip.ZipFile.open(Native Method) [:1.6.0_20]
>> at java.util.zip.ZipFile.<init>(ZipFile.java:114) [:1.6.0_20]
>> at java.util.jar.JarFile.<init>(JarFile.java:135) [:1.6.0_20]
>> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:67)
[:1.6.0_20]
>> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:214) [:1.6.0_20]
>> at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20]
>> at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:198)
[:1.6.0_20]
>> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:50)
[:1.6.0_20]
>> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70)
[:1.6.0_20]
>> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
[:1.6.0_20]
>> at
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
[:1.6.0_20]
>> at
com.sun.faces.config.AnnotationScanner.processClasspath(AnnotationScanner.java:290)
[:2.0.2-FCS]
>> at
com.sun.faces.config.AnnotationScanner.getAnnotatedClasses(AnnotationScanner.java:215)
[:2.0.2-FCS]
>> // HERE --- JBP?
>> at
com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:765)
[:2.0.2-FCS]
>> at
com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:736)
[:2.0.2-FCS]
>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[:1.6.0_20]
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
>> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:329)
[:2.0.2-FCS]
>> at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:223)
[:2.0.2-FCS]
>> at
org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:72)
[:1.0.0-SNAPSHOT]
>> at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3409)
[:]
>> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3872)
[:]
>> at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:309)
[:6.0.0-SNAPSHOT]
>> at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:144)
[:6.0.0-SNAPSHOT]
>> at
org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
[:6.0.0-SNAPSHOT]
>> at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
[:6.0.0-SNAPSHOT]
>> at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0-SNAPSHOT]
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_20]
>> at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_20]
>> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
>> at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
[:6.0.0.Beta5]
>> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
>> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
>> at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271)
[:6.0.0.Beta5]
>> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670)
[:6.0.0.Beta5]
>> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
[:2.2.0.Alpha10]
>> at $Proxy41.start(Unknown Source) at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53)
[:2.2.0.Alpha10]
>> at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41)
[:2.2.0.Alpha10]
>> at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
[jboss-dependency.jar:2.2.0.Alpha10]
>> at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
[jboss-dependency.jar:2.2.0.Alpha10]
>> at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
[jboss-dependency.jar:2.2.0.Alpha10]
>> at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
[jboss-dependency.jar:2.2.0.Alpha10]
>> at
org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301)
[:2.2.0.Alpha10]
>>
>>
>>
>> On Jun 3, 2010, at 2:48 PM, Stan Silvert wrote:
>>
>>
>>> Ales Justin wrote:
>>>
>>>> Old bug or something new?
>>>> Can you please attach the stack trace to the forums.
>>>>
>>> Done.
>>>
>>> https://community.jboss.org/message/546040#546040
>>>
>>>
>>
>>
>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
--
- DML ☍
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:13 p.m.
Ales Justin wrote:
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/com.sun.faces.spi.annotationprovider
Shouldn't the last one be AnnotationProvider instead of all low level chars?
AnnotationProvider javadoc
* <p>
* To register a custom AnnotationProvider with the runtime, place a file named
* com.sun.faces.spi.annotationprovider within META-INF/services of a JAR file,
* with a single line referencing the fully qualified class name of the AnnotationProvider
* implementation. Custom AnnotationProviders can be used to decorate the default
* AnnotationProvider by providing a constructor that takes an AnnotationProvider as the
* second parameter:</p>
*
3:18 p.m.
Ah, OK.
But it looks like the fqn works as well -- just tried it.
On Jun 3, 2010, at 3:13 PM, Stan Silvert wrote:
Ales Justin wrote:
> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/
> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/
> projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/
>
projects/jboss-jsf-int/trunk/jboss-faces/src/main/resources/META-INF/services/com.sun.faces.spi.annotationprovider
>
> Shouldn't the last one be AnnotationProvider instead of all low level chars?
>
>
AnnotationProvider javadoc
* <p>
* To register a custom AnnotationProvider with the runtime, place a file named
* com.sun.faces.spi.annotationprovider within META-INF/services of a JAR file,
* with a single line referencing the fully qualified class name of the
AnnotationProvider
* implementation. Custom AnnotationProviders can be used to decorate the default
* AnnotationProvider by providing a constructor that takes an AnnotationProvider as the
* second parameter:</p>
*
>
>
>
3:42 p.m.
New subject: [was: new scanning in AS trunk] JSF and scanning
Who adds this jboss-faces.jar to classpath?
Your integration deployers? Based on what?
jboss-faces.jar == jboss-faces-SNAPSHOT.jar ?
On thing I also noticed you should probably put jboss-structure.xml into
jsf.deployer/META-INF,
so you're not depending on "proper" structure deployers to be used,
when *not* recognizing your Mojara and jsf-libs dir as non-deployments.
e.g. someone might resurrect sar' lib/ structure deployer or have matching group
structure deployer
3:49 p.m.
New subject: [was: new scanning in AS trunk] JSF and scanning
Ales Justin wrote:
Who adds this jboss-faces.jar to classpath?
Your integration deployers? Based on what?
jboss-faces.jar == jboss-faces-SNAPSHOT.jar ?
Yes, right now it's a snapshot jar. It is added to the DeploymentUnit
classpath if the deployer determines that the WAR needs this version of JSF.
http://community.jboss.org/wiki/JSFonJBossAS6
3:56 p.m.
New subject: [was: new scanning in AS trunk] JSF and scanning
<bean name="JSFUrlIntegrationDeployer-20"
class="org.jboss.jsf.deployer.JSFUrlIntegrationDeployer">
<property name="JSFImplName">
<value>Mojarra-2.0</value>
</property>
<property name="JSFImplManagementDeployer">
<inject bean="JSFImplManagementDeployer"/>
</property>
<property name="additionalURLs">
<collection elementClass="java.lang.String">
<value>${jboss.lib.url}scanning-plugins.jar</value> // HERE
</collection>
</property>
</bean>
This is not good -- the additionalURLs.
I know why you put it there, but this can probably create a bunch of problems with other
scanning plugins.
e.g. CCE on Hibernate's Scanner
I think you can actually just rip off my JBossAnnotationProvider and put it into your
jboss-faces.jar,
and you then simply depend on scanning-plugins.jar,
which is actually already available at boot classpath - due to deployers usage,
and mc-int-servlet.jar which is in common/lib.
Let me know when you copied the JBP, so I'll remove it from scanning lib.
Who adds this jboss-faces.jar to classpath?
Your integration deployers? Based on what?
jboss-faces.jar == jboss-faces-SNAPSHOT.jar ?
OK, I checked the source code, so I know the answers to this questions.
On thing I also noticed you should probably put jboss-structure.xml
into jsf.deployer/META-INF,
so you're not depending on "proper" structure deployers to be used,
when *not* recognizing your Mojara and jsf-libs dir as non-deployments.
e.g. someone might resurrect sar' lib/ structure deployer or have matching group
structure deployer
I can add this if you like.
6:28 p.m.
Hi,
I committed a reimplementation of the war annotation scanning using
the new API, but the new scanning deployer is not working out too well
for me. If the new code fails due to a missing input, it falls back to
the old code. Let me know if it works for you (ie, no warning about
missing ResourcesIndex), as Ales cannot reproduce the problem.
Thanks,
Rémy
9:35 p.m.
I committed a reimplementation of the war annotation scanning using
the new API, but the new scanning deployer is not working out too well
for me. If the new code fails due to a missing input, it falls back to
the old code. Let me know if it works for you (ie, no warning about
missing ResourcesIndex), as Ales cannot reproduce the problem.
You don't need the ScanningMetaData code anymore
ScanningMetaData scanningMetaData = unit.getAttachment(ScanningMetaData.class);
for (VirtualFile path : classpath)
{
if (scanningMetaData == null
|| !(scanningMetaData.getPaths() == null
|| !scanningMetaData.getPaths().contains(path.getName())))
{
as this is all already taken care of in new ScanningDeployer.
10:05 p.m.
On Thu, Jun 3, 2010 at 9:35 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
You don't need the ScanningMetaData code anymore
ScanningMetaData scanningMetaData = unit.getAttachment(ScanningMetaData.class);
for (VirtualFile path : classpath)
{
if (scanningMetaData == null
|| !(scanningMetaData.getPaths() == null
|| !scanningMetaData.getPaths().contains(path.getName())))
{
as this is all already taken care of in new ScanningDeployer.
Really, it is able to associate the paths from the config with the
VirtualFile object ? Nice. So I'll remove these checks from the new
code.
Rémy
10:14 p.m.
> You don't need the ScanningMetaData code anymore
>
> ScanningMetaData scanningMetaData = unit.getAttachment(ScanningMetaData.class);
> for (VirtualFile path : classpath)
> {
> if (scanningMetaData == null
> || !(scanningMetaData.getPaths() == null
> || !scanningMetaData.getPaths().contains(path.getName())))
> {
>
> as this is all already taken care of in new ScanningDeployer.
Really, it is able to associate the paths from the config with the
VirtualFile object ? Nice. So I'll remove these checks from the new
code.
Too late, already done. ;-)
12:57 a.m.
On Thu, Jun 3, 2010 at 10:14 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
> Really, it is able to associate the paths from the config with
the
> VirtualFile object ? Nice. So I'll remove these checks from the new
> code.
Too late, already done. ;-)
Thanks. So I have the impression I'm the only person for whom it does
not work ;)
Rémy
1:08 a.m.
I may be having same problem as you. I'm trying to get
AnnotationRepository within a WAR DU and always getting NULL.
Rémy Maucherat wrote:
On Thu, Jun 3, 2010 at 10:14 PM, Ales Justin
<ales.justin(a)gmail.com> wrote:
>> Really, it is able to associate the paths from the config with the
>> VirtualFile object ? Nice. So I'll remove these checks from the new
>> code.
> Too late, already done. ;-)
Thanks. So I have the impression I'm the only person for whom it does
not work ;)
Rémy
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:01 p.m.
Following this commit (r105574), the tests in the
o.j.t.clustered.clusteredentity package started failing.[1] I brought an
AS checkout up to the commit before that (r105506) and they pass, but
with the r105574 commit they start failing.
The tests deploy ejb3 jars with persistence units included. The tests
are failing because the EJBs are not bound in JNDI. Looking at the logs
there are no obvious failures during the artifact deployments. But
there's no logging from any EJB3 deployers, just from Hibernate.
[1]
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
On 06/02/2010 08:26 AM, Ales Justin wrote:
I've just updated the AS trunk with new Scanning lib.
It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
Apart from AnnotationRepository (which was already there with the old code),
I've also hacked around Hibernate's Scanner a bit, so it uses new scanning
lib's ScannerImpl.
(the hack is mostly in place due to some impl issues in Hibernate itself, Emmanuel is
working on it)
JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
And web can use ResourcesIndex from DeploymentUnit -- Remy.
WeldScanningPlugin is currently commented out.
We need to disable one of the deployers in plugin's favor.
Pete, let me know when the new Weld release is coming in,
and I'll enable the plugin + run a few tests.
All in all, if you spot any issues / regressions wrt this change,
let me know, and I'll try to fix the stuff asap.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
10:07 p.m.
The tests artifacts are jars that all have this structure:
META-INF/
++ MANIFEST.MF (w/ nothing interesting
++ persistence.xml
org/blah/...
where some of the classes are entities and some are annotated EJB3
session beans. No ejb-jar.xml or jboss.xml.
The testsuite/output/lib/clusteredentity-test.jar is a good example.
In some but not all tests the jar is packaged in an ear along with a
datasource.
There's no EJB3 deployer logging, so perhaps the scanning isn't picking
up the EJB annotations?
On 06/03/2010 03:01 PM, Brian Stansberry wrote:
Following this commit (r105574), the tests in the
o.j.t.clustered.clusteredentity package started failing.[1] I brought an
AS checkout up to the commit before that (r105506) and they pass, but
with the r105574 commit they start failing.
The tests deploy ejb3 jars with persistence units included. The tests
are failing because the EJBs are not bound in JNDI. Looking at the logs
there are no obvious failures during the artifact deployments. But
there's no logging from any EJB3 deployers, just from Hibernate.
[1]
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
On 06/02/2010 08:26 AM, Ales Justin wrote:
> I've just updated the AS trunk with new Scanning lib.
> It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
>
> Apart from AnnotationRepository (which was already there with the old code),
> I've also hacked around Hibernate's Scanner a bit, so it uses new scanning
lib's ScannerImpl.
> (the hack is mostly in place due to some impl issues in Hibernate itself, Emmanuel is
working on it)
>
> JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>
> WeldScanningPlugin is currently commented out.
> We need to disable one of the deployers in plugin's favor.
> Pete, let me know when the new Weld release is coming in,
> and I'll enable the plugin + run a few tests.
>
> All in all, if you spot any issues / regressions wrt this change,
> let me know, and I'll try to fix the stuff asap.
>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
10:17 p.m.
The JPA has known issues:
ALR already fixed this with new jpa.vfs3 release.
And Shelly just confirmed this now works as expected.
The new jsp.vfs3 lib is already commited into c-m/pom.xml.
Can you try it and let us know if this also works for you?
On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
The tests artifacts are jars that all have this structure:
META-INF/
++ MANIFEST.MF (w/ nothing interesting
++ persistence.xml
org/blah/...
where some of the classes are entities and some are annotated EJB3
session beans. No ejb-jar.xml or jboss.xml.
The testsuite/output/lib/clusteredentity-test.jar is a good example.
In some but not all tests the jar is packaged in an ear along with a
datasource.
There's no EJB3 deployer logging, so perhaps the scanning isn't picking
up the EJB annotations?
On 06/03/2010 03:01 PM, Brian Stansberry wrote:
> Following this commit (r105574), the tests in the
> o.j.t.clustered.clusteredentity package started failing.[1] I brought an
> AS checkout up to the commit before that (r105506) and they pass, but
> with the r105574 commit they start failing.
>
> The tests deploy ejb3 jars with persistence units included. The tests
> are failing because the EJBs are not bound in JNDI. Looking at the logs
> there are no obvious failures during the artifact deployments. But
> there's no logging from any EJB3 deployers, just from Hibernate.
>
> [1]
>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>
> On 06/02/2010 08:26 AM, Ales Justin wrote:
>> I've just updated the AS trunk with new Scanning lib.
>> It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
>>
>> Apart from AnnotationRepository (which was already there with the old code),
>> I've also hacked around Hibernate's Scanner a bit, so it uses new
scanning lib's ScannerImpl.
>> (the hack is mostly in place due to some impl issues in Hibernate itself,
Emmanuel is working on it)
>>
>> JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>
>> WeldScanningPlugin is currently commented out.
>> We need to disable one of the deployers in plugin's favor.
>> Pete, let me know when the new Weld release is coming in,
>> and I'll enable the plugin + run a few tests.
>>
>> All in all, if you spot any issues / regressions wrt this change,
>> let me know, and I'll try to fix the stuff asap.
>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:42 p.m.
Still fails.
I don't think the problem is on the JPA side -- or at least that's not
the obvious surface problem. The persistence unit deployment seems to go ok.
The obvious surface problem is that during the deployment there is no
logging by any EJB3 related deployers. The session beans the test
invokes on are not getting deployed.
On 06/03/2010 03:17 PM, Ales Justin wrote:
The JPA has known issues:
> https://jira.jboss.org/browse/JBJPA-29
> https://jira.jboss.org/browse/JBAS-8064
ALR already fixed this with new jpa.vfs3 release.
And Shelly just confirmed this now works as expected.
The new jsp.vfs3 lib is already commited into c-m/pom.xml.
Can you try it and let us know if this also works for you?
On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
> The tests artifacts are jars that all have this structure:
>
> META-INF/
> ++ MANIFEST.MF (w/ nothing interesting
> ++ persistence.xml
> org/blah/...
>
> where some of the classes are entities and some are annotated EJB3
> session beans. No ejb-jar.xml or jboss.xml.
>
> The testsuite/output/lib/clusteredentity-test.jar is a good example.
>
> In some but not all tests the jar is packaged in an ear along with a
> datasource.
>
> There's no EJB3 deployer logging, so perhaps the scanning isn't picking
> up the EJB annotations?
>
> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>> Following this commit (r105574), the tests in the
>> o.j.t.clustered.clusteredentity package started failing.[1] I brought an
>> AS checkout up to the commit before that (r105506) and they pass, but
>> with the r105574 commit they start failing.
>>
>> The tests deploy ejb3 jars with persistence units included. The tests
>> are failing because the EJBs are not bound in JNDI. Looking at the logs
>> there are no obvious failures during the artifact deployments. But
>> there's no logging from any EJB3 deployers, just from Hibernate.
>>
>> [1]
>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>
>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>> I've just updated the AS trunk with new Scanning lib.
>>> It also includes some other MC changes: Reflect, MDR, Kernel, CL,
>>> Deployers.
>>>
>>> Apart from AnnotationRepository (which was already there with the
>>> old code),
>>> I've also hacked around Hibernate's Scanner a bit, so it uses new
>>> scanning lib's ScannerImpl.
>>> (the hack is mostly in place due to some impl issues in Hibernate
>>> itself, Emmanuel is working on it)
>>>
>>> JSF can now use new JBossAnnotationProvider -- let me know how that
>>> goes Stan.
>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>
>>> WeldScanningPlugin is currently commented out.
>>> We need to disable one of the deployers in plugin's favor.
>>> Pete, let me know when the new Weld release is coming in,
>>> and I'll enable the plugin + run a few tests.
>>>
>>> All in all, if you spot any issues / regressions wrt this change,
>>> let me know, and I'll try to fix the stuff asap.
>>>
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> <mailto:jboss-development@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> <mailto:jboss-development@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
7:38 p.m.
Is there a JIRA around this one? We are seeing similar clustering
deployment failures in our EJB3 build environment. I haven't yet looked
into the details to see what exactly causes the issue.
-Jaikiran
Brian Stansberry wrote:
Still fails.
I don't think the problem is on the JPA side -- or at least that's not
the obvious surface problem. The persistence unit deployment seems to go ok.
The obvious surface problem is that during the deployment there is no
logging by any EJB3 related deployers. The session beans the test
invokes on are not getting deployed.
On 06/03/2010 03:17 PM, Ales Justin wrote:
> The JPA has known issues:
>
>> https://jira.jboss.org/browse/JBJPA-29
>> https://jira.jboss.org/browse/JBAS-8064
> ALR already fixed this with new jpa.vfs3 release.
> And Shelly just confirmed this now works as expected.
>
> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
> Can you try it and let us know if this also works for you?
>
>
> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>
>> The tests artifacts are jars that all have this structure:
>>
>> META-INF/
>> ++ MANIFEST.MF (w/ nothing interesting
>> ++ persistence.xml
>> org/blah/...
>>
>> where some of the classes are entities and some are annotated EJB3
>> session beans. No ejb-jar.xml or jboss.xml.
>>
>> The testsuite/output/lib/clusteredentity-test.jar is a good example.
>>
>> In some but not all tests the jar is packaged in an ear along with a
>> datasource.
>>
>> There's no EJB3 deployer logging, so perhaps the scanning isn't picking
>> up the EJB annotations?
>>
>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>> Following this commit (r105574), the tests in the
>>> o.j.t.clustered.clusteredentity package started failing.[1] I brought an
>>> AS checkout up to the commit before that (r105506) and they pass, but
>>> with the r105574 commit they start failing.
>>>
>>> The tests deploy ejb3 jars with persistence units included. The tests
>>> are failing because the EJBs are not bound in JNDI. Looking at the logs
>>> there are no obvious failures during the artifact deployments. But
>>> there's no logging from any EJB3 deployers, just from Hibernate.
>>>
>>> [1]
>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>
>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>> I've just updated the AS trunk with new Scanning lib.
>>>> It also includes some other MC changes: Reflect, MDR, Kernel, CL,
>>>> Deployers.
>>>>
>>>> Apart from AnnotationRepository (which was already there with the
>>>> old code),
>>>> I've also hacked around Hibernate's Scanner a bit, so it uses
new
>>>> scanning lib's ScannerImpl.
>>>> (the hack is mostly in place due to some impl issues in Hibernate
>>>> itself, Emmanuel is working on it)
>>>>
>>>> JSF can now use new JBossAnnotationProvider -- let me know how that
>>>> goes Stan.
>>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>>
>>>> WeldScanningPlugin is currently commented out.
>>>> We need to disable one of the deployers in plugin's favor.
>>>> Pete, let me know when the new Weld release is coming in,
>>>> and I'll enable the plugin + run a few tests.
>>>>
>>>> All in all, if you spot any issues / regressions wrt this change,
>>>> let me know, and I'll try to fix the stuff asap.
>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> <mailto:jboss-development@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>
>> --
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> <mailto:jboss-development@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jboss-development
8:49 p.m.
I'll poke into this some more this afternoon and will file a JIRA. I
suspect it will be easy enough to isolate; there's ZERO logging from any
EJB3 deployer, so something pretty early in the process must be going wrong.
On 06/07/2010 12:38 PM, Jaikiran Pai wrote:
Is there a JIRA around this one? We are seeing similar clustering
deployment failures in our EJB3 build environment. I haven't yet looked
into the details to see what exactly causes the issue.
-Jaikiran
Brian Stansberry wrote:
> Still fails.
>
> I don't think the problem is on the JPA side -- or at least that's not
> the obvious surface problem. The persistence unit deployment seems to
> go ok.
>
> The obvious surface problem is that during the deployment there is no
> logging by any EJB3 related deployers. The session beans the test
> invokes on are not getting deployed.
>
> On 06/03/2010 03:17 PM, Ales Justin wrote:
>> The JPA has known issues:
>>
>>> https://jira.jboss.org/browse/JBJPA-29
>>> https://jira.jboss.org/browse/JBAS-8064
>> ALR already fixed this with new jpa.vfs3 release.
>> And Shelly just confirmed this now works as expected.
>>
>> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
>> Can you try it and let us know if this also works for you?
>>
>>
>> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>>
>>> The tests artifacts are jars that all have this structure:
>>>
>>> META-INF/
>>> ++ MANIFEST.MF (w/ nothing interesting
>>> ++ persistence.xml
>>> org/blah/...
>>>
>>> where some of the classes are entities and some are annotated EJB3
>>> session beans. No ejb-jar.xml or jboss.xml.
>>>
>>> The testsuite/output/lib/clusteredentity-test.jar is a good example.
>>>
>>> In some but not all tests the jar is packaged in an ear along with a
>>> datasource.
>>>
>>> There's no EJB3 deployer logging, so perhaps the scanning isn't
picking
>>> up the EJB annotations?
>>>
>>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>>> Following this commit (r105574), the tests in the
>>>> o.j.t.clustered.clusteredentity package started failing.[1] I
>>>> brought an
>>>> AS checkout up to the commit before that (r105506) and they pass, but
>>>> with the r105574 commit they start failing.
>>>>
>>>> The tests deploy ejb3 jars with persistence units included. The tests
>>>> are failing because the EJBs are not bound in JNDI. Looking at the
>>>> logs
>>>> there are no obvious failures during the artifact deployments. But
>>>> there's no logging from any EJB3 deployers, just from Hibernate.
>>>>
>>>> [1]
>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>
>>>>
>>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>>> I've just updated the AS trunk with new Scanning lib.
>>>>> It also includes some other MC changes: Reflect, MDR, Kernel, CL,
>>>>> Deployers.
>>>>>
>>>>> Apart from AnnotationRepository (which was already there with the
>>>>> old code),
>>>>> I've also hacked around Hibernate's Scanner a bit, so it uses
new
>>>>> scanning lib's ScannerImpl.
>>>>> (the hack is mostly in place due to some impl issues in Hibernate
>>>>> itself, Emmanuel is working on it)
>>>>>
>>>>> JSF can now use new JBossAnnotationProvider -- let me know how that
>>>>> goes Stan.
>>>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>>>
>>>>> WeldScanningPlugin is currently commented out.
>>>>> We need to disable one of the deployers in plugin's favor.
>>>>> Pete, let me know when the new Weld release is coming in,
>>>>> and I'll enable the plugin + run a few tests.
>>>>>
>>>>> All in all, if you spot any issues / regressions wrt this change,
>>>>> let me know, and I'll try to fix the stuff asap.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>
>>> --
>>> Brian Stansberry
>>> Lead, AS Clustering
>>> JBoss by Red Hat
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> <mailto:jboss-development@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
6:37 a.m.
Found it; should be easy to fix. Deployments whose names include the
string "cluster" aren't being scanned.
https://jira.jboss.org/browse/JBAS-8076
This problem may be the cause of some other failures as well, as
deployments including the string "hornetq" or "security" in their
names
will have the problem.
On 06/07/2010 01:49 PM, Brian Stansberry wrote:
I'll poke into this some more this afternoon and will file a
JIRA. I
suspect it will be easy enough to isolate; there's ZERO logging from any
EJB3 deployer, so something pretty early in the process must be going wrong.
On 06/07/2010 12:38 PM, Jaikiran Pai wrote:
> Is there a JIRA around this one? We are seeing similar clustering
> deployment failures in our EJB3 build environment. I haven't yet looked
> into the details to see what exactly causes the issue.
>
> -Jaikiran
> Brian Stansberry wrote:
>> Still fails.
>>
>> I don't think the problem is on the JPA side -- or at least that's not
>> the obvious surface problem. The persistence unit deployment seems to
>> go ok.
>>
>> The obvious surface problem is that during the deployment there is no
>> logging by any EJB3 related deployers. The session beans the test
>> invokes on are not getting deployed.
>>
>> On 06/03/2010 03:17 PM, Ales Justin wrote:
>>> The JPA has known issues:
>>>
>>>> https://jira.jboss.org/browse/JBJPA-29
>>>> https://jira.jboss.org/browse/JBAS-8064
>>> ALR already fixed this with new jpa.vfs3 release.
>>> And Shelly just confirmed this now works as expected.
>>>
>>> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
>>> Can you try it and let us know if this also works for you?
>>>
>>>
>>> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>>>
>>>> The tests artifacts are jars that all have this structure:
>>>>
>>>> META-INF/
>>>> ++ MANIFEST.MF (w/ nothing interesting
>>>> ++ persistence.xml
>>>> org/blah/...
>>>>
>>>> where some of the classes are entities and some are annotated EJB3
>>>> session beans. No ejb-jar.xml or jboss.xml.
>>>>
>>>> The testsuite/output/lib/clusteredentity-test.jar is a good example.
>>>>
>>>> In some but not all tests the jar is packaged in an ear along with a
>>>> datasource.
>>>>
>>>> There's no EJB3 deployer logging, so perhaps the scanning isn't
picking
>>>> up the EJB annotations?
>>>>
>>>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>>>> Following this commit (r105574), the tests in the
>>>>> o.j.t.clustered.clusteredentity package started failing.[1] I
>>>>> brought an
>>>>> AS checkout up to the commit before that (r105506) and they pass,
but
>>>>> with the r105574 commit they start failing.
>>>>>
>>>>> The tests deploy ejb3 jars with persistence units included. The
tests
>>>>> are failing because the EJBs are not bound in JNDI. Looking at the
>>>>> logs
>>>>> there are no obvious failures during the artifact deployments. But
>>>>> there's no logging from any EJB3 deployers, just from Hibernate.
>>>>>
>>>>> [1]
>>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>
>>>>>
>>>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>>>> I've just updated the AS trunk with new Scanning lib.
>>>>>> It also includes some other MC changes: Reflect, MDR, Kernel,
CL,
>>>>>> Deployers.
>>>>>>
>>>>>> Apart from AnnotationRepository (which was already there with
the
>>>>>> old code),
>>>>>> I've also hacked around Hibernate's Scanner a bit, so it
uses new
>>>>>> scanning lib's ScannerImpl.
>>>>>> (the hack is mostly in place due to some impl issues in
Hibernate
>>>>>> itself, Emmanuel is working on it)
>>>>>>
>>>>>> JSF can now use new JBossAnnotationProvider -- let me know how
that
>>>>>> goes Stan.
>>>>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>>>>
>>>>>> WeldScanningPlugin is currently commented out.
>>>>>> We need to disable one of the deployers in plugin's favor.
>>>>>> Pete, let me know when the new Weld release is coming in,
>>>>>> and I'll enable the plugin + run a few tests.
>>>>>>
>>>>>> All in all, if you spot any issues / regressions wrt this
change,
>>>>>> let me know, and I'll try to fix the stuff asap.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Lead, AS Clustering
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> <mailto:jboss-development@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
7:59 a.m.
Thanks for looking into this Brian.
As for the issue, I think, as already pointed out by Remy, relying on
deployment file names in itself isn't a good way of filtering out
deployments. I know it's a good to have feature, but I believe it should
be more of a "user deployment" feature rather than for deployments that
are shipped by JBoss AS. From what I understand, the real fix is to add
a (empty?) jboss-scanning.xml to such deployments which shouldn't be
scanned. Or maybe there's a better way based on metadata (version)? I'll
create a separate JIRA for that, so that we can get rid of these name
based filtering (atleast for JBoss AS shipped deployments).
regards,
-Jaikiran
Brian Stansberry wrote:
Found it; should be easy to fix. Deployments whose names include the
string "cluster" aren't being scanned.
https://jira.jboss.org/browse/JBAS-8076
This problem may be the cause of some other failures as well, as
deployments including the string "hornetq" or "security" in their
names will have the problem.
On 06/07/2010 01:49 PM, Brian Stansberry wrote:
> I'll poke into this some more this afternoon and will file a JIRA. I
> suspect it will be easy enough to isolate; there's ZERO logging from any
> EJB3 deployer, so something pretty early in the process must be going
> wrong.
>
> On 06/07/2010 12:38 PM, Jaikiran Pai wrote:
>> Is there a JIRA around this one? We are seeing similar clustering
>> deployment failures in our EJB3 build environment. I haven't yet looked
>> into the details to see what exactly causes the issue.
>>
>> -Jaikiran
>> Brian Stansberry wrote:
>>> Still fails.
>>>
>>> I don't think the problem is on the JPA side -- or at least that's
not
>>> the obvious surface problem. The persistence unit deployment seems to
>>> go ok.
>>>
>>> The obvious surface problem is that during the deployment there is no
>>> logging by any EJB3 related deployers. The session beans the test
>>> invokes on are not getting deployed.
>>>
>>> On 06/03/2010 03:17 PM, Ales Justin wrote:
>>>> The JPA has known issues:
>>>>
>>>>> https://jira.jboss.org/browse/JBJPA-29
>>>>> https://jira.jboss.org/browse/JBAS-8064
>>>> ALR already fixed this with new jpa.vfs3 release.
>>>> And Shelly just confirmed this now works as expected.
>>>>
>>>> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
>>>> Can you try it and let us know if this also works for you?
>>>>
>>>>
>>>> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>>>>
>>>>> The tests artifacts are jars that all have this structure:
>>>>>
>>>>> META-INF/
>>>>> ++ MANIFEST.MF (w/ nothing interesting
>>>>> ++ persistence.xml
>>>>> org/blah/...
>>>>>
>>>>> where some of the classes are entities and some are annotated EJB3
>>>>> session beans. No ejb-jar.xml or jboss.xml.
>>>>>
>>>>> The testsuite/output/lib/clusteredentity-test.jar is a good example.
>>>>>
>>>>> In some but not all tests the jar is packaged in an ear along with a
>>>>> datasource.
>>>>>
>>>>> There's no EJB3 deployer logging, so perhaps the scanning
isn't
>>>>> picking
>>>>> up the EJB annotations?
>>>>>
>>>>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>>>>> Following this commit (r105574), the tests in the
>>>>>> o.j.t.clustered.clusteredentity package started failing.[1] I
>>>>>> brought an
>>>>>> AS checkout up to the commit before that (r105506) and they
>>>>>> pass, but
>>>>>> with the r105574 commit they start failing.
>>>>>>
>>>>>> The tests deploy ejb3 jars with persistence units included. The
>>>>>> tests
>>>>>> are failing because the EJBs are not bound in JNDI. Looking at
the
>>>>>> logs
>>>>>> there are no obvious failures during the artifact deployments.
But
>>>>>> there's no logging from any EJB3 deployers, just from
Hibernate.
>>>>>>
>>>>>> [1]
>>>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>>>>> I've just updated the AS trunk with new Scanning lib.
>>>>>>> It also includes some other MC changes: Reflect, MDR, Kernel,
CL,
>>>>>>> Deployers.
>>>>>>>
>>>>>>> Apart from AnnotationRepository (which was already there with
the
>>>>>>> old code),
>>>>>>> I've also hacked around Hibernate's Scanner a bit, so
it uses new
>>>>>>> scanning lib's ScannerImpl.
>>>>>>> (the hack is mostly in place due to some impl issues in
Hibernate
>>>>>>> itself, Emmanuel is working on it)
>>>>>>>
>>>>>>> JSF can now use new JBossAnnotationProvider -- let me know
how
>>>>>>> that
>>>>>>> goes Stan.
>>>>>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>>>>>
>>>>>>> WeldScanningPlugin is currently commented out.
>>>>>>> We need to disable one of the deployers in plugin's
favor.
>>>>>>> Pete, let me know when the new Weld release is coming in,
>>>>>>> and I'll enable the plugin + run a few tests.
>>>>>>>
>>>>>>> All in all, if you spot any issues / regressions wrt this
change,
>>>>>>> let me know, and I'll try to fix the stuff asap.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Lead, AS Clustering
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>
>
8:11 a.m.
Thanks Brian,
this would also solve the issue I mentioned in a comment on JBAS-8060.
Cheers
Alessio
Brian Stansberry wrote:
Found it; should be easy to fix. Deployments whose names include the
string "cluster" aren't being scanned.
https://jira.jboss.org/browse/JBAS-8076
This problem may be the cause of some other failures as well, as
deployments including the string "hornetq" or "security" in their
names
will have the problem.
On 06/07/2010 01:49 PM, Brian Stansberry wrote:
> I'll poke into this some more this afternoon and will file a JIRA. I
> suspect it will be easy enough to isolate; there's ZERO logging from any
> EJB3 deployer, so something pretty early in the process must be going wrong.
>
> On 06/07/2010 12:38 PM, Jaikiran Pai wrote:
>
>> Is there a JIRA around this one? We are seeing similar clustering
>> deployment failures in our EJB3 build environment. I haven't yet looked
>> into the details to see what exactly causes the issue.
>>
>> -Jaikiran
>> Brian Stansberry wrote:
>>
>>> Still fails.
>>>
>>> I don't think the problem is on the JPA side -- or at least that's
not
>>> the obvious surface problem. The persistence unit deployment seems to
>>> go ok.
>>>
>>> The obvious surface problem is that during the deployment there is no
>>> logging by any EJB3 related deployers. The session beans the test
>>> invokes on are not getting deployed.
>>>
>>> On 06/03/2010 03:17 PM, Ales Justin wrote:
>>>
>>>> The JPA has known issues:
>>>>
>>>>
>>>>> https://jira.jboss.org/browse/JBJPA-29
>>>>> https://jira.jboss.org/browse/JBAS-8064
>>>>>
>>>> ALR already fixed this with new jpa.vfs3 release.
>>>> And Shelly just confirmed this now works as expected.
>>>>
>>>> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
>>>> Can you try it and let us know if this also works for you?
>>>>
>>>>
>>>> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>>>>
>>>>
>>>>> The tests artifacts are jars that all have this structure:
>>>>>
>>>>> META-INF/
>>>>> ++ MANIFEST.MF (w/ nothing interesting
>>>>> ++ persistence.xml
>>>>> org/blah/...
>>>>>
>>>>> where some of the classes are entities and some are annotated EJB3
>>>>> session beans. No ejb-jar.xml or jboss.xml.
>>>>>
>>>>> The testsuite/output/lib/clusteredentity-test.jar is a good example.
>>>>>
>>>>> In some but not all tests the jar is packaged in an ear along with a
>>>>> datasource.
>>>>>
>>>>> There's no EJB3 deployer logging, so perhaps the scanning
isn't picking
>>>>> up the EJB annotations?
>>>>>
>>>>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>>>>
>>>>>> Following this commit (r105574), the tests in the
>>>>>> o.j.t.clustered.clusteredentity package started failing.[1] I
>>>>>> brought an
>>>>>> AS checkout up to the commit before that (r105506) and they pass,
but
>>>>>> with the r105574 commit they start failing.
>>>>>>
>>>>>> The tests deploy ejb3 jars with persistence units included. The
tests
>>>>>> are failing because the EJBs are not bound in JNDI. Looking at
the
>>>>>> logs
>>>>>> there are no obvious failures during the artifact deployments.
But
>>>>>> there's no logging from any EJB3 deployers, just from
Hibernate.
>>>>>>
>>>>>> [1]
>>>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>
>>>>>>
>>>>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>>>>
>>>>>>> I've just updated the AS trunk with new Scanning lib.
>>>>>>> It also includes some other MC changes: Reflect, MDR, Kernel,
CL,
>>>>>>> Deployers.
>>>>>>>
>>>>>>> Apart from AnnotationRepository (which was already there with
the
>>>>>>> old code),
>>>>>>> I've also hacked around Hibernate's Scanner a bit, so
it uses new
>>>>>>> scanning lib's ScannerImpl.
>>>>>>> (the hack is mostly in place due to some impl issues in
Hibernate
>>>>>>> itself, Emmanuel is working on it)
>>>>>>>
>>>>>>> JSF can now use new JBossAnnotationProvider -- let me know
how that
>>>>>>> goes Stan.
>>>>>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>>>>>
>>>>>>> WeldScanningPlugin is currently commented out.
>>>>>>> We need to disable one of the deployers in plugin's
favor.
>>>>>>> Pete, let me know when the new Weld release is coming in,
>>>>>>> and I'll enable the plugin + run a few tests.
>>>>>>>
>>>>>>> All in all, if you spot any issues / regressions wrt this
change,
>>>>>>> let me know, and I'll try to fix the stuff asap.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Lead, AS Clustering
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>
>
--
Alessio Soldano
Web Service Lead, JBoss
11:29 a.m.
Yeah, my mistake. :-(
I was too eager to exclude those dirs, that I then forgot about TODO that I put into the
xml file.
<!-- dirs TODO - fix exact names -->
I'll see how easy it is to add custom jboss-scanning.xml to those dirs'
deployments.
On Jun 8, 2010, at 8:11 AM, Alessio Soldano wrote:
Thanks Brian,
this would also solve the issue I mentioned in a comment on JBAS-8060.
Cheers
Alessio
Brian Stansberry wrote:
> Found it; should be easy to fix. Deployments whose names include the
> string "cluster" aren't being scanned.
>
> https://jira.jboss.org/browse/JBAS-8076
>
> This problem may be the cause of some other failures as well, as
> deployments including the string "hornetq" or "security" in their
names
> will have the problem.
>
> On 06/07/2010 01:49 PM, Brian Stansberry wrote:
>
>> I'll poke into this some more this afternoon and will file a JIRA. I
>> suspect it will be easy enough to isolate; there's ZERO logging from any
>> EJB3 deployer, so something pretty early in the process must be going wrong.
>>
>> On 06/07/2010 12:38 PM, Jaikiran Pai wrote:
>>
>>> Is there a JIRA around this one? We are seeing similar clustering
>>> deployment failures in our EJB3 build environment. I haven't yet looked
>>> into the details to see what exactly causes the issue.
>>>
>>> -Jaikiran
>>> Brian Stansberry wrote:
>>>
>>>> Still fails.
>>>>
>>>> I don't think the problem is on the JPA side -- or at least
that's not
>>>> the obvious surface problem. The persistence unit deployment seems to
>>>> go ok.
>>>>
>>>> The obvious surface problem is that during the deployment there is no
>>>> logging by any EJB3 related deployers. The session beans the test
>>>> invokes on are not getting deployed.
>>>>
>>>> On 06/03/2010 03:17 PM, Ales Justin wrote:
>>>>
>>>>> The JPA has known issues:
>>>>>
>>>>>
>>>>>> https://jira.jboss.org/browse/JBJPA-29
>>>>>> https://jira.jboss.org/browse/JBAS-8064
>>>>>>
>>>>> ALR already fixed this with new jpa.vfs3 release.
>>>>> And Shelly just confirmed this now works as expected.
>>>>>
>>>>> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
>>>>> Can you try it and let us know if this also works for you?
>>>>>
>>>>>
>>>>> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>>>>>
>>>>>
>>>>>> The tests artifacts are jars that all have this structure:
>>>>>>
>>>>>> META-INF/
>>>>>> ++ MANIFEST.MF (w/ nothing interesting
>>>>>> ++ persistence.xml
>>>>>> org/blah/...
>>>>>>
>>>>>> where some of the classes are entities and some are annotated
EJB3
>>>>>> session beans. No ejb-jar.xml or jboss.xml.
>>>>>>
>>>>>> The testsuite/output/lib/clusteredentity-test.jar is a good
example.
>>>>>>
>>>>>> In some but not all tests the jar is packaged in an ear along
with a
>>>>>> datasource.
>>>>>>
>>>>>> There's no EJB3 deployer logging, so perhaps the scanning
isn't picking
>>>>>> up the EJB annotations?
>>>>>>
>>>>>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>>>>>
>>>>>>> Following this commit (r105574), the tests in the
>>>>>>> o.j.t.clustered.clusteredentity package started failing.[1]
I
>>>>>>> brought an
>>>>>>> AS checkout up to the commit before that (r105506) and they
pass, but
>>>>>>> with the r105574 commit they start failing.
>>>>>>>
>>>>>>> The tests deploy ejb3 jars with persistence units included.
The tests
>>>>>>> are failing because the EJBs are not bound in JNDI. Looking
at the
>>>>>>> logs
>>>>>>> there are no obvious failures during the artifact
deployments. But
>>>>>>> there's no logging from any EJB3 deployers, just from
Hibernate.
>>>>>>>
>>>>>>> [1]
>>>>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>
>>>>>>>
>>>>>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>>>>>
>>>>>>>> I've just updated the AS trunk with new Scanning
lib.
>>>>>>>> It also includes some other MC changes: Reflect, MDR,
Kernel, CL,
>>>>>>>> Deployers.
>>>>>>>>
>>>>>>>> Apart from AnnotationRepository (which was already there
with the
>>>>>>>> old code),
>>>>>>>> I've also hacked around Hibernate's Scanner a
bit, so it uses new
>>>>>>>> scanning lib's ScannerImpl.
>>>>>>>> (the hack is mostly in place due to some impl issues in
Hibernate
>>>>>>>> itself, Emmanuel is working on it)
>>>>>>>>
>>>>>>>> JSF can now use new JBossAnnotationProvider -- let me
know how that
>>>>>>>> goes Stan.
>>>>>>>> And web can use ResourcesIndex from DeploymentUnit --
Remy.
>>>>>>>>
>>>>>>>> WeldScanningPlugin is currently commented out.
>>>>>>>> We need to disable one of the deployers in plugin's
favor.
>>>>>>>> Pete, let me know when the new Weld release is coming
in,
>>>>>>>> and I'll enable the plugin + run a few tests.
>>>>>>>>
>>>>>>>> All in all, if you spot any issues / regressions wrt this
change,
>>>>>>>> let me know, and I'll try to fix the stuff asap.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jboss-development mailing list
>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Lead, AS Clustering
>>>>>> JBoss by Red Hat
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>
>>
>
>
>
--
Alessio Soldano
Web Service Lead, JBoss
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:08 p.m.
I have upgraded to jboss-aop 2.2.1.Alpha3 and jboss-classpool 1.0.0.Alpha6 along with
updates to bootstrap/aop.xml + the classpath in Main.java.
https://jira.jboss.org/browse/JBAS-8081
https://jira.jboss.org/browse/JBAS-8082
https://jira.jboss.org/browse/JBAS-8083
This should fix the following from
https://jira.jboss.org/secure/attachment/12334744/jbas8060-test-regressio...
======================================================================
Test: org.jboss.test.aop.test.ScopedAnnotatedTestCase(aop-scoped)
2010-06-02 21:19:10,325 DEBUG
[org.jboss.aop.asintegration.jboss5.AOPDeploymentAopMetaDataDeployer] (RMI TCP
Connection(2)-127.0.0.1) Finished deploying
AbstractVFSDeploymentContext@7879273{vfs:///work/TRUNK/trunk/testsuite/output/lib/aop-scoped-annotated.sar/aop-scoped-annotated.aop/}
2010-06-02 21:19:11,786 DEBUG [org.jboss.scanning.deployers.ScanningDeployer] (RMI TCP
Connection(2)-127.0.0.1) Error during deploy:
vfs:///work/TRUNK/trunk/testsuite/output/lib/aop-scoped-annotated.sar/aop-scoped-annotated.aop/:
java.lang.Error: Error visiting
"/work/TRUNK/trunk/testsuite/output/lib/aop-scoped-annotated.sar/aop-scoped-annotated.aop/org/jboss/test/aop/jdk15annotated/NoInterfacesPOJO2.class"
at
org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:268)
[jboss-classloading-vfs.jar:2.2.0.Alpha5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:407)
[jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409)
[jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409)
[jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409)
[jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409)
[jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409)
[jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:395)
[jboss-vfs.jar:3.0.0.CR5]
at
org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102)
[jboss-classloading-vfs.jar:2.2.0.Alpha5]
at
org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181)
[:2.2.0.Alpha5]
at
org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111)
[:1.0.0.Alpha2]
at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96)
[:1.0.0.Alpha2]
at org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:90)
[:1.0.0.Alpha2]
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
[:2.2.0.Alpha5]
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832)
[:2.2.0.Alpha5]
<snip>
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: Null type
at
org.jboss.scanning.plugins.visitor.IgnoreSetErrorHandler.handleError(IgnoreSetErrorHandler.java:57)
[:1.0.0.Alpha2]
at
org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:91)
[:1.0.0.Alpha2]
at
org.jboss.scanning.annotations.plugins.AnnotationsScanningPlugin.visit(AnnotationsScanningPlugin.java:89)
[:1.0.0.Alpha2]
at
org.jboss.scanning.spi.helpers.ScanningPluginWrapper.visit(ScanningPluginWrapper.java:112)
[:1.0.0.Alpha2]
at
org.jboss.classloading.plugins.visitor.FederatedResourceVisitor.visit(FederatedResourceVisitor.java:101)
[jboss-classloading.jar:2.2.0.Alpha5]
at
org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:264)
[jboss-classloading-vfs.jar:2.2.0.Alpha5]
On 8 Jun 2010, at 10:29, Ales Justin wrote:
Yeah, my mistake. :-(
I was too eager to exclude those dirs, that I then forgot about TODO that I put into the
xml file.
<!-- dirs TODO - fix exact names -->
I'll see how easy it is to add custom jboss-scanning.xml to those dirs'
deployments.
On Jun 8, 2010, at 8:11 AM, Alessio Soldano wrote:
> Thanks Brian,
> this would also solve the issue I mentioned in a comment on JBAS-8060.
> Cheers
> Alessio
>
> Brian Stansberry wrote:
>> Found it; should be easy to fix. Deployments whose names include the
>> string "cluster" aren't being scanned.
>>
>> https://jira.jboss.org/browse/JBAS-8076
>>
>> This problem may be the cause of some other failures as well, as
>> deployments including the string "hornetq" or "security" in
their names
>> will have the problem.
>>
>> On 06/07/2010 01:49 PM, Brian Stansberry wrote:
>>
>>> I'll poke into this some more this afternoon and will file a JIRA. I
>>> suspect it will be easy enough to isolate; there's ZERO logging from any
>>> EJB3 deployer, so something pretty early in the process must be going wrong.
>>>
>>> On 06/07/2010 12:38 PM, Jaikiran Pai wrote:
>>>
>>>> Is there a JIRA around this one? We are seeing similar clustering
>>>> deployment failures in our EJB3 build environment. I haven't yet
looked
>>>> into the details to see what exactly causes the issue.
>>>>
>>>> -Jaikiran
>>>> Brian Stansberry wrote:
>>>>
>>>>> Still fails.
>>>>>
>>>>> I don't think the problem is on the JPA side -- or at least
that's not
>>>>> the obvious surface problem. The persistence unit deployment seems
to
>>>>> go ok.
>>>>>
>>>>> The obvious surface problem is that during the deployment there is
no
>>>>> logging by any EJB3 related deployers. The session beans the test
>>>>> invokes on are not getting deployed.
>>>>>
>>>>> On 06/03/2010 03:17 PM, Ales Justin wrote:
>>>>>
>>>>>> The JPA has known issues:
>>>>>>
>>>>>>
>>>>>>> https://jira.jboss.org/browse/JBJPA-29
>>>>>>> https://jira.jboss.org/browse/JBAS-8064
>>>>>>>
>>>>>> ALR already fixed this with new jpa.vfs3 release.
>>>>>> And Shelly just confirmed this now works as expected.
>>>>>>
>>>>>> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
>>>>>> Can you try it and let us know if this also works for you?
>>>>>>
>>>>>>
>>>>>> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>>>>>>
>>>>>>
>>>>>>> The tests artifacts are jars that all have this structure:
>>>>>>>
>>>>>>> META-INF/
>>>>>>> ++ MANIFEST.MF (w/ nothing interesting
>>>>>>> ++ persistence.xml
>>>>>>> org/blah/...
>>>>>>>
>>>>>>> where some of the classes are entities and some are annotated
EJB3
>>>>>>> session beans. No ejb-jar.xml or jboss.xml.
>>>>>>>
>>>>>>> The testsuite/output/lib/clusteredentity-test.jar is a good
example.
>>>>>>>
>>>>>>> In some but not all tests the jar is packaged in an ear along
with a
>>>>>>> datasource.
>>>>>>>
>>>>>>> There's no EJB3 deployer logging, so perhaps the scanning
isn't picking
>>>>>>> up the EJB annotations?
>>>>>>>
>>>>>>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>>>>>>
>>>>>>>> Following this commit (r105574), the tests in the
>>>>>>>> o.j.t.clustered.clusteredentity package started
failing.[1] I
>>>>>>>> brought an
>>>>>>>> AS checkout up to the commit before that (r105506) and
they pass, but
>>>>>>>> with the r105574 commit they start failing.
>>>>>>>>
>>>>>>>> The tests deploy ejb3 jars with persistence units
included. The tests
>>>>>>>> are failing because the EJBs are not bound in JNDI.
Looking at the
>>>>>>>> logs
>>>>>>>> there are no obvious failures during the artifact
deployments. But
>>>>>>>> there's no logging from any EJB3 deployers, just from
Hibernate.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>>>>>>
>>>>>>>>> I've just updated the AS trunk with new Scanning
lib.
>>>>>>>>> It also includes some other MC changes: Reflect, MDR,
Kernel, CL,
>>>>>>>>> Deployers.
>>>>>>>>>
>>>>>>>>> Apart from AnnotationRepository (which was already
there with the
>>>>>>>>> old code),
>>>>>>>>> I've also hacked around Hibernate's Scanner a
bit, so it uses new
>>>>>>>>> scanning lib's ScannerImpl.
>>>>>>>>> (the hack is mostly in place due to some impl issues
in Hibernate
>>>>>>>>> itself, Emmanuel is working on it)
>>>>>>>>>
>>>>>>>>> JSF can now use new JBossAnnotationProvider -- let me
know how that
>>>>>>>>> goes Stan.
>>>>>>>>> And web can use ResourcesIndex from DeploymentUnit --
Remy.
>>>>>>>>>
>>>>>>>>> WeldScanningPlugin is currently commented out.
>>>>>>>>> We need to disable one of the deployers in
plugin's favor.
>>>>>>>>> Pete, let me know when the new Weld release is coming
in,
>>>>>>>>> and I'll enable the plugin + run a few tests.
>>>>>>>>>
>>>>>>>>> All in all, if you spot any issues / regressions wrt
this change,
>>>>>>>>> let me know, and I'll try to fix the stuff asap.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-development mailing list
>>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Lead, AS Clustering
>>>>>>> JBoss by Red Hat
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>> <mailto:jboss-development@lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>
>>>
>>
>>
>>
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
> _______________________________________________
> 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
5077
days inactive
5083
days old
jboss-development@lists.jboss.org
38 comments
12 participants
participants (12)
-
Ales Justin -
Alessio Soldano -
Bill Burke -
Brian Stansberry -
David M. Lloyd -
Jaikiran Pai -
Kabir Khan -
Marius Bogoevici -
Pete Muir -
Rémy Maucherat -
Scott Marlow -
Stan Silvert