March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3781) Stateful SB Instance Interceptor should not push SubjectContext if RunAsIdentity present

by Anil Saldhana (JIRA)

Stateful SB Instance Interceptor should not push SubjectContext if RunAsIdentity present ---------------------------------------------------------------------------------------- Key: JBAS-3781 URL: http://jira.jboss.com/jira/browse/JBAS-3781 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1, JBossAS-5.0.0.Beta Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.6.CR1 The following Subject Context push (with null Subject) to establish client security context should not be performed if the user has configured a RunAsIdentity in the caller bean. /* The security context must be established before the cache lookup because the activation of a session should have the caller's security context as ejbActivate is allowed to call other secured resources. Since the pm makes the ejbActivate call, we need to set the caller's security context. The only reason this shows up for stateful session is that we moved the SecurityInterceptor to after the instance interceptor to allow security exceptions to result in invalidation of the session. This may be too literal an interpretation of the ejb spec requirement that runtime exceptions should invalidate the session. */ SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null); The resolution is: if(SecurityActions.peekRunAsIdentity() == null) SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null); -- 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, 3 months

4
4
0 / 0

[JBoss JIRA] Updated: (JBMICROCONT-31) ClassLoading abstraction

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-31?page=all ] Scott M Stark updated JBMICROCONT-31: ------------------------------------- Assignee: Ales Justin Assigning to Ales as this should be done in the context of the osgi bundle work. > ClassLoading abstraction > ------------------------ > > Key: JBMICROCONT-31 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-31 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Ales Justin > Fix For: JBossMC_2_0_0_CR1 > > > Need to come up with a classloading abstraction that isn't going to change in future. > e.g. Look at jboss-aop problem with > 3.2.x UnifiedClassLoader > 4.0.x RepositoryClassLoader > 5.0.x ??? (not even JMX based) > I think the easiest way to do this to define some simple interfaces/factories > for where this needs to be referenced from code. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-104) DeploymentContext shortName for jar is messed up as well as url

by Bill Burke (JIRA)

DeploymentContext shortName for jar is messed up as well as url --------------------------------------------------------------- Key: JBMICROCONT-104 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-104 Project: JBoss MicroContainer Issue Type: Bug Components: Container Reporter: Bill Burke The DeploymentContext.getName() ends up being the full URL of a JAR if you have a JAR file within a directory, its name is jar:file:/.../foo.jar!/ Shouldn't this be a "short" name? My bet this has something to do with how the URL is messed up too for VirtualFiles that are JARs. -- 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, 3 months

4
3
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-5) Main Deployer

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-5?page=all ] Scott M Stark closed JBMICROCONT-5. ----------------------------------- Fix Version/s: JBossMC_2_0_0 Beta3 (was: JBossMC_2_0_0_CR1) Resolution: Done Assignee: Scott M Stark (was: Dimitris Andreadis) > Main Deployer > ------------- > > Key: JBMICROCONT-5 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-5 > Project: JBoss MicroContainer > Issue Type: Task > Components: Deployment > Reporter: Adrian Brock > Assigned To: Scott M Stark > Fix For: JBossMC_2_0_0 Beta3 > > > MainDeployer > ------------ > The primary methods of MainDeployer are > (re/un)deploy(URL) > other methods are > (un)register/register(deployer, priority) > which will be used by the microcontainer > when a deployer is installed > stats based methods that expose information from the VDF > and config/constructors methods for things like the VDF and > initial deployers. > deploy(url) > 1) create a skeleton VDF context for the top level deployment > 2) ask the structural component chain who recognises it > repeat recursively for identified subcontexts > 3) invoke down the deployment component chain > starting with the deepest subcontexts first > redeploy(url) > similar to deploy() but performing a reinstall on the > microcontainer (i.e. suspend on valve for components being > reinstalled) > undeploy(url) > invoke down the deployment chain in reverse order > to remove the installed components > Reverse order means both in terms of subcontexts > and priority. > (un)register/register(deployer) > The deployer here identifies the structural and > deployment components of the deployer > and their respective "priorities". > This will be the name in the registry which > might be instantiated later. > Where present, the deployer is added to the > relevent chain. > ISSUE: Need to tighten up the semantics of the > register/unregister(deployer) for when the > deployment component has dependencies and > cannot be instantiated immediately -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-914) Web deployer can't find EJB via ejb-link in web.xml

by Brian Stansberry (JIRA)

