December 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Moved: (JBJCA-12) Programmatic Connection Definition Deployment

by Jesper Pedersen (JIRA)

[ https://jira.jboss.org/jira/browse/JBJCA-12?page=com.atlassian.jira.plugi... ] Jesper Pedersen moved JBAS-1425 to JBJCA-12: -------------------------------------------- Project: JBoss JCA (was: JBoss Application Server) Key: JBJCA-12 (was: JBAS-1425) Component/s: Core (was: JCA service) Security: (was: Public) > Programmatic Connection Definition Deployment > --------------------------------------------- > > Key: JBJCA-12 > URL: https://jira.jboss.org/jira/browse/JBJCA-12 > Project: JBoss JCA > Issue Type: Task > Components: Core > Reporter: Adrian Brock > Assignee: Jesper Pedersen > Priority: Minor > > Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48673 > Provide a mechanism where ConnectionFactorys/DataSources (Connection Definitions) > can be deployed/undeployed programmatically. > The basic design is as follows: > 1) Provide a mechanism to instantiate MetaData for a connection factory. > This information is the same as the -ds.xml deployment format. > The MetaData can be logically divided into at least the following categories: > * RAR/ConnectionDefinition identification > * ManagedConnectionFactory > * Pool > * Security > * ConnectionManager > * Proxy/JNDI binding > 2) Write an optimized version of the MetaData for the DataSource deployments > which are really a simplified version of the ConnectionFactory deployments with some > hardwiring. > 3) Write a service that deploys the ConnectionFactory (creates MBeans) > from the MetaData and undeploys them based on their id (jndi binding). > 4) Convert the ConnectionFactory deployer to construct the MetaData from the -ds.xml > files and invoke the service new service. -- 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

15 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2198) convert portal quickstart guide to product format

by Prabhat Jha (JIRA)

convert portal quickstart guide to product format ------------------------------------------------- Key: JBPORTAL-2198 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2198 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Quickstart Guide Reporter: Prabhat Jha Assignee: Samson Kittoli current contents are at: http://anonsvn.jboss.org/repos/portal/docs/branches/JBoss_Portal_Branch_2.... Please put the converted contents at http://anonsvn.jboss.org/repos/portal/docs/enterprise/trunk/ -- 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

15 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-871) ContextObjectInputStream caches classes, potentially causing classloader leaks

by Sei Syvalta (JIRA)

ContextObjectInputStream caches classes, potentially causing classloader leaks ------------------------------------------------------------------------------ Key: JGRP-871 URL: https://jira.jboss.org/jira/browse/JGRP-871 Project: JGroups Issue Type: Bug Affects Versions: 2.7 Environment: all Reporter: Sei Syvalta Assignee: Bela Ban If jgroups is installed at application server lib directory, a classloader leak will occur. When web app is undeployed, static classCache in ContextObjectInputStream will still refer those web app classes preventing web app to undeploy properly. I think proper fix would be to remove this caching completely. Additionally, it might be worth to check the current version form jboss: http://fisheye.jboss.org/browse/JBossCommon/common-core/trunk/src/main/ja.... It has some fixes for java 6. -- 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

15 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-5864) Redeploy shows

by Arjen Smedes (JIRA)

Redeploy shows -------------- Key: JBAS-5864 URL: https://jira.jboss.org/jira/browse/JBAS-5864 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers, JSF Affects Versions: JBossAS-4.2.3.GA Environment: Kubuntu, JDK 1.6 Reporter: Arjen Smedes Assignee: Ales Justin Hi, running jdk1.6.0_02, Maven2 (2.0.7) and jboss maven plugin (1.3.1) to deploy JSF-1.2 webapp into JBOSS-4.2.3.GA. Redeploy generates the following stacktrace: 21:56:38,684 INFO [TomcatDeployer] undeploy, ctxPath=/upstream2, warUrl=.../tmp/deploy/tmp33776upstream2-exp.war/ 21:56:38,693 ERROR [[/upstream2]] Exception sending context destroyed event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener java.lang.NullPointerException at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:234) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3895) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4527) at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1163) at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) After that, the application runs normally (as it seems, it's a HelloWorld for JSF, so not much functionality built in as yet). -- 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

15 years, 6 months

3
15
0 / 0

[JBoss JIRA] Created: (JGRP-874) PING/TCPGOSSIP: unregister member on leaving the cluster

by Bela Ban (JIRA)

PING/TCPGOSSIP: unregister member on leaving the cluster -------------------------------------------------------- Key: JGRP-874 URL: https://jira.jboss.org/jira/browse/JGRP-874 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.6.8, 2.7 Unregistration on graceful leave reduces the risk of GossipRouter returning the wrong member list, and e.g. asking the wrong coord to JOIN -- 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

15 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1615) Externalize attachment names as a contract away from the deployers themselves

by Andrew Lee Rubinger (JIRA)

Externalize attachment names as a contract away from the deployers themselves ----------------------------------------------------------------------------- Key: EJBTHREE-1615 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1615 Project: EJB 3.0 Issue Type: Task Components: common, deployers Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 1.0.0-CR1 Deployers should adhere to a contract specifying their dependencies (input and output), such that other deployers may be decoupled. Ie. Deployer A wants to depend on Deployer B's output, but not depend on the deployer itself. -- 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

