April 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8977) Remoting remote client proxy and interceptors

by David Lloyd (JIRA)

Remoting remote client proxy and interceptors --------------------------------------------- Key: JBAS-8977 URL: https://issues.jboss.org/browse/JBAS-8977 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.Beta3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-8976) In-VM remote client proxy interceptors

by David Lloyd (JIRA)

In-VM remote client proxy interceptors -------------------------------------- Key: JBAS-8976 URL: https://issues.jboss.org/browse/JBAS-8976 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.Beta3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-8850) Transactional CDI events not work in case of remote EJB call

by Eugene Romanenko (JIRA)

Transactional CDI events not work in case of remote EJB call ------------------------------------------------------------ Key: JBAS-8850 URL: https://issues.jboss.org/browse/JBAS-8850 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Weld/CDI Affects Versions: 6.0.0.Final Reporter: Eugene Romanenko Assignee: Marius Bogoevici When EJB fires CDI event, observer method called only if TransactionPhase set to IN_PROGRESS. When TransactionPhase set to any other value (transactional event), JBoss shows error: {code}20:55:40,700 ERROR [org.jboss.weld.Event] WELD-000401 Failure while notifying an observer of event er.t2.TestEvent@78a17a{code} Looks like there problem with cdi events during remote call. Testcase: {code:title=TestEvent.java|borderStyle=solid} public class TestEvent { private String message; public TestEvent(String message) { this.message = message; } public String getMessage() { return message; } } {code} {code:title=T2Remote.java|borderStyle=solid} @Remote public interface T2Remote { void theTest(); } {code} {code:title=T2Bean.java|borderStyle=solid} @Stateless public class T2Bean implements T2Remote { @Inject private Event<TestEvent> events; @Override public void theTest() { events.fire(new TestEvent("from bean " + System.currentTimeMillis())); } } {code} {code:title=TestListener.java|borderStyle=solid} @Stateless public class TestListener { public void listen( @Observes(during=AFTER_COMPLETION) TestEvent evt ) { System.out.println("Event: " + evt.getMessage()); } } {code} Simple remote client: {code:title=Main.java|borderStyle=solid} public class Main { public static void main(String[] args) throws Exception { Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); properties.put(Context.PROVIDER_URL, "localhost"); Context ctx = new InitialContext( properties ); Object ref = ctx.lookup( "T2Bean/remote" ); T2Remote t = (T2Remote)ref; t.theTest(); System.out.println( "theTest() called!" ); } } {code} In debug log we have following exception: {code} 2011-01-25 09:13:04,359 DEBUG [org.jboss.ejb3.stateless.StatelessContainer] (WorkerThread#0[127.0.0.1:3536]) Received dynamic invocation for method with hash: -4087570856943461660 2011-01-25 09:13:04,359 DEBUG [org.jboss.weld.Event] (WorkerThread#0[127.0.0.1:3536]) WELD-000400 Sending event er.tst.TestEvent@151e0c7 directly to observer [method] public er.tst.TestListener.listen(TestEvent) 2011-01-25 09:13:04,359 ERROR [org.jboss.weld.Event] (WorkerThread#0[127.0.0.1:3536]) WELD-000401 Failure while notifying an observer of event er.tst.TestEvent@151e0c7 2011-01-25 09:13:04,359 DEBUG [org.jboss.weld.Event] (WorkerThread#0[127.0.0.1:3536]) throwing: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [interface org.jboss.weld.context.ejb.EjbRequestContext]; Bindings: [@org.jboss.weld.context.unbound.Unbound()] at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:788) [:6.0.0.Final] at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:80) [:6.0.0.Final] at org.jboss.weld.event.DeferredEventNotification$RunInRequest.run(DeferredEventNotification.java:103) [:6.0.0.Final] at org.jboss.weld.event.DeferredEventNotification.run(DeferredEventNotification.java:64) [:6.0.0.Final] at org.jboss.weld.event.TransactionSynchronizedRunnable.afterCompletion(TransactionSynchronizedRunnable.java:62) [:6.0.0.Final] at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:117) [:6.0.0.Final] at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:371) [:6.0.0.Final] at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:104) [:6.0.0.Final] at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:159) [:6.0.0.Final] at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1158) [:6.0.0.Final] at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:119) [:6.0.0.Final] at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) [:6.0.0.Final] at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:82) [:0.0.1] at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:255) [:0.0.1] at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:349) [:0.0.1] at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209) [:0.0.1] at org.jboss.ejb3.tx2.aop.CMTTxInterceptorWrapper.invoke(CMTTxInterceptorWrapper.java:52) [:0.0.1] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) [:1.0.0.GA] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42) [:1.0.3] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:182) [:1.7.17] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) [:1.7.17] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) [:1.7.17] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.17] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) [:1.7.17] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA] at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:392) [:1.7.17] at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53) [:1.7.17] at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) [jboss-aop.jar:2.2.1.GA] at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) [:6.0.0.Final] at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791) [:6.0.0.Final] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) [:6.0.0.Final] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548) [:6.0.0.Final] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) [:6.0.0.Final] 2011-01-25 09:13:04,375 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#0[127.0.0.1:3536]) WorkerThread#0[127.0.0.1:3536] closed socketWrapper: ServerSocketWrapper[Socket[addr=/127.0.0.1,port=3536,localport=3873].15fe804] {code} -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
4
0 / 0

