[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
nathan dennis commented on WFLY-1376:
-------------------------------------
I am also seeing this on CR1
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
> Key: WFLY-1376
> URL: https://issues.jboss.org/browse/WFLY-1376
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
> <error-page>
> <error-code>404</error-code>
> <location>/error/pageNotFound.jsf</location>
> </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 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
10 years, 2 months
[JBoss JIRA] (WFLY-2838) Revisit default mod_cluster metric for WildFly 8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-2838:
--------------------------------------
The "default" thread pool is server-wide -- so any subsystem can use those threads. Which might be an interesting metric, but might not be an ideal default.
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
> Key: WFLY-2838
> URL: https://issues.jboss.org/browse/WFLY-2838
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity..
--
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, 2 months
[JBoss JIRA] (WFLY-2851) Can't validate jboss-deployment-structure.xml due to incorrect schema
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2851?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-2851:
------------------------------------
Assignee: Stuart Douglas
> Can't validate jboss-deployment-structure.xml due to incorrect schema
> ---------------------------------------------------------------------
>
> Key: WFLY-2851
> URL: https://issues.jboss.org/browse/WFLY-2851
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Harald Wellmann
> Assignee: Stuart Douglas
>
> The following deployment structure cannot be validated against the XML schema:
> {code:xml}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="foo"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.
--
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, 2 months
[JBoss JIRA] (DROOLS-419) "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-419?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-419:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-419
> URL: https://issues.jboss.org/browse/DROOLS-419
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Right hand side of diagram at http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/...
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20140130.drools6testmvnlatest.zip
>
>
> Hello, this is to report (potentially) a bug about "Cannot find KieModule: com.acme:X:RELEASE" or "Cannot find KieModule: com.acme:X:LATEST" when invoking {{kieServices.newKieContainer( releaseId )}} with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> More precisely, with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/... , I mean that before launching Application, I performed
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> h5. Disclaimer
> I'm not 100% sure whether this is bug of maven process, maven libraries, or Drools library; I prefer to report it anyway because likely could impact other users if installing via the maven-dependency-plugin:get goal, especially in distributed or JavaEE deployments? Sorry if actually not Drools library bug, I report all details below, *including current workaround* I have found to avoid this issue.
> h5. DETAILS
> Suppose there is a kjar artifact KIE module, {{'drools6testmvnlatest.therules'}}, as per attached project zip file. And this artifact is installed in local nexus repository at http://nexus-hostname/nexus/content/repositories/releases/ .
> Now ,suppose with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/... , _Application_ is jar {{'drools6testmvnlatest.thestandaloneengine'}} as per attached project zip file, and is being executed on a dedicate machine, not the development computers.
> {code:title=App.java}
> public static void main( String[] args ) {
> KieServices kieServices = KieServices.Factory.get();
> ReleaseId releaseId = kieServices.newReleaseId( "com.acme", "drools6testmvnlatest.therules", args[0] );
> KieContainer kContainer = kieServices.newKieContainer( releaseId );
> KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
> kieBaseConf.setOption( EventProcessingOption.STREAM );
> KieBase kBase = kContainer.newKieBase(kieBaseConf);
> for ( KiePackage a : kBase.getKiePackages()) {
> for (Rule r : a.getRules()) {
> logger.info("KiePackage {} Rule {}", new Object[]{a.getName(), r.getName()});
> }
> }
> }
> {code}
> The first thing to do before executing it, would be to fetch and install into local .m2 repository the required KIE module Rule artifact project kjar {{'drools6testmvnlatest.therules'}}. To do so, the following command is executed:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> Execution of
> {code}
> java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar RELEASE
> {code}
> Would generate the following stack trace
> {code}
> Exception in thread "main" java.lang.RuntimeException: Cannot find KieModule: com.acme:drools6testmvnlatest.therules:RELEASE
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
> at com.acme.drools6testmvnlatest.thestandaloneengine.App.main(App.java:24)
> {code}
> Same for LATEST as launch parameter.
> But fixed version, eg: 0.0.2 as launch parameter, will work.
> {code}
> D:\inbox>java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar 0.0.2
> 2014-01-30 19:24:12,128 [main] INFO org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added:ZipKieModule[ ReleaseId=com.acme:drools6testmvnlatest.therules:0.0.2file=D:\Documents and Settings\mmortari\.m2\repository\com\acme\drools6testmvnlatest.therules\0.0.2\drools6testmvnlatest.therules-0.0.2.jar]
> 2014-01-30 19:24:12,440 [main] INFO com.acme.drools6testmvnlatest.thestandaloneengine.App - KiePackage com.acme.drools6testmvnlatest.therules Rule Dummy rule on String
> {code}
> Please notice at this point this is the content of the .m2 local repository (this led me to discover the workaround)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> └───drools6testmvnlatest.therules
> │ maven-metadata-nexus-hostname-nexus.xml
> │ maven-metadata-nexus-hostname-nexus.xml.sha1
> │ maven-metadata-temp.xml
> │ maven-metadata-temp.xml.sha1
> │ resolver-status.properties
> │
> └───0.0.2
> drools6testmvnlatest.therules-0.0.2.jar
> drools6testmvnlatest.therules-0.0.2.jar.sha1
> drools6testmvnlatest.therules-0.0.2.pom
> drools6testmvnlatest.therules-0.0.2.pom.sha1
> _remote.repositories
> {code}
> h5. WORKAROUND
> The only options 1-2-3 ways I found to avoid this issue, and be able to launch successfully with RELEASE or LATEST as the launch parameter for the ReleaseId version, is to:
> h6. Workaround Option 1
> Do 'fake' a pom.xml with the dependency, something similar to:
> {code}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.acme</groupId>
> <artifactId>fakepom</artifactId>
> <version>0.0.1</version>
> <packaging>jar</packaging>
> <dependencies>
> <dependency>
> <groupId>com.acme</groupId>
> <artifactId>drools6testmvnlatest.therules</artifactId>
> <version>RELEASE</version>
> </dependency>
> </dependencies>
>
> </project>
> {code}
> And then launch maven in the same directory of this 'fake' pom.xml with the following command:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:go-offline
> {code}
> This usually generate the 'maven-metadata-local' file in the local .m2 repo:
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> └───drools6testmvnlatest.therules
> │ maven-metadata-nexus-hostname-nexus.xml
> │ maven-metadata-nexus-hostname-nexus.xml.sha1
> │ maven-metadata-local.xml
> │ maven-metadata-local.xml.sha1
> │ maven-metadata-temp.xml
> │ maven-metadata-temp.xml.sha1
> │ resolver-status.properties
> │
> └───0.0.2
> drools6testmvnlatest.therules-0.0.2.jar
> drools6testmvnlatest.therules-0.0.2.jar.sha1
> drools6testmvnlatest.therules-0.0.2.pom
> drools6testmvnlatest.therules-0.0.2.pom.sha1
> _remote.repositories
> {code}
> h6. Workaround Option2
> Well, actually this is to report that not all the time the Option1 works, so what I do, is that I copy-rename the 'maven-metadata-temp.xml' file into the 'maven-metadata-local.xml' file.
> h6. Workaround Option3
> Download manually the .jar file, the .pom file from the nexus webapplication, then usual maven
> {code}
> D:\inbox>mvn install:install-file -Dfile=drools6testmvnlatest.therules-0.0.2.jar -DpomFile=drools6testmvnlatest.therules-0.0.2.pom -Dpackaging=jar
> {code}
> This will create directly the 'maven-metadata-local.xml' file and the ' -Dpackaging=jar' option do force it to install it in the .m2 local repository with .jar extension (not kjar)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> └───drools6testmvnlatest.therules
> │ maven-metadata-local.xml
> │
> └───0.0.2
> drools6testmvnlatest.therules-0.0.2.jar
> drools6testmvnlatest.therules-0.0.2.pom
> _remote.repositories
> {code}
--
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, 2 months
[JBoss JIRA] (WFLY-2838) Revisit default mod_cluster metric for WildFly 8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-2838:
--------------------------------------
JFC would prefer autogenerating capacity of the busyness metric (e.g. in JBW it is 128 requests per sec per CPU) [or session.]
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
> Key: WFLY-2838
> URL: https://issues.jboss.org/browse/WFLY-2838
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity..
--
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, 2 months
[JBoss JIRA] (WFLY-2838) Revisit default mod_cluster metric for WildFly 8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-2838:
--------------------------------------
Stuart is fine with CPU.
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
> Key: WFLY-2838
> URL: https://issues.jboss.org/browse/WFLY-2838
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity..
--
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, 2 months
[JBoss JIRA] (DROOLS-383) switch over String in function
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-383?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-383:
------------------------------------
The problem is not only in functions. It happens exactly the same if you try to use the switch over String directly in a consequence.
That error message is generated by the Eclipse Java Compiler the we are using internally at the moment.
The only way to fix this is to migrate to the native Java compiler that it is something that we have already planned.
This is only a reason more to make this migration asap.
> switch over String in function
> ------------------------------
>
> Key: DROOLS-383
> URL: https://issues.jboss.org/browse/DROOLS-383
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20131219.drools6scratch-switchoverstring.zip
>
>
> *Executive Summary*: if I try to implement switch over String as per Java 1.7, inside of DRL function, compilation of DRL fails, but the error message would suggest that actually switch over String should work.
> *Steps to reproduce*
> Have a DRL file with function with String parameter and inside the function a switch over the parameter, for example
> {code:title=acme.drl|borderStyle=solid}
> rule "Stupid rule over String"
> when
> String()
> then
> System.out.println("Hello world");
> end
> function void theTest(String input) {
> switch(input) {
> case "Hello World" :
> System.out.println("yep");
> break;
> default :
> System.out.println("uh");
> break;
> }
> }
> {code}
> Have simple code to compile DRL for default KieBase, for example snippet:
> {code:title=App.java|borderStyle=solid}
> String input = "Hello World";
> // Java 1.7
> switch(input) {
> case "Hello World" :
> System.out.println("yep");
> break;
> default :
> System.out.println("uh");
> break;
> }
> System.out.println( "Hello World!" );
> KieServices ks = KieServices.Factory.get();
> KieContainer kContainer = ks.getKieClasspathContainer();
> KieBase kieBase = kContainer.getKieBase();
> for ( KiePackage kp : kieBase.getKiePackages() ) {
> for (Rule rule : kp.getRules()) {
> System.out.println("kp" + kp + " rule " + rule.getName());
> }
> }
> {code}
> Console would log DRL compile fails with error:
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=acme.drl, line=-1, column=0
> text=Error importing : 'defaultpkg.TheTest.theTest'], Message [id=2, level=ERROR, path=acme.drl, line=8, column=0
> text=[ function theTesttheTest (line:8): Cannot switch on a value of type String. Only convertible int values, strings or enum constants are permitted
> ]], Message [id=3, level=ERROR, path=acme.drl, line=1, column=0
> text=Rule Compilation error The import defaultpkg.TheTest cannot be resolved]]
> {noformat}
> Please notice the 'strings' bit in the error message : {{Cannot switch on a value of type String. Only convertible int values, *strings* or enum constants are permitted}}
> Therefore would suggest it would compile a switch over String, but for some reason it is failing to recognize that input parameter is indeed a String?
> Thank you
> Ciao
> MM
--
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, 2 months
[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov closed WFLY-2785.
---------------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2785
> URL: https://issues.jboss.org/browse/WFLY-2785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.CR1
> Environment: windows
> Reporter: Aleksandar Kostadinov
> Assignee: Aleksandar Kostadinov
> Labels: addressing, domain, socket
> Fix For: 8.0.0.Final
>
> Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>
> import java.io.IOException;
> import java.io.OutputStream;
> -import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.util.Collections;
> import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
> public boolean execute(ManagedServer server) throws Exception {
> assert Thread.holdsLock(ManagedServer.this); // Call under lock
> // Reconnect
> - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> + final String hostName = managementSocket.getHostString();
> final int port = managementSocket.getPort();
> processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
> return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.
--
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, 2 months
[JBoss JIRA] (WFLY-2522) Error when invoking @Remove method for stateful bean in transaction
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2522?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-2522:
---------------------------------
Priority: Major (was: Blocker)
Steps to Reproduce:
1- Download projects from http://www.filedropper.com/jbosstxsyncerror
The zip contains 3 projects
JBossTxSyncError : EJB Project
JBossTxSyncErrorClient : EJB Client Project
JBossTxSyncErrorEar : Ear project
2- Import project into Eclipse
3- add required libraries in build path
JBossTxSyncError
JBoss 7.1 Runtime
JBossTxSyncErrorClient
jboss-client.jar
jboss-ejb-api_3.1_spec-1.0.2.Final.jar
4- create table using create.sql file under JBossTxSyncErrorClient
5- configure jboss-ejb-client.properties file under JBossTxSyncErrorClient
6- configure a datasource for mysql connection
7- enter datasource Jndi name in file messages.properties under JBossTxSyncError project in key EmployeeBean.datasourceJndi
8- deploy ear file and run OldEjbClient.java
was:
1- Download projects from http://www.filedropper.com/jbosstxsyncerror
The zip contains 3 projects
JBossTxSyncError : EJB Project
JBossTxSyncErrorClient : EJB Client Project
JBossTxSyncErrorEar : Ear project
2- Import project into Eclipse
3- add required libraries in build path
JBossTxSyncError
JBoss 7.1 Runtime
JBossTxSyncErrorClient
jboss-client.jar
jboss-ejb-api_3.1_spec-1.0.2.Final.jar
4- create table using create.sql file under JBossTxSyncErrorClient
5- configure jboss-ejb-client.properties file under JBossTxSyncErrorClient
6- configure a datasource for mysql connection
7- enter datasource Jndi name in file messages.properties under JBossTxSyncError project in key EmployeeBean.datasourceJndi
8- deploy ear file and run OldEjbClient.java
This only occurs if you attempt to remove an EJB in a transaction synchronization callback.
> Error when invoking @Remove method for stateful bean in transaction
> -------------------------------------------------------------------
>
> Key: WFLY-2522
> URL: https://issues.jboss.org/browse/WFLY-2522
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Beta1
> Reporter: noel a.a
> Assignee: David Lloyd
>
> I'm invoking method annotated with @Remove
> {code}
> @Remove
> public void remove() {
> ...
> {code}
> On invocation inside active transaction I'm getting following error :
> {noformat}
> Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:374)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:351)
> at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:165) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:57) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:283) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:200) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> ... 140 more
> {noformat}
> EJB Spec paragraphe 4.6.4 states:
> {quote}
> If a session bean instance is participating in a transaction, it is an error for a client to invoke the remove method on the session object’s home or component interface object. The container must detect such an attempt and throw the javax.ejb.RemoveException to the client. The container should not mark the client’s transaction for rollback, thus allowing the client to recover. Note that this restriction only applies to the remove method on the session object’s home or component interface, not to the invocation of @Remove methods.
> {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, 2 months