15 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1614) Extract out logic to decorate metadata w/ JNDI Binding Policy from EjbMetadataJndiPolicyDecoratorDeployer

by Andrew Lee Rubinger (JIRA)

Extract out logic to decorate metadata w/ JNDI Binding Policy from EjbMetadataJndiPolicyDecoratorDeployer --------------------------------------------------------------------------------------------------------- Key: EJBTHREE-1614 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1614 Project: EJB 3.0 Issue Type: Task Components: common, deployers Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 1.0.0-CR1 This logic is useful outside of the deployer itself, ie in a test. -- 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

15 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-865) TCP: bind_port is ignored

by Bela Ban (JIRA)

TCP: bind_port is ignored ------------------------- Key: JGRP-865 URL: https://jira.jboss.org/jira/browse/JGRP-865 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Vladimir Blagojevic Priority: Minor Fix For: 2.6.8, 2.7 In the 2.6 branch, when we only set TCP.bind_port (e.g. to 7900), it is ignored. We need to set start_port. Make sure bind_port is actually used, verify this is the case in 2.7 as well -- 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

15 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-6290) EJB call fails from ServletContextListener

by Aul Kapoor (JIRA)

EJB call fails from ServletContextListener ------------------------------------------ Key: JBAS-6290 URL: https://jira.jboss.org/jira/browse/JBAS-6290 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-5.0.0.CR2 Reporter: Aul Kapoor Assignee: Carlo de Wolf Priority: Critical Fix For: JBossAS-4.2.4.GA Our application EAR has Web and App Module. The App Module has a stateless bean which needs to be called from the ServletContextListener of the WebModule. The jndi lookups return the EJBObject of the corresponding bean but when the method is invoked exception is raised as follows. Caused by: java.lang.NullPointerException at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:420) at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:97) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy192.invoke(Unknown Source) at org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:125) After the EAR is deployed the EJB call can be successfully made through any servlet but fails if made from ServletContextListener -- 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

15 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-6289) org.jboss.ejb.plugins.SecurityInterceptor causes login without corresponding logout

by Marco Schulze (JIRA)

org.jboss.ejb.plugins.SecurityInterceptor causes login without corresponding logout ----------------------------------------------------------------------------------- Key: JBAS-6289 URL: https://jira.jboss.org/jira/browse/JBAS-6289 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.2.GA Reporter: Marco Schulze When changing the identity within a server method (e.g. in a session bean or message-driven bean), the org.jboss.ejb.plugins.SecurityInterceptor causes a login without a corresponding logout ever happening. The result is a memory leak. In order to trace this problem down, I put some code into my login-module that dumps stack traces of commit() methods having been called without corresponding logout() calls. Here's one example stack trace: java.lang.Exception: StackTrace at org.nightlabs.jfire.jboss.authentication.JFireServerLoginModule.commit(JFireServerLoginModule.java:280) at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:580) at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:603) at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:537) at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344) at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:211) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:135) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107) at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:637) at org.jboss.ejb.Container.invoke(Container.java:981) at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359) at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133) at $Proxy97.create(Unknown Source) at org.nightlabs.jfire.asyncinvoke.AsyncInvokerBaseBean.onMessage(AsyncInvokerBaseBean.java:203) 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:597) at org.jboss.invocation.Invocation.performCall(Invocation.java:359) at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:495) at org.nightlabs.jfire.jboss.transaction.ForceRollbackOnExceptionInterceptor.invoke(ForceRollbackOnExceptionInterceptor.java:54) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158) at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:116) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:109) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:402) at org.jboss.ejb.Container.invoke(Container.java:960) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:987) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1287) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:891) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170) at org.jboss.mq.SpySession.run(SpySession.java:323) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:761) at java.lang.Thread.run(Thread.java:619) The org.nightlabs.jfire.asyncinvoke.AsyncInvokerBaseBean.onMessage(...) does the following: 1) Create a LoginContext and perform login(). 2) Obtain an EJB's LocalHome. 3) Obtain the EJB proxy from the LocalHome. 4) Call the EJB method. 5) logout() - corresponding to step 1. Here's the source: loginContext = new LoginContext( LoginData.DEFAULT_SECURITY_PROTOCOL, createAuthCallbackHandler(ism, envelope)); loginContext.login(); try { AsyncInvokerDelegateLocal invokerDelegate = null; try { invokerDelegate = AsyncInvokerDelegateUtil.getLocalHome().create(); } catch (Exception x) { logger().fatal("Obtaining stateless session bean AsyncInvokerDelegateLocal failed!", x); messageContext.setRollbackOnly(); } if (invokerDelegate != null) doInvoke(envelope, invokerDelegate); } finally { loginContext.logout(); } In a similar scenario (not the stack trace above), I worked around this problem by manually pushing a RunAsIdentity into the SecurityAssociation. When a RunAsIdentity is present, the SecurityInterceptor does not perform a login. -- 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

15 years, 6 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2008