July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-855) Intermittent Disconnection from CLI After Reload in domain mode

by Joe Wertz (JIRA)

Joe Wertz created WFCORE-855: -------------------------------- Summary: Intermittent Disconnection from CLI After Reload in domain mode Key: WFCORE-855 URL: https://issues.jboss.org/browse/WFCORE-855 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 2.0.0.Alpha12 Reporter: Joe Wertz Assignee: Joe Wertz Fix For: 2.0.0.Alpha12 Description of problem: CLI scripts for management of managed domain Version-Release number of selected component (if applicable): 6.4.3.CP.CR1 How reproducible: Always Steps to Reproduce: Use CLI script: :read-attribute(name=process-type) reload --host=master :read-attribute(name=process-type) or commands option for script Actual results: 6.4.3 ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)' { "outcome" => "success", "result" => "Domain Controller" } Failed to establish connection in 6025ms Expected results: 6.3.3 ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)' { "outcome" => "success", "result" => "Domain Controller" } { "outcome" => "success", "result" => "Domain Controller" } Additional info: - Follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1232933 - using --timeout doesn't workaround the problem -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ] Jesper Pedersen commented on WFLY-4682: --------------------------------------- wmq.8.rar can't be modified > 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.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-249) verifyCredential method(s) misleading

by David Lloyd (JIRA)

David Lloyd created ELY-249: ------------------------------- Summary: verifyCredential method(s) misleading Key: ELY-249 URL: https://issues.jboss.org/browse/ELY-249 Project: WildFly Elytron Issue Type: Bug Components: API / SPI, Realms Reporter: David Lloyd The {{verifyCredential(Object credential)}} method is misleading. It is in fact not generally possible or practical to verify a credential; rather what is being done is verifying a guess. I propose a couple changes. First, the argument to the method should be renamed "guess" to indicate that the object being passed in isn't a credential, but rather a credential-specific guess. Second, I propose that Password no longer be considered a valid argument to this method. The only use that serves is to extract a clear password guess anyway. Finally, I think we should consider renaming the method to something else, like: * verifyCredentialGuess * verifyGuess * checkCredentialGuess * etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-867) Drools Template files are ignored by KieBuilder

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-867?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-867. -------------------------------- Fix Version/s: 6.3.0.CR1 Resolution: Done Fixed by https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/e040e1ed3 and https://github.com/droolsjbpm/drools/commit/ee28a6e9b > Drools Template files are ignored by KieBuilder > ----------------------------------------------- > > Key: DROOLS-867 > URL: https://issues.jboss.org/browse/DROOLS-867 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.3.0.CR1 > > > Drools Template files (with extension .template) are currently ignored by KieBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-867) Drools Template files are ignored by KieBuilder

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-867: ---------------------------------- Summary: Drools Template files are ignored by KieBuilder Key: DROOLS-867 URL: https://issues.jboss.org/browse/DROOLS-867 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco Drools Template files (with extension .template) are currently ignored by KieBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5042) Two persistence.xml in two EJB projects within one EAR don't work

by Martin Rauscher (JIRA)

