[JBoss JIRA] (DROOLS-568) Module dependencies missing from brms and bpms layers to support remote runtime engines
by David Ward (JIRA)
David Ward created DROOLS-568:
---------------------------------
Summary: Module dependencies missing from brms and bpms layers to support remote runtime engines
Key: DROOLS-568
URL: https://issues.jboss.org/browse/DROOLS-568
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss EAP 6.3
Reporter: David Ward
Assignee: Mark Proctor
Regarding artifacts:
org.kie:kie-eap-distributions-brms-layer::6.1.0.CR2
org.kie:kie-eap-integration-brms:brms-layer:6.0.2-redhat-7
org.kie:kie-eap-distributions-bpms-layer::6.1.0.CR2
org.kie:kie-eap-integration-bpms:bpms-layer:6.0.2-redhat-7
And these modules:
modules/system/layers/brms/org/kie/main/module.xml
modules/system/layers/bpms/org/kie/main/module.xml
There are missing libraries needed to support the remote rest and jms runtime engine factories (and associated builders):
org.kie.services.client.api.RemoteJmsRuntimeEngineFactory/Builder
org.kie.services.client.api.RemoteRestRuntimeEngineFactory/Builder
Including at least these resource-roots:
org.kie.remote:kie-services-client
org.kie.remote:kie-services-jaxb
and this dependency module:
org.jboss.resteasy:resteasy-jackson-provider
(Although still validating other possible dependencies.)
Without having all the necessary libraries included and dependencies linked, using the RemoteRuntimeEngines via kie-services-client is not possible.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-3619:
-------------------------------
Comment: was deleted
(was: You could edit your previous comment to "***" out information that you might not want to share. If you can't edit and want me to delete the comment, let me know that as well.)
> XA END / un-enlist for database connection called to early
> ----------------------------------------------------------
>
> Key: WFLY-3619
> URL: https://issues.jboss.org/browse/WFLY-3619
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, JCA, JPA / Hibernate, Transactions
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64-bit
> JDK 1.8.0_05-b13 64-Bit
> MS SQL Server 2012 database
> Latest MS JDBC driver
> XA datasource
> Reporter: Andreas Liebscher
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: server.jca.log, server_MSSQL_Trace.log
>
>
> While trying to port an EE application from JBoss5 to WF8 the following problem occurred:
> EJBs (@Required) using JPA to do some data changes.
> Some changes get already written to the database, others reside in the session cache.
> After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion.
> Then more changes are flushed to the database, but I run in a reproduceable database locking problem.
> After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call.
> There should be exactly one xa transaction active processing all data changes.
> But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction.
> After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour:
> - a connection is enlisted and xa start called
> - the same connection is used for several select / insert / update statements
> - after return of the top EJB call on the same connection xa end and connection un-enlist is called
> - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected.
> Shouldn't xa end be called AFTER beforeCompletion / session flush!?!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-2870) Distinct HTTP and HTTPS listen addresses for management HTTP interface are not configurable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2870?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2870:
-----------------------------------
Fix Version/s: 8.1.0.CR1
(was: 9.0.0.Beta1)
> Distinct HTTP and HTTPS listen addresses for management HTTP interface are not configurable
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-2870
> URL: https://issues.jboss.org/browse/WFLY-2870
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.1.0.CR1
>
>
> Add a single attribute to the existing http management interface resource, named "secure-interface". The current attributes are "interface", "http-port", "https-port", with the "interface" value being used for both ports. The new "secure-interface" attribute would specify the interface to use for the "https-port" socket. It, unlike "interface", will accept a null value, in which case the value for "interface" will be used for the "https-port" socket. This would be the standard config and preserves backward compatibility.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3689) Ability to specify a resource adapter reference in jboss-ejb3.xml without the ear name
by Tomasz Adamski (JIRA)
Tomasz Adamski created WFLY-3689:
------------------------------------
Summary: Ability to specify a resource adapter reference in jboss-ejb3.xml without the ear name
Key: WFLY-3689
URL: https://issues.jboss.org/browse/WFLY-3689
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: EJB, JCA
Reporter: Tomasz Adamski
Assignee: Tomasz Adamski
Priority: Minor
Resource adapters can be packaged inside an EAR file. With the current set up it is necessary to specify the EAR name when referencing it jboss-ejb3.xml file.
Extension is needed that would allow to avoid adding the EAR name all together for the resource adapter.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3662) CLI control flow statements not working for commands
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3662?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky commented on WFLY-3662:
-----------------------------------------
The idea of if-else-end-if and try-catch-finally was that each block of statements was supposed to be transformed into a batch and executed as an atomic operation request depending on the condition. This contract works properly.
Here, you mix commands that can't be a part of a batch (e.g. echo and module) with the operations. The CLI, in the current impl, still goes through the lines in all the blocks and composes batches for all of them. When the CLI is in a batch mode and meets a command which can't be a part of the batch, it executes the command right away. (That's a deliberate decision and is useful for commands like cd, etc.)
So, the CLI composes batches for all the blocks it parses, it doesn't execute any of them until the whole if-else-end-if structure is parsed. Then it evaluates the condition and chooses which batch to execute.
According to the original purpose, this is not a bug. I'd classify it as an enhancement. I agree, it's tempting to assume your use-case should work and it's undoubtedly a useful functionality. I'm gonna look into this.
> CLI control flow statements not working for commands
> ----------------------------------------------------
>
> Key: WFLY-3662
> URL: https://issues.jboss.org/browse/WFLY-3662
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Reporter: Stanley Hillner
> Assignee: Alexey Loubyansky
> Priority: Critical
> Labels: cli, command, command-line, script
>
> The CLI control flows, such as if-then-else, are not working for CLI commands, such as echo or module. Using commands in control flows results in the strange behavior that these commands are executed in each case without respecting to what the if-statement evaluated.
> I am trying to customize a fresh wildfly server with some modules and settings for our development process. I decided to add modules using a CLI script that gets executed by maven, but when the script declares the following the module command in the 'then' block is executed in each case:
> {noformat}
> if (outcome == failed) of /core-service=module-loading:list-resource-loader-paths(module=oracle.jdbcaq)
> module add --name=oracle.jdbcaq ...
> end-if
> ...
> {noformat}
> I've also verified this behavior with another structure that just checks a property and echos something and both echos were executed:
> {noformat}
> /system-property=x:add(value=123)
> if (result == 123) of /system-property=x:read-attribute(name=value)
> echo "If block"
> /system-property=x:read-attribute(name=value)
> else
> echo "Else block"
> /system-property=x:read-attribute(name=value)
> end-if
> {noformat}
> The next thing is that if you just put echos into the if and else blocks, the CLI processor complains about an empty if-block. Try this one:
> {noformat}
> /system-property=x:add(value=123)
> if (result == 123) of /system-property=x:read-attribute(name=value)
> echo "If block"
> else
> echo "Else block"
> end-if
> {noformat}
> This behavior has also been observed by other users (see the forum reference) and for me it is critical to our setup since the only alternative would be copying modules manually to the modules folder. Furthermore, there might be other commands required for us to adapt the standalone configuration that need to be nested in an if-statement.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-746) Add jboss-dmr documentation to the Admin Guide
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-746?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-746.
-----------------------------------
Assignee: Brian Stansberry
Resolution: Done
I did 95%+ of this ages ago; see https://docs.jboss.org/author/display/WFLY9/Detyped+management+and+the+jb... (or equivalent page for earlier releases.)
There are a couple TODOs re: outlining the text representation grammar at the bottom of that page, but I'm not going to keep this issue open just for that.
> Add jboss-dmr documentation to the Admin Guide
> ----------------------------------------------
>
> Key: WFLY-746
> URL: https://issues.jboss.org/browse/WFLY-746
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: No Release
>
>
> Basic documentation on DMR:
> 1) Purpose
> 2) Source location and maven coordinates
> 3) Description of the 2 public classes, ModelNode and ModelType, link to 1.0.0.Final code for each on github
> 4) Some simple examples
> 5) Fully document the string format, so people know how to read DMR output and how to write DMR input
> 6) Links to 5) above in the CLI docs, both in a place that describes how to read output and in a place that describes the format for parameter values in low-level operation requests
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3688) datasources subsystem: xa-datasource properties doe not support the use of multiple values for one property
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3688?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved WFCORE-32 to WFLY-3688:
-----------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-3688 (was: WFCORE-32)
Affects Version/s: 8.1.0.Final
(was: 1.0.0.CR1)
Component/s: JCA
(was: Domain Management)
> datasources subsystem: xa-datasource properties doe not support the use of multiple values for one property
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3688
> URL: https://issues.jboss.org/browse/WFLY-3688
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.1.0.Final
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> The oracle JDBC driver had a method:
> setConnectionProperties(java.util.Properties value)
> which is needed to set several connection properties for datasources.
> Most (all?) of these connection properties do not have individual setters.
> WildFly does not support setting a "Properties" value for "xa-datasource-property"
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months