[JBoss JIRA] (AS7-6341) EJB2 CMP - 'JBAS014172: Instance not found in cache' after remove and recreate an entity in the same Tx
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6341?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6341:
----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> made a comment on [bug 915169|https://bugzilla.redhat.com/show_bug.cgi?id=915169]
verified with EAP 6.1.0.ER3
> EJB2 CMP - 'JBAS014172: Instance not found in cache' after remove and recreate an entity in the same Tx
> -------------------------------------------------------------------------------------------------------
>
> Key: AS7-6341
> URL: https://issues.jboss.org/browse/AS7-6341
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Priority: Minor
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> If an entity is removed and new created within the same transaction the 'afterCompletition' procedure try to sync it twice.
> It looks like that the entity is registered twice in this case.
> The Exception is shown in the server.log, nevertheless the transactions and method execution will be succeed.
> The following Exception can be safely ignored.
> 08:17:10,005 ERROR [org.jboss.as.ejb3] (EJB default - 4) JBAS014138: Exception releasing entity: java.lang.IllegalStateException: JBAS014172: Instance [org.jboss.as.cmp.component.CmpEntityBeanComponentInstance@31b489ae] not found in cache
> at org.jboss.as.ejb3.component.entity.entitycache.ReferenceCountingEntityCache.release(ReferenceCountingEntityCache.java:86) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.releaseInstance(EntityBeanSynchronizationInterceptor.java:154) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.access$200(EntityBeanSynchronizationInterceptor.java:56) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.afterCompletion(EntityBeanSynchronizationInterceptor.java:219) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:103)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:252) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:315) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:214) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:65) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:321) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-5497) Exception handling of EJB container for MDB is incorrect
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5497?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5497:
----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 900803|https://bugzilla.redhat.com/show_bug.cgi?id=900803] from ON_QA to VERIFIED
> Exception handling of EJB container for MDB is incorrect
> --------------------------------------------------------
>
> Key: AS7-5497
> URL: https://issues.jboss.org/browse/AS7-5497
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.2.Final (EAP)
> Environment: JBoss EAP 6.0.0
> Reporter: Adam Kovari
> Assignee: JBoss SET
> Priority: Minor
> Labels: eap6, ejb3.1
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> After deploying a MDB with Container-Managed transaction and
> TransactionAttribute NOT_SUPPORTED, a RuntimeException thrown from
> within the MDB onMessage() is reported to the Adapter as such, with no
> EJBException wrapping. I.e.: the "((javax.jms.MessageListener)
> endPoint).onMessage(message)" call in our adapter fails with the
> exception type originally thrown.
> This does not look compliant with EJB 3.1 spec(JSR 318: Enterprise
> JavaBeansTM, Version 3.1, Table 20 page 392, last cell bottom right):
> "Throw EJBException that wraps the original exception to resource
> adapter".
> Another part of spec I was just made aware of says this:
> p383 of the spec states -
> In the case of a message-driven bean, the container logs the exception and then throws a javax.ejb.EJBException that wraps the original exception to the resource adapter. (See [15]).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-5497) Exception handling of EJB container for MDB is incorrect
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5497?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5497:
----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> made a comment on [bug 900803|https://bugzilla.redhat.com/show_bug.cgi?id=900803]
verified in 6.1.0.ER3
> Exception handling of EJB container for MDB is incorrect
> --------------------------------------------------------
>
> Key: AS7-5497
> URL: https://issues.jboss.org/browse/AS7-5497
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.2.Final (EAP)
> Environment: JBoss EAP 6.0.0
> Reporter: Adam Kovari
> Assignee: JBoss SET
> Priority: Minor
> Labels: eap6, ejb3.1
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> After deploying a MDB with Container-Managed transaction and
> TransactionAttribute NOT_SUPPORTED, a RuntimeException thrown from
> within the MDB onMessage() is reported to the Adapter as such, with no
> EJBException wrapping. I.e.: the "((javax.jms.MessageListener)
> endPoint).onMessage(message)" call in our adapter fails with the
> exception type originally thrown.
> This does not look compliant with EJB 3.1 spec(JSR 318: Enterprise
> JavaBeansTM, Version 3.1, Table 20 page 392, last cell bottom right):
> "Throw EJBException that wraps the original exception to resource
> adapter".
> Another part of spec I was just made aware of says this:
> p383 of the spec states -
> In the case of a message-driven bean, the container logs the exception and then throws a javax.ejb.EJBException that wraps the original exception to the resource adapter. (See [15]).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBAS-7210) JBossContextConfig needs to be isolated from the war class loader
by John Chan (JIRA)
[ https://issues.jboss.org/browse/JBAS-7210?page=com.atlassian.jira.plugin.... ]
John Chan commented on JBAS-7210:
---------------------------------
Dear Jaikiran and all the experts alike, can you teach me how to check out the source codes and how to build the binaries program from them so that I can install the application server to a Window machine (and a Linux server later)? Forgive me that I am a complete newbie and have never tried to do this kind of things for an open source project like JBOSS AS. Is that any tutorial that describe these steps?
Dear Bruno HALEBLIAN, can you build the binary program of the JBOSS_5_1_0_GA Application Server that includes the fix in question and share with me on the web? Millions of thanks if you can do so! Please help!
> JBossContextConfig needs to be isolated from the war class loader
> -----------------------------------------------------------------
>
> Key: JBAS-7210
> URL: https://issues.jboss.org/browse/JBAS-7210
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ClassLoading, Web (Tomcat) service
> Affects Versions: JBossAS-5.1.0.GA
> Reporter: Scott Stark
> Assignee: Scott Stark
> Fix For: 6.0.0.M2
>
> Attachments: jbas-7210.war.zip
>
>
> The parsing of the context.xml by the JBossContextConfig class is using the tccl which causes problems when the war app has tried to load its own xml parser.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-2227) Port the legacy jmx-console to AS7
by Boris Trishkin (JIRA)
[ https://issues.jboss.org/browse/AS7-2227?page=com.atlassian.jira.plugin.s... ]
Boris Trishkin updated AS7-2227:
--------------------------------
Attachment: jmx-console.war
Replaced illegal characters to fix mbeans listing error
> Port the legacy jmx-console to AS7
> ----------------------------------
>
> Key: AS7-2227
> URL: https://issues.jboss.org/browse/AS7-2227
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JMX
> Reporter: Dimitris Andreadis
> Assignee: Darran Lofthouse
> Labels: JMX, as7, jmx-console
> Attachments: jmx-console.war, jmx-console.war
>
>
> I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console.
> I've ported the old console in this branch:
> https://github.com/dandreadis/jboss-as/commits/jmx-console
> It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war)
> If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default?
> The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-4251) AS7.1.0.Final makes stale references untill contents inside 'tmp' folder are cleared
by Mahesh Khatal (JIRA)
[ https://issues.jboss.org/browse/AS7-4251?page=com.atlassian.jira.plugin.s... ]
Mahesh Khatal commented on AS7-4251:
------------------------------------
Hi,
Needed urgently!!
My application is deployed on JBOSS 7.1.1 ,when i do deployments, server/tmp/vfs folder gets increasing and application gets slow down.
Is there any way to come out of this.
Thanx!!
> AS7.1.0.Final makes stale references untill contents inside 'tmp' folder are cleared
> ------------------------------------------------------------------------------------
>
> Key: AS7-4251
> URL: https://issues.jboss.org/browse/AS7-4251
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.Final
> Environment: Windows 7 enterprise, service pack1 64 bit OS
> Reporter: Nagendra Prasad Bhat
> Assignee: Stuart Douglas
>
> Jboss AS 7.1.0.Final often makes stale references. Deployment of Jars/Wars in standalone 'deployments' directory takes stale references and outputs unexpected log messages like 'unresolved compilation', 'It is indirectly referenced from required .class files
> 'etc. Same set of artifacts work fine when contents of tmp>vfs and tmp>work>jboss.web are deleted and server is bounced. Here is the trace for this issue. This was never encountered in previous AS7.1 and AS7.0 releases.
> {noformat}
> 17:47:19,549 DEBUG [org.jboss.resteasy.core.SynchronousDispatcher] (http-AUS-XXXX.rws.ad.mycompany.com-10.30.19.9-8080-1) PathInfo: phone/products/callrequest
> 17:47:19,565 INFO [com.mycompany.xyz.so.comm.service.PCommuServiceImpl] (http-AUS-XXXX.rws.ad.mycompany.com-10.30.19.9-8080-1) End of Comm cService method - schedulePCallRequest(). Time taken by the service is [4]ms
> 17:47:19,577 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/comm].[Resteasy]] (http-AUS-XXXX.rws.ad.mycompany.com-10.30.19.9-8080-1) Servlet.service() for servlet Resteasy threw exception: org.jboss.resteasy.spi.UnhandledException: java.lang.Error: Unresolved compilation problems:
> The type com.mycompany.xyz.comm.responses.CResponse cannot be resolved. It is indirectly referenced from required .class files
> The import com.mycompany.xyz.comm.constants cannot be resolved
> The import com.mycompany.xyz.comm.errorcodes cannot be resolved
> The import com.mycompany.xyz.comm.exception cannot be resolved
> The import com.mycompany.xyz.comm.exception cannot be resolved
> The import com.mycompany.xyz.comm.exception cannot be resolved
> The import com.mycompany.xyz.comm.responses.CResponse cannot be resolved
> The import com.mycompany.xyz.comm.responses.SResponse cannot be resolved
> The import com.mycompany.xyz.comm.responses.SResponse cannot be resolved
> The import com.mycompany.xyz.comm.responses.SResponse cannot be resolved
> The import com.mycompany.xyz.sl cannot be resolved
> The import com.mycompany.xyz.sl cannot be resolved
> The import com.mycompany.xyz.sl cannot be resolved
> The import com.mycompany.xyz.sl cannot be resolved
> CResponse cannot be resolved to a type
> The method createMyCase(Map<String,String>) from the type PCommuImpl refers to the missing type Exception
> The type com.mycompany.xyz.comm.exception.SOperationException cannot be resolved. It is indirectly referenced from required .class files
> The method getPControlOperationException(PCommuErrors, String, String) from the type CommExceptionHandler refers to the missing type SOperationException
> SException cannot be resolved to a type
> SResponse cannot be resolved
> SSystemException cannot be resolved to a type
> The type com.mycompany.xyz.comm.exception.SSystemException cannot be resolved. It is indirectly referenced from required .class files
> The method getSystemException() from the type PCommHelper refers to the missing type SSystemException
> CResponse cannot be resolved to a type
> SResponse cannot be resolved
> SException cannot be resolved to a type
> SResponse cannot be resolved to a type
> PControlService cannot be resolved to a type
> PControlServiceImpl cannot be resolved to a type
> SResponse cannot be resolved to a type
> CErrors cannot be resolved to a variable
> SConstants cannot be resolved to a variable
> SSystemException cannot be resolved to a type
> CErrors cannot be resolved to a variable
> SConstants cannot be resolved to a variable
> SException cannot be resolved to a type
> SResponse cannot be resolved
> SErrorResponse cannot be resolved to a type
> SSystemException cannot be resolved to a type
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:340) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:540) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:502) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.1.GA.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.1.GA.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.10.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.10.Final.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.10.Final.jar:]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.0.Final.jar:7.1.0.Final]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.10.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.10.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.10.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.10.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.10.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.10.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.10.Final.jar:]
> at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_20]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-1805) Empty directories under "tmp/vfs" keeps on growing between server restarts
by Mahesh Khatal (JIRA)
[ https://issues.jboss.org/browse/AS7-1805?page=com.atlassian.jira.plugin.s... ]
Mahesh Khatal commented on AS7-1805:
------------------------------------
Hi,
Needed urgently!!
My application is deployed on JBOSS 7.1.1 ,when i do deployments, server/tmp/vfs folder gets increasing and application gets slow down.
Is there any way to come out of this.
Thanx!!
> Empty directories under "tmp/vfs" keeps on growing between server restarts
> --------------------------------------------------------------------------
>
> Key: AS7-1805
> URL: https://issues.jboss.org/browse/AS7-1805
> Project: Application Server 7
> Issue Type: Bug
> Components: VFS
> Affects Versions: 7.0.1.Final
> Reporter: Ramesh Reddy
> Assignee: Maas van den Berg
> Fix For: 8.0.0.Alpha1
>
>
> When you have active deployment deployed to the server and you are restarting server for various reasons, the tmp/vfs keeps on growing with empty directories. It deletes the contents under the directory but not the directory itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBAS-7210) JBossContextConfig needs to be isolated from the war class loader
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/JBAS-7210?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on JBAS-7210:
------------------------------------
>> But then what is the point of back porting the JBOSS_5_1_0_GA with the fix as mentioned in Bruno Haleblian's comment?
Bruno did not "backport" the fix to 5.1.0. All he did was patch his version of 5.1.0 source code and rebuilt it. You can do the same if you want to.
> JBossContextConfig needs to be isolated from the war class loader
> -----------------------------------------------------------------
>
> Key: JBAS-7210
> URL: https://issues.jboss.org/browse/JBAS-7210
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ClassLoading, Web (Tomcat) service
> Affects Versions: JBossAS-5.1.0.GA
> Reporter: Scott Stark
> Assignee: Scott Stark
> Fix For: 6.0.0.M2
>
> Attachments: jbas-7210.war.zip
>
>
> The parsing of the context.xml by the JBossContextConfig class is using the tccl which causes problems when the war app has tried to load its own xml parser.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month