January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3965) JaasSecurityDomainMBean is missing JaasSecurityDomain attributes

by Scott M Stark (JIRA)

JaasSecurityDomainMBean is missing JaasSecurityDomain attributes ---------------------------------------------------------------- Key: JBAS-3965 URL: http://jira.jboss.com/jira/browse/JBAS-3965 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.5.GA Reporter: Scott M Stark Assigned To: Scott M Stark Attachments: JaasSecurityDomain-xmbean.xml The CipherAlgorithm attribute is missing from the JaasSecurityDomainMBean interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3198?page=comments#action_12349546 ] Tom Elrod commented on JBAS-3198: ---------------------------------- Fix for /server/src/main/org/jboss/invocation/pooled/interfaces/OptimizedObjectInputStream.java as well as additions to testsuite (see JBAS-3863) have been added to following code branches: https://svn.jboss.org/repos/jbossas/branches/Branch_4_0 https://svn.jboss.org/repos/jbossas/branches/Branch_4_2 https://svn.jboss.org/repos/jbossas/trunk > Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA). > ----------------------------------------------------------------------------------- > > Key: JBAS-3198 > URL: http://jira.jboss.com/jira/browse/JBAS-3198 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ClassLoading > Affects Versions: JBossAS-4.0.5.CR1 > Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5 > Reporter: Eric Hambuch > Assigned To: Tom Elrod > Priority: Critical > Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1 > > Attachments: example.zip > > > When using the pooled invoker (PooledInvokerHA) in the "all" configuration with separated classloaders for each EAR (as described in Wiki:ClassLoadingConfiguration) an invocation to a bean causes confusion to the separated classloaders. > More detailed: > I switched from jrmpha-invoker (which creates a new thread for each request which is really bad) to pooledha invoker in a clustered environment. I have to Stateless Session Beans that share the same bean interface. Each Session Bean is deployed in a separate EAR. In "ear-deployer.xml" I switched "isolated" to "true" to separate the classloaders of the EARs. > When I call the first bean everything works fine. But when I try to call the second bean (same interface, but different bean!) JBoss throws the following exception: > java.rmi.ServerException: RuntimeException; nested exception is: > java.lang.IllegalArgumentException: argument type mismatch > at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:386) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196) > at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:264) > at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) > at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) > at org.jboss.ejb.Container.invoke(Container.java:873) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.invocation.pooled.server.PooledInvokerHA.invoke(PooledInvokerHA.java:146) > at org.jboss.invocation.pooled.server.ServerThread.processInvocation(ServerThread.java:213) > at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:268) > at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:139) > Caused by: java.lang.IllegalArgumentException: argument type mismatch > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.invocation.Invocation.performCall(Invocation.java:345) > at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) > at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149) > at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) > at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106) > at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:158) > at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62) > at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154) > at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) > The IllegalArgumentException comes from the fact that the Method.invoke() is called with a class of the wrong classloader (class from other EAR). > With jrmpha-invoker everything works fine. Maybe the thread pool causes a mixture of the classloaders? > I created a minimized example that can be provided if required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3863) Need to properly test the PooledInvoker for scoped invocations

by Adrian Brock (JIRA)

Need to properly test the PooledInvoker for scoped invocations -------------------------------------------------------------- Key: JBAS-3863 URL: http://jira.jboss.com/jira/browse/JBAS-3863 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Remoting Affects Versions: JBossAS-4.0.5.CR1 Reporter: Adrian Brock Since the above task shows that even the most basic marshalling of the return type is not present in the PooledInvoker code, there are clearly no serious tests of the PooledInvoker in scoped environments. These tests need to be written and any broken behaviour fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-314) JMS Bank sending reply exception

by Daniel Brum (JIRA)

JMS Bank sending reply exception -------------------------------- Key: JBESB-314 URL: http://jira.jboss.com/jira/browse/JBESB-314 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 RC1 Reporter: Daniel Brum Assigned To: Daniel Brum Fix For: 4.0 >From the JMSBank code (NON-esb): [java] 15:12:54,260 INFO [Bank] Bank 'JMSBasedBank' received a request for SSN=1234567890 for $1000 over 12 months. [java] 15:12:54,263 INFO [Bank] Bank 'JMSBasedBank offers SSN=1234567890 BankQuoteReply=[interestRate=8.60, quoteId=JMSBasedBank-0, errorCode=0, customerUID=1234567890] [java] 15:12:54,291 INFO [ManagerJMS] Looking up connection factory [java] 15:12:54,311 INFO [ManagerJMS] Creating connection [java] 15:12:54,316 INFO [ManagerJMS] Creating session [java] 15:12:54,350 ERROR [ManagerJMS] This destination does not exist ! [java] javax.jms.JMSException: This destination does not exist ! [java] at org.jboss.mq.server.JMSDestinationManager.createQueue(JMSDestinationManager.java:582) [java] at org.jboss.mq.server.JMSServerInterceptorSupport.createQueue(JMSServerInterceptorSupport.java:163) [java] at org.jboss.mq.server.TracingInterceptor.createQueue(TracingInterceptor.java:307) [java] at org.jboss.mq.server.JMSServerInvoker.createQueue(JMSServerInvoker.java:164) [java] at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:133) [java] at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396) [java] at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392) [java] at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748) [java] at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-713) Document better the cases in which failedNodeID of ConnectionFactoryEndpoint.createConnectionDelegate(username, password, failedNodeID) is disregarded

by Ovidiu Feodorov (JIRA)

