October 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Web Services] - Re: JBAS-4890:EJBAccessException: Caller unauthorized

by anil.saldhana＠jboss.com

The JIRA issue is closed now. Scott had made a RunAsIdentity push of "anonymous" in the absence of any RAI, which is wrong. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098537#4098537 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098537

17 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: SingleSignOn method visibility change

by scott.stark＠jboss.org

Must be. I have checked in the ClusteredSingleSignOn changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098536#4098536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098536

17 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBAS-4890:EJBAccessException: Caller unauthorized

by anil.saldhana＠jboss.com

The issue seems to be stemming from the following change that Scott made: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/tomcat/src/main/... I will fix it and see if this JIRA issue can be closed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098533#4098533 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098533

17 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Duplicate mbean removal

by scott.stark＠jboss.org

On shutdown of the jbossas server I'm seeing these spurious errors due to the Connector trying to unregister itself or some other mbean: | 13:00:10,081 INFO [TomcatDeployment] undeploy, ctxPath=/web-console, vfsUrl=management/console-mgr.sar/web-console.war | 13:00:10,092 ERROR [Connector] invalid Object Name | javax.management.InstanceNotFoundException: jboss.remoting:service=invoker,transport= bisocket,host=succubus.starkinternational.com,port=4457,clientMaxPoolSize=50,clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper,dataType=jms,marshaller=org.jboss.jms.wireformat.JMSWireFormat,numberOfCallRetries=1,numberOfRetries=1,serverSocketClass=org.jboss.jms.server.remoting.ServerSocketWrapper,socket.check_connection=false,timeout=0,unmarshaller=org.jboss.jms.wireformat.JMSWireFormat is not registered. | at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529) | at org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383) | at org.jboss.remoting.transport.Connector.stop(Connector.java:744) | 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:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:184) | at $Proxy4.stop(Unknown Source) | at org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56) | at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90) | at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58) | at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:334) | at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1323) | at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1009) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:627) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411) | at org.jboss.system.ServiceController.doChange(ServiceController.java:659) | at org.jboss.system.ServiceController.stop(ServiceController.java:481) | at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:156) | at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:136) | at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:46) | at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:73) | at org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:187) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:947) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:940) | at org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:902) | at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:334) | at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1323) | at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1009) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:627) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411) | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:420) | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:354) | at org.jboss.deployers.plugins.main.MainDeployerImpl.shutdown(MainDeployerImpl.java:382) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:151) | at org.jboss.bootstrap.AbstractServerImpl.shutdownServer(AbstractServerImpl.java:482) | at org.jboss.bootstrap.AbstractServerImpl$ShutdownHook.run(AbstractServerImpl.java:778) | It should not be doing that. Registration is handled by the deployer layer. The Connector source is not in the jboss thirdparty repository (it should be as a jboss-remoting-sources.jar), so I can't check what is going on. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098531#4098531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098531

17 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: SingleSignOn method visibility change

by bstansberry＠jboss.com

Perhaps a result of the conversation on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121054 ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098526#4098526 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098526

17 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Connector.getEmptySessionPath dropped

by scott.stark＠jboss.org

