[JBoss JIRA] (WFLY-943) XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
by Joshua Wilson (JIRA)
[ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.s... ]
Joshua Wilson commented on WFLY-943:
------------------------------------
Looks like this was fixed on Wildfly.
https://github.com/wildfly/wildfly/pull/5560
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
> Key: WFLY-943
> URL: https://issues.jboss.org/browse/WFLY-943
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation
> Affects Versions: 8.0.0.Alpha3
> Reporter: Elias Ross
> Fix For: 8.0.0.Final
>
> Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd: elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd: elementFormDefault="unqualified"
--
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, 2 months
[JBoss JIRA] (WFLY-2635) HTTP Management Interface Configuration
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim commented on WFLY-2635:
----------------------------------------
I'll have a go for this one and try to provide the changes to allow the ip- and useragent- based filters to be configured for the management server. I currently have the filters enabled but missing the configuration part.
> HTTP Management Interface Configuration
> ---------------------------------------
>
> Key: WFLY-2635
> URL: https://issues.jboss.org/browse/WFLY-2635
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> Various configuration items are required for the HTTP Management interface, this is a parent task to combine them.
--
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, 2 months
[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-1376:
-----------------------------------
can you try with latest nightly build https://community.jboss.org/thread/224262
> 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
12 years, 2 months
[JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote Transaction Timeout
by Sfe Br (JIRA)
Sfe Br created WFLY-2852:
----------------------------
Summary: JBoss 7 - EJB Remote Transaction Timeout
Key: WFLY-2852
URL: https://issues.jboss.org/browse/WFLY-2852
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Sfe Br
Fix For: JBoss AS7 7.2.0.Final
I have a remote call that allow to run a process that takes more than 5 minutes, after passing this time the transaction was canceled and the global transaction was rollbacked at the commit phase.
The problem is that i can't modify the timeout value.
Note: After consulting the method createOrResumeXidTransaction of the EJBRemoteTransactionPropagatingInterceptor class, I found that the timeout value is always 300 seconds (it seems that this value is hardcoded)
You can refer to my discussion with jaikiran pai: https://community.jboss.org/thread/236493
Thanks,
--
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, 2 months
[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
12 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
12 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
12 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
12 years, 2 months