[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance
by Nicholas Williams (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ]
Nicholas Williams commented on JBLOGGING-95:
--------------------------------------------
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. :-)
Is there anything I can do to help move things along?
> Add Logger/LoggerProvider to support new Log4j 2 to improve performance
> -----------------------------------------------------------------------
>
> Key: JBLOGGING-95
> URL: https://issues.jboss.org/browse/JBLOGGING-95
> Project: JBoss Logging
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: jboss-logging-spi
> Affects Versions: 3.2.0.Beta1
> Reporter: Nicholas Williams
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 3.2.0.Beta1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API.
> Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2.
--
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
11 years, 11 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1789:
---------------------------
Fix Version/s: 3.5
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> - a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
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
11 years, 11 months
[JBoss JIRA] (JGRP-1786) 3.5
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1786:
---------------------------
Summary: 3.5 (was: TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler)
Fix Version/s: 3.5
Hi Richard,
good analysis, I'm trying to resolve this in 3.5 and backport if needed. Note though that DefaultScheduler (despite its name) is not used anymore...
> 3.5
> ---
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
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
11 years, 11 months
[JBoss JIRA] (AS7-5088) Weblogic EJB Lookup fails from JBoss AS
by living lazer (JIRA)
[ https://issues.jboss.org/browse/AS7-5088?page=com.atlassian.jira.plugin.s... ]
living lazer commented on AS7-5088:
-----------------------------------
Was this moved to a forum? I am facing the same issue, no idea and already spent 24hours...
> Weblogic EJB Lookup fails from JBoss AS
> ----------------------------------------
>
> Key: AS7-5088
> URL: https://issues.jboss.org/browse/AS7-5088
> Project: Application Server 7
> Issue Type: Bug
> Environment: JBoss AS 7.1.0.Final
> EJB Deployed in Weblogic 10
> OS - Windows XP
> JDK - jdk160_05 (Used by jboss)
> Reporter: Badal Pradhan
>
> I am trying to access EJB deployed in Weblogic 10 by its RemoteInterface from JBoss.
> My initial context config for lookup is as below:
> Hashtable<String,String> wlContextEnv = new Hashtable<String,String>();
> wlContextEnv.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
> wlContextEnv.put(Context.PROVIDER_URL, "t3://localhost:7001");
> wlInitialContext = new InitialContext(wlContextEnv);
> During access the bean it throws the below exception:
> java.lang.LinkageError: Failed to link weblogic/corba/client/cluster/ORBSocketFactory
> .....
> Caused by: java.lang.ClassNotFoundException: com.sun.corba.se.spi.legacy.connection.ORBSocketFactory
> Since the above class belongs to jdk rt.jar then what is the issue here? Am I missed any config for it.
> Note: I have wlclient.jar in my ear/lib.
--
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
11 years, 11 months
[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException
by David Tombs (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
David Tombs commented on DROOLS-319:
------------------------------------
Hi Michael, I don't remember exactly how I did it but somewhere on the stacktrace from the exception I saw which constraint it was evaluating. Hope that helps.
> "Unknown boolean operator" RuntimeException
> -------------------------------------------
>
> Key: DROOLS-319
> URL: https://issues.jboss.org/browse/DROOLS-319
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Windows 8, java version "1.7.0_40"
> Reporter: David Tombs
> Assignee: Mark Proctor
>
> Steps to reproduce:
> # Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
> # Execute the rule against a few objects.
> Actual Result:
> An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
> {noformat}
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}
> Expected Result:
> Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
--
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
11 years, 11 months
[JBoss JIRA] (WFLY-1168) MDB is looking up UserTransaction even if it isn't Bean Managed
by Gus Gu (JIRA)
[ https://issues.jboss.org/browse/WFLY-1168?page=com.atlassian.jira.plugin.... ]
Gus Gu commented on WFLY-1168:
------------------------------
Will this fix be deployed in WildFly 8 final? I got the exception when I run seam 2.3 app and WildFly 8 CR1. Thanks!!
> MDB is looking up UserTransaction even if it isn't Bean Managed
> ---------------------------------------------------------------
>
> Key: WFLY-1168
> URL: https://issues.jboss.org/browse/WFLY-1168
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Eduardo Martins
>
> Investigating on a use case I've seen that MDB comes to org.jboss.jca.adapters.jdbc.WrapperDataSource looking up for UT. It fails with this exception
> javax.naming.NamingException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction [Root exception is java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction]
> the problem is exposed running
> org.jboss.as.test.integration.ejb.mdb.MDBTestCase
--
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
11 years, 11 months