November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2138) Upgrade Jaxb depedency

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2138?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-2138: ------------------------------------- Assignee: Michael Biarnes Kiefer (was: Edson Tirelli) > Upgrade Jaxb depedency > ---------------------- > > Key: DROOLS-2138 > URL: https://issues.jboss.org/browse/DROOLS-2138 > Project: Drools > Issue Type: Bug > Reporter: Petar Tahchiev > Assignee: Michael Biarnes Kiefer > > I'm sorry if this is no the correct place to report this but when building my project with jdk9, I get this warning: > {code} > [WARNING] Failed to build parent project for com.sun.xml.bind.mvn:jaxb-bundles:pom:2.2.11 > [WARNING] Failed to build parent project for com.sun.xml.bind:jaxb-core:jar:2.2.11 > [WARNING] Unable to obtain POM for artifact : com.sun.xml.bind:jaxb-core:jar:2.2.11:compile > org.apache.maven.project.InvalidProjectModelException: Some problems were encountered while processing the POMs: > [ERROR] 'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} @ com.sun.xml.bind.mvn:jaxb-parent:[unknown-version], /home/petar/.m2/repository/com/sun/xml/bind/mvn/jaxb-parent/2.2.11/jaxb-parent-2.2.11.pom, line 164, column 29 > for project > at org.apache.maven.project.DefaultMavenProjectBuilder.transformError(DefaultMavenProjectBuilder.java:193) > at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:240) > at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251) > at org.codehaus.mojo.license.api.DefaultDependenciesTool.loadProjectDependencies(DefaultDependenciesTool.java:233) > at org.codehaus.mojo.license.api.DefaultThirdPartyHelper.loadDependencies(DefaultThirdPartyHelper.java:152) > at org.codehaus.mojo.license.AddThirdPartyMojo.loadDependencies(AddThirdPartyMojo.java:294) > at org.codehaus.mojo.license.AbstractAddThirdPartyMojo.init(AbstractAddThirdPartyMojo.java:400) > at org.codehaus.mojo.license.AbstractLicenseMojo.execute(AbstractLicenseMojo.java:169) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > {code} > which happens to be because of the jaxb dependency you have here: > https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... > which requires the {{tools.jar}} (from jaxb-parent-2.2.11 pom.xml): > {code} >  > <dependency> > <groupId>com.sun</groupId> > <artifactId>tools</artifactId> > <version>1.6</version> > <scope>system</scope> > <systemPath>${tools.jar}</systemPath> > </dependency> > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2328) CLI connect command should accept a --bind parameter

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2328?page=com.atlassian.jira.plugi... ] Ingo Weiss reassigned WFCORE-2328: ---------------------------------- Assignee: Ingo Weiss (was: Jean-Francois Denise) > CLI connect command should accept a --bind parameter > ---------------------------------------------------- > > Key: WFCORE-2328 > URL: https://issues.jboss.org/browse/WFCORE-2328 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Brian Stansberry > Assignee: Ingo Weiss > Priority: Minor > > When you launch the CLI you can pass a --bind=xxx param which then controls the client side bind address used for connections. But you can't specify this with the connect command itself. > This is minor; I just noticed it while experimenting with the fix for WFCORE-2225 when I wanted to confirm the fix was working by using the CLI. > Also, I noticed that if I did a "connect --bind=192.168.1.10" the CLI accepted the invalide command. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3424) Replace MSC listeners with stability monitors

by Richard Opalka (JIRA)

