[JBoss JIRA] Created: (EJBTHREE-2237) Application exception lost if thrown in method annotated with @PostConstruct
by none given (JIRA)
Application exception lost if thrown in method annotated with @PostConstruct
----------------------------------------------------------------------------
Key: EJBTHREE-2237
URL: https://issues.jboss.org/browse/EJBTHREE-2237
Project: EJB 3.0
Issue Type: Bug
Reporter: none given
If a singleton session bean throws an application exception in a method annotated with {{@PostConstruct}} the application exception is not visible in the log. The exception that is thrown is a {{java.lang.RuntimeException}} with the message "Could not invoke PostConstruct on the newly created bean instance, the cause is a {{java.lang.NullPointerException}} instead of the application exception.
A simple singleton session bean to replicate the bug:
{code}
import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.Startup;
@Startup
@Singleton
public class TestSingletonBean
{
@PostConstruct
public void init() throws Exception
{
throw new Exception("Where did I go?");
}
}
{code}
The exception from {{server.log}}:
{code}
12:37:38,966 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=startup-singleton-initiator:topLevelUnit=javaee6-manager.jar,unit=javaee6-manager.jar,bean=TestSingletonBean aliases=[startup-singleton-initiator:bean=TestSingletonBean,topLevelUnit=javaee6-manager.jar,unit=javaee6-manager.jar] state=Create: java.lang.RuntimeException: Could not invoke PostConstruct on the newly created bean instance
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.get(SingletonEJBInstanceManagerImpl.java:152) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.deployer.StartupSingletonInitiator.start(StartupSingletonInitiator.java:84) [:1.0.0-alpha-28]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_22]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_22]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_22]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_22]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_22]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_22]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.invokeCallback(AOPBasedSingletonContainer.java:1063) [:1.0.0-alpha-28]
at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:1396) [:1.7.17]
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.postConstruct(AOPBasedSingletonContainer.java:760) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:133) [:1.0.0-alpha-28]
... 70 more
Caused by: java.lang.NullPointerException
at org.jboss.ejb3.EJBContainer.getApplicationException(EJBContainer.java:509) [:1.7.17]
at org.jboss.ejb3.singleton.aop.impl.ConstructionInvocationContextAdapter.getApplicationException(ConstructionInvocationContextAdapter.java:62) [:1.0.0-alpha-28]
at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:163) [:0.0.1]
at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [:0.0.1]
at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:392) [:0.0.1]
at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:211) [:0.0.1]
at org.jboss.ejb3.tx2.aop.CMTTxInterceptorWrapper.invoke(CMTTxInterceptorWrapper.java:52) [:0.0.1]
at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:80) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) [:1.0.0.GA]
at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:80) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.17]
at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:80) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:90) [:1.1.3]
at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_221024277.invoke(InvocationContextInterceptor_z_setup_221024277.java) [:]
at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:80) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:80) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.invokeCallback(AOPBasedSingletonContainer.java:1059) [:1.0.0-alpha-28]
... 73 more
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBNAME-53) InitialContext#lookup does not timeout on cached context
by Stian Thorgersen (JIRA)
InitialContext#lookup does not timeout on cached context
--------------------------------------------------------
Key: JBNAME-53
URL: https://issues.jboss.org/browse/JBNAME-53
Project: JBoss Naming
Issue Type: Bug
Reporter: Stian Thorgersen
I've got an issue where InitialContext#lookup will hang forever doing a lookup if there is a problem with the network. I appreciate this is the default settings of the TCP sockets to wait forever, so I've tried to configure the timeout using 'jnp.timeout' and 'jnp.sotimeout'. If the network is disconnected prior to the first attempt to do a lookup it times out as expected (I assume this is 'jnp.timeout' which configures the timeout to create the connection). However, if the network is disconnected after one ore more successful lookups have been performed it waits forever. I assume this is there 'jnp.sotimeout' should have kicked in, but doesn't seem to.
{code}
Hashtable<String, String> env = new Hashtable<String, String>();
env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
env.put("java.naming.provider.url", "jnp://10.9.1.11:1099");
env.put("java.naming.factory.url.pkgs", "org.jboss.naming");
env.put("jnp.socketFactor", "org.jnp.interfaces.TimedSocketFactory");
env.put("jnp.timeout", "1000");
env.put("jnp.sotimeout", "1000");
InitialContext ctx = new InitialContext(env);
ctx.lookup("something");
// disconnect network here
ctx.lookup("something");
{code}
In the above example if I disconnect the network before the first lookup it times out as expected, but if I disconnect the network between the first lookup and the second lookup it waits forever. I've tried to wrap it in a thread, that is then interrupted after a timeout, but that doesn't work.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBAS-9365) InitialContext#lookup does not timeout on cached context
by Stian Thorgersen (JIRA)
InitialContext#lookup does not timeout on cached context
--------------------------------------------------------
Key: JBAS-9365
URL: https://issues.jboss.org/browse/JBAS-9365
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Stian Thorgersen
I've got an issue where InitialContext#lookup will hang forever doing a lookup if there is a problem with the network. I appreciate this is the default settings of the TCP sockets to wait forever, so I've tried to configure the timeout using 'jnp.timeout' and 'jnp.sotimeout'. If the network is disconnected prior to the first attempt to do a lookup it times out as expected (I assume this is 'jnp.timeout' which configures the timeout to create the connection). However, if the network is disconnected after one ore more successful lookups have been performed it waits forever. I assume this is there 'jnp.sotimeout' should have kicked in, but doesn't seem to.
{code}
Hashtable<String, String> env = new Hashtable<String, String>();
env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
env.put("java.naming.provider.url", "jnp://10.9.1.11:1099");
env.put("java.naming.factory.url.pkgs", "org.jboss.naming");
env.put("jnp.socketFactor", "org.jnp.interfaces.TimedSocketFactory");
env.put("jnp.timeout", "1000");
env.put("jnp.sotimeout", "1000");
InitialContext ctx = new InitialContext(env);
ctx.lookup("something");
// disconnect network here
ctx.lookup("something");
{code}
In the above example if I disconnect the network before the first lookup it times out as expected, but if I disconnect the network between the first lookup and the second lookup it waits forever. I've tried to wrap it in a thread, that is then interrupted after a timeout, but that doesn't work.
Looking at the source code from JBoss Naming it seems that 'jnp.timeout' and 'jnp.sotimeout' is only used to retrieve the NamingServer_Stub, once that is retrieved and cached I can't see that they are being used any longer. I believe this would result in the problem I'm seeing as NamingServer_Stub#lookup would not have a socket timeout associated with the RMI call.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3735) javax.ws.rs.ext.FactoryFinder use application's Class Loader which causes CL Memory Leak
by Philippe Guinot (JIRA)
Philippe Guinot created AS7-3735:
------------------------------------
Summary: javax.ws.rs.ext.FactoryFinder use application's Class Loader which causes CL Memory Leak
Key: AS7-3735
URL: https://issues.jboss.org/browse/AS7-3735
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.0.CR1b
Environment: Seam 2.2.2 webapp with Resteasy 2.3.1
Reporter: Philippe Guinot
Assignee: David Lloyd
Deploying a Seam 2 application with Resteasy (deployed as JAR withing EarContent/lib) actually causes the following issue:
* When Seam access classes such as CacheControl, Cookie, EntityTag, MediaType or NewCookie, it loads my application's Resteasy classes, as using the CurrentThread's context class loader.
* So I ended up with the static field delegate of those classes keeping a reference to my application's class loader which cause a CL Memory Leak.
Since, the javax.ws.rs.core.Cookie/Entitytag, etc.. are server side components, I don't think they should refer to any deployed application.
To avoid this, the only way to do so, was at the server start-up to initialize those components in that way:
{code}
try {
javax.ws.rs.core.CacheControl.valueOf("");
} catch (IllegalArgumentException e) {
}
try {
javax.ws.rs.core.Cookie.valueOf("");
} catch (IllegalArgumentException e) {
}
try {
javax.ws.rs.core.EntityTag.valueOf("");
} catch (IllegalArgumentException e) {
}
try {
javax.ws.rs.core.MediaType.valueOf("");
} catch (IllegalArgumentException e) {
}
try {
javax.ws.rs.core.NewCookie.valueOf("");
} catch (IllegalArgumentException e) {
}{code}
(I put this in org.jboss.as.server.Main before line 91, but this is not the best place of course. Perhaps a class such as JreMemoryLeakPreventionListener should be used, but for the moment the use of this listener is disabled in JBoss Web 7, see https://community.jboss.org/thread/164760 )
But, since the RuntimeDelegate needed to find the Resteasy classed, I had to use the module ClassLoader instead of the current context class loader in the javax.ws.rs.ext.FactoryFinder.getContextClassLoader() method. Then, as the javax.ws.rs.api module actually depends on the org.jboss.resteasy.resteasy-jaxrs, this works well and avoids any dependency to my application's class loader.
--
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
14 years, 4 months