[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)
8 years, 3 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)
8 years, 3 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)
8 years, 3 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)
8 years, 3 months
[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed
by lorenzo benvenuti (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ]
lorenzo benvenuti commented on JBJCA-1321:
------------------------------------------
Thank you Stefano (next time I'll post the question in the forum).
lorenzo
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: JBJCA-1321
> URL: https://issues.jboss.org/browse/JBJCA-1321
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: lorenzo benvenuti
> Assignee: Lin Gao
> Priority: Critical
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1854) Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1854:
-------------------------------------------
Fixed by WFCORE-1851
> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1854
> URL: https://issues.jboss.org/browse/WFCORE-1854
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha9
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
> "outcome" => "success",
> "result" => [
> {
> "path" => "META-INF/",
> "directory" => true
> },
> {
> "path" => "META-INF/MANIFEST.MF",
> "directory" => false,
> "file-size" => 130L
> },
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/application.xml",
> "directory" => false,
> "file-size" => 802L
> },
> {
> "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
> "directory" => false,
> "file-size" => 1955L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
> "directory" => false,
> "file-size" => 5582L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
> "directory" => false,
> "file-size" => 143L
> }
> ]
> }
> {code}
> WFCORE-1851 does not fix this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1854) Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet closed WFCORE-1854.
-------------------------------------
Resolution: Cannot Reproduce Bug
> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1854
> URL: https://issues.jboss.org/browse/WFCORE-1854
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha9
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
> "outcome" => "success",
> "result" => [
> {
> "path" => "META-INF/",
> "directory" => true
> },
> {
> "path" => "META-INF/MANIFEST.MF",
> "directory" => false,
> "file-size" => 130L
> },
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/application.xml",
> "directory" => false,
> "file-size" => 802L
> },
> {
> "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
> "directory" => false,
> "file-size" => 1955L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
> "directory" => false,
> "file-size" => 5582L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
> "directory" => false,
> "file-size" => 143L
> }
> ]
> }
> {code}
> WFCORE-1851 does not fix this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ]
Stefano Maestri commented on JBJCA-1321:
----------------------------------------
It would be better to ask this questions through our forum than jira.
Anyway the steps you described are correct. An alternative would be building latest 1.2 branch which already include this patch.
regards
S.
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: JBJCA-1321
> URL: https://issues.jboss.org/browse/JBJCA-1321
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: lorenzo benvenuti
> Assignee: Lin Gao
> Priority: Critical
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed
by lorenzo benvenuti (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ]
lorenzo benvenuti commented on JBJCA-1321:
------------------------------------------
Hi,
unfortunately this bug has became critical for our customers and we can't wait for a new version of Wildfly. We were thinking to proceed in this way:
- Download sources for tag 1.2.5.Final (the version Wildfly 9.0.2 is using)
- Apply patches from the PRs
- Build a new jar and swap the original with it
Should we perform some additional operation in order to be able to cancel the statement (such as enabling it in some configuration file or something like that)? Judging from the PRs I guess overwriting the jar should be enough but we want to be sure.
Thank you,
lorenzo
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: JBJCA-1321
> URL: https://issues.jboss.org/browse/JBJCA-1321
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: lorenzo benvenuti
> Assignee: Lin Gao
> Priority: Critical
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7031) Redirect Port Fails to Redirect to 3rd Party HTTP Port
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-7031.
-----------------------------
Assignee: Tomaz Cerar (was: Stuart Douglas)
Resolution: Rejected
This is not an issue at all.
It is just misconfiguration and nothing else.
You need to configure secure port binding for http-listener so server knows to what https port to redirect if needed to. See "redirect-socket" config on http-listener
I think easiest for you would be to just upgrade to WildFly 10.1.0.Final which by default comes with https-listener configured and also redirect ports.
> Redirect Port Fails to Redirect to 3rd Party HTTP Port
> ------------------------------------------------------
>
> Key: WFLY-7031
> URL: https://issues.jboss.org/browse/WFLY-7031
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR1
> Reporter: Joe Carder
> Assignee: Tomaz Cerar
> Priority: Minor
>
> When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
> ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> With the redirect socket to a port opened by JBoss, it works as expected. I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months