[JBoss JIRA] (LOGMGR-67) Improve LogManager formatter capability: System resources, thread ID and minified category
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-67?page=com.atlassian.jira.plugin.... ]
James Perkins updated LOGMGR-67:
--------------------------------
Fix Version/s: 1.5.0.Beta2
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
> Key: LOGMGR-67
> URL: https://issues.jboss.org/browse/LOGMGR-67
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 1.3.2.Final
> Environment: JBoss EAP 6.0.1
> Reporter: Jeremy KUHN
> Assignee: James Perkins
> Labels: jboss
> Fix For: 1.5.0.Beta2, 2.0.0.Beta1
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-88) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------
Jaikiran Pai <jpai(a)redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746]
Hi Rostislav,
I do have the results and one specific test is failing out of a bunch of tests. I see what's going on but I don't yet know why. Progress has been a bit slow because the tests are long running to reproduce, investigate and retry again. So far, I haven't figured out the fix or an area/project to fix this. So I don't really have any real update yet, but am looking into it.
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-88
> URL: https://issues.jboss.org/browse/WFLY-88
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Fix For: 8.0.0.Alpha1
>
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (DROOLS-235) Issues with Drools Eclipse plugin
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-235?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-235.
--------------------------------
Fix Version/s: 6.0.0.CR3
Resolution: Done
Fixed by using the new KIE api when building a project containing a kmodule.xml file
> Issues with Drools Eclipse plugin
> ---------------------------------
>
> Key: DROOLS-235
> URL: https://issues.jboss.org/browse/DROOLS-235
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR2
> Reporter: Kris Verlaenen
> Assignee: Mario Fusco
> Fix For: 6.0.0.CR3
>
> Attachments: Screenshot1.png
>
>
> When generating a sample Drools project with the Eclipse plugin (6.0.x), there are several issues:
> * When DroolsBuilder is trying to parse the Sample.drl, it seems to be failing to import the Message class (resulting in 11 errors in the problems view), see screenshot1. Executing the test does seem to work though
> * When both Sample.drl and Sample.xls are created in the same project, the imports seems to clash, executing the test fails when compiling:
> java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=rules/Sample.drl, line=15, column=0
> text=Rule Compilation error The import com.sample.DroolsTest.Message collides with another import statement], Message [id=2, level=ERROR, path=dtables/Sample.xls, line=15, column=0
> text=Rule Compilation error The import com.sample.DroolsTest.Message collides with another import statement], Message [id=3, level=ERROR, path=dtables/Sample.xls, line=5, column=0
> text=Rule Compilation error The import com.sample.DroolsTest.Message collides with another import statement], Message [id=4, level=ERROR, path=rules/Sample.drl, line=5, column=0
> text=Rule Compilation error The import com.sample.DroolsTest.Message collides with another import statement]]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:170)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:298)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:273)
> at com.sample.DroolsTest.main(DroolsTest.java:17)
> Isn't this allowed?
> * When executing DroolsTest, there seems to be a Sysout somewhere in the code base:
> kmodules: file:/NotBackedUp/jBPM-6.0.0.CR2/jbpm-installer/workspace/drools/target/META-INF/kmodule.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-88) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746]
Jaikiran, do you have results ?
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-88
> URL: https://issues.jboss.org/browse/WFLY-88
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Fix For: 8.0.0.Alpha1
>
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does not work on MacOS
by Romain PELISSE (JIRA)
[ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.... ]
Romain PELISSE reassigned WFLY-1928:
------------------------------------
Assignee: Thomas Diesler (was: Romain PELISSE)
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
> Key: WFLY-1928
> URL: https://issues.jboss.org/browse/WFLY-1928
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Alpha4
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 8.0.0.Beta1
>
>
> {code}
> FuseFabric:karaf@root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-203) add modules for Hibernate versions (3.x, 4.1.x/4.2.x), OpenJPA, EclipseLink which contain the JipiJapa integration jars
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-203?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on WFLY-203:
-----------------------------------
If you can't contribute a patch to EclipseLink, at least vote for the https://bugs.eclipse.org/bugs/show_bug.cgi?id=414974 issue to be fixed.
> add modules for Hibernate versions (3.x, 4.1.x/4.2.x), OpenJPA, EclipseLink which contain the JipiJapa integration jars
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-203
> URL: https://issues.jboss.org/browse/WFLY-203
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Craig Ringer
> Assignee: Scott Marlow
> Priority: Minor
> Labels: eclipselink, jpa
> Fix For: 8.0.0.Alpha2
>
>
> For EclipseLink to properly identify the container and set up correct transaction integration, etc, it needs the property "eclipselink.target-server" to be set to "JBoss".
> There's an open issue asking EclipseLink to auto detect the container (https://bugs.eclipse.org/bugs/show_bug.cgi?id=383257) but right now, a simple solution to making EclipseLink work well on AS7 is for AS7 to pass that property to EclipseLink.
> That'll help prevent issues and confusion like this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=365704
> Users can set it as a system property right now as shown on bug 383257, but really it'd be best if JBoss passed it to the persistence unit during creation.
> Time permitting I'll give this a go.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months