[JBoss JIRA] Created: (JBAS-8429) Verify log messages from OSGi bundles feed to aggreaged logfile

by Thomas Diesler (JIRA)

Verify log messages from OSGi bundles feed to aggreaged logfile --------------------------------------------------------------- Key: JBAS-8429 URL: https://jira.jboss.org/browse/JBAS-8429 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: OSGi integration Reporter: Thomas Diesler Assignee: David Bosschaert Fix For: 7.0.0.M1 A bundle may use LogService, SLF4J, JDK, Apache Commons or JBoss Logging. All of these must feed to the common log system -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-8938) Separate $JAVA_OPTS for ProcessController and HostController

by Brian Stansberry (JIRA)

Separate $JAVA_OPTS for ProcessController and HostController ------------------------------------------------------------ Key: JBAS-8938 URL: https://issues.jboss.org/browse/JBAS-8938 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry The way domain.sh and domain.conf work now, whatever value gets assigned to $JAVA_OPTS gets passed to java, so affects the vm used for the ProcessController, and then gets passed through as a param to the PC which uses it for creating the HostController process. We should have a separate variable for the PC, or perhaps use $JAVA_OPTS for neither and have 2 new variables. Settings for the PC are unlikely to be optimum for the HC, and using the same var makes it harder to set of debugging (e.g. both the PC and HC process will try and use the same port for remote socket debugging.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1778) Drools builder raises errors for non-decision tables XLS files

by Edson Tirelli (JIRA)

Drools builder raises errors for non-decision tables XLS files -------------------------------------------------------------- Key: JBRULES-1778 URL: https://jira.jboss.org/jira/browse/JBRULES-1778 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.0.0.M1 Reporter: Edson Tirelli Assignee: Kris Verlaenen Fix For: FUTURE As it is now, the eclipse "drools builder" is raising errors for any XLS file that is not a decision table. For instance, in drools-examples there is the ExampleCheese.xls file used for a drools-template example that acuses the following error: No RuleTable's were found in spreadsheet. ExampleCheese.xls drools-examples/src/main/rules/org/drools/examples Unknown Drools Error -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

4
3
0 / 0

[JBoss JIRA] Created: (LOGTOOL-6) Remove file sorting before processing translation file

by Kevin Pollet (JIRA)

Remove file sorting before processing translation file ------------------------------------------------------ Key: LOGTOOL-6 URL: https://issues.jboss.org/browse/LOGTOOL-6 Project: Log Tool Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta1 Reporter: Kevin Pollet Assignee: David Lloyd Fix For: 1.0.0.Beta2 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JGRP-1271) MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError

by Eric Sirianni (JIRA)

MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError ---------------------------------------------------------------------------------------------- Key: JGRP-1271 URL: https://issues.jboss.org/browse/JGRP-1271 Project: JGroups Issue Type: Bug Affects Versions: 2.11 Environment: All Reporter: Eric Sirianni Assignee: Bela Ban The presence of 'public static final' RequestOptions SYNC and ASYNC implies strongly that RequestOptions are immutable. Otherwise, clients could be changing the meaning of these shared constants. However, MuxMessageDispatcher.cast() mutates the passed-in RequestOptions to set the RspFilter. It chains the existing RspFilter in the RequestOptions to a new one: options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()) The result of this is that the following innocent looking code code will quickly lead to a stack overflow as the RspFilter chain in the RequestOptions.ASYNC object grows without bound: while (true) { muxMessageDispatcher.cast(dests, msg, RequestOptions.ASYNC, false); } The workaround is to create a new RequestOptions object per call to cast() : while (true) { muxMessageDispatcher.cast(dests, msg, new RequestOptions(...), false); } I recommend either: A. Deprecating the public static final RequestOptions ASYNC and SYNC fields and heavily JavaDoc'ing that clients must use a fresh RequestOptions for each send() or cast() invocation. -or- B. JavaDoc'ing the RequestOptions class as *immutable* and fixing MuxMessageDispatcher and other such JGroups blocks that mutate RequestOptions. You may wish to add a "copy constructor" to RequestOptions to facilitate this. The fix for MuxMessageDispatcher is fairly easy - just "clone" the passed-in RequestOptions and set the NoMuxHandlerRspFilter on the new RequestOptions object: < return super.cast(dests, msg, options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()), blockForResults); --- > RequestOptions newOptions = new RequestOptions(options.getMode(), options.getTimeout(), options.getAnycasting(), options, (filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter(), options.getFlags()); > return super.cast(dests, msg, newOptions), blockForResults); -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2284) OutOfMemoryException at DT loading

by Sergey Vanskov (JIRA)

OutOfMemoryException at DT loading ---------------------------------- Key: JBRULES-2284 URL: https://jira.jboss.org/jira/browse/JBRULES-2284 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-decisiontables Affects Versions: 5.0.1.FINAL Environment: Core2Quad Windows XP Pro 64 Reporter: Sergey Vanskov Assignee: Mark Proctor I have created DT having 20.000 rows with 4 conditions and 1 action in CSV format and set the following parameters for JVM -Xmx3072M -XX:MaxPermSize=256M. I haveOutOfMemoryException with the following stack trace java.lang.OutOfMemoryError: Java heap space at java.lang.String.format(String.java:2558) at org.drools.lang.DroolsParserExceptionFactory.formatParserLocation(DroolsParserExceptionFactory.java:203) at org.drools.lang.DroolsParserExceptionFactory.createErrorMessage(DroolsParserExceptionFactory.java:104) at org.drools.lang.DroolsParserExceptionFactory.createDroolsException(DroolsParserExceptionFactory.java:89) at org.drools.lang.DRLParser.reportError(DRLParser.java:350) at org.antlr.runtime.BaseRecognizer.recoverFromMismatchedToken(BaseRecognizer.java:624) at org.antlr.runtime.BaseRecognizer.match(BaseRecognizer.java:115) at org.drools.lang.DRLParser.fact(DRLParser.java:9841) at org.drools.lang.DRLParser.lhs_pattern(DRLParser.java:9388) at org.drools.lang.DRLParser.pattern_source(DRLParser.java:7432) at org.drools.lang.DRLParser.lhs_unary(DRLParser.java:6582) at org.drools.lang.DRLParser.lhs_and(DRLParser.java:6229) at org.drools.lang.DRLParser.lhs_or(DRLParser.java:5877) at org.drools.lang.DRLParser.lhs(DRLParser.java:5673) at org.drools.lang.DRLParser.normal_lhs_block(DRLParser.java:5580) at org.drools.lang.DRLParser.when_part(DRLParser.java:3975) at org.drools.lang.DRLParser.rule(DRLParser.java:3769) at org.drools.lang.DRLParser.statement(DRLParser.java:993) at org.drools.lang.DRLParser.compilation_unit(DRLParser.java:484) at org.drools.compiler.DrlParser.compile(DrlParser.java:238) at org.drools.compiler.DrlParser.parse(DrlParser.java:78) at org.drools.compiler.DrlParser.parse(DrlParser.java:83) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:275) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:510) at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:31) .... Is 3Gb not enough for such a problem?! How may memory requirements be estimated? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-9205) Clicking on a subsytem in web console shows a "Could not reveal xxx" message

by jaikiran pai (JIRA)

Clicking on a subsytem in web console shows a "Could not reveal xxx" message ---------------------------------------------------------------------------- Key: JBAS-9205 URL: https://issues.jboss.org/browse/JBAS-9205 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Console Environment: JBoss AS7 upstream (March 31 2011) Reporter: jaikiran pai Assignee: Heiko Braun Attachments: ejb3-subsystem.png Logging into AS7 web console and clicking on any of the subsystems under the "Subsystem" tree shows a error message like: "Could not reveal: server/ejb3". The server has been started in standalone mode. OS: Ubuntu 10.10 Browser : Firefox 3.6.3 JDK: Sun Java 1.6.0_21 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2011