[JBoss JIRA] Created: (AS7-1684) Add configuration setting that allows an extended persistence context to be propagated even if there is no JTA transaction
by Scott Marlow (JIRA)
Add configuration setting that allows an extended persistence context to be propagated even if there is no JTA transaction
---------------------------------------------------------------------------------------------------------------------------
Key: AS7-1684
URL: https://issues.jboss.org/browse/AS7-1684
Project: Application Server 7
Issue Type: Feature Request
Components: JPA / Hibernate
Affects Versions: 7.0.0.Beta2
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 7.1.0.Beta1
Earlier versions of AS, allowed an extended persistence context (XPC) to propagate, even if no JTA transaction was active during use of the XPC. With the recent fix to AS7-1663, using an XPC outside of a JTA transaction and then invoking a transactional entity manager inside of a JTA transaction, will not propagate the XPC into the new transaction.
Add a domain default setting that allows the (not used in a JTA transaction) XPC to propagate into the new transaction (on behalf of a transactional entity manager). This will only happen if the XPC is active in the call stack.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 12 months
[JBoss JIRA] Created: (JBWEB-211) Jasper Parser drops exception root cause
by Andrew Sacamano (JIRA)
Jasper Parser drops exception root cause
----------------------------------------
Key: JBWEB-211
URL: https://issues.jboss.org/browse/JBWEB-211
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tomcat
Affects Versions: JBossWeb-2.1.9.GA
Environment: All
Reporter: Andrew Sacamano
Assignee: Remy Maucherat
Priority: Minor
Line 342 in of java/org/apache/jasper/compiler/Parser.java (see below) commits one of the cardinal sins of exception handling - it drops the original stack trace, and original root causes.
This has contributed to the premature grey hair of one of our sysadmins, as he tries to sort out why a particular tag is causing the JSP compiler to puke.
327
328 /*
329 * Invokes parserController to parse the included page
330 */
331 private void processIncludeDirective(String file, Node parent)
332 throws JasperException {
333 if (file == null) {
334 return;
335 }
336
337 try {
338 parserController.parse(file, parent, jarFileUrl);
339 } catch (FileNotFoundException ex) {
340 err.jspError(start, "jsp.error.file.not.found", file);
341 } catch (Exception ex) {
342 err.jspError(start, ex.getMessage());
343 }
344 }
345
It looks like there is a bit of work involved to craft a better response, perhaps adding another jspError variant - but surely the actual exception is important enough to go through the effort.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 12 months
[JBoss JIRA] (AS7-3180) Clean shutdown often results in "Problems unmarshalling remote command from byte buffer"
by Radoslav Husar (Created) (JIRA)
Clean shutdown often results in "Problems unmarshalling remote command from byte buffer"
----------------------------------------------------------------------------------------
Key: AS7-3180
URL: https://issues.jboss.org/browse/AS7-3180
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.0.CR1
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.0.Final
When shutting down a server from a cluster, it often results in
WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Cache manager is either starting up or shutting down but it's not interrupted, so type (id=74) cannot be resolved.
incluing verbose logging which doesnt seem necessary
and jgroups logs
[JBossINF] 12:28:22,392 SEVERE [org.jgroups.protocols.UNICAST2] perf19/web: sender window for perf21/web not found
is this a real problem? if not, can it be handled more cleanly?
{noformat}
[JBossINF] 12:28:21,960 INFO [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-7) Pausing Coyote HTTP/1.1 on http-perf19-10.16.90.56-8080
[JBossINF] 12:28:21,961 INFO [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-7) Stopping Coyote HTTP/1.1 on http-perf19-10.16.90.56-8080
[JBossINF] 12:28:21,974 INFO [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
[JBossINF] 12:28:21,975 INFO [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
[JBossINF] 12:28:22,008 INFO [org.jboss.as.clustering] JBAS010302: Stopped org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB cache from sfsb container
[JBossINF] 12:28:22,010 INFO [org.hornetq.core.server.impl.HornetQServerImpl] HornetQ Server version 2.2.7.Final (HQ_2_2_7_FINAL_AS7, 121) [be9627f1-362f-11e1-986b-d4856468f854] stopped
[JBossINF] 12:28:22,012 INFO [org.apache.coyote.ajp.AjpAprProtocol] Pausing Coyote AJP/1.3 on ajp-perf19-10.16.90.56-8009
[JBossINF] 12:28:22,012 INFO [org.apache.coyote.ajp.AjpAprProtocol] Stopping Coyote AJP/1.3 on ajp-perf19-10.16.90.56-8009
[JBossINF] 12:28:22,013 INFO [org.jboss.as.clustering] JBAS010302: Stopped org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl cache from sfsb container
[JBossINF] 12:28:22,022 INFO [jacorb.poa] POA RootPOA destroyed
[JBossINF] 12:28:22,029 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
[JBossINF] 12:28:22,029 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
[JBossINF] 12:28:22,030 INFO [jacorb.orb] prepare ORB for shutdown...
[JBossINF] 12:28:22,030 INFO [jacorb.orb] ORB going down...
[JBossINF] 12:28:22,031 INFO [jacorb.orb] ORB shutdown complete
[JBossINF] 12:28:22,032 INFO [jacorb.orb] ORB run, exit
[JBossINF] 12:28:22,032 INFO [jacorb.orb.iiop] Listener exited
[JBossINF] 12:28:22,036 INFO [org.jboss.weld] Stopping weld service
[JBossINF] 12:28:22,038 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
[JBossINF] 12:28:22,038 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
[JBossINF] 12:28:22,047 INFO [org.jboss.as.server.deployment] Stopped deployment clusterbench-ee6-ejb.jar in 91ms
[JBossINF] 12:28:22,048 INFO [org.jboss.as.server.deployment] Stopped deployment clusterbench-ee6-web.war in 91ms
[JBossINF] 12:28:22,049 INFO [org.jboss.as.server.deployment] Stopped deployment clusterbench-ee6.ear in 97ms
[JBossINF] 12:28:22,057 INFO [org.jboss.as.clustering] JBAS010302: Stopped registry cache from web container
[JBossINF] 12:28:22,063 INFO [org.jboss.as.clustering] JBAS010302: Stopped repl cache from web container
[JBossINF] 12:28:22,069 INFO [org.jboss.as.clustering] JBAS010302: Stopped repl cache from sfsb container
[JBossINF] 12:28:22,336 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
[JBossINF] 12:28:22,392 SEVERE [org.jgroups.protocols.UNICAST2] perf19/web: sender window for perf21/web not found
[JBossINF] 12:28:22,440 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
[JBossINF] 12:28:22,441 INFO [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying TransactionManagerService
[JBossINF] 12:28:22,442 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager
[JBossINF] 12:28:22,463 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Cache manager is either starting up or shutting down but it's not interrupted, so type (id=74) cannot be resolved.
[JBossINF] at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:257) [infinispan-core-5.1.0.CR1.jar:5.1.0.CR1]
[JBossINF] at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
[JBossINF] at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
[JBossINF] at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.4.GA.jar:1.3.4.GA]
[JBossINF] at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:120) [infinispan-core-5.1.0.CR1.jar:5.1.0.CR1]
[JBossINF] at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:115) [infinispan-core-5.1.0.CR1.jar:5.1.0.CR1]
[JBossINF] at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:79) [infinispan-core-5.1.0.CR1.jar:5.1.0.CR1]
[JBossINF] at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:50) [infinispan-core-5.1.0.CR1.jar:5.1.0.CR1]
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:139) [infinispan-core-5.1.0.CR1.jar:5.1.0.CR1]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:447) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:354) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:230) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:556) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler.up(ClassLoaderAwareUpHandler.java:56) [jboss-as-clustering-jgroups-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
[JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jboss.as.clustering.jgroups.MuxChannel$ClassLoaderAwareMuxUpHandler.up(MuxChannel.java:64) [jboss-as-clustering-jgroups-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
[JBossINF] at org.jgroups.JChannel.up(JChannel.java:716) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:481) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:178) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:881) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:383) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:733) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:561) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:126) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:140) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.FD.up(FD.java:273) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:284) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:354) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:358) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1174) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1709) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1691) [jgroups-3.0.1.Final.jar:3.0.1.Final]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
[JBossINF]
[JBossINF] 12:28:22,809 INFO [org.jboss.as] JBoss AS 7.1.0.Final-SNAPSHOT "Flux Capacitor" stopped in 815ms
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 12 months
[JBoss JIRA] Created: (AS7-1976) WAR file using WAR_BUNDLES_JSF_IMPL embedded in an EAR file fails deployment
by Oren Samuel (JIRA)
WAR file using WAR_BUNDLES_JSF_IMPL embedded in an EAR file fails deployment
----------------------------------------------------------------------------
Key: AS7-1976
URL: https://issues.jboss.org/browse/AS7-1976
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.0.2.Final, 7.0.1.Final
Reporter: Oren Samuel
Assignee: Remy Maucherat
EAR file containing a WAR file that bundles Myfaces 1.2.7 fails deployment (trying to load JSF 2 libraries although WAR_BUNDLES_JSF_IMPL is set)
15:27:59,585 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.subunit."MyFacesTest.ear"."myfacesTest.war".INSTALL: org
.jboss.msc.service.StartException in service jboss.deployment.subunit."MyFacesTest.ear"."myfacesTest.war".INSTALL: Failed to process phase INSTALL of subdeployment "myfacesTest.war
" of deployment "MyFacesTest.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
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.lang.RuntimeException: Failed to load class com.sun.faces.config.ConfigureListener
at org.jboss.as.ee.component.deployers.EEClassConfigurationProcessor$1.compute(EEClassConfigurationProcessor.java:141)
at org.jboss.as.ee.component.deployers.EEClassConfigurationProcessor$1.compute(EEClassConfigurationProcessor.java:122)
at org.jboss.as.ee.component.LazyValue.get(LazyValue.java:40)
at org.jboss.as.ee.component.EEApplicationDescription.getClassConfiguration(EEApplicationDescription.java:183)
at org.jboss.as.ee.component.ComponentDescription.createConfiguration(ComponentDescription.java:153)
at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:70)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
... 5 more
Caused by: java.lang.ClassNotFoundException: com.sun.faces.config.ConfigureListener from [Module "deployment.MyFacesTest.ear.myfacesTest.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103)
at java.lang.Class.forName0(Native Method) [:1.6.0_21]
at java.lang.Class.forName(Class.java:247) [:1.6.0_21]
at org.jboss.as.ee.component.deployers.EEClassConfigurationProcessor$1.compute(EEClassConfigurationProcessor.java:139)
... 11 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 12 months
[JBoss JIRA] (AS7-2325) Get rid of reflection configuring the ProtocolHandler in WebConnectorService
by Kabir Khan (Created) (JIRA)
Get rid of reflection configuring the ProtocolHandler in WebConnectorService
----------------------------------------------------------------------------
Key: AS7-2325
URL: https://issues.jboss.org/browse/AS7-2325
Project: Application Server 7
Issue Type: Feature Request
Components: Web
Reporter: Kabir Khan
Assignee: Remy Maucherat
Fix For: 7.1.0.CR1
A lot of the set methods do
{code}
if (ssl.hasDefined(Constants.PASSWORD)) {
Method m = connector.getProtocolHandler().getClass().getMethod("setSSLPassword", String.class);
m.invoke(connector.getProtocolHandler(), ssl.get(Constants.PASSWORD).asString());
}
if (ssl.hasDefined(Constants.CERTIFICATE_KEY_FILE)) {
Method m = connector.getProtocolHandler().getClass().getMethod("setSSLCertificateKeyFile", String.class);
m.invoke(connector.getProtocolHandler(), ssl.get(Constants.CERTIFICATE_KEY_FILE).asString());
}
//etc.
{code}
The ProtocolHandler inteface does not expose them, so maybe they should go there or another common interface for configuring PH's
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 12 months
[JBoss JIRA] Created: (AS7-1663) An extended persistence context should not be propagated if there is no JTA transaction
by Scott Marlow (JIRA)
An extended persistence context should not be propagated if there is no JTA transaction
---------------------------------------------------------------------------------------
Key: AS7-1663
URL: https://issues.jboss.org/browse/AS7-1663
Project: Application Server 7
Issue Type: Feature Request
Components: JPA / Hibernate
Affects Versions: 7.0.0.Final
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 7.0.2.Final
JPA 2.0 specification section 7.6.3.1 Requirements for Persistence Context Propagation:
"
Persistence contexts are propagated by the container across component invocations as follows.
If a component is called and there is no JTA transaction or the JTA transaction is not propagated, the
persistence context is not propagated.
"
For the case of a SFSB (with an extended persistence context XPC) method that is not in a JTA transaction, invoking a SLSB (with a transactional entity manager PC) method that requires a transaction. The SLSB method should not use the extended persistence context but should instead start a new persistence context instead for the duration of the SLSB transaction (will end at the method end).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 12 months