2 a.m.
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it
once (using NetBeans redeploying after sitting overnight). The sumptom is the
'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will
probably not work very well in this new thread anyway, unless you set the TCCL to the
correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it to
be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative
'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader
being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the
contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should
only be a problem when you start trying to use threads that you have spawned yourself to
interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as the
original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a
security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do that
stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any
class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it
portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which
screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving
and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang
around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both
those things in the same thread. Can I unset the TCCL at the end of the run() method (in a
finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2 a.m.
New subject: [JBoss JIRA] Updated: (SEAMCRON-15) CL issues on redeployment
[
https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugi...
]
Peter Royle updated SEAMCRON-15:
--------------------------------
Fix Version/s: 3.0.0.Alpha1
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Fix For: 3.0.0.Alpha1
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it
once (using NetBeans redeploying after sitting overnight). The sumptom is the
'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will
probably not work very well in this new thread anyway, unless you set the TCCL to the
correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it
to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative
'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader
being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the
contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should
only be a problem when you start trying to use threads that you have spawned yourself to
interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as
the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a
security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do
that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any
class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it
portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which
screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving
and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang
around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both
those things in the same thread. Can I unset the TCCL at the end of the run() method (in a
finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:52 a.m.
New subject: [JBoss JIRA] Updated: (SEAMCRON-15) CL issues on redeployment
[
https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugi...
]
Peter Royle updated SEAMCRON-15:
--------------------------------
Fix Version/s: 3.0.0.Alpha2
(was: 3.0.0.Alpha1)
Postponed until Alpha2 since SEAMCRON-23 appears to have addressed the symptoms at the
very least.
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Fix For: 3.0.0.Alpha2
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it
once (using NetBeans redeploying after sitting overnight). The sumptom is the
'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will
probably not work very well in this new thread anyway, unless you set the TCCL to the
correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it
to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative
'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader
being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the
contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should
only be a problem when you start trying to use threads that you have spawned yourself to
interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as
the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a
security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do
that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any
class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it
portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which
screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving
and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang
around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both
those things in the same thread. Can I unset the TCCL at the end of the run() method (in a
finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:52 a.m.
New subject: [JBoss JIRA] Commented: (SEAMCRON-15) CL issues on redeployment
[
https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugi...
]
Peter Royle commented on SEAMCRON-15:
-------------------------------------
Update: The issue was more likely being caused by the fact that the schedulers weren't
being shut down in Weld and were trying to fire in the background with absolutely no
context available to them. Having solved that (SEAMCRON-23) this issue seems to not show
up anymore. I will still apply the concepts Stuart described, but will put them off until
Alpha2 while we see how Alpha1 behaves without it.
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Fix For: 3.0.0.Alpha2
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it
once (using NetBeans redeploying after sitting overnight). The sumptom is the
'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will
probably not work very well in this new thread anyway, unless you set the TCCL to the
correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it
to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative
'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader
being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the
contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should
only be a problem when you start trying to use threads that you have spawned yourself to
interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as
the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a
security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do
that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any
class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it
portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which
screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving
and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang
around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both
those things in the same thread. Can I unset the TCCL at the end of the run() method (in a
finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:46 p.m.
New subject: [JBoss JIRA] Commented: (SEAMCRON-15) CL issues on redeployment
[
https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugi...
]
Sebastian Sachtleben commented on SEAMCRON-15:
----------------------------------------------
I use currently the latest Seam Cron SNAPSHOT and getting on jboss as 7 while shutdown:
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) Exception(s) thrown
during observer of BeforeShutdown
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) :
java.lang.IllegalStateException: Singleton not set for ModuleClassLoader for Module
"deployment.replicascene.war:main" from Service Module Loader
at
org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:71)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.weld.context.AbstractSharedContext.getBeanStore(AbstractSharedContext.java:54)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:94)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:693)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:264)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:62)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:50)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:499)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.as.weld.WeldContainer.stop(WeldContainer.java:102)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.weld.services.WeldService.stop(WeldService.java:103)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1869)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
On next publish I run into:
14:39:21,097 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread
1-13) Unsanitized stacktrace from failed start...:
com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException:
com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:C:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Ccom%5Csun%5Cjsf-impl%5Cmain%5Cjsf-impl-2.0.3-b05.jar!/com/sun/faces/jsf-ri-runtime.xml':
DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from
DTDDVFactory.
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:667)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:303)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:220)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
[jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.util.concurrent.ExecutionException:
com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:C:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Ccom%5Csun%5Cjsf-impl%5Cmain%5Cjsf-impl-2.0.3-b05.jar!/com/sun/faces/jsf-ri-runtime.xml':
DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from
DTDDVFactory.
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) [:1.6.0_21]
at java.util.concurrent.FutureTask.get(FutureTask.java:83) [:1.6.0_21]
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:665)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 10 more
Caused by: com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:C:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Ccom%5Csun%5Cjsf-impl%5Cmain%5Cjsf-impl-2.0.3-b05.jar!/com/sun/faces/jsf-ri-runtime.xml':
DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from
DTDDVFactory.
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:839)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:784)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_21]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_21]
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:653)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 10 more
Caused by: org.apache.xerces.impl.dv.DVFactoryException: DTD factory class
org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaValidator.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
org.apache.xerces.jaxp.validation.XMLSchemaValidatorComponentManager.<init>(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.ValidatorHandlerImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.AbstractXMLSchema.newValidatorHandler(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
__redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:119)
[jboss-modules.jar:1.0.1.GA]
at
com.sun.faces.config.ConfigManager$ParseTask.getBuilderForSchema(ConfigManager.java:1042)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.getDocument(ConfigManager.java:911)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:830)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 14 more
14:39:21,103 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/replicascene]] (MSC
service thread 1-13) Exception sending context initialized event to listener instance of
class com.sun.faces.config.ConfigureListener: com.sun.faces.config.ConfigurationException:
CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl
does not extend from DTDDVFactory.
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:220)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
[jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: org.apache.xerces.impl.dv.DVFactoryException: DTD factory class
org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaValidator.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
org.apache.xerces.jaxp.validation.XMLSchemaValidatorComponentManager.<init>(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.ValidatorHandlerImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.AbstractXMLSchema.newValidatorHandler(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
__redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:119)
[jboss-modules.jar:1.0.1.GA]
at
com.sun.faces.config.ConfigManager$ParseTask.getBuilderForSchema(ConfigManager.java:1042)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.getDocument(ConfigManager.java:911)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:830)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:784)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_21]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_21]
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:653)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:303)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 9 more
14:39:21,105 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-13)
Error listenerStart
14:39:21,105 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-13)
Context [/replicascene] startup failed due to previous errors
14:39:21,105 SCHWERWIEGEND [javax.enterprise.resource.webcontainer.jsf.config] (MSC
service thread 1-13) Unexpected exception when attempting to tear down the Mojarra
runtime: java.lang.IllegalStateException: Die Anwendung wurde bei Systemstart nicht
einwandfrei initialisiert, Factory konnte nicht gefunden werden:
javax.faces.application.ApplicationFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804)
[jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306)
[jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:104)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:312)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3465)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3970)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3888)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
[jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Without Seam Module dependency my application shutdown without exception and republish
works fine.
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Fix For: 3.0.0.Alpha2
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it
once (using NetBeans redeploying after sitting overnight). The sumptom is the
'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will
probably not work very well in this new thread anyway, unless you set the TCCL to the
correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it
to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative
'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader
being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the
contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should
only be a problem when you start trying to use threads that you have spawned yourself to
interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as
the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a
security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do
that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any
class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it
portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which
screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving
and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang
around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both
those things in the same thread. Can I unset the TCCL at the end of the run() method (in a
finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:54 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (SEAMCRON-15) CL issues on redeployment
[
https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugi...
]
Sebastian Sachtleben edited comment on SEAMCRON-15 at 8/19/11 8:52 AM:
-----------------------------------------------------------------------
I use currently the latest Seam Cron SNAPSHOT and getting on jboss as 7 while shutdown:
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) Exception(s) thrown
during observer of BeforeShutdown
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) :
java.lang.IllegalStateException: Singleton not set for ModuleClassLoader for Module
"deployment.replicascene.war:main" from Service Module Loader
at
org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:71)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.weld.context.AbstractSharedContext.getBeanStore(AbstractSharedContext.java:54)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:94)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:693)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:264)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:62)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:50)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:499)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.as.weld.WeldContainer.stop(WeldContainer.java:102)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.weld.services.WeldService.stop(WeldService.java:103)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1869)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
was (Author: cosmostunes):
I use currently the latest Seam Cron SNAPSHOT and getting on jboss as 7 while
shutdown:
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) Exception(s) thrown
during observer of BeforeShutdown
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) :
java.lang.IllegalStateException: Singleton not set for ModuleClassLoader for Module
"deployment.replicascene.war:main" from Service Module Loader
at
org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:71)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.weld.context.AbstractSharedContext.getBeanStore(AbstractSharedContext.java:54)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:94)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:693)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:264)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:62)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:50)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:499)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.as.weld.WeldContainer.stop(WeldContainer.java:102)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.weld.services.WeldService.stop(WeldService.java:103)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1869)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
On next publish I run into:
14:39:21,097 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread
1-13) Unsanitized stacktrace from failed start...:
com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException:
com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:C:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Ccom%5Csun%5Cjsf-impl%5Cmain%5Cjsf-impl-2.0.3-b05.jar!/com/sun/faces/jsf-ri-runtime.xml':
DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from
DTDDVFactory.
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:667)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:303)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:220)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
[jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.util.concurrent.ExecutionException:
com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:C:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Ccom%5Csun%5Cjsf-impl%5Cmain%5Cjsf-impl-2.0.3-b05.jar!/com/sun/faces/jsf-ri-runtime.xml':
DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from
DTDDVFactory.
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) [:1.6.0_21]
at java.util.concurrent.FutureTask.get(FutureTask.java:83) [:1.6.0_21]
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:665)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 10 more
Caused by: com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:C:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Ccom%5Csun%5Cjsf-impl%5Cmain%5Cjsf-impl-2.0.3-b05.jar!/com/sun/faces/jsf-ri-runtime.xml':
DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from
DTDDVFactory.
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:839)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:784)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_21]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_21]
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:653)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 10 more
Caused by: org.apache.xerces.impl.dv.DVFactoryException: DTD factory class
org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaValidator.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
org.apache.xerces.jaxp.validation.XMLSchemaValidatorComponentManager.<init>(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.ValidatorHandlerImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.AbstractXMLSchema.newValidatorHandler(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
__redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:119)
[jboss-modules.jar:1.0.1.GA]
at
com.sun.faces.config.ConfigManager$ParseTask.getBuilderForSchema(ConfigManager.java:1042)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.getDocument(ConfigManager.java:911)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:830)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 14 more
14:39:21,103 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/replicascene]] (MSC
service thread 1-13) Exception sending context initialized event to listener instance of
class com.sun.faces.config.ConfigureListener: com.sun.faces.config.ConfigurationException:
CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl
does not extend from DTDDVFactory.
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:220)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
[jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: org.apache.xerces.impl.dv.DVFactoryException: DTD factory class
org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.impl.xs.XMLSchemaValidator.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
org.apache.xerces.jaxp.validation.XMLSchemaValidatorComponentManager.<init>(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.ValidatorHandlerImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.validation.AbstractXMLSchema.newValidatorHandler(Unknown
Source) [xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source)
[xercesImpl-2.9.1.jar:]
at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
[xercesImpl-2.9.1.jar:]
at
__redirected.__DocumentBuilderFactory.newDocumentBuilder(__DocumentBuilderFactory.java:119)
[jboss-modules.jar:1.0.1.GA]
at
com.sun.faces.config.ConfigManager$ParseTask.getBuilderForSchema(ConfigManager.java:1042)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.getDocument(ConfigManager.java:911)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:830)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:784)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_21]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_21]
at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:653)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:303)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
... 9 more
14:39:21,105 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-13)
Error listenerStart
14:39:21,105 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-13)
Context [/replicascene] startup failed due to previous errors
14:39:21,105 SCHWERWIEGEND [javax.enterprise.resource.webcontainer.jsf.config] (MSC
service thread 1-13) Unexpected exception when attempting to tear down the Mojarra
runtime: java.lang.IllegalStateException: Die Anwendung wurde bei Systemstart nicht
einwandfrei initialisiert, Factory konnte nicht gefunden werden:
javax.faces.application.ApplicationFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804)
[jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306)
[jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:104)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:312)
[jsf-impl-2.0.3-b05.jar:2.0.3-]
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3465)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3970)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3888)
[jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
[jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Without Seam Module dependency my application shutdown without exception and republish
works fine.
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Fix For: 3.0.0.Alpha2
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it
once (using NetBeans redeploying after sitting overnight). The sumptom is the
'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will
probably not work very well in this new thread anyway, unless you set the TCCL to the
correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it
to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative
'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader
being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the
contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should
only be a problem when you start trying to use threads that you have spawned yourself to
interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as
the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a
security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do
that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any
class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it
portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which
screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving
and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang
around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both
those things in the same thread. Can I unset the TCCL at the end of the run() method (in a
finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:54 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (SEAMCRON-15) CL issues on redeployment
[
https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugi...
]
Sebastian Sachtleben edited comment on SEAMCRON-15 at 8/19/11 8:53 AM:
-----------------------------------------------------------------------
I use currently the latest Seam Cron SNAPSHOT and getting on jboss as 7 while shutdown:
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) Exception(s) thrown
during observer of BeforeShutdown
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) :
java.lang.IllegalStateException: Singleton not set for ModuleClassLoader for Module
"deployment.test.war:main" from Service Module Loader
at
org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:71)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.weld.context.AbstractSharedContext.getBeanStore(AbstractSharedContext.java:54)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:94)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:693)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:264)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:62)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:50)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:499)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.as.weld.WeldContainer.stop(WeldContainer.java:102)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.weld.services.WeldService.stop(WeldService.java:103)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1869)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
was (Author: cosmostunes):
I use currently the latest Seam Cron SNAPSHOT and getting on jboss as 7 while
shutdown:
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) Exception(s) thrown
during observer of BeforeShutdown
14:39:12,107 ERROR [org.jboss.weld.Bootstrap] (MSC service thread 1-7) :
java.lang.IllegalStateException: Singleton not set for ModuleClassLoader for Module
"deployment.replicascene.war:main" from Service Module Loader
at
org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:71)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.weld.context.AbstractSharedContext.getBeanStore(AbstractSharedContext.java:54)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:94)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:693)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:264)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at
org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:62)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdownImpl.java:50)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:499)
[weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.as.weld.WeldContainer.stop(WeldContainer.java:102)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.weld.services.WeldService.stop(WeldService.java:103)
[jboss-as-weld-7.0.1.Final.jar:7.0.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1869)
at
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Fix For: 3.0.0.Alpha2
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it
once (using NetBeans redeploying after sitting overnight). The sumptom is the
'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will
probably not work very well in this new thread anyway, unless you set the TCCL to the
correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it
to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative
'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader
being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the
contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should
only be a problem when you start trying to use threads that you have spawned yourself to
interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as
the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a
security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do
that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any
class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it
portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which
screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving
and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang
around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both
those things in the same thread. Can I unset the TCCL at the end of the run() method (in a
finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4780
days inactive
4874
days old
6 comments
2 participants
participants (2)
-
Peter Royle (JIRA) -
Sebastian Sachtleben (JIRA)