[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator
by Liu Yan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ]
Liu Yan updated DROOLS-185:
---------------------------
5.5.0.final.regards.
--------------------------------
来自我的新浪邮箱android客户端
-------- 原始邮件 --------
发件人:Davide Sottara (JIRA)
时 间:2015年1月23日 13:01(星期五)
收件人:oscar_cqu@sina.com
主题:[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator
Davide Sottara commented on DROOLS-185
Re: ClassCastException at ConditionEvaluator
Which version are you using? This should have been fixed in recent versions
Add Comment
This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29)
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
> Key: DROOLS-185
> URL: https://issues.jboss.org/browse/DROOLS-185
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Reporter: Sergey Alaev
> Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
> String getString();
> }
> interface B {
> String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
> A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by Nick . (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
Nick . commented on WFLY-4205:
------------------------------
Loved it, thanks Stuart....
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
> Fix For: 9.0.0.Beta1
>
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-3389) Error Connecting to WildFly via JMX
by Oliver Waeldrich (JIRA)
[ https://issues.jboss.org/browse/WFLY-3389?page=com.atlassian.jira.plugin.... ]
Oliver Waeldrich commented on WFLY-3389:
----------------------------------------
The stack trace indicates that Eclipse was started with a JDK < 1.7. java.net.InetSocketAddress.getHostString() was introduced with JDK 1.7. Use an sctual JDK to launch eclipse and the error should disappear.
> Error Connecting to WildFly via JMX
> -----------------------------------
>
> Key: WFLY-3389
> URL: https://issues.jboss.org/browse/WFLY-3389
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.CR1
> Environment: Windows 7 32 bit, behind a proxy that only lets IE through
> Reporter: R Veach
> Assignee: Darran Lofthouse
> Priority: Minor
> Attachments: console page.htm, eclipse error.txt, server.log
>
>
> When server is running through Eclipse Kepler, admin console is completely blank no error messages in the console and an Eclipse error dialog pops up.
> I tried running it outside eclipse using "standalone.bat" but get the same result. No error in the console, don't see the eclipse error anywhere, but the admin console doesn't show up.
> I have JBoss AS 7.1.1.Final and can access the console, but it may require a page refresh for it to fully display. Refreshing the page doesn't help in 8.1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4288) error when trying to execute commands using jboss-cli.sh
by André Caldeira (JIRA)
[ https://issues.jboss.org/browse/WFLY-4288?page=com.atlassian.jira.plugin.... ]
André Caldeira commented on WFLY-4288:
--------------------------------------
just to add that we use jboss-cli regularly in our installation so that we can configure jboss according to each scenario that we have.
> error when trying to execute commands using jboss-cli.sh
> --------------------------------------------------------
>
> Key: WFLY-4288
> URL: https://issues.jboss.org/browse/WFLY-4288
> Project: WildFly
> Issue Type: Bug
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: André Caldeira
> Assignee: Jason Greene
>
> Hi,
> I've configured jboss to use ssl, and after this change, sometimes, the command cannot be executed:
> [root@<node> ~]# /opt/oss/NSN-SQM-sqm_jboss/install/jboss-eap-6.2/bin/jboss-cli.sh --connect
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:284)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:292)
> at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9990
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:969)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:808)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:784)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:947)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
> at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:322)
> at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:318)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> ... 23 more
> In server.log what I can see when it happens is:
> 17:08:30,279 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> 17:08:42,071 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> 17:11:47,100 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> this problem only happens sometimes...
> Thanks in advance,
> Br,
> André
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4239) Support Locale.forLanguageTag()
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4239?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4239:
--------------------------------------
WFCORE-521 has been merged, so here is the PR: https://github.com/wildfly/wildfly-core/pull/456
> Support Locale.forLanguageTag()
> --------------------------------
>
> Key: WFLY-4239
> URL: https://issues.jboss.org/browse/WFLY-4239
> Project: WildFly
> Issue Type: Feature Request
> Components: Localization
> Affects Versions: 9.0.0.Alpha1
> Environment: JDK 7
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> The rules for Locale are different in JDK 6 vs 7, and this getLocale() method was written to conform to the JDK 6 rules. Hence it assumes 2 chars for language, 2 chars for country. Beginning with JDK 7 things are much more complex, and we don't support that. The language can be up to 8 chars, country can be [a-zA-Z]{2} | [0-9]{3}, there's the "script" element, and most importantly, Locale.forLanguageTag().
> It would be nice to at least support Locale.forLanguageTag().
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4288) error when trying to execute commands using jboss-cli.sh
by André Caldeira (JIRA)
André Caldeira created WFLY-4288:
------------------------------------
Summary: error when trying to execute commands using jboss-cli.sh
Key: WFLY-4288
URL: https://issues.jboss.org/browse/WFLY-4288
Project: WildFly
Issue Type: Bug
Affects Versions: JBoss AS7 7.2.0.Final
Reporter: André Caldeira
Assignee: Jason Greene
Hi,
I've configured jboss to use ssl, and after this change, sometimes, the command cannot be executed:
[root@<node> ~]# /opt/oss/NSN-SQM-sqm_jboss/install/jboss-eap-6.2/bin/jboss-cli.sh --connect
org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:284)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.modules.Module.run(Module.java:292)
at org.jboss.modules.Main.main(Main.java:455)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9990
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:969)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:808)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:784)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282)
... 8 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:947)
... 11 more
Caused by: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160)
at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
... 13 more
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:322)
at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:318)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337)
at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
... 23 more
In server.log what I can see when it happens is:
17:08:30,279 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
17:08:42,071 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
17:11:47,100 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
this problem only happens sometimes...
Thanks in advance,
Br,
André
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (SECURITY-874) CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/SECURITY-874?page=com.atlassian.jira.plug... ]
Bartosz Baranowski resolved SECURITY-874.
-----------------------------------------
Resolution: Done
Merged on 19/01
> CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
> -------------------------------------------------------------------------------------------------
>
> Key: SECURITY-874
> URL: https://issues.jboss.org/browse/SECURITY-874
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_4_0_21.Final
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Attachments: SECURITY-874.patch
>
>
> org.jboss.security.identity.extensions.CredentialIdentityFactory.NULL_IDENTITY does not get initialized to an empty identity due to initialization method returning a reference to NULL_IDENTITY, which has not initialized yet, resulting in null pointer. This causes NullPointerException in org.jboss.security.SecurityContextUtil.clearIdentities() and org.jboss.security.SecurityContextUtil.getIdentities() methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months