[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann edited comment on WFLY-1533 at 6/25/13 4:49 AM:
-------------------------------------------------------------------
It happens when my logout method (see below) is processed.
{code}
@Named
@SessionScoped
public class AuthModel implements Serializable {
@Inject
private transient HttpServletRequest request;
@Inject
private transient HttpSession session;
...
public String logout() {
try {
request.logout();
}
catch (ServletException e) {
return null;
}
session.invalidate();
return "/index?faces-redirect=true";
}
}
{code}
was (Author: juergen.zimmermann):
It happens when my logout method (see below) is processed.
{code}
@Named
@SessionScoped
public class AuthModel implements Serializable {
@Inject
private transient HttpServletRequest request;
@Inject
private transient HttpSession session;
...
public String logout() {
try {
request.logout(); // Der Loginname wird zurueckgesetzt
}
catch (ServletException e) {
return null;
}
session.invalidate();
return "/index?faces-redirect=true";
}
}
{code}
> UT015005: Error invoking method requestDestroyed on listener class
> -------------------------------------------------------------------
>
> Key: WFLY-1533
> URL: https://issues.jboss.org/browse/WFLY-1533
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1533:
------------------------------------------
It happens when my logout method (see below) is processed.
{code}
@Named
@SessionScoped
public class AuthModel implements Serializable {
@Inject
private transient HttpServletRequest request;
@Inject
private transient HttpSession session;
...
public String logout() {
try {
request.logout(); // Der Loginname wird zurueckgesetzt
}
catch (ServletException e) {
return null;
}
session.invalidate();
return "/index?faces-redirect=true";
}
}
{code}
> UT015005: Error invoking method requestDestroyed on listener class
> -------------------------------------------------------------------
>
> Key: WFLY-1533
> URL: https://issues.jboss.org/browse/WFLY-1533
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1529) CNFE for a class implementing a taglib function
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1529?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1529:
------------------------------------------
Stuart, it tried several variants: as soon as RichFaces comes in I'm running into this issue. IMHO it looks as a similiar issue like https://issues.jboss.org/browse/RF-13061. Therefore, I propose to wait for RF 5.0.0.Alpha2 when they support Mojarra 2.2.x
> CNFE for a class implementing a taglib function
> -----------------------------------------------
>
> Key: WFLY-1529
> URL: https://issues.jboss.org/browse/WFLY-1529
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I'm using the latest WildFly snapshot containing Undertow 1.0.0.Alpha19. When I implement a JSF taglib having 1 function, then I get the stacktrace below when the .war file is deployed. This feature works fine with EAP 6.1.
> The JSF function is implemented in de.shop.util.JsfFunctions and declared in WEB-INF/shop.taglib.xml as follows:
> <?xml version="1.0" encoding="UTF-8"?>
> <facelet-taglib xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facelettaglibary_2_2.xsd"
> version="2.2">
> <namespace>http://shop.de</namespace>
> <function>
> <function-name>aktuellesDatum</function-name>
> <function-class>de.shop.util.JsfFunctions</function-class>
> <function-signature>
> java.util.Date aktuellesDatum()
> </function-signature>
> </function>
> </facelet-taglib>
> The stacktrace in the WildFly console:
> 12:25:16,832 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] Critical error during deployment: : com.sun.faces.config.ConfigurationException: javax.faces.FacesException: de.shop.util.JsfFunctions from [Module "deployment.shop2.war:main" from Service Module Loader]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processFunctions(FaceletTaglibConfigProcessor.java:642) [jsf-impl-2.2.0-jbossorg-2.jar:]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:325) [jsf-impl-2.2.0-jbossorg-2.jar:]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:270) [jsf-impl-2.2.0-jbossorg-2.jar:]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:437) [jsf-impl-2.2.0-jbossorg-2.jar:]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214) [jsf-impl-2.2.0-jbossorg-2.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:144) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:158) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:74)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: javax.faces.FacesException: de.shop.util.JsfFunctions from [Module "deployment.shop2.war:main" from Service Module Loader]
> at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:384) [jsf-impl-2.2.0-jbossorg-2.jar:]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processFunctions(FaceletTaglibConfigProcessor.java:638) [jsf-impl-2.2.0-jbossorg-2.jar:]
> ... 12 more
> Caused by: java.lang.ClassNotFoundException: de.shop.util.JsfFunctions from [Module "deployment.shop2.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.1.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.1.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.1.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.1.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.1.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_21]
> at java.lang.Class.forName(Class.java:266) [rt.jar:1.7.0_21]
> at com.sun.faces.util.Util.loadClass(Util.java:301) [jsf-impl-2.2.0-jbossorg-2.jar:]
> at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376) [jsf-impl-2.2.0-jbossorg-2.jar:]
> ... 13 more
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1572) NPE in org.jboss.resteasy.spi.metadata.ResourceConstructor
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1572?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann closed WFLY-1572.
------------------------------------
Fix Version/s: 8.0.0.Alpha2
Resolution: Done
The issue is gone after I upgraded from the snapshot to the final 8.0.0.Alpha2 release.
> NPE in org.jboss.resteasy.spi.metadata.ResourceConstructor
> ----------------------------------------------------------
>
> Key: WFLY-1572
> URL: https://issues.jboss.org/browse/WFLY-1572
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I just tried the WildFly snapshot containing RESTEasy 3.0.1.Final. After I added the Maven dependency org.jboss.resteasy:resteasy-cache-core (http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/Cache_NoCa...) I got the following stacktrace:
> 15:29:01,083 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.undertow.deployment.default-host./shop: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-host./shop: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1898) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
> at org.jboss.resteasy.spi.metadata.ResourceConstructor.<init>(ResourceConstructor.java:24)
> at org.jboss.resteasy.spi.metadata.ResourceBuilder$ResourceConstructorBuilder.<init>(ResourceBuilder.java:424)
> at org.jboss.resteasy.spi.metadata.ResourceBuilder$ResourceClassBuilder.constructor(ResourceBuilder.java:96)
> at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:681)
> at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:41)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:207)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:193)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:179)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:156)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:75)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:400)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:146)
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:63)
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:377)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:81)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:68)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> ... 3 more
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1517) regression: using a ResourceAdaptor (rar) which has properties that use primitives as arguments will fail to deploy
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1517?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1517:
-----------------------------------------------
Tom Fonteyne <tfonteyn(a)redhat.com> changed the Status of [bug 976294|https://bugzilla.redhat.com/show_bug.cgi?id=976294] from ASSIGNED to MODIFIED
> regression: using a ResourceAdaptor (rar) which has properties that use primitives as arguments will fail to deploy
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1517
> URL: https://issues.jboss.org/browse/WFLY-1517
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.0.0.Alpha1
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
> Fix For: 8.0.0.Alpha2
>
>
> org.jboss.as.connector.util.Injection.java:159
> protected Method findMethod(Class<?> clz, String methodName, String propertyType) {
> while (!clz.equals(Object.class)) {
> List<Method> hits = null;
> Method[] methods = clz.getDeclaredMethods();
> for (int i = 0; i < methods.length; i++) {
> Method method = methods[i];
> if (methodName.equals(method.getName()) && method.getParameterTypes().length == 1) {
> if (propertyType == null || propertyType.equals(method.getParameterTypes()[0].getName())) {
> the above is not taking primitives into account.
> Example, the IBM IMS connector ims1132.rar has:
> <config-property>
> <config-property-name>enableHASupport</config-property-name>
> <config-property-type>java.lang.Boolean</config-property-type>
> <config-property-value>true</config-property-value>
> </config-property>
> and the method:
> public void setEnableHASupport(boolean isHAEnabled)
> Our "FindMethod" will find this method but will fail to select it as it compares "java.lang.Boolean" with "boolean"
--
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
12 years, 4 months
[JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime due to eval in query (BW chaining)
by Wolfgang Laun (JIRA)
Wolfgang Laun created DROOLS-178:
------------------------------------
Summary: NoSuchMethodError at runtime due to eval in query (BW chaining)
Key: DROOLS-178
URL: https://issues.jboss.org/browse/DROOLS-178
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Priority: Critical
An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
Exception in thread "main" java.lang.NoSuchMethodError:
pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
Source)
at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
Source)
at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
at pythagoras.Main.makeFacts(Main.java:94)
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-924) All classes that implement AsyncListener are treated as components causing JBAS011006
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-924:
----------------------------------------------
Osamu Nagano <onagano(a)redhat.com> made a comment on [bug 900711|https://bugzilla.redhat.com/show_bug.cgi?id=900711]
The same WARN level log and stack trace happens with org.springframework.web.context.request.async.StandardServletAsyncWebRequest. Both of Servlet3Continuation and StandardServletAsyncWebRequest implement javax.servlet.AsyncListener and all instances of the interface are expected to have the default constructor by the current implementation (due to https://issues.jboss.org/browse/JBWEB-224).
But I think it's a strong assumption. Spec says some of AsyncListener instance must have a zero argument constructor [1], but I guess not all instances must. Shouldn't we expect the default constructor only for annotated ones like @ManagedBean?
[1] http://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html#creat...
> All classes that implement AsyncListener are treated as components causing JBAS011006
> -------------------------------------------------------------------------------------
>
> Key: WFLY-924
> URL: https://issues.jboss.org/browse/WFLY-924
> Project: WildFly
> Issue Type: Bug
> Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
> Reporter: Brad Maxwell
> Assignee: Remy Maucherat
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> And this stack is logged as a warning:
> 11:08:40,879 INFO [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack:
> 16:48:57,302 WARN [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
--
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
12 years, 4 months
[JBoss JIRA] (DROOLS-172) Multiple proxy instances for same trait
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-172?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-172:
---------------------------------------
I think I have fixed it.. I am still using multiple proxies, but now they don't override or overlap with each other. In my tests it works both with rules and queries.
I'll review the fix and commit it tomorrow, it will be in 5.6 and 6.x
> Multiple proxy instances for same trait
> ---------------------------------------
>
> Key: DROOLS-172
> URL: https://issues.jboss.org/browse/DROOLS-172
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Beta3
> Reporter: Fabian Meyer
> Assignee: Mark Proctor
> Priority: Minor
>
> If two traits with the same super trait are don to an object, two proxy instances of the super trait are created.
> !https://dl.dropboxusercontent.com/u/26663016/Trait.png!
--
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
12 years, 4 months