Martin Rauscher created WFLY-5042: ------------------------------------- Summary: Two persistence.xml in two EJB projects within one EAR don't work Key: WFLY-5042 URL: https://issues.jboss.org/browse/WFLY-5042 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Affects Versions: 9.0.0.Final Reporter: Martin Rauscher Assignee: Scott Marlow We have an EAR containing a JAR in /lib and two EJBs and one WAR each referencing the JAR. The rest of the dependencies is: WAR->EJB1->EJB2. If each of the EJB JARs has its own persistence.xml the EAR cannot be deployed anymore to WildFly. (It worked on WebSphere) This works fine as long as no persistence.xml exists. As soon as each EJB gets its own persistence.xml (in our full project they point to different DSs) we're not able to deploy anymore. Wildfly doesn't seem to be able to resolve dependencies between modules as soon as there are two persistence.xml's. Despite the (repro) project doesn't even use it (yet). If you remove the persistence.xml's the project works fine. From the error (see below) it looks like the services defined in EJB1 try to use the persistence unit defined in EJB2 despite there not being any kind of reference. Repro on [GitHub|https://github.com/Hades32/wildfly-issues]. Forum discussion [here|https://developer.jboss.org/thread/261445], including logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4956) Automatically enable Hibernate Search in deployments and allow override properties

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4956?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-4956: ------------------------------------ created pull request https://github.com/wildfly/wildfly/pull/7862 > Automatically enable Hibernate Search in deployments and allow override properties > ---------------------------------------------------------------------------------- > > Key: WFLY-4956 > URL: https://issues.jboss.org/browse/WFLY-4956 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Scott Marlow > > In case a deployment is using Hibernate ORM - either native Hibernate APIs or JPA - we should check if Hibernate Search also needs to be made available to the deployment (the *application classpath*). > * if any entity class has the `(a)org.hibernate.search.annotations.Indexed` annotation > * and/or if the persistence.xml has a any configuration property matching `hibernate.search.*`. > If either of these is true, *and* the default Hibernate ORM module is being added as well, then we should also add the module {{org.hibernate.search.orm:main}}. > If the user is overriding the Hibernate ORM version, then we shall not add this dependency either as the org.hibernate.search.orm:main module strictly refers and imports the module {{org.hibernate:main}}. > In all cases, the user should be able to override the deployer decision using a configuration property defined in the persistence unit > {{wildfly.jpa.hibernate.search.includedSlot}} > * if not present, use the automatic decision rules described above, and possibly log the action being taken > * if set to `none`, do not include Hibernate Search > * if set to `auto`, will behave like not having set the property > * if set to something else, use it as a slot name for the module you > will depend on -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-852) add Hibernate Search deployment processor

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFCORE-852?page=com.atlassian.jira.plugin... ] Scott Marlow closed WFCORE-852. ------------------------------- > add Hibernate Search deployment processor > ----------------------------------------- > > Key: WFCORE-852 > URL: https://issues.jboss.org/browse/WFCORE-852 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 2.0.0.Alpha12 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4450) Add test coverage for datasource credentials in security domain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4450?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4450: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1204286|https://bugzilla.redhat.com/show_bug.cgi?id=1204286] from ON_QA to VERIFIED > Add test coverage for datasource credentials in security domain > --------------------------------------------------------------- > > Key: WFLY-4450 > URL: https://issues.jboss.org/browse/WFLY-4450 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Fix For: 9.0.0.CR1 > > > Credentials coming to a DataSource from a security domain should be tested on supported platforms. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-849) XmlCompletionScannerTest fails with IBM JDK 8

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-849?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet commented on WFCORE-849: ------------------------------------------ Since the test doesn't keep a strong reference on the logger it gets garbage collected during it. > XmlCompletionScannerTest fails with IBM JDK 8 > --------------------------------------------- > > Key: WFCORE-849 > URL: https://issues.jboss.org/browse/WFCORE-849 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.0.Alpha11 > Reporter: Marek Kopecký > Assignee: ehsavoie Hugonnet > > *Description of problem:* > org.jboss.as.server.deployment.scanner.XmlCompletionScannerTest#testIncompleteDocument fails on IBM JDK 8 > *How reproducible:* > 100% on RHEL7 && IBM JDK 8 > 60% on RHEL6 && 64-bit && IBM JDK 8 > *Steps to Reproduce:* > # get fresh wildfly-core > # cd deployment-scanner > # mvn test -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -DfailIfNoTests=false -Dtest=XmlCompletionScannerTest > *Actual results:* > {noformat} > Running org.jboss.as.server.deployment.scanner.XmlCompletionScannerTest > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.254 sec <<< FAILURE! - in org.jboss.as.server.deployment.scanner.XmlCompletionScannerTest > testIncompleteDocument(org.jboss.as.server.deployment.scanner.XmlCompletionScannerTest) Time elapsed: 0.214 sec <<< FAILURE! > java.lang.AssertionError: > Expected: is <1> > but: was <0> > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.junit.Assert.assertThat(Assert.java:865) > at org.junit.Assert.assertThat(Assert.java:832) > at org.jboss.as.server.deployment.scanner.XmlCompletionScannerTest.testIncompleteDocument(XmlCompletionScannerTest.java:65) > {noformat} > *Expected results:* > No errors in output -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2015