Document better the cases in which failedNodeID of ConnectionFactoryEndpoint.createConnectionDelegate(username, password, failedNodeID) is disregarded ------------------------------------------------------------------------------------------------------------------------------------------------------ Key: JBMESSAGING-713 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-713 Project: JBoss Messaging Issue Type: Sub-task Components: Documentation and Training Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 1.2.0.Beta2 javadoc the method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBCACHE-139) Node notification event that ecludes myself

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-139?page=comments#action_12349534 ] Brian Stansberry commented on JBCACHE-139: ------------------------------------------ If I understand this correctly, the "local" flag that now gets passed with the events does much the same thing too. In the AS I use a ThreadLocal to pass info to a listener so it knows to ignore stuff my own code is generating locally, but with the new flag I can rip that out. > Node notification event that ecludes myself > ------------------------------------------- > > Key: JBCACHE-139 > URL: http://jira.jboss.com/jira/browse/JBCACHE-139 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Bela Ban > Fix For: 2.0.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > It will be nice to have a notification mechanism that can exclude myself (who modifies the node in the first place). This is needed in cache invlidation, for example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-826) allow custom JMX names for EJB3 MBeans

by William DeCoste (JIRA)

allow custom JMX names for EJB3 MBeans -------------------------------------- Key: EJBTHREE-826 URL: http://jira.jboss.com/jira/browse/EJBTHREE-826 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: William DeCoste Assigned To: William DeCoste -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-139) Node notification event that ecludes myself

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-139?page=comments#action_12349529 ] Manik Surtani commented on JBCACHE-139: --------------------------------------- Is this still relevant? Invalidation is in place and works fine without such a notification. Can this be closed? > Node notification event that ecludes myself > ------------------------------------------- > > Key: JBCACHE-139 > URL: http://jira.jboss.com/jira/browse/JBCACHE-139 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Bela Ban > Fix For: 2.0.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > It will be nice to have a notification mechanism that can exclude myself (who modifies the node in the first place). This is needed in cache invlidation, for example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-298) URL parsing in EdtFtpImpl.checkParms()

by Bernard Tison (JIRA)

URL parsing in EdtFtpImpl.checkParms() -------------------------------------- Key: JBESB-298 URL: http://jira.jboss.com/jira/browse/JBESB-298 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Bernard Tison Assigned To: Mark Little I think there might be a problem with the way user/password information is parsed from the FTP URL for a FTP Gateway. This is based on the static router quickstart example. The jbossesb.xml contains the following provider definition: Code: <ftp-provider name="FTPprovider" hostname="localhost" > <ftp-bus busid="StaticRouterFtpGW" > <ftp-message-filter username="ftpuser" password="ftppassword" passive="false" directory="/tmp/esbInput" input-suffix=".dat" /> </ftp-bus> </ftp-provider> This results in the following definition in the jbossesb-gateway.xml: Code: <Ftp-Gateway URL="ftp://ftpuser:ftppassword@localhost:/tmp/esbInput" errorDelete="true" gatewayClass="org.jboss.soa.esb.listeners.gateway.RemoteGatewayListener" ...(non-relevant portion removed) "/> When the gateway is initialized, the org.jboss.internal.soa.esb.util.EdtFtpImpl class will parse the URL and connect to the FTP server. To parse the username/password out of the URL, the checkParms() method of the EdtFtpImpl class uses the following code (lines 190-198): Code: String[] sa = (null == url) ? null : url.getAuthority().split(":"); m_sUser = (null!=sa) ? sa[0] :m_oParms.getAttribute(PARMS_USER); if (null == m_sUser) throw new Exception("No username specified for FTP"); m_sPasswd = (null!=sa) ? sa[1] :m_oParms.getAttribute(PARMS_PASSWD); The url.getAuthority() method returns ftpuser:ftppassword@localhost, which results in m_sUser="ftpuser" and m_sPasswd="ftppassword@localhost". This should be: m_sUser="ftpuser" and m_sPasswd="ftppassword". Suggestion for fix: use url.getUserInfo() to get the user/password out of the FTP URL. This is how it is done in the EdtFtpImpl(FTPEpr p_oP, boolean p_bConnect) constructor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

3
2
0 / 0

[JBoss JIRA] Commented: (JBRULES-218) Add 'forall' Conditional Element

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-218?page=comments#action_12349525 ] Edson Tirelli commented on JBRULES-218: --------------------------------------- $ svn log -r 8677 -v ------------------------------------------------------------------------ r8677 | tirelli | 2007-01-03 18:57:09 -0300 (Wed, 03 Jan 2007) | 1 line Changed paths: M /labs/jbossrules/trunk/drools-core/.project M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/base/BaseClassFieldExtractor.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/Accumulate.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/Collect.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/Column.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/ConditionalElement.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/EvalCondition.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/From.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/GroupElement.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/LogicTransformer.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/Rule.java A /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/rule/RuleConditionElement.java D /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/spi/AvailableVariables.java M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/spi/ColumnExtractor.java A /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/spi/DeclarationScopeResolver.java (from /labs/jbossrules/trunk/dr ools-core/src/main/java/org/drools/spi/AvailableVariables.java:8603) M /labs/jbossrules/trunk/drools-core/src/main/java/org/drools/spi/FunctionResolver.java M /labs/jbossrules/trunk/drools-core/src/test/java/org/drools/rule/LogicTransformerTest.java M /labs/jbossrules/trunk/drools-core/src/test/resources/correct_processTree1.dat M /labs/jbossrules/trunk/drools-core/src/test/resources/correct_transform1.dat JBRULES-218: adding support to variable scope resolution in core ------------------------------------------------------------------------ > Add 'forall' Conditional Element > -------------------------------- > > Key: JBRULES-218 > URL: http://jira.jboss.com/jira/browse/JBRULES-218 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assigned To: Edson Tirelli > Fix For: 3.1-m2 > > > Add 'forall' Conditional Element -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 4 months

1
0
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 January 2007