Richard Opalka created WFCORE-3424: -------------------------------------- Summary: Replace MSC listeners with stability monitors Key: WFCORE-3424 URL: https://issues.jboss.org/browse/WFCORE-3424 Project: WildFly Core Issue Type: Enhancement Components: Server Affects Versions: 4.0.0.Alpha2 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 4.0.0.Alpha3 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3421) Incorrect usage of requires for defining the relationship between outflow-anonymous and outflow-security-domains

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3421?page=com.atlassian.jira.plugi... ] Martin Choma commented on WFCORE-3421: -------------------------------------- Sorry, I thought edit of my previous comment invalidates your comment. So I wanted hold conversation consistent. Deleted Darran's comment: {noformat} Do we have any examples where setting an attribute to it's default value does mean that it's required attribute must also be defined? {noformat} > Incorrect usage of requires for defining the relationship between outflow-anonymous and outflow-security-domains > ---------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3421 > URL: https://issues.jboss.org/browse/WFCORE-3421 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 4.0.0.Alpha2 > Reporter: ehsavoie Hugonnet > > If outflow-anonymous is set to false then there is no need for outflow-security-domains as the default configuration shows clearly. > So > {noformat} > /subsystem=elytron/security-domain=ApplicationDomain:add(default-realm=ApplicationRealm,outflow-anonymous=false,realms=[{realm=ApplicationRealm,role-decoder=groups-to-roles}]) > {noformat} > should work like > {noformat} > /subsystem=elytron/security-domain=ApplicationDomain:add(default-realm=ApplicationRealm,realms=[{realm=ApplicationRealm,role-decoder=groups-to-roles}]) > {noformat} > A custom validation code is required instead of relying on the setRequires of SimpleAttributeDefinition -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1799) [Guided Decision Table] Field can not be bound if formula calculation type is used

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1799?page=com.atlassian.jira.plugi... ] Jozef Marko reassigned DROOLS-1799: ----------------------------------- Assignee: Jozef Marko (was: Michael Anstis) > [Guided Decision Table] Field can not be bound if formula calculation type is used > ---------------------------------------------------------------------------------- > > Key: DROOLS-1799 > URL: https://issues.jboss.org/browse/DROOLS-1799 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.4.1.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Fix For: 7.5.0.Final > > > It should be possible to bind the field of the constraint, even if the constraint calculation type is "formula". Examples of such rules can be seen in the [PR|https://github.com/kiegroup/drools/pull/1552]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1799) [Guided Decision Table] Field can not be bound if formula calculation type is used

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1799?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1799: -------------------------------- Tester: Michael Anstis (was: Jozef Marko) > [Guided Decision Table] Field can not be bound if formula calculation type is used > ---------------------------------------------------------------------------------- > > Key: DROOLS-1799 > URL: https://issues.jboss.org/browse/DROOLS-1799 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.4.1.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Fix For: 7.5.0.Final > > > It should be possible to bind the field of the constraint, even if the constraint calculation type is "formula". Examples of such rules can be seen in the [PR|https://github.com/kiegroup/drools/pull/1552]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1799) [Guided Decision Table] Field can not be bound if formula calculation type is used

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1799?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1799: -------------------------------- Affects Version/s: 7.4.1.Final > [Guided Decision Table] Field can not be bound if formula calculation type is used > ---------------------------------------------------------------------------------- > > Key: DROOLS-1799 > URL: https://issues.jboss.org/browse/DROOLS-1799 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.4.1.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Fix For: 7.5.0.Final > > > It should be possible to bind the field of the constraint, even if the constraint calculation type is "formula". Examples of such rules can be seen in the [PR|https://github.com/kiegroup/drools/pull/1552]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1799) [Guided Decision Table] Field can not be bound if formula calculation type is used

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1799?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1799: -------------------------------- Fix Version/s: 7.5.0.Final > [Guided Decision Table] Field can not be bound if formula calculation type is used > ---------------------------------------------------------------------------------- > > Key: DROOLS-1799 > URL: https://issues.jboss.org/browse/DROOLS-1799 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.4.1.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Fix For: 7.5.0.Final > > > It should be possible to bind the field of the constraint, even if the constraint calculation type is "formula". Examples of such rules can be seen in the [PR|https://github.com/kiegroup/drools/pull/1552]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9455) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-9455?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated WFLY-9455: ---------------------------------- Steps to Reproduce: Could be reproduced with jbosstm quickstart at https://github.com/jbosstm/quickstart {code} export JBOSS_HOME=... cp $JBOSS_HOME/docs/examples/configs/standalone-xts.xml $JBOSS_HOME/standalone/configuration mvn clean && mvn install -pl XTS/wsat-jta-multi_service -am -Parq -Dtest=BridgeFromJTATest#testCommit {code} was: Could be reproduced with jbosstm quickstart at https://github.com/jbosstm/quickstart {code} export JBOSS_HOME=... cp $JBOSS_HOME/docs/examples/configs/standalone-xts.xml $JBOSS_HOME/standalone/configuration mvn clean; mvn install -pl XTS/wsat-jta-multi_service -am -Parq -Dtest=BridgeFromJTATest#testCommit {code} > WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions > ------------------------------------------------------------------------------------- > > Key: WFLY-9455 > URL: https://issues.jboss.org/browse/WFLY-9455 > Project: WildFly > Issue Type: Bug > Components: XTS > Affects Versions: 11.0.0.CR1 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > It happens to get exception > {code} > ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0 > ERROR [org.jboss.as.txn] (default task-12) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction > at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:100) > at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1510) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} > when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11. > The integration issues were already discussed as part of the JBTM-2853. > Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs. > The trouble seems to be caused by the fact that transaction is imported on ivocation of WS > https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... > but as it was suspended in the integration code before > https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or... > now the WFTC holds the notion about the transaction even on call of > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... > and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3421) Incorrect usage of requires for defining the relationship between outflow-anonymous and outflow-security-domains

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3421?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-3421: ------------------------------------------ [~mchoma] Please don't delete my comments. I don't want to identify where we have attributes that have a default and a requires specified. I want to identify cases where these two are specified and the error reported by the management tier is actually valid. i.e. Where an attribute has a default defined then a subsystem can always correctly function using that value without the required attribute being set. How does explicitly setting an attribute to it's default value made the required attribute required. We have a proposal to add custom validation code to eliminate an error message that for me at the moment makes no sense - I would like to know if there are examples this error being reported is actually valid. > Incorrect usage of requires for defining the relationship between outflow-anonymous and outflow-security-domains > ---------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3421 > URL: https://issues.jboss.org/browse/WFCORE-3421 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 4.0.0.Alpha2 > Reporter: ehsavoie Hugonnet > > If outflow-anonymous is set to false then there is no need for outflow-security-domains as the default configuration shows clearly. > So > {noformat} > /subsystem=elytron/security-domain=ApplicationDomain:add(default-realm=ApplicationRealm,outflow-anonymous=false,realms=[{realm=ApplicationRealm,role-decoder=groups-to-roles}]) > {noformat} > should work like > {noformat} > /subsystem=elytron/security-domain=ApplicationDomain:add(default-realm=ApplicationRealm,realms=[{realm=ApplicationRealm,role-decoder=groups-to-roles}]) > {noformat} > A custom validation code is required instead of relying on the setRequires of SimpleAttributeDefinition -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 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 November 2017