[JBoss JIRA] (DROOLS-562) Can't install migration tool
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-562?page=com.atlassian.jira.plugin... ]
Petr Široký edited comment on DROOLS-562 at 7/24/14 9:50 AM:
-------------------------------------------------------------
Just tried this one: http://repository.jboss.org/nexus/content/repositories/public-jboss/org/d... and it seems to be working well.
was (Author: psiroky-redhat.com):
Just tried this one: http://repository.jboss.org/nexus/content/repositories/public-jboss/org/d... and it seems to working well.
> Can't install migration tool
> ----------------------------
>
> Key: DROOLS-562
> URL: https://issues.jboss.org/browse/DROOLS-562
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 Enterprise
> Reporter: Skip Skip
> Assignee: Mark Proctor
> Priority: Blocker
>
> We are migrating some DROOLs from DROOLs 5.0 to the latest version, and moving our applications to JBoss AS 7.
> Looking into how to migrate these DROOLs, I found it recommended to use the migration tool that is located here drools-wb/drools-wb-jcr2vfs-migration at master · droolsjbpm/drools-wb · GitHub which is a sub-project of https://github.com/droolsjbpm/drools-wb
>
> When I try to build drools-wb with maven (mvn install), I keep dying here: Failure to find org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT
> When I try to just make the migration tool, I get this error:
> Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.8 or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.sf.docbook:docbook-xsl-ns:jar:1.74.0, net.socialchange.doctype:doctype-changer:jar:1.1: Could not find artifact net.sf.docbook:docbook-xsl-ns:jar:1.74.0 in gtrepositories
> Is the package 6.2.0-SNAPSHOT available anywhere publicly? If I don't have access to that code, is there a way for me to just get the migration utility?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-562) Can't install migration tool
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-562?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-562:
------------------------------------
Just tried this one: http://repository.jboss.org/nexus/content/repositories/public-jboss/org/d... and it seems to working well.
> Can't install migration tool
> ----------------------------
>
> Key: DROOLS-562
> URL: https://issues.jboss.org/browse/DROOLS-562
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 Enterprise
> Reporter: Skip Skip
> Assignee: Mark Proctor
> Priority: Blocker
>
> We are migrating some DROOLs from DROOLs 5.0 to the latest version, and moving our applications to JBoss AS 7.
> Looking into how to migrate these DROOLs, I found it recommended to use the migration tool that is located here drools-wb/drools-wb-jcr2vfs-migration at master · droolsjbpm/drools-wb · GitHub which is a sub-project of https://github.com/droolsjbpm/drools-wb
>
> When I try to build drools-wb with maven (mvn install), I keep dying here: Failure to find org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT
> When I try to just make the migration tool, I get this error:
> Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.8 or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.sf.docbook:docbook-xsl-ns:jar:1.74.0, net.socialchange.doctype:doctype-changer:jar:1.1: Could not find artifact net.sf.docbook:docbook-xsl-ns:jar:1.74.0 in gtrepositories
> Is the package 6.2.0-SNAPSHOT available anywhere publicly? If I don't have access to that code, is there a way for me to just get the migration utility?
--
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 Andreas Liebscher (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Andreas Liebscher updated WFLY-3619:
------------------------------------
Attachment: server.jca.log
> 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] (DROOLS-562) Can't install migration tool
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-562?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-562:
------------------------------------
You can find the latest snapshots here: http://repository.jboss.org/nexus/content/repositories/public-jboss/org/d...
However, I am not sure what is the current state of the migration tool. It might be worth trying the 6.0.3-SNAPSHOT which _should_ work.
> Can't install migration tool
> ----------------------------
>
> Key: DROOLS-562
> URL: https://issues.jboss.org/browse/DROOLS-562
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 Enterprise
> Reporter: Skip Skip
> Assignee: Mark Proctor
> Priority: Blocker
>
> We are migrating some DROOLs from DROOLs 5.0 to the latest version, and moving our applications to JBoss AS 7.
> Looking into how to migrate these DROOLs, I found it recommended to use the migration tool that is located here drools-wb/drools-wb-jcr2vfs-migration at master · droolsjbpm/drools-wb · GitHub which is a sub-project of https://github.com/droolsjbpm/drools-wb
>
> When I try to build drools-wb with maven (mvn install), I keep dying here: Failure to find org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT
> When I try to just make the migration tool, I get this error:
> Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.8 or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.sf.docbook:docbook-xsl-ns:jar:1.74.0, net.socialchange.doctype:doctype-changer:jar:1.1: Could not find artifact net.sf.docbook:docbook-xsl-ns:jar:1.74.0 in gtrepositories
> Is the package 6.2.0-SNAPSHOT available anywhere publicly? If I don't have access to that code, is there a way for me to just get the migration utility?
--
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 Andreas Liebscher (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Andreas Liebscher updated WFLY-3619:
------------------------------------
Attachment: server_MSSQL_Trace.log
Trace from MSSQL JDBC Driver
> 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_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-3619) XA END / un-enlist for database connection called to early
by Andreas Liebscher (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Andreas Liebscher edited comment on WFLY-3619 at 7/24/14 9:30 AM:
------------------------------------------------------------------
I already increased the log level for analyzing, I found an older log file and attach it...
Additionally I have a log file with logging from MS SQL JDBC driver, that makes all XA calls visible.
was (Author: aliebscher):
I already increased the log level for analyzing, I found an older log file and attach it...
> 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
>
> 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] (DROOLS-562) Can't install migration tool
by Skip Skip (JIRA)
Skip Skip created DROOLS-562:
--------------------------------
Summary: Can't install migration tool
Key: DROOLS-562
URL: https://issues.jboss.org/browse/DROOLS-562
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Windows 7 Enterprise
Reporter: Skip Skip
Assignee: Mark Proctor
Priority: Blocker
We are migrating some DROOLs from DROOLs 5.0 to the latest version, and moving our applications to JBoss AS 7.
Looking into how to migrate these DROOLs, I found it recommended to use the migration tool that is located here drools-wb/drools-wb-jcr2vfs-migration at master · droolsjbpm/drools-wb · GitHub which is a sub-project of https://github.com/droolsjbpm/drools-wb
When I try to build drools-wb with maven (mvn install), I keep dying here: Failure to find org.kie:kie-parent-with-dependencies:pom:6.2.0-SNAPSHOT
When I try to just make the migration tool, I get this error:
Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.8 or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.sf.docbook:docbook-xsl-ns:jar:1.74.0, net.socialchange.doctype:doctype-changer:jar:1.1: Could not find artifact net.sf.docbook:docbook-xsl-ns:jar:1.74.0 in gtrepositories
Is the package 6.2.0-SNAPSHOT available anywhere publicly? If I don't have access to that code, is there a way for me to just get the migration utility?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-320) Allow jconsole to be launched as a modular application
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-320?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse edited comment on WFLY-320 at 7/24/14 8:38 AM:
----------------------------------------------------------------
Just marking this as out of date as now the client jar is referenced making a switch to module based class loading redundant.
A switch to modular class loading would actually be bad now as the current situation makes it easier to move the jconsole script to another machine without needing to duplicate modules.
was (Author: dlofthouse):
Just marking this as out of date as now the client jar is referenced making a switch to module based class loading redundant.
A switch to modular class loading would actually be mad now as the current situation makes it easier to move the jconsole script to another machine without needing to duplicate modules.
> Allow jconsole to be launched as a modular application
> ------------------------------------------------------
>
> Key: WFLY-320
> URL: https://issues.jboss.org/browse/WFLY-320
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMX, Scripts
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> Make the jconsole scripts launch jconsole as as a modular application. Get rid of the classpath building that resulted in AS7-6498.
> Some (mildly edited) discussion:
> bstansberry: BTW, I filed a JIRA to make the vault tool a proper modular app in AS next. I'm not sure if that's doable for jconsole
> [10:37am] darranl: bstansberry: Yes vault should be modular - I don't believe jconsole is as easily possible unless we add a module for the jconsole classes
> [10:38am] darranl: bstansberry: the problem with jconsole was that we actually needed to call jconsole which I think was a binary so we were just created an extended classpath for that binary to use
> [10:38am] bstansberry: darranl: ok, will do. I didn't file a JIRA for modular jconsole because I figured there would be problems
> [10:39am] darranl: bstansberry: having said that it may be possible now to just switch to use the client jar - that did not exist at the time the jconsole script was first written
> [10:40am] darranl: but at this point may be safer to just update the root of the modules folder and switch to client later
> [10:40am] bstansberry: darranl: this will become more of an issue once we have patching
> [10:40am] bstansberry: since this script won't pick up any patches we may have issued for the listed modules
> [10:40am] bstansberry: and no way are we going to add that to the script
> [10:43am] dmlloyd: I've booted jconsole from within modules before
> [10:43am] dmlloyd: it's possible
> [10:43am] darranl: If it is possbile then maybe we can just make it modular
> [10:44am] dmlloyd: java -jar ~/.m2/repository/org/jboss/modules/jboss-modules/1.1.4.GA/jboss-modules-1.1.4.GA.jar -jar ~/local/jdk/home/lib/jconsole.jar
> [10:44am] dmlloyd: easy as bananas
> [10:45am] dmlloyd: if you use -cp you can also add dependencies via -dep
> [10:45am] dmlloyd: or we could create a jconsole module from openjdk even
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-320) Allow jconsole to be launched as a modular application
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-320?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse resolved WFLY-320.
-----------------------------------
Assignee: Darran Lofthouse
Fix Version/s: 9.0.0.Beta1
(was: Awaiting Volunteers)
Resolution: Out of Date
Just marking this as out of date as now the client jar is referenced making a switch to module based class loading redundant.
A switch to modular class loading would actually be mad now as the current situation makes it easier to move the jconsole script to another machine without needing to duplicate modules.
> Allow jconsole to be launched as a modular application
> ------------------------------------------------------
>
> Key: WFLY-320
> URL: https://issues.jboss.org/browse/WFLY-320
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMX, Scripts
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> Make the jconsole scripts launch jconsole as as a modular application. Get rid of the classpath building that resulted in AS7-6498.
> Some (mildly edited) discussion:
> bstansberry: BTW, I filed a JIRA to make the vault tool a proper modular app in AS next. I'm not sure if that's doable for jconsole
> [10:37am] darranl: bstansberry: Yes vault should be modular - I don't believe jconsole is as easily possible unless we add a module for the jconsole classes
> [10:38am] darranl: bstansberry: the problem with jconsole was that we actually needed to call jconsole which I think was a binary so we were just created an extended classpath for that binary to use
> [10:38am] bstansberry: darranl: ok, will do. I didn't file a JIRA for modular jconsole because I figured there would be problems
> [10:39am] darranl: bstansberry: having said that it may be possible now to just switch to use the client jar - that did not exist at the time the jconsole script was first written
> [10:40am] darranl: but at this point may be safer to just update the root of the modules folder and switch to client later
> [10:40am] bstansberry: darranl: this will become more of an issue once we have patching
> [10:40am] bstansberry: since this script won't pick up any patches we may have issued for the listed modules
> [10:40am] bstansberry: and no way are we going to add that to the script
> [10:43am] dmlloyd: I've booted jconsole from within modules before
> [10:43am] dmlloyd: it's possible
> [10:43am] darranl: If it is possbile then maybe we can just make it modular
> [10:44am] dmlloyd: java -jar ~/.m2/repository/org/jboss/modules/jboss-modules/1.1.4.GA/jboss-modules-1.1.4.GA.jar -jar ~/local/jdk/home/lib/jconsole.jar
> [10:44am] dmlloyd: easy as bananas
> [10:45am] dmlloyd: if you use -cp you can also add dependencies via -dep
> [10:45am] dmlloyd: or we could create a jconsole module from openjdk even
--
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 Stanley Hillner (JIRA)
Stanley Hillner created WFLY-3662:
-------------------------------------
Summary: 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
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