[JBoss JIRA] (DROOLS-372) InstantiationError during condition evaluation in Drools 6.0.0.Final
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-372?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-372:
------------------------------------------------
Tomas Schlosser <tschloss(a)redhat.com> changed the Status of [bug 1040007|https://bugzilla.redhat.com/show_bug.cgi?id=1040007] from ON_QA to VERIFIED
> InstantiationError during condition evaluation in Drools 6.0.0.Final
> --------------------------------------------------------------------
>
> Key: DROOLS-372
> URL: https://issues.jboss.org/browse/DROOLS-372
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Environment: reproduced on both jdk 6 and jdk 7
> Reporter: Loic Albertin
> Assignee: Mario Fusco
> Fix For: 6.0.1.Final
>
> Attachments: drools-issue.zip
>
>
> Kindly find bellow the initial discussion from rules-user(a)list.jboss.org
> In addition I attach a sample project that reproduce the error.
> To run it simply type 'mvn clean install exec:java'.
> An interesting thing is that on my environment the issue always appears at the 21st insertion.
> {quote}
> Hi all,
> I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
> The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
> The rule condition is quite simple
> $e : JasmineEventEB(probe == "Button:pris" && value == "1")
> In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
> The stacktrace is:
> {noformat}
> java.lang.InstantiationError: java.io.Serializable
> at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1149)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> {noformat}
> I tested both with the java and mvel dialect with the same result.
> Does someone has already encountered this kind of error?
> If you need more details or clarifications please let me know.
> Thanks & regards,
> Loïc
> {quote}
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2706?page=com.atlassian.jira.plugin.... ]
Andre Pankraz updated WFLY-2706:
--------------------------------
Component/s: Web (Undertow)
> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
> Key: WFLY-2706
> URL: https://issues.jboss.org/browse/WFLY-2706
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: CentOS, OpenJDK7
> Reporter: Andre Pankraz
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> assert context != null;
> this.servletContext = context;
> final String serverInfo = servletContext.getServerInfo();
> jboss = serverInfo.contains("JBoss") ;
> glassfish = serverInfo.contains("GlassFish")
> || serverInfo.contains("Sun Java System Application Server");
> weblogic = serverInfo.contains("WebLogic");
> jonas = System.getProperty("jonas.name") != null;
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2706?page=com.atlassian.jira.plugin.... ]
Andre Pankraz updated WFLY-2706:
--------------------------------
Description:
javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
"Undertow" and not with JBoss or Wildfly. Is this intentional?
Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
void initServletContext(ServletContext context) {
assert context != null;
this.servletContext = context;
final String serverInfo = servletContext.getServerInfo();
jboss = serverInfo.contains("JBoss") ;
glassfish = serverInfo.contains("GlassFish")
|| serverInfo.contains("Sun Java System Application Server");
weblogic = serverInfo.contains("WebLogic");
jonas = System.getProperty("jonas.name") != null;
Environment: CentOS, OpenJDK7
> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
> Key: WFLY-2706
> URL: https://issues.jboss.org/browse/WFLY-2706
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Environment: CentOS, OpenJDK7
> Reporter: Andre Pankraz
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> assert context != null;
> this.servletContext = context;
> final String serverInfo = servletContext.getServerInfo();
> jboss = serverInfo.contains("JBoss") ;
> glassfish = serverInfo.contains("GlassFish")
> || serverInfo.contains("Sun Java System Application Server");
> weblogic = serverInfo.contains("WebLogic");
> jonas = System.getProperty("jonas.name") != null;
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2701) Deployed JMS resources are not manageable in the GUI console
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2701?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-2701:
-----------------------------------
Note that such JMS resources are not part of the server management model and should only appear in the "runtime" tab of the admin console
> Deployed JMS resources are not manageable in the GUI console
> ------------------------------------------------------------
>
> Key: WFLY-2701
> URL: https://issues.jboss.org/browse/WFLY-2701
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMS
> Affects Versions: 8.0.0.CR1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> JMS resources that are part of a deployment are not manageable using the GUI console.
> They are manageable using the CLI console though under
> {noformat}
> /deployment=*/subsystem=messaging/hornetq-server=*
> {noformat}
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems in Wildfly
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2705?page=com.atlassian.jira.plugin.... ]
Andre Pankraz updated WFLY-2705:
--------------------------------
Description:
I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in jboss-as-7.2.0.Final.)
* If i have an JSF inputText in a form (hence POST)
* and I enter "TestÜÖÄ"
* I get "TestÃ?Ã?Ã" as result.
If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
I have set in the environment:
-Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
An encoding filter didn't help either.
May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
Example page for quick test:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Test</title>
</h:head>
<h:body>
<h1>Test ÜÄÖ</h1>
<h:form id="test">
<h:inputText label="Test: " value="#{test.test}">
<f:ajax render=":test" />
</h:inputText>
AJAX: #{test.test}
<br />
<h:commandButton action="#{test.print()}" value="Print" />
</h:form>
</h:body>
</html>
</f:view>
package test;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
@Named
@RequestScoped
public class Test {
private String test;
public String getTest() {
return test;
}
public void setTest(String test) {
this.test = test;
}
public String print() {
System.out.println("TEST: " + getTest());
return "success";
}
}
Environment:
CentOS
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
> Key: WFLY-2705
> URL: https://issues.jboss.org/browse/WFLY-2705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
> Reporter: Andre Pankraz
> Assignee: Stuart Douglas
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "TestÜÖÄ"
> * I get "TestÃ?Ã?Ã" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
> -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> <html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> <title>Test</title>
> </h:head>
> <h:body>
> <h1>Test ÜÄÖ</h1>
> <h:form id="test">
> <h:inputText label="Test: " value="#{test.test}">
> <f:ajax render=":test" />
> </h:inputText>
> AJAX: #{test.test}
> <br />
> <h:commandButton action="#{test.print()}" value="Print" />
> </h:form>
> </h:body>
> </html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> private String test;
> public String getTest() {
> return test;
> }
> public void setTest(String test) {
> this.test = test;
> }
> public String print() {
> System.out.println("TEST: " + getTest());
> return "success";
> }
> }
--
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
10 years, 4 months
[JBoss JIRA] (AS7-4990) Cannot embed Jersey 1.13-b01 with error: UnsupportedOperationException: JBAS011859: Naming context is read-only
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4990?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated AS7-4990:
--------------------------------------
Forum Reference: https://community.jboss.org/message/851434#851434
> Cannot embed Jersey 1.13-b01 with error: UnsupportedOperationException: JBAS011859: Naming context is read-only
> ---------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4990
> URL: https://issues.jboss.org/browse/AS7-4990
> Project: Application Server 7
> Issue Type: Bug
> Components: Naming
> Affects Versions: 7.1.1.Final
> Environment: JBoss AS 7.1.1.Final (removing the jaxrs subsystem)
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
> Linux annafi.dev 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:57:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Hendy Irawan
> Assignee: Stuart Douglas
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: jerseyissue.zip
>
>
> {code}
> 03:47:22,356 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"thread-inmem-jerseywar.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"thread-inmem-jerseywar.war\".WeldService: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:126)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:116)
> at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:338)
> at org.jboss.as.naming.InitialContext.createSubcontext(InitialContext.java:229)
> at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:346)
> at javax.naming.InitialContext.createSubcontext(InitialContext.java:483)
> at com.sun.jersey.server.impl.cdi.CDIExtension$1.stepInto(CDIExtension.java:280)
> at com.sun.jersey.server.impl.cdi.CDIExtension.diveIntoJNDIContext(CDIExtension.java:267)
> at com.sun.jersey.server.impl.cdi.CDIExtension.createJerseyConfigJNDIContext(CDIExtension.java:273)
> at com.sun.jersey.server.impl.cdi.CDIExtension.initialize(CDIExtension.java:192)
> at com.sun.jersey.server.impl.cdi.CDIExtension.beforeBeanDiscovery(CDIExtension.java:297)
> 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:601)
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
> at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
> at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:229)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46)
> at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:46)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:322)
> at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
> at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
> 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.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "}}}}
> {code}
> Sample project to reproduce:
> https://github.com/ceefour/odata-sandbox/tarball/jboss-jndi-readonly-jersey
> in folder: thread-inmem-jerseywar
> The JBoss AS 7.1.1 configuration is in: thread-inmem-jerseywar/jboss/standalone-no-jaxrs.xml
--
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
10 years, 4 months