Another compile error in the org.jboss.web.tomcat.service.session.JBossManager implementation of the org.apache.catalina.Manager interface is due to the org.apache.catalina.connector.Connector dropping the getEmptySessionPath method. This was being used in the session cookie creation: | public void setNewSessionCookie(String sessionId, HttpServletResponse response) | { | if (response != null) | { | Context context = (Context) container_; | Connector connector = ((Response)response).getConnector(); | if (context.getCookies()) | { | // set a new session cookie | Cookie newCookie = new Cookie(Globals.SESSION_COOKIE_NAME, sessionId); | if (log_.isTraceEnabled()) | { | log_.trace("Setting cookie with session id:" + sessionId + " & name:" + Globals.SESSION_COOKIE_NAME); | } | | String contextPath = null; | if (!connector.getEmptySessionPath() && (context != null)) { | contextPath = context.getEncodedPath(); | } | | if ((contextPath != null) && (contextPath.length() > 0)) { | newCookie.setPath(contextPath); | } else { | newCookie.setPath("/"); | } | What replaces this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098514#4098514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098514

17 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - SingleSignOn method visibility change

by scott.stark＠jboss.org

After updating my workspace today I'm seeing compile errors in the org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn due to a change in the base org.apache.catalina.authenticator.SingleSignOn. It appears a number of protected methods have been made public: | compile-classes: | [javac] Compiling 35 source files to /home/svn/JBossHead/jboss-head/tomcat/output/classes | /home/svn/JBossHead/jboss-head/tomcat/src/main/org/jboss/web/tomcat/service/session/JBossManager.java:325: cannot find symbol | symbol : method getEmptySessionPath() | location: class org.apache.catalina.connector.Connector | if (!connector.getEmptySessionPath() && (context != null)) { | ^ | /home/svn/JBossHead/jboss-head/tomcat/src/main/org/jboss/web/tomcat/service/sso/ClusteredSingleSignOn.java:687: associate(java.lang.String,org.apache.catalina.Session) in org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn cannot override associate(java.lang.String,org.apache.catalina.Session) in org.apache.catalina.authenticator.SingleSignOn; attempting to assign weaker access privileges; was public | protected void associate(String ssoId, Session session) | ^ | /home/svn/JBossHead/jboss-head/tomcat/src/main/org/jboss/web/tomcat/service/sso/ClusteredSingleSignOn.java:793: deregister(java.lang.String) in org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn cannot override deregister(java.lang.String) in org.apache.catalina.authenticator.SingleSignOn; attempting to assign weaker access privileges; was public | protected void deregister(String ssoId) | ^ | /home/svn/JBossHead/jboss-head/tomcat/src/main/org/jboss/web/tomcat/service/sso/ClusteredSingleSignOn.java:897: reauthenticate(java.lang.String,org.apache.catalina.Realm,org.apache.catalina.connector.Request) in org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn cannot override reauthenticate(java.lang.String,org.apache.catalina.Realm,org.apache.catalina.connector.Request) in org.apache.catalina.authenticator.SingleSignOn; attempting to assign weaker access privileges; was public | protected boolean reauthenticate(String ssoId, Realm realm, | ^ | /home/svn/JBossHead/jboss-head/tomcat/src/main/org/jboss/web/tomcat/service/sso/ClusteredSingleSignOn.java:944: register(java.lang.String,java.security.Principal,java.lang.String,java.lang.String,java.lang.String) in org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn cannot override register(java.lang.String,java.security.Principal,java.lang.String,java.lang.String,java.lang.String) in org.apache.catalina.authenticator.SingleSignOn; attempting to assign weaker access privileges; was public | protected void register(String ssoId, Principal principal, String authType, | ^ | Note: Some input files use or override a deprecated API. | Note: Recompile with -Xlint:deprecation for details. | Note: Some input files use unchecked or unsafe operations. | Note: Recompile with -Xlint:unchecked for details. | 5 errors | I'll change these for now, but whether this change is expected is the question. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098513#4098513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098513

17 years, 2 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by sohil.shah＠jboss.com

Looking at this discussion, looks like two efforts are being proposed. 1/ A re-usable POJO ACL layer across JEMS (topic of this discussion, and IMO a higher priority item) 2/ A re-usable Identity Management Framework across JEMS (IMO, a nice to have, but not too urgent, especially considering the agreements that all JEMS projects will have to come to, in order to decide it) I think ACL layer Design/Implementation should not be bogged down by the slower paced Identity Framework Design. They should be independent components of each other. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098488#4098488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098488

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JBoss ESB HelloWorld and Eclipse IDE

by cavnesss

Thank you! I apologize for posting in the Design area and have found some other forum areas that are more appropriate. I'm just getting up to speed on JBoss and I'm digging away. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098481#4098481 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098481

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JBoss ESB HelloWorld and Eclipse IDE

by Kevin.Conner＠jboss.com

Sorry but we do not yet integrate into that aspect. Installation into a server is handled by the ant script. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098463#4098463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098463

17 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007