Web deployer can't find EJB via ejb-link in web.xml --------------------------------------------------- Key: EJBTHREE-914 URL: http://jira.jboss.com/jira/browse/EJBTHREE-914 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 CR1 Reporter: Brian Stansberry If you package an EJB3 jar in an ear with a war, you can't bind the EJBs into the webapp ENC via ejb-link; if you try the deployment fails. You get: 2007-03-15 17:23:26,210 ERROR [org.jboss.deployment.MainDeployer] Could not start deployment: file:/C:/dev/jboss/jboss-4.2/build/output/jboss-4.2.0.GA/server/all/tmp/deploy/tmp51991classloader-leak-simple-ejb3.ear-contents/classloader-leak-simple-ejb3.war org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NamingException: ejb-ref: ejb/ClassloaderLeakEJB3SLSB, no ejb-link in web.xml and no jndi-name in jboss-web.xml) at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384) at org.jboss.web.WebModule.startModule(WebModule.java:83) at org.jboss.web.WebModule.startService(WebModule.java:61) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) 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:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) Caused by: javax.naming.NamingException: ejb-ref: ejb/ClassloaderLeakEJB3SLSB, no ejb-link in web.xml and no jndi-name in jboss-web.xml at org.jboss.web.AbstractWebDeployer.linkEjbRefs(AbstractWebDeployer.java:695) at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:517) at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878) at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:158) at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104) at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375) at org.jboss.web.WebModule.startModule(WebModule.java:83) at org.jboss.web.WebModule.startService(WebModule.java:61) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) 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:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy54.start(Unknown Source) I followed the linking process into org.jboss.ejb.EjbUtil.resolveAbsoluteLink method. It fails because the DeploymentInfo.metaData field is null for the ejb deployment. (If it weren't null, for this to work it would have to be an instance of org.jboss.metadata.ApplicationMetaData, a requirement an ejb3 deployment probably wouldn't meet.) -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-727) Make Client's implicitly created Connectors accessible

by Ron Sigal (JIRA)

Make Client's implicitly created Connectors accessible ------------------------------------------------------ Key: JBREM-727 URL: http://jira.jboss.com/jira/browse/JBREM-727 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta2 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta2 (Bluto) If the callback Connectors created by Client.addlistener(InvokerCallbackHandler, Map metadata) were accessible, they could be reused. -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-634) update doc on callbacks

by Tom Elrod (JIRA)

update doc on callbacks ----------------------- Key: JBREM-634 URL: http://jira.jboss.com/jira/browse/JBREM-634 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: callbacks Affects Versions: 2.2.0.Alpha3 (Bluto) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Update doc to include more info on callbacks, especially changes made for JBREM-622 -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-722) BisocketClientInvoker should start pinging on control connection without waiting for call to createsocket()

by Ron Sigal (JIRA)

BisocketClientInvoker should start pinging on control connection without waiting for call to createsocket() ----------------------------------------------------------------------------------------------------------- Key: JBREM-722 URL: http://jira.jboss.com/jira/browse/JBREM-722 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) Currently, a callback BisocketClientInvoker waits for the first call to createSocket() to start pinging on control connection. But the BisocketServerInvoker.ControlMonitorTimerTask on the client side doesn't start testing for pings until it gets the first ping. So, if the control connection were to break before the first call to createSocket(), the ControlMonitorTimerTask wouldn't recreate the control connection and createSocket() wouldn't be able to get a new socket. -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-254) Remove ThreadContextClassLoaderChanger

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-254?page=all ] Clebert Suconic closed JBMESSAGING-254. --------------------------------------- Resolution: Done > Remove ThreadContextClassLoaderChanger > -------------------------------------- > > Key: JBMESSAGING-254 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-254 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Clebert Suconic > Priority: Critical > Fix For: 1.2.0.SP1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Kabir has fixed this in AOP so this is no longer necessary. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBBUILD-177) Update build to match developer changes since last release

by Paul Gier (JIRA)

[ http://jira.jboss.com/jira/browse/JBBUILD-177?page=all ] Paul Gier closed JBBUILD-177. ----------------------------- Resolution: Out of Date No one seems to know anything about this issue, so I'm closing it. > Update build to match developer changes since last release > ---------------------------------------------------------- > > Key: JBBUILD-177 > URL: http://jira.jboss.com/jira/browse/JBBUILD-177 > Project: JBoss Build System > Issue Type: Task > Reporter: Ruel Loehr > Original Estimate: 1 week > Remaining Estimate: 1 week > -- 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, 3 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 March 2007