[JBoss JIRA] (WFLY-6071) Mixed domain test suite should test using the legacy domain.xml files
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-6071:
--------------------------------------
Summary: Mixed domain test suite should test using the legacy domain.xml files
Key: WFLY-6071
URL: https://issues.jboss.org/browse/WFLY-6071
Project: WildFly
Issue Type: Task
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
The mixed domain testsuite is doing a lot of testing starting with the current release standard configs, then manipulating to get to something interoperable, and then launching a slave.
This is fine, but we need explicit coverage of the primary use case: take a config that worked in the legacy release, install it on the DC, and then have the slave start, confirming that the slave was able to join.
This is basically what users will do -- take profiles that worked and try and use them with a current DC and legacy slaves. Trying to take new profiles and adapt them to work on legacy slaves is more of a corner case. And testing that corner case as the primary coverage leads to holes, where the "correction" logic ends up hiding problems that shouldn't be hidden, e.g. WFCORE-1311.
So, for each legacy release we should boot the current DC with the standard domain.xml for that release and then start a legacy slave from that release.
We may need to apply some correction here too, but if we do it's a good opportunity to check why it's necessary, and whether a more user-friendly solution can be found.
That's not 100% coverage as there are things that weren't in our standard domain.xml, but it's a good smoke test. Subsystem specific test suites can check for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (LOGTOOL-76) JBoss Logging Processor should support WSDLException
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-76?page=com.atlassian.jira.plugin... ]
James Perkins closed LOGTOOL-76.
--------------------------------
Resolution: Duplicate Issue
This isn't quite a duplicate of LOGTOOL-79, but it would solve the issue so I'm closing it for now.
> JBoss Logging Processor should support WSDLException
> ----------------------------------------------------
>
> Key: LOGTOOL-76
> URL: https://issues.jboss.org/browse/LOGTOOL-76
> Project: Log Tool
> Issue Type: Bug
> Reporter: Tom Cunningham
> Assignee: David Lloyd
>
> This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
> {code}
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg,
> java.lang.Throwable t)
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg)
> {code}
> When I try to localize with this :
> {code}
> /**
> * couldNotFindServiceInTheWSDL method definition.
> * @param portName the portName
> * @param definitionDocumentBaseURI definitionDocumentBaseURI
> * @return WSDLException
> */
> @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
> WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
> {code}
> I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors. We should support them.
> {noformat}
> Failure:
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi... ]
Artur Kronenberg commented on DROOLS-1030:
------------------------------------------
For the people coming here with the same issue, this is the workaround I implemented:
1. Add a new Interface with say one method isExpired(). This method determines whether or not the fact can go.
2. Add a rule to match that interface. For me the Interface is called Expirable. This is my rule:
rule "fact_expiry_automation"
when
$e : Expirable( expired == true );
then
retract($e);
end
3. Have all your facts implement that interface.
4. Add a timer task manually that calls fireAllRules. Use an AgendaFilter in case you want to only match this rule exactly.
5. Run the task as often as you wish.
You will also have to remove the expires annotation on the original facts to stop drools from also trying to expire facts.
This solution has an issue where the expiry for the facts only work if the facts are inserted on session level. For example, I had to restructure my rules to not use entrypoints so that these facts could also expire programatically.
Hope that helps
> Nullpointer in JpaTimerJobInstance.call on startup
> ---------------------------------------------------
>
> Key: DROOLS-1030
> URL: https://issues.jboss.org/browse/DROOLS-1030
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
> Attachments: test-standalone.zip
>
>
> Hi,
> I have noticed Nullpointer exceptions when I try and reload a persisted session on startup. It is a bit hard to recreate (I am actually not managing it now since I deleted all old sessions to attempt recreation) but I figured maybe someone has an idea. Essentially I am getting this NPE twice:
> java.lang.NullPointerException: null
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> When debugging I noticed the following behaviour which points to a race condition:
> If I start my server and try to recreate the session, those NPEs happen 2x.
> If I start my server and put a breakpoint BEFORE creating the CommandService for execution, I can wait for a few seconds and the service can be found.
> It appears that the scheduler's timerJobFactoryManager is not fully there at the time the sessions is being loaded? Or something else is racing with the service creation.
> Is there a way for me to make sure everything is fully instantiated before I use drools? Does a workaround exist? Is this even a bug?
> Thanks and let me know your thoughts. If I run into this again I will attempt to try and reproduce it. Let me know if more info is needed!
> UPDATE:
> I noticed that the reason I can't reproduce it at the moment is that the JpaTimerJobInstance is never called with the newly persisted session. It appears that that timer job depends on something else to happen so that it thinks it needs to start the timerJob
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-637) /subsystem=logging/log-file resource cannot cope with an expression in the path
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-637?page=com.atlassian.jira.plugin... ]
James Perkins reassigned WFCORE-637:
------------------------------------
Assignee: (was: James Perkins)
> /subsystem=logging/log-file resource cannot cope with an expression in the path
> -------------------------------------------------------------------------------
>
> Key: WFCORE-637
> URL: https://issues.jboss.org/browse/WFCORE-637
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Affects Versions: 1.0.0.Beta3
> Reporter: Ivo Studensky
> Priority: Optional
>
> In log subsystem, nested expression can be used for path.
> {noformat}
> "path" => {
> "type" => STRING,
> "description" => "The filesystem path.",
> "expressions-allowed" => true,
> "nillable" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> {noformat}
> so if I use following log configuration :
> {noformat}
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="${jboss.server.name}.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="true"/>
> {noformat}
> server log name will be HOST_NAME.log and there is no problems to write.
> However, there is no log-file resource for it. This also leads into an issue that it cannot be displayed in Admin console Log Viewer menu.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-4682:
-----------------------------------
Note that the messaging-activemq subsystem is doing several things related to using JMS:
1. load the javax.jms.api so that it is available for deployment
2. support injection of JMSContext
3. handle JMS resources annotation definitions and deployment descriptors.
This issue deals only with (1) but (2) and (3) must also be available to the users with WebSphere MQ 8.
When an users wants to use WebSphere MQ 8 for its messaging broker, I'd suggest to always keep the messaging-activemq subsystem to provide (1), (2), and (3). As long as he does not add any <server> resource in the subsystem, there will be no Artemis code involved at all.
> standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4682
> URL: https://issues.jboss.org/browse/WFLY-4682
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, MSC
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Bartosz Baranowski
> Labels: duplicate
> Attachments: standalone-full.xml
>
>
> Deployment (Servlet, EJB, MDB) which is using Websphere MQ 8 resource adapter to send/receive messages from external Websphere MQ 8 instance is not loading "javax.jms.api" module. Deployment is using JMS api.
> This is change in behaviour against previous versions EAP 6/Widlfly 9.
> There is no error during deploy. Failures occur in the moment when deployment for example servlet is called. Following error is logged in EAP 7.0.0.DR2 log:
> {code}
> 08:57:24,835 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "servlet.war" with deployment "servlet.war"
> 08:57:24,838 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /home/mnovak/projects/eap-tests-wsmq/ibm-mq-testsuite/src/test/config/ibm8/install/jboss-eap-7.0/standalone/data/content/62/931347d12b65c80cd2201372be52f0494e361a/content
> 08:57:25,794 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /CleaningServlet/CleaningServlet: java.lang.NoClassDefFoundError: javax/jms/Message
> at org.jboss.as.test.ibm.mq.servlet.CleaningServlet.doGet(CleaningServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: javax.jms.Message from [Module "deployment.servlet.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 30 more
> {code}
> Websphere MQ resource adapter is rar archive in deployments directory. It's not configured in module. Only way to force loading of "javax.jms.api" for deployment is to add Dependecies: javax.jms.api to MANIFEST.MF or add it to global-modules. This negatively affects usability.
> Can be javax.jms.api loaded for deployment by default for "full" and "full-ha" profile?
> I'm adding standalone-full.xml with configuration for EAP 7.0.0.DR2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1040) Kie server on Tomcat with JACCValve fails authorisation
by Karel Suta (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1040?page=com.atlassian.jira.plugi... ]
Karel Suta commented on DROOLS-1040:
------------------------------------
fixed and merged into master and 6.4.x
> Kie server on Tomcat with JACCValve fails authorisation
> -------------------------------------------------------
>
> Key: DROOLS-1040
> URL: https://issues.jboss.org/browse/DROOLS-1040
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.0.Beta1
> Environment: Tomcat
> Kie server 6.4.0-SNAPSHOT
> Reporter: Karel Suta
> Assignee: Karel Suta
> Priority: Minor
> Labels: reported-by-qe
> Fix For: 6.4.0.CR1
>
>
> When Kie server is run on Tomcat container with org.kie.integration.tomcat.JACCValve configured then JBPM operations which needs authorisation invoked on Kie server fails with:
> "User '[UserImpl:'Roles']' does not have permissions to execute operation...".
> Error happens just with JACCValve which is used for Workbench, so this isn't critical issue.
> Issue is caused by JACCValve which register PolicyContextHandler with Subject returning 2 principals in HashSet, one principal represents user, second represent its roles.
> JACCIdentityProvider in Kie server in method getName() returns first principal from Subject which it finds, in case it is roles principal then is returned "Roles" as user name, which is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
