[JBoss JIRA] (DROOLS-1319) Workbench Remote Maven artifacts deployment
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1319?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1319:
---------------------------------------
Configure the maven settings.xml file to deploy to the remote server.
> Workbench Remote Maven artifacts deployment
> -------------------------------------------
>
> Key: DROOLS-1319
> URL: https://issues.jboss.org/browse/DROOLS-1319
> Project: Drools
> Issue Type: Feature Request
> Reporter: Kavi sri
> Assignee: Edson Tirelli
>
> Hi,
> I created Rules in Drools workbench 6.2. And deployed the same as a Maven artifact to my local folder in Centos (/local/.m2 - Assuming my Workbench also deployed in the same Centos. Now i want to deploy the artifacts from Drools workbench to remote server [Say other Centos / Nexus repository]. How can i achieve it. Please suggest.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1320) [OSGi] drools-compiler uses wrong package name to import kie-ci
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1320?page=com.atlassian.jira.plugi... ]
Petr Široký updated DROOLS-1320:
--------------------------------
Description: drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.\*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}. (was: drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}.)
> [OSGi] drools-compiler uses wrong package name to import kie-ci
> ---------------------------------------------------------------
>
> Key: DROOLS-1320
> URL: https://issues.jboss.org/browse/DROOLS-1320
> Project: Drools
> Issue Type: Bug
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.\*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1320) [OSGi] drools-compiler uses wrong package name to import kie-ci
by Petr Široký (JIRA)
Petr Široký created DROOLS-1320:
-----------------------------------
Summary: [OSGi] drools-compiler uses wrong package name to import kie-ci
Key: DROOLS-1320
URL: https://issues.jboss.org/browse/DROOLS-1320
Project: Drools
Issue Type: Bug
Reporter: Petr Široký
Assignee: Petr Široký
drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7268) Elytron jdbc-realm *-index attributes validation
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7268?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7268:
-----------------------------------
Assignee: Ilia Vassilev
> Elytron jdbc-realm *-index attributes validation
> ------------------------------------------------
>
> Key: WFLY-7268
> URL: https://issues.jboss.org/browse/WFLY-7268
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Minor
>
> If I try to set any of password mapper (e.g. {{clear-password-mapper}}) and any of *-index attribute (e.g. {{password-index}}) with 0 value I get error from elytron
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/jdbc-realm=d:add(principal-query=[{sql="a",data-source="ExampleDS", bcrypt-mapper={password-index=0, salt-index=1, iteration-count-index=2}}])
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1",
> "rolled-back" => true
> }
> {code}
> and exception in server log
> {code}
> 07:16:47,608 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("jdbc-realm" => "b")
> ]): java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1
> at org.wildfly.common.Assert.checkMinimumParameter(Assert.java:132)
> at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper.<init>(PasswordKeyMapper.java:63)
> at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper$Builder.build(PasswordKeyMapper.java:389)
> at org.wildfly.extension.elytron.JdbcRealmDefinition$ClearPasswordObjectDefinition.toPasswordKeyMapper(JdbcRealmDefinition.java:133)
> at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.resolveKeyMappers(JdbcRealmDefinition.java:571)
> at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.performRuntime(JdbcRealmDefinition.java:534)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Could that be validated in subsystem? There would be 2 benefits:
> * no exception is thrown in log. Exception seems like something suprised us.
> * message contains more proper attribute name, e.g. hashColumn -> password-index.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7235) InfinispanResourceRefTestCase fails with security manager
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-7235?page=com.atlassian.jira.plugin.... ]
Ingo Weiss reassigned WFLY-7235:
--------------------------------
Assignee: Ingo Weiss (was: Jan Tymel)
> InfinispanResourceRefTestCase fails with security manager
> ---------------------------------------------------------
>
> Key: WFLY-7235
> URL: https://issues.jboss.org/browse/WFLY-7235
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
> at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
> at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
> at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
> at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
> at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
> ... 210 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1319) Workbench Remote Maven artifacts deployment
by Kavi sri (JIRA)
Kavi sri created DROOLS-1319:
--------------------------------
Summary: Workbench Remote Maven artifacts deployment
Key: DROOLS-1319
URL: https://issues.jboss.org/browse/DROOLS-1319
Project: Drools
Issue Type: Feature Request
Reporter: Kavi sri
Assignee: Edson Tirelli
Hi,
I created Rules in Drools workbench 6.2. And deployed the same as a Maven artifact to my local folder in Centos (/local/.m2 - Assuming my Workbench also deployed in the same Centos. Now i want to deploy the artifacts from Drools workbench to remote server [Say other Centos / Nexus repository]. How can i achieve it. Please suggest.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7236) DatasourceNonCcmTestCase fails with security manager
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-7236?page=com.atlassian.jira.plugin.... ]
Ingo Weiss reassigned WFLY-7236:
--------------------------------
Assignee: Ingo Weiss (was: Jan Tymel)
> DatasourceNonCcmTestCase fails with security manager
> ----------------------------------------------------
>
> Key: WFLY-7236
> URL: https://issues.jboss.org/browse/WFLY-7236
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testJTADS*
> *org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testNonJTADS*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/dummy.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.dummy.jar:main" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> ... 146 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6409) Update default domain configuration to use remote+http
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6409?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet updated WFLY-6409:
------------------------------------
Summary: Update default domain configuration to use remote+http (was: Update default domain configuration to use http-remoting)
> Update default domain configuration to use remote+http
> ------------------------------------------------------
>
> Key: WFLY-6409
> URL: https://issues.jboss.org/browse/WFLY-6409
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> Our default domain configuration still use the native remote protocol on port 9999 for DC-HC communication. Update those files so that we use http-remoting on port 9990.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7268) Elytron jdbc-realm *-index attributes validation
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7268?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6314 to WFLY-7268:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7268 (was: JBEAP-6314)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
> Elytron jdbc-realm *-index attributes validation
> ------------------------------------------------
>
> Key: WFLY-7268
> URL: https://issues.jboss.org/browse/WFLY-7268
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Priority: Minor
>
> If I try to set any of password mapper (e.g. {{clear-password-mapper}}) and any of *-index attribute (e.g. {{password-index}}) with 0 value I get error from elytron
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/jdbc-realm=d:add(principal-query=[{sql="a",data-source="ExampleDS", bcrypt-mapper={password-index=0, salt-index=1, iteration-count-index=2}}])
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1",
> "rolled-back" => true
> }
> {code}
> and exception in server log
> {code}
> 07:16:47,608 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("jdbc-realm" => "b")
> ]): java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1
> at org.wildfly.common.Assert.checkMinimumParameter(Assert.java:132)
> at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper.<init>(PasswordKeyMapper.java:63)
> at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper$Builder.build(PasswordKeyMapper.java:389)
> at org.wildfly.extension.elytron.JdbcRealmDefinition$ClearPasswordObjectDefinition.toPasswordKeyMapper(JdbcRealmDefinition.java:133)
> at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.resolveKeyMappers(JdbcRealmDefinition.java:571)
> at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.performRuntime(JdbcRealmDefinition.java:534)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Could that be validated in subsystem? There would be 2 benefits:
> * no exception is thrown in log. Exception seems like something suprised us.
> * message contains more proper attribute name, e.g. hashColumn -> password-index.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months