July 2015 - jboss-jira - Jboss List Archives

[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)

8 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)

8 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)

8 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)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4188) Client Mapping expressions are allowed but are not resolved if used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4188?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4188: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1175442|https://bugzilla.redhat.com/show_bug.cgi?id=1175442] from ON_QA to VERIFIED > Client Mapping expressions are allowed but are not resolved if used > ------------------------------------------------------------------- > > Key: WFLY-4188 > URL: https://issues.jboss.org/browse/WFLY-4188 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Chao Wang > Fix For: 9.0.0.Beta1 > > > If socket binding with client-mapping is used to provide a valid client address for EJB invocation to the client the expressions are not resolved. > Depend on the attribute the parsing failed direct during startup (port# is not numeric) or the expression is send to the client where the Exception is thrown at runtime. > Notice for EJB invocation the problem is only visible if the application is clustered, otherwise the cluster view (where the client-mapping take effect) is not send to the client. > Dec 17, 2014 2:53:43 PM org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager getEJBReceiver > INFO: Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='redhat', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}', destinationPort=8080}], resolvedDestination=[Destination address=${jboss.node.name}, destination port=8080]} in cluster ejb > java.lang.RuntimeException: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# > at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102) > at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) > ... 8 more > Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# > at java.net.URI$Parser.fail(URI.java:2829) > at java.net.URI$Parser.parseAuthority(URI.java:3167) > at java.net.URI$Parser.parseHierarchical(URI.java:3078) > at java.net.URI$Parser.parse(URI.java:3034) > at java.net.URI.<init>(URI.java:680) > at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100) > at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298) > ... 12 more -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5041) Test case for Reuse authenticated subject from incoming context when security domains match

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-5041: ---------------------------------- Summary: Test case for Reuse authenticated subject from incoming context when security domains match Key: WFLY-5041 URL: https://issues.jboss.org/browse/WFLY-5041 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Ondrej Lukas Assignee: Ondrej Lukas Add tests for Reuse authenticated subject from incoming context when security domains match. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-783) Intermittent Disconnection from CLI After Reload

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-783?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-783: ------------------------------------------------ Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1232933|https://bugzilla.redhat.com/show_bug.cgi?id=1232933] from ASSIGNED to VERIFIED > Intermittent Disconnection from CLI After Reload > ------------------------------------------------- > > Key: WFCORE-783 > URL: https://issues.jboss.org/browse/WFCORE-783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Alpha5 > Reporter: Joe Wertz > Assignee: Joe Wertz > Fix For: 2.0.0.Alpha8 > > > Race condition in server reload. The CLI only waits for a connection to be established and does not check the server status before continuing to execute commands. If the next command is executed before the server had completed the reload, failures occur. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-854) CLI Variables 'set' command broken

by Joe Wertz (JIRA)

[ https://issues.jboss.org/browse/WFCORE-854?page=com.atlassian.jira.plugin... ] Joe Wertz updated WFCORE-854: ----------------------------- Description: Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. With the upgrade, the commands overlap and interfere. Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. Export didn't exist before the upgrade, so disabling it doesn't cause problems. This was missed by the tests because part of the CLI actually bypasses AESH and most of the tests use that method. was: Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. With the upgrade, the commands overlap and interfere. Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. Export didn't exist before the upgrade, so disabling it doesn't cause problems. > CLI Variables 'set' command broken > ---------------------------------- > > Key: WFCORE-854 > URL: https://issues.jboss.org/browse/WFCORE-854 > 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 > > Original Estimate: 2 hours > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. > With the upgrade, the commands overlap and interfere. > Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. > Export didn't exist before the upgrade, so disabling it doesn't cause problems. > This was missed by the tests because part of the CLI actually bypasses AESH and most of the tests use that method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-854) CLI Variables 'set' command broken

by Joe Wertz (JIRA)

Joe Wertz created WFCORE-854: -------------------------------- Summary: CLI Variables 'set' command broken Key: WFCORE-854 URL: https://issues.jboss.org/browse/WFCORE-854 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 Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. With the upgrade, the commands overlap and interfere. Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. Export didn't exist before the upgrade, so disabling it doesn't cause problems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-18) jconsole window for an AS 7 server is labeled "JBoss CLI"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-18?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration updated WFLY-18: ---------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1215278 > jconsole window for an AS 7 server is labeled "JBoss CLI" > --------------------------------------------------------- > > Key: WFLY-18 > URL: https://issues.jboss.org/browse/WFLY-18 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Brian Stansberry > Assignee: Stan Silvert > Priority: Minor > Fix For: 8.0.0.Alpha1 > > Attachments: jconsole-screenshot.png > > > Run jconsole.sh and connect to an AS 7 server instance. The resulting window in jconsole is labeled "JBoss CLI / <machine name>". > The term CLI should be reserved for the actual CLI tool. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2015