[JBoss JIRA] Created: (WELD-802) Specialization of Beans registered through portable extension does not work.
by Jozef Hartinger (JIRA)
Specialization of Beans registered through portable extension does not work.
----------------------------------------------------------------------------
Key: WELD-802
URL: https://issues.jboss.org/browse/WELD-802
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.CR2
Reporter: Jozef Hartinger
@ApplicationScoped
public class SeamExceptionMapper implements ExceptionMapper<Throwable>
{
}
@ApplicationScoped
@Specializes
public class CatchExceptionMapper extends SeamExceptionMapper
{
}
both these beans are registered via a portable extension:
event.addAnnotatedType(manager.createAnnotatedType(CatchExceptionMapper.class));
event.addAnnotatedType(manager.createAnnotatedType(SeamExceptionMapper.class));
The app fails to deploy with the following exception:
15:08:15,668 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///home/jharting/jboss/Seam_3/jboss-6.0.0.20101110-CR1/server/default/deploy/seam-tasks.war_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.DefinitionException: WELD-000047 Specializing bean must extend another bean: Managed Bean [class org.jboss.seam.rest.exceptions.CatchExceptionMapper] with qualifiers [@Any @Default]
at org.jboss.weld.bean.ManagedBean.specialize(ManagedBean.java:530) [:6.0.0.20101110-CR1]
at org.jboss.weld.bean.AbstractBean.initialize(AbstractBean.java:112) [:6.0.0.20101110-CR1]
at org.jboss.weld.bean.AbstractClassBean.initialize(AbstractClassBean.java:172) [:6.0.0.20101110-CR1]
at org.jboss.weld.bean.ManagedBean.initialize(ManagedBean.java:366) [:6.0.0.20101110-CR1]
at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:110) [:6.0.0.20101110-CR1]
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216) [:6.0.0.20101110-CR1]
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:359) [:6.0.0.20101110-CR1]
at org.jboss.weld.integration.deployer.env.helpers.BootstrapBean.boot(BootstrapBean.java:92) [:6.0.0.20101110-CR1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_23]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha8]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.20101110-CR1]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:59) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:94) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.1.0.Alpha1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_23]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_23]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_23]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_23]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_23]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (WELD-617) Can not find beans when deploying compressed Archive to Tomcat
by Aslak Knutsen (JIRA)
Can not find beans when deploying compressed Archive to Tomcat
--------------------------------------------------------------
Key: WELD-617
URL: https://jira.jboss.org/browse/WELD-617
Project: Weld
Issue Type: Bug
Components: Servlet Container Support
Affects Versions: 1.0.1.Final
Reporter: Aslak Knutsen
When deploying a compressed Archive on Tomcat, WebAppBeanDeploymentArchive.scan fails to find and classes.
In WebAppBeanDeploymentArchive.scan we try to get the File object representation of the WEB-INF/classes directory so we can recursively scan for classes, but in Tomcat this is a URL to jndi backed by a DirContext.
WebAppBeanDeploymentArchive.scan
{ // inside scan
File webInfClasses = Servlets.getRealFile(servletContext, WEB_INF_CLASSES);
{ // inside getRealFile
String realPath = servletContext.getRealPath(path);
realPath == null
URL resourcePath = servletContext.getResource(path);
resourcePath == jndi:/localhost/test/WEB-INF/classes
}
webInfClasses == null
}
End result is no classes are found.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (WELD-904) Observer method inheritance broken
by Christian Bauer (JIRA)
Observer method inheritance broken
----------------------------------
Key: WELD-904
URL: https://issues.jboss.org/browse/WELD-904
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.1.Final
Reporter: Christian Bauer
Priority: Minor
/*
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<alternatives>
<class>Foo$Bar</class>
</alternatives>
</beans>
*/
@ApplicationScoped
public class Foo {
public static void main(String[] args) {
WeldContainer weld = new Weld().initialize();
weld.event().select(MyEvent.class).fire(new MyEvent());
}
static class MyEvent {
}
@Qualifier
@Target({FIELD, PARAMETER})
@Retention(RUNTIME)
public @interface SomeQualifier {
}
@PostConstruct
void init() {
System.out.println("INIT FOO");
}
void onEvent(@Observes MyEvent e) {
System.out.println("EVENT FOO");
}
@Alternative
@Specializes
static public class Bar extends Foo {
@Override
void init() {
System.out.println("INIT BAR");
}
@Override
void onEvent(@Observes @SomeQualifier MyEvent e) {
System.out.println("EVENT BAR");
}
}
}
The expected output is:
INIT BAR
The actual output is:
INIT BAR
EVENT BAR
Removing the @SomeQualifier annotation on the Bar#onEvent() method results in:
INIT BAR
EVENT BAR
EVENT BAR
Removing also the @Observes annotation on the Bar#onEvent() method results in:
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (WELD-885) NPE in org.jboss.weld.wicket.util.NonContextual.<init>
by Ondrej Zizka (JIRA)
NPE in org.jboss.weld.wicket.util.NonContextual.<init>
------------------------------------------------------
Key: WELD-885
URL: https://issues.jboss.org/browse/WELD-885
Project: Weld
Issue Type: Bug
Components: Servlet Container Support
Affects Versions: 1.0.1.Final
Environment: Jetty 6.1.26
Wicket 1.4.16
Reporter: Ondrej Zizka
I have a standalone app with embedded Jetty running a Wicket app.
I added weld-wicket as dependency, and after I changed parent class
of my WicketApplication to WeldApplication and tried to run, the NPE occured.
Whole project can be seen at
http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0
20:56:17.343 ERROR [main] / unavailable
java.lang.NullPointerException
at org.jboss.weld.wicket.util.NonContextual.<init>(NonContextual.java:33)
at org.jboss.weld.wicket.WeldApplication.internalInit(WeldApplication.java:50)
at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:723)
at org.apache.wicket.protocol.http.ReloadingWicketFilter.init(ReloadingWicketFilter.java:175)
at org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:219)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:736)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.jboss.jawabot.web.RunInJetty.run(RunInJetty.java:145)
at org.jboss.jawabot.mod.web.WebModuleHook.initModule(WebModuleHook.java:18)
at org.jboss.jawabot.JawaBotApp.initAndStartModules(JawaBotApp.java:106)
at org.jboss.jawabot.JawaBotApp.main(JawaBotApp.java:53)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (WELD-842) Event injection via constructor injection results in stacktrace.
by Christopher Brock (JIRA)
Event injection via constructor injection results in stacktrace.
-----------------------------------------------------------------
Key: WELD-842
URL: https://issues.jboss.org/browse/WELD-842
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final
Reporter: Christopher Brock
{code}
/**
* @author Mike Brock .
*/
@ApplicationScoped
public class HelloWorldService {
private Event<ResponseEvent> responseEvent;
@Inject
public HelloWorldService(Event<ResponseEvent> responseEvent) {
this.responseEvent = responseEvent;
}
public void handleMessage(@Observes MessageEvent event) {
System.out.println("Received Message: " + event.getMessage());
responseEvent.fire(new ResponseEvent(event.getMessage()));
}
}
{code}
Results in stacktrace:
{code}
com.google.common.collect.ComputationException: org.jboss.weld.exceptions.DefinitionException: org.jboss.errai.demos.cdi.helloworld.server.org$jboss$weld$bean-flat-ManagedBean-class_org$jboss$errai$demos$cdi$helloworld$server$HelloWorldService_$$_WeldClientProxy
at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:602)
at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:462)
at com.google.common.collect.CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2045)
at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:112)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:660)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:252)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:614)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:607)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:601)
at org.jboss.errai.cdi.server.EventDispatcher.callback(EventDispatcher.java:60)
{code}
Thought it was a problem in our integration at first, but then I realized the problem does not happen when field injection is used for the Event.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
by Ancoron Luciferis (JIRA)
weld-osgi-bundle binds to invalid SLF4J package versions
--------------------------------------------------------
Key: WELD-932
URL: https://issues.jboss.org/browse/WELD-932
Project: Weld
Issue Type: Bug
Components: OSGi support
Affects Versions: 1.1.1.Final
Environment: OSGi + SLF4J 1.6.x
Reporter: Ancoron Luciferis
Priority: Critical
Fix For: 1.1.2.Final
The current weld-osgi-bundle is a bit weird in multiple ways:
# it packages slf4j 1.5.6 and at the same time imports it
# the package import definition is not a range, although incompatible API's are known already (1.5.x vs. 1.6.x)
The actual problem manifests itself e.g. in GlassFish 3.1+ with a deployed SLF4J 1.6.1:
{noformat}
WARNING: Failed to deploy bundle com.something.support.web [319]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of com.something.support.web [319] failed because of following reason: Failed while deploying bundle com.something.support.web [319] : java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 10 more
Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
at org.slf4j.cal10n.LocLogger.info(LocLogger.java:122)
at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:213)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:345)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
... 12 more
{noformat}
This introduces problems when someone deploys an application which in turn requires the SLF4J API 1.6.x.
So I suggest to fix it like this:
{noformat}
Import-Package:
...
org.slf4j;version="[1.5.10,1.6)";resolution:=optional,
org.slf4j.helpers;version="[1.5.10,1.6)";resolution:=optional,
org.slf4j.spi;version="[1.5.10,1.6)";resolution:=optional
{noformat}
Furthermore there are still some placeholders inside the {{META-INF/MANIFEST.MF}}:
{noformat}
Specification-Version: ${parsedVersion.osgiVersion}
Maven-Version: ${maven.version}
SCM: r${buildNumber}
{noformat}
The final goal should be to get rid of embedding the org.slf4j stuff altogether.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (WELD-865) Weld allows for concurrent call to conversation
by George Sapountzis (JIRA)
Weld allows for concurrent call to conversation
-----------------------------------------------
Key: WELD-865
URL: https://issues.jboss.org/browse/WELD-865
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts, Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.1.0.Final
Reporter: George Sapountzis
Concurrent calls to a @ConversationScoped component:
Thread 1:
AbstractConversationContext.activate(String cid)
ConversationImpl.lock(long timeout) <-- returns true
correctly proceed inside method
Thread 2:
AbstractConversationContext.activate(String cid)
ConversationImpl.lock(long timeout) <-- returns false but activate() does not check result !!!
*incorrectly* proceed inside method
----
I think AbstractConversationContext.activate(String cid) should check the result of ConversationImpl.lock(long timeout) and not allow the second thread to proceed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months