[JBoss JIRA] (AS7-4189) bean-validation quickstart fails to start managed container
by David Salter (JIRA)
David Salter created AS7-4189:
---------------------------------
Summary: bean-validation quickstart fails to start managed container
Key: AS7-4189
URL: https://issues.jboss.org/browse/AS7-4189
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Environment: Tests performed on 64-bit Oracle Java 7 on Ubuntu
Reporter: David Salter
The Arquillian tests fail on the bean-validation quickstart when run against a managed JBoss server as in the following output.
Updating to use the jboss-javaee-6.0-with-tools version 1.0.0.M4 in pom.xml seems to fix the issue.
$ export JBOSS_HOME=/home/david/Apps/jboss-as-7.1.1.Final/
$ mvn clean test -Parq-jbossas-managed
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss AS Quickstarts: Bean Validation 7.1.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ bean-validation ---
[INFO] Deleting /home/david/Development/Java/quickstart/quickstart/bean-validation/target
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ bean-validation ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ bean-validation ---
[INFO] Compiling 1 source file to /home/david/Development/Java/quickstart/quickstart/bean-validation/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ bean-validation ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.1:testCompile (default-testCompile) @ bean-validation ---
[INFO] Compiling 1 source file to /home/david/Development/Java/quickstart/quickstart/bean-validation/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ bean-validation ---
[INFO] Surefire report directory: /home/david/Development/Java/quickstart/quickstart/bean-validation/target/surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.as.quickstarts.kitchensink.test.MemberValidationTest
log4j:WARN No appenders could be found for logger (org.jboss.logging).
log4j:WARN Please initialize the log4j system properly.
Mar 15, 2012 19:43:25 AM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/local/java/jdk1.7.0_03/bin/java, -Xmx512m, -XX:MaxPermSize=128m, -Djboss.home.dir=/home/david/Apps/jboss-as-7.1.1.Final/, -Dorg.jboss.boot.log.file=/home/david/Apps/jboss-as-7.1.1.Final//standalone/log/boot.log, -Dlogging.configuration=file:/home/david/Apps/jboss-as-7.1.1.Final//standalone/configuration/logging.properties, -Djboss.modules.dir=/home/david/Apps/jboss-as-7.1.1.Final//modules, -jar, /home/david/Apps/jboss-as-7.1.1.Final/jboss-modules.jar, -mp, /home/david/Apps/jboss-as-7.1.1.Final//modules, -logmodule, org.jboss.logmanager, -jaxpmodule, javax.xml.jaxp-provider, -mbeanserverbuildermodule, org.jboss.as.jmx, org.jboss.as.standalone, -server-config, standalone.xml]
WARNING: -logmodule is deprecated. Please use the system property 'java.util.logging.manager' or the 'java.util.logging.LogManager' service loader.
Invalid option '-mbeanserverbuildermodule'
Usage: java [-jvmoptions...] -jar jboss-modules.jar [-options...] <module-spec> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -jar <jar-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -cp <class-path> <class-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -class <class-name> [args...]
where <module-spec> is a valid module specification string
and options include:
-help Display this message
-modulepath <search path of directories>
-mp <search path of directories>
A list of directories, separated by ':', where modules may be located
If not specified, the value of the "module.path" system property is used
-class Specify that the final argument is a
class to load from the class path; not compatible with -jar
-cp,-classpath <search path of archives or directories>
A search path for class files; implies -class
-dep,-dependencies <module-spec>[,<module-spec>,...]
A list of module dependencies to add to the class path;
requires -class or -cp
-jar Specify that the final argument is the name of a
JAR file to run as a module; not compatible with -class
-config <config-location>
The location of the module configuration. Either -mp or -config
may be specified, but not both
-jaxpmodule <module-name>
The default JAXP implementation to use of the JDK
-version Print version and exit
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.13 sec <<< FAILURE!
Results :
Tests in error:
org.jboss.as.quickstarts.kitchensink.test.MemberValidationTest: Could not start container
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
--
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, 1 month
[JBoss JIRA] (JBRULES-3427) Wrong pattern's offsets calculation with complex LHS conditions
by Mario Fusco (JIRA)
Mario Fusco created JBRULES-3427:
------------------------------------
Summary: Wrong pattern's offsets calculation with complex LHS conditions
Key: JBRULES-3427
URL: https://issues.jboss.org/browse/JBRULES-3427
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
When combining AND and OR conditions in a complex LHS, the pattern's offsets is not calculated correctly leading to a NPE when trying to extract the object related with the wrong pattern from a tuple.
The following test reproduces the problem:
@Test
public void testPatternOffset() throws Exception {
String str = "package org.drools.test; \n" +
"declare A\n" +
"end\n" +
"declare B\n" +
" field : int\n" +
"end\n" +
"declare C\n" +
" field : int\n" +
"end\n" +
"rule R when\n" +
"( " +
" A( ) or ( A( ) and B( ) ) " +
") and (\n" +
" A( ) or ( B( $bField : field ) and C( field != $bField ) )\n" +
")\n" +
"then\n" +
" System.out.println(\"rule fired\");\n" +
"end\n";
KnowledgeBase kbase = loadKnowledgeBaseFromString( str );
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
FactType typeA = kbase.getFactType( "org.drools.test", "A" );
FactType typeB = kbase.getFactType( "org.drools.test", "B" );
FactType typeC = kbase.getFactType( "org.drools.test", "C" );
Object a = typeA.newInstance();
ksession.insert( a );
Object b = typeB.newInstance();
typeB.set( b, "field", 1 );
ksession.insert( b );
Object c = typeC.newInstance();
typeC.set( c, "field", 1 );
ksession.insert( c );
ksession.fireAllRules();
}
--
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, 1 month
[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, 1 month
[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, 1 month