[jira] Created: (SM-801) can not deploy bridge-sa in apache-servicemix-3.1-incubating-SNAPSHOT + Geronimo 1.2 Beta
can not deploy bridge-sa in apache-servicemix-3.1-incubating-SNAPSHOT + Geronimo 1.2 Beta - Key: SM-801 URL: https://issues.apache.org/activemq/browse/SM-801 Project: ServiceMix Issue Type: Bug Components: geronimo Environment: apache-servicemix-3.1-incubating-SNAPSHOT + Geronimo 1.2 Beta Reporter: xiaoxiong duan Fix For: 3.1 deploy bridge-sa in apache-servicemix-3.1-incubating-SNAPSHOT + Geronimo 1.2 Beta get the following exception: 16:36:22,180 INFO [FileSystemXmlApplicationContext] Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': using default [EMAIL PROTECTED] 16:36:22,180 INFO [DefaultListableBeanFactory] Pre-instantiating singletons in factory [org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [org.apache.servicemix.jms.JmsEndpoint,connectionFactory]; root of BeanFactory hierarchy] 16:36:22,190 INFO [ServiceUnitLifeCycle] Starting service unit: bridge-http-su 16:36:22,210 INFO [ServiceAssembly] doFail called for JBI service assembly: bridge-sa 16:36:22,210 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=servicemix-assemblies/bridge-sa/0.0/car?jbiType=JBIServiceAssembly,name=bridge-sa java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamWriter at org.apache.servicemix.http.processors.ConsumerProcessor.init(ConsumerProcessor.java:79) at org.apache.servicemix.http.HttpEndpoint.createConsumerProcessor(HttpEndpoint.java:300) at org.apache.servicemix.soap.SoapEndpoint.activate(SoapEndpoint.java:346) at org.apache.servicemix.common.ServiceUnit.start(ServiceUnit.java:55) at org.apache.servicemix.common.BaseServiceUnitManager.start(BaseServiceUnitManager.java:151) at org.apache.servicemix.jbi.framework.ServiceUnitLifeCycle.start(ServiceUnitLifeCycle.java:103) at org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle.start(ServiceAssemblyLifeCycle.java:130) at org.apache.servicemix.jbi.framework.ServiceAssemblyLifeCycle.start(ServiceAssemblyLifeCycle.java:105) at org.apache.servicemix.geronimo.ServiceMixGBean.register(ServiceMixGBean.java:201) at org.apache.servicemix.geronimo.ServiceMixGBean$$FastClassByCGLIB$$fcdcf76b.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.servicemix.geronimo.Container$$EnhancerByCGLIB$$d7d47bd7.register(generated) at org.apache.servicemix.geronimo.ServiceAssembly.doStart(ServiceAssembly.java:55) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:984) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:543) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:378) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:527) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:508) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at
[jira] Created: (GERONIMO-2689) New View for JNDI name in all the contexts
New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2105) When redeploying with no version number, new entries in config.xml break
[ https://issues.apache.org/jira/browse/GERONIMO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2105: -- Attachment: g2105.war When redeploying with no version number, new entries in config.xml break Key: GERONIMO-2105 URL: https://issues.apache.org/jira/browse/GERONIMO-2105 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1.x Attachments: g2105-1.2.war, g2105.war Let's say you deploy foo with no version number and config.xml content. Then through the console or some other mechanism, you set a property on a previously unlisted GBean. Now you get something like this: module name=default/foo/1149955208117/war gbean name=default/foo/1149955208117/war?J2EEApplication=null,WebModule=default/foo/1149955208117/war,j2eeType=GBean,name=MyGBean attribute name=barvalue/attribute Now you redeploy foo, and it migrates the config.xml entry to the new version number. However, what you actually get is this: module name=default/foo/1149955408117/war gbean name=default/foo/1149955223470/war?J2EEApplication=null,WebModule=default/foo/1149955223470/war,j2eeType=GBean,name=MyGBean attribute name=barvalue/attribute Note the different version numbers between module and gbean elements. In other words, the version in the main config.xml entry is updated, but the version in the GBean entries is not. This means that the module will fail to start, as it will treat the GBean as a brand new GBean declaration and crap out when it has no GBeanInfo defined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2105) When redeploying with no version number, new entries in config.xml break
[ https://issues.apache.org/jira/browse/GERONIMO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2105: -- Attachment: g2105-1.2.war When redeploying with no version number, new entries in config.xml break Key: GERONIMO-2105 URL: https://issues.apache.org/jira/browse/GERONIMO-2105 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1.x Attachments: g2105-1.2.war, g2105.war Let's say you deploy foo with no version number and config.xml content. Then through the console or some other mechanism, you set a property on a previously unlisted GBean. Now you get something like this: module name=default/foo/1149955208117/war gbean name=default/foo/1149955208117/war?J2EEApplication=null,WebModule=default/foo/1149955208117/war,j2eeType=GBean,name=MyGBean attribute name=barvalue/attribute Now you redeploy foo, and it migrates the config.xml entry to the new version number. However, what you actually get is this: module name=default/foo/1149955408117/war gbean name=default/foo/1149955223470/war?J2EEApplication=null,WebModule=default/foo/1149955223470/war,j2eeType=GBean,name=MyGBean attribute name=barvalue/attribute Note the different version numbers between module and gbean elements. In other words, the version in the main config.xml entry is updated, but the version in the GBean entries is not. This means that the module will fail to start, as it will treat the GBean as a brand new GBean declaration and crap out when it has no GBeanInfo defined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2105) When redeploying with no version number, new entries in config.xml break
[
https://issues.apache.org/jira/browse/GERONIMO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-2105:
--
Affects Version/s: 2.0
1.2
1.1.2
Fix Version/s: (was: 1.1.x)
2.0
1.x
1.1.2
Some of the recent recent deployer fixes seems to have fixed this problem in
branches\1.1 (with a glitch that the migrated values reflect only upon
restarting the app explicitly). The problem still remains in 1.2 and 2.0.
Here are my findings from the investigation I have done using sample web
applications g2105.war and g2105-1.2.war. Excerpt from config.xml at each step
is given where ever relevant.
branches\1.1 (rev 492571)
step 1: Deploy g2105.war
{code}
module name=jira/G2105/1167917098620/war/
{code}
step 2: Access http://localhost:8080/G2105/ . The browser should show
Attribute value is ORIGINAL.
{code}
module name=jira/G2105/1167917098620/war
gbean
name=jira/G2105/1167917098620/war?J2EEApplication=null,WebModule=jira/G2105/1167917098620/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
step 3: Redeploy g2105.war
{code}
module name=jira/G2105/1167917210461/war
gbean
name=jira/G2105/1167917210461/war?J2EEApplication=null,WebModule=jira/G2105/1167917210461/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
Note: Even though the config.xml entry is migrated properly, the value change
does not reflect until the application (or server) is restarted explicitly
after step 3.
step 4: Access http://localhost:8080/G2105/ . The browser should show
Attribute value is CHANGED.
branches\1.2 (rev 492571)
step 1: deploy g2105-1.2.war
{code}
module name=jira/G2105/1167917997542/war/
{code}
step 2: Access http://localhost:8080/G2105/
{code}
module name=jira/G2105/1167917997542/war
gbean
name=jira/G2105/1167917997542/war?J2EEApplication=null,WebModule=jira/G2105/1167917997542/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
step 3: Redeploy g2105-1.2.war
{code}
module name=jira/G2105/1167918100641/war
gbean
name=jira/G2105/1167917997542/war?J2EEApplication=null,WebModule=jira/G2105/1167917997542/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
step 4: Access http://localhost:8080/G2105/
{code}
module name=jira/G2105/1167918100641/war
gbean
name=jira/G2105/1167917997542/war?J2EEApplication=null,WebModule=jira/G2105/1167917997542/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
gbean
name=jira/G2105/1167918100641/war?J2EEApplication=null,WebModule=jira/G2105/1167918100641/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
step 5: Restart of G fails
trunk (rev 492571)
step 1: deploy g2105-1.2.war
{code}
module name=jira/G2105/1167920244553/war/
{code}
step 2: Access http://localhost:8080/G2105/
{code}
module name=jira/G2105/1167920244553/war
gbean
name=jira/G2105/1167920244553/war?J2EEApplication=null,WebModule=jira/G2105/1167920244553/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
step 3: Redeploy g2105-1.2.war
{code}
module name=jira/G2105/1167920343696/war
gbean
name=jira/G2105/1167920244553/war?J2EEApplication=null,WebModule=jira/G2105/1167920244553/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
step 4: Access http://localhost:8080/G2105/
{code}
module name=jira/G2105/1167920343696/war
gbean
name=jira/G2105/1167920244553/war?J2EEApplication=null,WebModule=jira/G2105/1167920244553/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
gbean
name=jira/G2105/1167920343696/war?J2EEApplication=null,WebModule=jira/G2105/1167920343696/war,j2eeType=SecurityRealm,name=ORIGINAL
attribute name=realmNameCHANGED/attribute
/gbean
/module
{code}
step 5: Restart of G fails
When redeploying with no version number, new entries in config.xml break
Key: GERONIMO-2105
URL: https://issues.apache.org/jira/browse/GERONIMO-2105
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: kernel
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Aaron Mulder
[jira] Commented: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462235 ] Michael Sowka commented on GERONIMO-2686: - I run into a very similar looking problem when trying to deploy a JMS Resource from the Console on G1.2 (OS X 1.2 beta svn, Win 1.2 beta): 10:02:42,248 ERROR [AbstractHandler] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:299) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(AbstractHandler.java:471) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBeforeView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:326) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The
[jira] Created: (AMQ-1115) Memory Leak: OutOfMemoryException throws if TopicSubscriber.receive(timeout) is used to pull JMS messages
Memory Leak: OutOfMemoryException throws if TopicSubscriber.receive(timeout) is used to pull JMS messages - Key: AMQ-1115 URL: https://issues.apache.org/activemq/browse/AMQ-1115 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 4.1.0 Environment: Windows XP Professional, JDK 1.5 Reporter: Sam Zhou Attachments: ActiveMq Tester.zip Attached sources can generate OutOfMemoryException when ActiveMQ pulls messages by using TopicSubscriber.receive(timeout), on the other hand, if I use callback TopicSubscriber.onMessage(), all the messages are received without any problem. Please see README.TXT for detail usage of the program. Assume I set prefetch=50, publisherCount=10, subscriberCount=10, each publisher publishs 500 messages, and each message size is 100kb, If I use callback (option -msgcallback given in command line), e.g., TopicSubscriber.onMessage(), all 50,000 messages are received without error. if I don't use callback (option -msgcallback not given in command line), e.g., TopicSubscriber.receive(timeout), after receiving about a thousand of messages, OutOfMemory error occurs, and the program starts to throw Exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2692) Current specs/trunk fails to build, due to missing modules
Current specs/trunk fails to build, due to missing modules -- Key: GERONIMO-2692 URL: https://issues.apache.org/jira/browse/GERONIMO-2692 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Affects Versions: 2.0-M2 Reporter: Donald Woods Assigned To: Donald Woods Fix For: 2.0-M2 The current geronimo/specs/trunk fails to build, because several specs were released and moved out of /trunk, but were not removed from the modules list to build in the main pom.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2693) Application classloader contains a massive number of duplicate classpath entries
Application classloader contains a massive number of duplicate classpath entries Key: GERONIMO-2693 URL: https://issues.apache.org/jira/browse/GERONIMO-2693 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 1.1.1 Environment: WAS CE 1.1.0.1 Reporter: Mike Perham I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/. When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths: jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF If I do a getResources(foo) and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath. I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear. This is a blocker preventing us from using our application on WAS CE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2693) Application classloader contains a massive number of duplicate classpath entries
[ https://issues.apache.org/jira/browse/GERONIMO-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462241 ] Mike Perham commented on GERONIMO-2693: --- You can easily print out your own classpath with this elegant hack. :-) Enumeration e = Thread.currentThread().getContextClassLoader().getResources(META-INF); List entries = Collections.list(e); Application classloader contains a massive number of duplicate classpath entries Key: GERONIMO-2693 URL: https://issues.apache.org/jira/browse/GERONIMO-2693 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1.1 Environment: WAS CE 1.1.0.1 Reporter: Mike Perham Attachments: cpath.txt I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/. When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths: jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF If I do a getResources(foo) and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath. I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear. This is a blocker preventing us from using our application on WAS CE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2692) Current specs/trunk fails to build, due to missing modules
[ https://issues.apache.org/jira/browse/GERONIMO-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Cabrera resolved GERONIMO-2692. Resolution: Fixed Thanks Donald! Current specs/trunk fails to build, due to missing modules -- Key: GERONIMO-2692 URL: https://issues.apache.org/jira/browse/GERONIMO-2692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.0-M2 Reporter: Donald Woods Fix For: 2.0-M2 Attachments: G2692-specs-2.0.patch The current geronimo/specs/trunk fails to build, because several specs were released and moved out of /trunk, but were not removed from the modules list to build in the main pom.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2692) Current specs/trunk fails to build, due to missing modules
[ https://issues.apache.org/jira/browse/GERONIMO-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2692: --- Attachment: G2692-specs-2.0.patch Current specs/trunk fails to build, due to missing modules -- Key: GERONIMO-2692 URL: https://issues.apache.org/jira/browse/GERONIMO-2692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.0-M2 Reporter: Donald Woods Assigned To: Donald Woods Fix For: 2.0-M2 Attachments: G2692-specs-2.0.patch The current geronimo/specs/trunk fails to build, because several specs were released and moved out of /trunk, but were not removed from the modules list to build in the main pom.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1116) deadlock when shutting down client that is configured with failover=true and is presently disconnected from broker
deadlock when shutting down client that is configured with failover=true and is
presently disconnected from broker
--
Key: AMQ-1116
URL: https://issues.apache.org/activemq/browse/AMQ-1116
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0.2
Reporter: Chris Hofstaedter
Sounds like a great idea to me :) Please go ahead and submit a jira with the
patch and we'll get it integrated ASAP
On 1/4/07, Chris Hofstaedter [EMAIL PROTECTED] wrote:
I ran into this issue as well on = 4.0.2. I never tested it against
4.1.The FailoverTransport doesn't shutdown if it is disconnected at
the time of the shutdown.
I believe that the root cause is in the
FailoverTransport.oneway(Command
command) function which will hold onto the command and keep trying to
reconnect until the message is sent or the transport is disposed.
I applied a local patch that seems to solve the problem. Note that
I've only tested the patch against 4.0.2.
Specifically, I early return from the oneway function if the command
is ShutdownInfo and the connectedTransport is null. This seems to
solve the problem in that I get clean shutdowns on the client when
failover is true and the client is presently disconnected.
Does this seem like a reasonable patch? Should I create a JIRA with
this info?
-Original Message-
From: James Strachan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 12, 2006 4:46 AM
To: activemq-users@geronimo.apache.org
Subject: Re: failover mode and client shutdown
There could be a bug relating to closes with the failover transport
possibly, but the ActiveMQConnection does wait up to the closeTimeout
for a close to succeed before shutting down - so you could try reduce
the timeout.
http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/a
pa
che/activemq/ActiveMQConnection.html#setCloseTimeout(int)
On 12/12/06, Keith Irwin [EMAIL PROTECTED] wrote:
Folks--
When we have clients running and we take down AMQ (= 4.1.0), then
attempt to shutdown the clients with Control-C (rather than kill the
JVM with a -9), the clients won't shut down. It's as if a close
on the failover connection never reaches the amq client classes.
I note that in the 4.1.0 release notes, this issue is referenced,
and the advice is to set the maxReconnectAttempts (or similar)
property to something non-zero.
The problem is that we don't want there to be a max number of
attempts. Unless we specifically want to take down the client (say,
for an apt-get package upgrade), we want it to keep on trying
forever.
SO, my question: Is there an architectural reason for not being able
to close a failover connection if AMQ is down?
If it isn't impossible due to tradeoffs elsewhere in the code base,
we might be willing to submit a patch to fix the issue.
Our only other recourse is to attempt to close the connections in
separate threads, then timeout those threads after a while and fall
out the end of the java process.
For instance:
Thread th = new Thread(new Runnable() {
public void run() {
connection.close();
}
});
th.start();
// give up after 2 seconds
Thread.currentThread().join(2000);
I guess this is do-able, but it seems, you know, some how, well,
wrong.
So, is it worth investigating a patch to AMQ?
Keith
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2694) STATUS file sent out as the Geronimo Weekly Status email needs updating
STATUS file sent out as the Geronimo Weekly Status email needs updating --- Key: GERONIMO-2694 URL: https://issues.apache.org/jira/browse/GERONIMO-2694 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: documentation Affects Versions: 1.2, 2.0-M2 Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 2.0-M2 The geronimo/server/trunk/STATUS file needs to be updated to mention trunk is now 2.0, where the 1.2 branch is located and the fact that 1.2-Beta and 2.0-M1 were released. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-2686: --- Priority: Critical (was: Major) Affects Version/s: 1.2 Fix Version/s: 2.0-M2 1.2 Seems to have been broken by http://issues.apache.org/jira/browse/GERONIMO-2627 (RC 482859 (1.2) and 482870 (trunk)). database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico Priority: Critical Fix For: 1.2, 2.0-M2 From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The terminal shows the following error: ERROR [DatabasePoolPortlet] Unable to save connection pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:325) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:542) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) 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: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Axis Implementation of XML DOM
Geronimo or Axis version being used?
-Donald
Phani Madgula wrote:
Hi
There is a problem in Axis implementation of Comment.getNodeType(). I
have the following code that recreates the issue.
*
import
* javax.xml.namespace.QName;*
**import* javax.xml.soap.Node ;*
**import* org.apache.axis.message.SOAPBodyElement;*
**import * org.w3c.dom.Comment;*
**public* *class* AxisXMLCommentTest {*
**public* *static* *void * main(String args[]) {*
*SOAPBodyElement sb = *new* SOAPBodyElement(* new*
QName(http://www.phanibalaji.com,test;))*;
* Comment c = sb.getOwnerDocument().createComment(TEST);*
*sb.appendChild(c);*
** if* (c.getNodeType() != Node./COMMENT_NODE/) {*
*System./ err/.println(Node is of diffe*rent type*); *
*} *else* {*
*System./err/.println(Success); *
* }
}
}
I am getting the condition *if* (c.getNodeType() != Node./COMMENT_NODE/)
as true. But, it must be false.
Can anybody comment?
Regards
Phani
smime.p7s
Description: S/MIME Cryptographic Signature
Re: hostname vs. IP
Using getHostName was removed back in the 1.1 release, as it only returned the short hostname, which causes problems when using the deployer to machines using DHCP or not in the same sub-domain. -Donald Bruce Snyder wrote: On 12/7/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, is there a way to force Geronimo to display the hostname when deploying apps? it seems to randomly change from one interface to another (I have 2 IPs diff network on my machine) and from IP to server name. I can't figure out why Geronimo is picking one over the other, it seems to be random. Web Applications: http://192.168.1.10:8080/ http://192.168.1.10:8080/console http://192.168.1.10:8080/console-standard http://192.168.1.10:8080/dojo http://192.168.1.10:8080/hello http://192.168.1.10:8080/remote-deploy Any suggestions? This is probably because only the method InetAddress.getHost() is being used instead of InetAddress.getHostName(). But using getHostName() and having it work correctly requires a reverse lookup to be performed. But I'm sure it can be changed. Bruce smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-2693) Application classloader contains a massive number of duplicate classpath entries
[ https://issues.apache.org/jira/browse/GERONIMO-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Perham updated GERONIMO-2693: -- Attachment: cpath.txt Application classloader contains a massive number of duplicate classpath entries Key: GERONIMO-2693 URL: https://issues.apache.org/jira/browse/GERONIMO-2693 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1.1 Environment: WAS CE 1.1.0.1 Reporter: Mike Perham Attachments: cpath.txt I have an EAR with an MDB jar and two WARs. The EAR contains a large number of jars within a lib directory. The wars and ejb-jar all contain MANIFEST.MF Class-Path entries which reference those jars within lib/. When I print out my WAR classpath, I get output attached. The duplications don't really matter all that much except for the duplications due to non-canonicalized paths: jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/lib/fabric-gov-api-1.4.0.jar!/META-INF jar:file:/D:/perforce/depot/external/wasce/1.1.0.1/repository/com/ibm/websphere/fabric-tools-ear/6.0/fabric-tools-ear-6.0.car/fabric-tools-web.war/../lib/fabric-gov-api-1.4.0.jar!/META-INF If I do a getResources(foo) and that gov-api jar has a foo resource, the system will think there are two foo resources when in fact there is only one, due to different URLs for the same resource. As a result, for instance, this causes Apache Hivemind to blow up with an error due to it thinking a component jar is doubly defined in the classpath. I'm unclear why Geronimo is adding all the lib jars to my classpath without my asking. It seems like the various J2EE modules should be able to control their own classpath wrt jars in the ear. This is a blocker preventing us from using our application on WAS CE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2692) Current specs/trunk fails to build, due to missing modules
[ https://issues.apache.org/jira/browse/GERONIMO-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2692: --- Patch Info: [Patch Available] Assignee: (was: Donald Woods) Attached patch that removes the 3 specs that were released and moved to tags - geronimo-annotation_1.0_spec, geronimo-interceptor_3.0_spec, geronimo-jpa_3.0_spec Current specs/trunk fails to build, due to missing modules -- Key: GERONIMO-2692 URL: https://issues.apache.org/jira/browse/GERONIMO-2692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.0-M2 Reporter: Donald Woods Fix For: 2.0-M2 Attachments: G2692-specs-2.0.patch The current geronimo/specs/trunk fails to build, because several specs were released and moved out of /trunk, but were not removed from the modules list to build in the main pom.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: No legacy repos for Geronimo projects using Maven2
Is that an open invitation to help recreate those scripts?
Do others see a need for this? I certainly would like to see us put
them back in geronimo/server/trunk (or genesis) and enhance them to
allow svn checkout/update and orderly building of genesis, specs, server
and even handle openejb and devtools.
-Donald
Jason Dillon wrote:
You don't need to add this to settings.xml, you can simply:
mvn -Dmaven.repo.local=some/path
But you are right, to make this work, we need those native scripts to
bootstrap the build again and set the correct value for the repo.
--jason
On Jan 2, 2007, at 8:32 AM, Donald Woods wrote:
You can create a settings.xml in the default user/.m2 directory to
point to an alternate local repo dir, like -
?xml version=1.0 encoding=UTF-8?
settings
localRepository${LOCAL_GERONIMO_M2_REPO}/localRepository
/settings
But the downside, is you're leaving it up to each developer to either
supply this environment variable or manually update the file and it
would be used by all Maven2 builds So, you would really need to
restore the bootstrap scripts to setup a local Geronimo repo dir
(checkout or update the needed files from svn) and then run a
multistage server build (genesis, maven plugins, modules, configs and
assemblies)
-Donald
Jason Dillon wrote:
Unfortunately this would have to be externally controlled, can not
specify maven.repo.local in a pom, and if you could, can't root it to
the project, as ${pom.basedir} will always keep changing.
This was possible in m1 though... for what its worth. Only way to do
this in m2 is to use native scripts.
:-(
--jason
On Dec 11, 2006, at 2:49 PM, Guillaume Nodet wrote:
Is there a way to specify that in the pom ?
Or you have to rely on users to specify it on the command
line everytime they build (or use batch files).
On 12/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
What do you mean? If you specify -Dmaven.repo.local=./svn-repo (or
where ever the svn checkout is) and run the build offline, then the
repo won't get modified, and thus only chance a bad artifact would
get in there would be if someone checked in something bad, or if the
local `mvn install` got messed up, but generally `mvn install`
artifacts will never be checked into that repo.
It is really too bad that there is not a local repo for deps and then
a local repo for generated artifacts. The whole local repo thing is
lossy IMO and makes it very difficult to assure quality of releases.
--jason
On Dec 11, 2006, at 7:55 AM, Guillaume Nodet wrote:
Also, keep in mind that there is no way to bypass the
local repository afaik. So if a bad artifact goes into the
user local repo, it may disturb Geronimo's build, even
if Geronimo build only use a single svn based remote
repo. In such a case, the only way to ensure that the
build will work is to start from a clean local repo.
On 12/9/06, Jason Dillon [EMAIL PROTECTED] wrote:
On Dec 8, 2006, at 6:41 PM, Prasad Kashyap wrote:
... At this point... and ya, I may be in a
bad mood now... I don't think that mvn is an appropriate tool
for
building production quality products... period.
I hear ye. I share the pain. But I fear the alternative -
spending
considerable time migrating to another build system.
Ya, I know... I'm not suggesting that we change any time soon.
But I
do fear that there is going to be some serious ongoing pain.
When you return from your bad mood to your jolly good ole' self
again,
I dunno... I'm jaded now... good ole jolly jason was eaten by
the big
angry maven monster... :-P
can you please shed more light on what it would take to have this
*ONE* repo; it's pros and cons and such..
I've sent a few emails about this in the past. Major hurtles to
this
are going to be sysadmin/network overheads, ASF infra politics, and
of course keeping the artifacts in sync. There are just way to
many
things that need to get downloaded, making the window for problems
really quite massive.
I'm still trying to figure out how to effectively workaround this
problem for an open community... in a corporate setting this is
a no
brainer, setup a machine, back it up, setup proximity or
maven-proxy
to aggregate remote repos, then create a few local repos backed by
svn to hold custom artifacts or specific versions to help reduce
risk
incurred by remote artifact stability. Then each project just
lists
that one repo.
This works well, but due to the way maven works, other dependencies
may list repos, which will then get picked up and used for
artifacts
selection, which tends to pollute the sanity and stability, but
usually not too much. But its yet another flaw in maven's
architecture which while its flexible and easy for smaller
projects,
its nearly impossible to make any sort of assurances for larger
more
complicated projects. Actually even for smaller ones it makes it
very very difficult to ensure build stability
[jira] Updated: (GERONIMO-2694) STATUS file sent out as the Geronimo Weekly Status email needs updating
[ https://issues.apache.org/jira/browse/GERONIMO-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2694: --- Attachment: G2694-server-trunk.patch STATUS file sent out as the Geronimo Weekly Status email needs updating --- Key: GERONIMO-2694 URL: https://issues.apache.org/jira/browse/GERONIMO-2694 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: documentation Affects Versions: 1.2, 2.0-M2 Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 2.0-M2 Attachments: G2694-server-trunk.patch The geronimo/server/trunk/STATUS file needs to be updated to mention trunk is now 2.0, where the 1.2 branch is located and the fact that 1.2-Beta and 2.0-M1 were released. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2694) STATUS file sent out as the Geronimo Weekly Status email needs updating
[ https://issues.apache.org/jira/browse/GERONIMO-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2694: --- Patch Info: [Patch Available] Assignee: (was: Donald Woods) Updated to match current state of trunk for 2.0 and branches for 1.2, along with releases on 12/22. STATUS file sent out as the Geronimo Weekly Status email needs updating --- Key: GERONIMO-2694 URL: https://issues.apache.org/jira/browse/GERONIMO-2694 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: documentation Affects Versions: 1.2, 2.0-M2 Reporter: Donald Woods Priority: Trivial Fix For: 2.0-M2 Attachments: G2694-server-trunk.patch The geronimo/server/trunk/STATUS file needs to be updated to mention trunk is now 2.0, where the 1.2 branch is located and the fact that 1.2-Beta and 2.0-M1 were released. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Axis Implementation of XML DOM
Have you opened a bug report in the AXIS v1.x JIRA?
https://issues.apache.org/jira/browse/AXIS
-Donald
Phani Madgula wrote:
Hi
There is a problem in Axis implementation of Comment.getNodeType(). I
have the following code that recreates the issue.
*
import
* javax.xml.namespace.QName;*
**import* javax.xml.soap.Node ;*
**import* org.apache.axis.message.SOAPBodyElement;*
**import * org.w3c.dom.Comment;*
**public* *class* AxisXMLCommentTest {*
**public* *static* *void * main(String args[]) {*
*SOAPBodyElement sb = *new* SOAPBodyElement(* new*
QName(http://www.phanibalaji.com,test;))*;
* Comment c = sb.getOwnerDocument().createComment(TEST);*
*sb.appendChild(c);*
** if* (c.getNodeType() != Node./COMMENT_NODE/) {*
*System./ err/.println(Node is of diffe*rent type*); *
*} *else* {*
*System./err/.println(Success); *
* }
}
}
I am getting the condition *if* (c.getNodeType() != Node./COMMENT_NODE/)
as true. But, it must be false.
Can anybody comment?
Regards
Phani
smime.p7s
Description: S/MIME Cryptographic Signature
[result] Release geronimo-ejb_3.0_spec
Vote passes with 6 +1s (5 binding) and no other votes. -David On Dec 28, 2006, at 1:29 PM, David Blevins wrote: Fixed, verified to be compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-ejb_3.0_spec/ Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-ejb_3.0_spec/1.0/ I hereby propose we release this branch and it's binaries as final. Here's my +1 -David
[jira] Updated: (GERONIMO-2670) Update geronimo plugin repository version
[ https://issues.apache.org/jira/browse/GERONIMO-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated GERONIMO-2670: --- Affects Version/s: 2.0 Fix Version/s: 2.0 Update geronimo plugin repository version - Key: GERONIMO-2670 URL: https://issues.apache.org/jira/browse/GERONIMO-2670 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M1, 2.0 Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 2.0-M1, 2.0 Update the geronimo plugin repository version number in geronimo-plugin.xml files. Also update assemblies to point at new repository list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2650) JSP 2.1 error in Jetty/Tomcat
[
https://issues.apache.org/jira/browse/GERONIMO-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462286
]
Paul McMahan commented on GERONIMO-2650:
I think the problem with deferred assignment in EL might now be fixed in
tomcat. See
http://svn.apache.org/viewvc?view=revrevision=492639
JSP 2.1 error in Jetty/Tomcat
-
Key: GERONIMO-2650
URL: https://issues.apache.org/jira/browse/GERONIMO-2650
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: web
Affects Versions: 2.0-M1
Reporter: Krishnakumar B
Assigned To: Joe Bohn
Attachments: SampleJSP.war
Deploying a web application with JSP 2.1 features throws error in Jetty and
Tomcat
On Tomcat 6:
---
org.apache.jasper.JasperException: /SampleJSP.jsp(12,35) #{..} is not allowed
in template text
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
org.apache.jasper.compiler.ErrorDispatcher.dispatch
(ErrorDispatcher.java:406)
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:101)
org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:710)
org.apache.jasper.compiler.Node$ELExpression.accept (Node.java:935)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392)
org.apache.jasper.compiler.Node$Root.accept (Node.java:489)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
org.apache.jasper.compiler.Validator.validate(Validator.java:1679)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:178)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:306)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:273)
org.apache.jasper.JspCompilationContext.compile
(JspCompilationContext.java:566)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:314)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service (JspServlet.java:266)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
On Jetty 6.0:
org.apache.jasper.JasperException: /SampleJSP.jsp(12,35) #{..} is not allowed
in template text
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch
(ErrorDispatcher.java:406)
at
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:101)
at
org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:710)
at org.apache.jasper.compiler.Node$ELExpression.accept (Node.java:935)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:489)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at org.apache.jasper.compiler.Validator.validate(Validator.java:1679)
at org.apache.jasper.compiler.Compiler.generateJava (Compiler.java:178)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:306)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java :273)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:566)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:314)
at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:320)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :459)
at
org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.apache.geronimo.jetty6.JettyServletHandler.doHandle
(JettyServletHandler.java:55)
at
org.apache.geronimo.jetty6.JettyServletHandler$ActualJettyServletHandler.handle(JettyServletHandler.java:62)
at org.apache.geronimo.jetty6.JettyServletHandler$NoOpChainedHandler.handle
(JettyServletHandler.java:70)
at
org.apache.geronimo.jetty6.JettyServletHandler.handle(JettyServletHandler.java:47)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle
(ThreadClassloaderHandler.java:46)
at
Re: svn commit: r492105 - in /geronimo/server: branches/1.1/applications/console-standard/src/webapp/WEB-INF/view/repository/ branches/1.2/applications/console/geronimo-console-standard/src/main/webap
Vamsi, Shouldn't the localFile.split in the if below use / for *nix instead of \\? If so, then it needs to be corrected in each of the jsps that were changed. Joe [EMAIL PROTECTED] wrote: +// Split the path +var pathParts = localFile.split(\\); // Assuming windows file delim +if(localFile.indexOf(/) 0) // May be *nix delim +pathParts = localFile.split(\\);
Re: svn commit: r492105 - in /geronimo/server: branches/1.1/applications/console-standard/src/webapp/WEB-INF/view/repository/ branches/1.2/applications/console/geronimo-console-standard/src/main/webap
Joe, You are right. Thanks for pointing this out. I have tested the javascript separately before merging and testing it in console jsps. I missed this during the reorg. Will fix it right away. Vamsi On 1/5/07, Joe Bohn [EMAIL PROTECTED] wrote: Vamsi, Shouldn't the localFile.split in the if below use / for *nix instead of \\? If so, then it needs to be corrected in each of the jsps that were changed. Joe [EMAIL PROTECTED] wrote: +// Split the path +var pathParts = localFile.split(\\); // Assuming windows file delim +if(localFile.indexOf(/) 0) // May be *nix delim +pathParts = localFile.split(\\);
Re: Annotation processing
Hi David, your definitive list of JEE5 annotations is wonderful--I've been looking all over the place trying to locate the authoritative source. Where/how did you find them ?? Tim David Blevins wrote: On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote: Hi David, thanks for kicking off this discussion and I agree with most of your steps below. However, since it seems that annotations are now pervasive in many of the JSR specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably even more that I personally haven't uncovered) it seems like a concise set of responsibilities for all these annotation-specific JSRs might mitigate some confusion and hopefully prevent overlap and/or conflicts (i.e., who is going to do what). So for example, I'm responsible for the Geronimo JEE5 Deployment JSR (88) and I'm making these three assumptions below: 1 -- The current Geronimo JSR-88 implementation will be enhanced (by me) to provide a metadata-complete XML deployment descriptor, which is essentially what you've described below in steps 1-3. 2 -- The work associated with assumption #1 should encompass as many of the impacted JSRs as possible on the Geronimo side from a deployment perspective to minimize the number of folks making similar changes to the Geronimo builders/deployers. Thus, these JSRs should be encompassed by the JSR-88 implementation for Geronimo: -- JSR 77 (JEE5 management--this JSR in particular has already been mentioned as a candidate by Paul and Chris and I agree with them) -- JSR 88(Deployment) -- JSR 175 (Java annotations) -- JSR 181(Web Services metadata) -- JSR 250 (Common annotations) 3 -- Your step number 4 below (add objects to inject resources) feels like a duplicate of your step 3 (deploy from the modified xml descriptor...) but again will/should be implemented under the auspices of JSR-88. So, if that seems reasonable then I would still have a couple questions: 1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a separate and distinct deployment implementation for annotations in OpenEJB ?? I'm guessing yes based on the OPENEJB-216 JIRA and all its subtasks but just would again like some validation so as to better understand the implications if any from a Geronimo responsibility perspective. 2 -- Are there any other JSRs impacted by annotations for JEE5 compliance ?? Well, that's certainly an interesting idea. There are 149 annotations in all of Java EE 5 [1] and only 10 of them are generic JSR 250 annotations -- and most specs don't use those. Are you sure consolidating all of them into one task is a good idea? You'd be looking at months of work just to catch up to where most projects already are. If this is truly just about getting meta-data complete descriptors, there's really no work for ejbs anyway as there'll be a metadata-complete ejb-jar.xml in the GBeans we produce from deployment which is the way the current integration satisfies the JSR-88 requirement. Thoughts? -David [1] Made a list for you http://cwiki.apache.org/GMOxDEV/java-ee-5-annotations.html -- Thanks, Tim McConnell
[jira] Created: (SM-802) Refactor the Auditor MBean interface to avoid method overloading (which cause problems with JMX)
Refactor the Auditor MBean interface to avoid method overloading (which cause problems with JMX) Key: SM-802 URL: https://issues.apache.org/activemq/browse/SM-802 Project: ServiceMix Issue Type: Bug Components: servicemix-audit Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-803) Deployment events for a more pluggable hot deployer
Deployment events for a more pluggable hot deployer --- Key: SM-803 URL: https://issues.apache.org/activemq/browse/SM-803 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1747) HTTP-methods checks
[
https://issues.apache.org/jira/browse/GERONIMO-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462317
]
Christopher M. Cardona commented on GERONIMO-1747:
--
Hi David,
I tried deploying Apache Slide webapp with security constraint set to enable
authentication on 2.0-M1 but I got the following error:
{code:xml}
...
Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [err
or: cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not match patter
n for http-methodType in namespace http://java.sun.com/xml/ns/javaee, error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not match pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
Descriptor: web-app xsi:schemaLocation=http://java.sun.com/xml/ns/javaeehttp:/
/java.sun.com/xml/ns/javaee/web-app_2_5.xsd version=2.5 xmlns:xsi=http://www
.w3.org/2001/XMLSchema-instance xmlns=http://java.sun.com/xml/ns/javaee;
display-nameJakarta Slide WebDAV Server/display-name
!--Definition and configuration of servlet filters--
filter
filter-namewebdavlog/filter-name
filter-classorg.apache.slide.webdav.filter.LogFilter/filter-class
init-param
descriptionDefines the format of a log line.
The following placeholders are available:
%T=thread-name,
%t=date-time,
%P=principal-name,
%m=method-name,
%s=status-code,
%l=default-status-text,
%L=detailed-status-text,
%i=elapsed-time,
%p=relative-request-uri,
%u=request-uri.
%x=request-content-length.
%A=header User-Agent./description
param-namelogFormat/param-name
param-value%T, %t, %P, %m, %s %l, %i, %p/param-value
/init-param
init-param
descriptionIf true, output is directed to STDOUT./description
param-nameoutputToConsole/param-name
param-valuetrue/param-value
/init-param
init-param
descriptionIf true, output is directed to the servlet's log file./descr
iption
param-nameoutputToServletLog/param-name
param-valuefalse/param-value
/init-param
!--init-param
param-nameoutputToFile/param-name
param-valuec:\webdav.log.xml/param-value
descriptionIf present, output is directed to the specified file./
description
/init-param--
/filter
!--If you're operating Slide with an SSL connection and with authentication e
nabled
and you notice that Internet Explorer is unable to open some file types
you may
want to uncomment the following filter and its associated filter-mappin
g. See the
javadoc for the NoCacheFilter class for a description of the problem an
d discussion
of the ramifications.--
!--filter
filter-namenocache/filter-name
filter-classorg.apache.slide.webdav.filter.NoCacheFilter/filter-class
/filter--
filter-mapping
filter-namewebdavlog/filter-name
servlet-namewebdav/servlet-name
/filter-mapping
!--filter-mapping
filter-namenocache/filter-name
servlet-namewebdav/servlet-name
/filter-mapping--
!--Definition and configuration of Slide's WebDAV servlet.--
servlet
display-nameSlide DAV Server/display-name
servlet-namewebdav/servlet-name
servlet-classorg.apache.slide.webdav.WebdavServlet/servlet-class
init-param
descriptionPath to the domain configuration file, relative to the path o
f the
web application.
The default is '/Domain.xml'./description
param-namedomain/param-name
param-value/Domain.xml/param-value
/init-param
init-param
descriptionName of the Slide namespace that should be accessed by this s
ervlet.
If this parameter is provided, make sure the corresponding names
pace
is defined in the domain configuration file. Otherwise, the defa
ult
namespace will be used, if one exists./description
param-namenamespace/param-name
param-valueslide/param-value
/init-param
init-param
descriptionScope of the Slide namespace that should be exposed by this s
ervlet.
For example, if you want to expose only the /files collection v
ia
WebDAV, set this parameter to '/files'. In that case, any URLs
of the
form '/context-path/servlet-path/*' will be mapped to '/files/*
'
in the Slide namespace.
The default value is an empty string./description
param-namescope/param-name
param-value/
/init-param
init-param
descriptionThis init-parameter determines the depth limit for PROPFIND a
nd other
methods, to avoid performance hits on the server
Re: svn commit: r492633 - /geronimo/specs/trunk/pom.xml
Why were these deleted? This is soo retarded IMO... If we are going to be using the specs/trunk as a some transient place for specs to live, then it should be completely removed, and each spec should get its own trunk/branches/tags and be treated like a normal project. Moving stuff in and out of trunk on some ethereal whim is a horrible plan. --jason On Jan 4, 2007, at 8:51 AM, [EMAIL PROTECTED] wrote: Author: adc Date: Thu Jan 4 08:51:02 2007 New Revision: 492633 URL: http://svn.apache.org/viewvc?view=revrev=492633 Log: GERONIMO-2692 Removed missing modules Modified: geronimo/specs/trunk/pom.xml Modified: geronimo/specs/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/pom.xml? view=diffrev=492633r1=492632r2=492633 == --- geronimo/specs/trunk/pom.xml (original) +++ geronimo/specs/trunk/pom.xml Thu Jan 4 08:51:02 2007 @@ -120,13 +120,10 @@ /activation modules -modulegeronimo-annotation_1.0_spec/module modulegeronimo-ejb_3.0_spec/module modulegeronimo-el_1.0_spec/module -modulegeronimo-interceptor_3.0_spec/module modulegeronimo-j2ee-management_1.1_spec/module modulegeronimo-jacc_1.1_spec/module -modulegeronimo-jpa_3.0_spec/module modulegeronimo-jsp_2.1_spec/module modulegeronimo-ws-metadata_2.0_spec/module /modules
[jira] Resolved: (SM-803) Deployment events for a more pluggable hot deployer
[ https://issues.apache.org/activemq/browse/SM-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-803. Resolution: Fixed Author: gnodet Date: Thu Jan 4 12:57:08 2007 New Revision: 492735 URL: http://svn.apache.org/viewvc?view=revrev=492735 Log: SM-803: Deployment events for a more pluggable hot deployer Added: incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/event/DeploymentAdapter.java (with props) incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/event/DeploymentEvent.java (with props) incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/event/DeploymentListener.java (with props) Modified: incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/container/JBIContainer.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/AutoDeploymentService.java Deployment events for a more pluggable hot deployer --- Key: SM-803 URL: https://issues.apache.org/activemq/browse/SM-803 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-802) Refactor the Auditor MBean interface to avoid method overloading (which cause problems with JMX)
[ https://issues.apache.org/activemq/browse/SM-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-802. Resolution: Fixed Author: gnodet Date: Thu Jan 4 13:00:24 2007 New Revision: 492738 URL: http://svn.apache.org/viewvc?view=revrev=492738 Log: SM-802: Refactor the Auditor MBean interface to avoid method overloading (which cause problems with JMX) Add a Start / Stop button on the console for the Auditor service Added: incubator/servicemix/trunk/web/servicemix-web-console/src/main/java/org/apache/servicemix/web/controller/ServiceLifeCycle.java (with props) Modified: incubator/servicemix/trunk/core/servicemix-audit/src/main/java/org/apache/servicemix/jbi/audit/AbstractAuditor.java incubator/servicemix/trunk/core/servicemix-audit/src/main/java/org/apache/servicemix/jbi/audit/AuditorMBean.java incubator/servicemix/trunk/core/servicemix-audit/src/main/java/org/apache/servicemix/jbi/audit/jdbc/JdbcAuditor.java incubator/servicemix/trunk/core/servicemix-audit/src/main/java/org/apache/servicemix/jbi/audit/lucene/LuceneAuditor.java incubator/servicemix/trunk/core/servicemix-audit/src/test/java/org/apache/servicemix/jbi/audit/jdbc/JdbcAuditorTest.java incubator/servicemix/trunk/distributions/apache-servicemix-web/pom.xml incubator/servicemix/trunk/distributions/apache-servicemix-web/src/main/java/org/apache/servicemix/web/http/HttpComponentListener.java incubator/servicemix/trunk/distributions/apache-servicemix-web/src/main/webapp/WEB-INF/servicemix.xml incubator/servicemix/trunk/web/servicemix-web-console/src/main/java/org/apache/servicemix/web/Auditor.java incubator/servicemix/trunk/web/servicemix-web-console/src/main/webapp/WEB-INF/dispatcher-servlet.xml incubator/servicemix/trunk/web/servicemix-web-console/src/main/webapp/WEB-INF/web.xml incubator/servicemix/trunk/web/servicemix-web-console/src/main/webapp/audit.jsp Refactor the Auditor MBean interface to avoid method overloading (which cause problems with JMX) Key: SM-802 URL: https://issues.apache.org/activemq/browse/SM-802 Project: ServiceMix Issue Type: Bug Components: servicemix-audit Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1747) HTTP-methods checks
[ https://issues.apache.org/jira/browse/GERONIMO-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher M. Cardona updated GERONIMO-1747: - Attachment: slide.war HTTP-methods checks --- Key: GERONIMO-1747 URL: https://issues.apache.org/jira/browse/GERONIMO-1747 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.0 Environment: Windows 2003, java 1.4 Reporter: Ilya Platonov Fix For: 1.1.2 Attachments: slide.war, web.xml I'm tring to run jakarta-slide web-application on geronimo application server. Slide provides WebDAV support. When security constrain is not set, everything works fine exept some minor issues but when I put some security constraints for servlets I got following error in server.log. 15:43:58,132 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Invalid HTTPMethodSpec at javax.security.jacc.HTTPMethodSpec.init(HTTPMethodSpec.java:114) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:84) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:428) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:262) at org.apache.geronimo.tomcat.valve.PolicyContextValve.invoke(PolicyContextValve.java:50) at org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) at org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) at org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) When I looked through Geronimo source code I found that GET, POST, PUT, DELETE, HEAD, OPTIONS and TRACE http-methods hardcoded into HTTPMethodSpec class and if you tring to use another method it throws this exception. Problem is that WebDAV specification extends standard HTTP-methods, for example it uses MKCOL and LOCK methods so jakarta-slide just not working. Is there any workaround for this bug or geronimo is just not able to handle any HTTP protocol extensions??? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Help needed on http methods and regular expressions
Chris Cardona has been trying to test the jacc 1.1 extended http-
method support by deploying slide (GERONIMO-1747) and I don't know
enough about regular expressions to see where the problem is.
The http 1.1 spec says:
(5.1.1) extension-method = token
(2.2)
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
I think this means a hyphen is allowed in an extension-method.
The web-app 2.5 schema says:
xsd:simpleType name=http-methodType
xsd:annotation
xsd:documentation
A HTTP method type as defined in HTTP 1.1 section 2.2.
/xsd:documentation
/xsd:annotation
xsd:restriction base=xsd:token
xsd:pattern value=[\p{L}-[\p{Cc}\p{Z}]]+/
/xsd:restriction
/xsd:simpleType
I have roughly no clue what that means.
Xmlbeans is complaining:
cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not match
patter
n for http-methodType in namespace http://java.sun.com/xml/ns/javaee,
error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not match
pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
I see 3 possiblilites:
1. I'm wrong and http 1.1 spec does not allow hyphens in extension
methods
2. sun is wrong and the regexp in http-methodType means something
other than the definition in the http 1.1 spec
3. xmlbeans is wrong and is not interpreting the regexp in the schema
correctly.
Anyone have a clue?
Help!
thanks
david jencks
[jira] Closed: (GERONIMO-2670) Update geronimo plugin repository version
[ https://issues.apache.org/jira/browse/GERONIMO-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2670. -- Resolution: Fixed Update geronimo plugin repository version - Key: GERONIMO-2670 URL: https://issues.apache.org/jira/browse/GERONIMO-2670 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M1, 2.0 Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 2.0-M1, 2.0 Update the geronimo plugin repository version number in geronimo-plugin.xml files. Also update assemblies to point at new repository list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Annotation processing
On Jan 4, 2007, at 12:22 PM, Tim McConnell wrote: Hi David, your definitive list of JEE5 annotations is wonderful-- I've been looking all over the place trying to locate the authoritative source. Where/how did you find them ?? Grepped all the spec jars and compared that against the TCK for accuracy and to fill in any missing. -David David Blevins wrote: On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote: Hi David, thanks for kicking off this discussion and I agree with most of your steps below. However, since it seems that annotations are now pervasive in many of the JSR specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably even more that I personally haven't uncovered) it seems like a concise set of responsibilities for all these annotation-specific JSRs might mitigate some confusion and hopefully prevent overlap and/or conflicts (i.e., who is going to do what). So for example, I'm responsible for the Geronimo JEE5 Deployment JSR (88) and I'm making these three assumptions below: 1 -- The current Geronimo JSR-88 implementation will be enhanced (by me) to provide a metadata-complete XML deployment descriptor, which is essentially what you've described below in steps 1-3. 2 -- The work associated with assumption #1 should encompass as many of the impacted JSRs as possible on the Geronimo side from a deployment perspective to minimize the number of folks making similar changes to the Geronimo builders/deployers. Thus, these JSRs should be encompassed by the JSR-88 implementation for Geronimo: -- JSR 77 (JEE5 management--this JSR in particular has already been mentioned as a candidate by Paul and Chris and I agree with them) -- JSR 88(Deployment) -- JSR 175 (Java annotations) -- JSR 181(Web Services metadata) -- JSR 250 (Common annotations) 3 -- Your step number 4 below (add objects to inject resources) feels like a duplicate of your step 3 (deploy from the modified xml descriptor...) but again will/should be implemented under the auspices of JSR-88. So, if that seems reasonable then I would still have a couple questions: 1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a separate and distinct deployment implementation for annotations in OpenEJB ?? I'm guessing yes based on the OPENEJB-216 JIRA and all its subtasks but just would again like some validation so as to better understand the implications if any from a Geronimo responsibility perspective. 2 -- Are there any other JSRs impacted by annotations for JEE5 compliance ?? Well, that's certainly an interesting idea. There are 149 annotations in all of Java EE 5 [1] and only 10 of them are generic JSR 250 annotations -- and most specs don't use those. Are you sure consolidating all of them into one task is a good idea? You'd be looking at months of work just to catch up to where most projects already are. If this is truly just about getting meta-data complete descriptors, there's really no work for ejbs anyway as there'll be a metadata-complete ejb-jar.xml in the GBeans we produce from deployment which is the way the current integration satisfies the JSR-88 requirement. Thoughts? -David [1] Made a list for you http://cwiki.apache.org/GMOxDEV/java-ee-5- annotations.html -- Thanks, Tim McConnell
Re: Help needed on http methods and regular expressions
On Jan 4, 2007, at 1:27 PM, David Jencks wrote:
Chris Cardona has been trying to test the jacc 1.1 extended http-
method support by deploying slide (GERONIMO-1747) and I don't know
enough about regular expressions to see where the problem is.
The http 1.1 spec says:
(5.1.1) extension-method = token
(2.2)
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
I think this means a hyphen is allowed in an extension-method.
It means hypen is not allowed. I.e. ascii 0-127 is allowed except
0-31,32,34,40,41,44,47,58,59,60,61,62,63,64,91,92,93,123,125
-David
The web-app 2.5 schema says:
xsd:simpleType name=http-methodType
xsd:annotation
xsd:documentation
A HTTP method type as defined in HTTP 1.1 section 2.2.
/xsd:documentation
/xsd:annotation
xsd:restriction base=xsd:token
xsd:pattern value=[\p{L}-[\p{Cc}\p{Z}]]+/
/xsd:restriction
/xsd:simpleType
I have roughly no clue what that means.
Xmlbeans is complaining:
cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not
match patter
n for http-methodType in namespace http://java.sun.com/xml/ns/
javaee, error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not match
pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
I see 3 possiblilites:
1. I'm wrong and http 1.1 spec does not allow hyphens in extension
methods
2. sun is wrong and the regexp in http-methodType means something
other than the definition in the http 1.1 spec
3. xmlbeans is wrong and is not interpreting the regexp in the
schema correctly.
Anyone have a clue?
Help!
thanks
david jencks
[jira] Created: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
Requests using Non-secure HTTP connections cannot access unsecured web resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource collection,
and an unsecured web resource collection. The secured web collection is by
default everything that matches the / pattern. In the unsecured web
collection, we use specific URL patterns so that certain resources can be
accessed prior to login. Note that there is no security role defined for the
unsecured web resource collection, as these resources should be available to
every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is null.
In the case of a null principal, the code seems to base its authorization on
whether or not the request is secure! This seems very strange to me, as it
should be able to accept normal, unauthenticated, HTTP connections to unsecure
web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462359
]
Jeff Genender commented on GERONIMO-2695:
-
Please post your geronimo-web.xml. You should have done a role/principal
mapping which would effectively give you a default principal if
unauthenticated. In other words, the principal would never be null.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462360
]
Aman Nanner commented on GERONIMO-2695:
---
Hi,
My web module is contained with an application module, so I defined an empty
default principal as follows:
security:security
security:default-principal
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal
name= /
/security:default-principal
security:role-mappings
security:role role-name=MXSYSTEM
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal
name=mxsystem designated-run-as=true /
/security:role
/security:role-mappings
/security:security
I did this as I did not want my unsecured web resources to run under any
principal (i.e. I wanted them to run as unauthenticated).
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462362
]
Jeff Genender commented on GERONIMO-2695:
-
Ok...can you throw together a small war evincing this problem and post it to
the JIRA and we should be able to debug and fix it. Thanks.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
Re: Annotation processing
On Jan 4, 2007, at 3:13 PM, Tim McConnell wrote: Now that's very interesting, I've been using the Annotation Type Hierarchy from http://java.sun.com/javaee/5/docs/api/overview- tree.html but your list appears to be more accurate. Seems like they're missing these two: javax.xml.ws.addressing.Action javax.xml.ws.addressing.FaultAction Strange -David David Blevins wrote: On Jan 4, 2007, at 12:22 PM, Tim McConnell wrote: Hi David, your definitive list of JEE5 annotations is wonderful-- I've been looking all over the place trying to locate the authoritative source. Where/how did you find them ?? Grepped all the spec jars and compared that against the TCK for accuracy and to fill in any missing. -David David Blevins wrote: On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote: Hi David, thanks for kicking off this discussion and I agree with most of your steps below. However, since it seems that annotations are now pervasive in many of the JSR specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably even more that I personally haven't uncovered) it seems like a concise set of responsibilities for all these annotation-specific JSRs might mitigate some confusion and hopefully prevent overlap and/or conflicts (i.e., who is going to do what). So for example, I'm responsible for the Geronimo JEE5 Deployment JSR (88) and I'm making these three assumptions below: 1 -- The current Geronimo JSR-88 implementation will be enhanced (by me) to provide a metadata-complete XML deployment descriptor, which is essentially what you've described below in steps 1-3. 2 -- The work associated with assumption #1 should encompass as many of the impacted JSRs as possible on the Geronimo side from a deployment perspective to minimize the number of folks making similar changes to the Geronimo builders/ deployers. Thus, these JSRs should be encompassed by the JSR-88 implementation for Geronimo: -- JSR 77 (JEE5 management--this JSR in particular has already been mentioned as a candidate by Paul and Chris and I agree with them) -- JSR 88(Deployment) -- JSR 175 (Java annotations) -- JSR 181(Web Services metadata) -- JSR 250 (Common annotations) 3 -- Your step number 4 below (add objects to inject resources) feels like a duplicate of your step 3 (deploy from the modified xml descriptor...) but again will/should be implemented under the auspices of JSR-88. So, if that seems reasonable then I would still have a couple questions: 1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a separate and distinct deployment implementation for annotations in OpenEJB ?? I'm guessing yes based on the OPENEJB-216 JIRA and all its subtasks but just would again like some validation so as to better understand the implications if any from a Geronimo responsibility perspective. 2 -- Are there any other JSRs impacted by annotations for JEE5 compliance ?? Well, that's certainly an interesting idea. There are 149 annotations in all of Java EE 5 [1] and only 10 of them are generic JSR 250 annotations -- and most specs don't use those. Are you sure consolidating all of them into one task is a good idea? You'd be looking at months of work just to catch up to where most projects already are. If this is truly just about getting meta-data complete descriptors, there's really no work for ejbs anyway as there'll be a metadata-complete ejb-jar.xml in the GBeans we produce from deployment which is the way the current integration satisfies the JSR-88 requirement. Thoughts? -David [1] Made a list for you http://cwiki.apache.org/GMOxDEV/java- ee-5-annotations.html --Thanks, Tim McConnell -- Thanks, Tim McConnell
[jira] Updated: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Nanner updated GERONIMO-2695:
--
Attachment: test.war
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462368
]
Aman Nanner commented on GERONIMO-2695:
---
I've attached a very simple WAR that demonstrates the issue. You'll be able to
access the index.html via HTTPS, but not HTTP.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462371
]
Jeff Genender commented on GERONIMO-2695:
-
Also...I think I see a possible issue in your web.xml.
Looking at your web.xml it appears that your security constraints are
overlapping. This can cause problems. You can either make it more specific as
to what is secure and what is not, or you can try changing the order of
precedence (which is a shot in the dark).
Try swapping the order of how they appear (make the unauthenticated come
second). Right now your authenticated /* overrides the unauthenticated
completely, and thus you really have no such thing as an unauthenticated
access. Try making that one come first, then the unauthenticated becomes the
exception.
Here is a great article on this issue and provides some good background to the
problem you may be encountering:
http://www2.sys-con.com/ITSG/virtualcd/Java/archives/0704/mccay/index.html
In particular, and which applies to my statement above:
Tomcat's implementation of the constraint-matching algorithm requires that the
constraints appear within the deployment descriptor in the order of precedence
required for the different types of URL patterns
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462372
]
Aman Nanner commented on GERONIMO-2695:
---
Actually, I can omit the secured resource collection completely and I still
experience the same issue. The test WAR that I included only has an unsecured
resource collection and thus demonstrates this.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[ https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462374 ] Jeff Genender commented on GERONIMO-2695: - Actually, I can omit the secured resource collection completely and I still experience the same issue. The test WAR that I included only has an unsecured resource collection and thus demonstrates this. Yep and this is my point. I believe your web.xml is wrong. Here is the changes to the web.xml you put in your example and it works absolutely fine for me: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/j2ee; version=2.4 display-nameTest Web Application/display-name security-constraint display-nameSecure Constraint/display-name web-resource-collection web-resource-nameSecure Resource Collection/web-resource-name url-pattern//url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameMXSYSTEM/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint display-nameUnsecure Constraint/display-name web-resource-collection web-resource-nameUnsecure Resource Collection/web-resource-name url-pattern/index.html/url-pattern url-pattern/login.html/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-name*/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config security-role descriptionMaintenix Application System Role/description role-nameMXSYSTEM/role-name /security-role /web-app Requests using Non-secure HTTP connections cannot access unsecured web resources Key: GERONIMO-2695 URL: https://issues.apache.org/jira/browse/GERONIMO-2695 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, Tomcat, web Affects Versions: 1.1.1 Environment: Geronimo running on Windows XP Reporter: Aman Nanner Attachments: test.war Consider the following fragment of my web.xml in my WAR: security-constraint display-nameUnsecure Constraint/display-name web-resource-collection web-resource-nameUnsecure Resource Collection/web-resource-name url-pattern/common/error/*/url-pattern url-pattern/common/includes/*/url-pattern url-pattern/common/Message.jsp/url-pattern url-pattern/common/resources/*/url-pattern url-pattern/common/security/login.jsp/url-pattern url-pattern/common/security/logout.jsp/url-pattern url-pattern/servlet/branding/*/url-pattern url-pattern/servlet/image/*/url-pattern url-pattern/servlet/login/*/url-pattern url-pattern/servlet/definecookie/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint display-nameSecure Constraint/display-name web-resource-collection web-resource-nameSecure Resource Collection/web-resource-name url-pattern//url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameMXSYSTEM/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/common/security/PreLogin.jsp/form-login-page form-error-page/common/security/error.jsp/form-error-page /form-login-config /login-config security-role descriptionApplication System Role/description role-nameMXSYSTEM/role-name /security-role There are two sets of web resources defined: a secured web
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462375
]
Jeff Genender commented on GERONIMO-2695:
-
Oh to be more poignant...I can make your test.war work by adding the following
to your constraint:
auth-constraint
role-name*/role-name
/auth-constraint
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462376
]
Aman Nanner commented on GERONIMO-2695:
---
Hmm...I'll test this out in a bit.
I was under the impression that
auth-constraint
role-name*/role-name
/auth-constraint
---
implies that all AUTHENTICATED users of any role are allowed to access the
given resource. I know that failure to specify an authorization constraint
implies unrestricted access for JBoss, WebLogic, and Jetty. Perhaps this is an
area of subjective interpretation of the Servlet 2.4 spec.
In this case, is it possible to modify the interpretation such that the absence
of an auth-constraint tag implies the above XML fragment, such that these web
applications can port over to Geronimo more easily?
Thanks
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462386
]
Jeff Genender commented on GERONIMO-2695:
-
We let Tomcat do the deployment so this is a Tomcat thing. Are you saying this
works in JBoss? I understand they use the Tomcat deployer too. If you are
saying that the war file you attached works fine in JBoss but not in Geronimo,
then we need to dig deeper because that part of the deployment is being
implemented purely by Tomcat on both platforms and they should operate the
same. If not, then you have likely found a bug, and we need to investigate the
TomcatGeronimoRealm a bit more deeply.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
Re: Help needed on http methods and regular expressions
On Jan 4, 2007, at 6:12 PM, David Blevins wrote:
On Jan 4, 2007, at 1:27 PM, David Jencks wrote:
Chris Cardona has been trying to test the jacc 1.1 extended http-
method support by deploying slide (GERONIMO-1747) and I don't know
enough about regular expressions to see where the problem is.
The http 1.1 spec says:
(5.1.1) extension-method = token
(2.2)
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
I think this means a hyphen is allowed in an extension-method.
It means hypen is not allowed. I.e. ascii 0-127 is allowed except
0-31,32,34,40,41,44,47,58,59,60,61,62,63,64,91,92,93,123,125
I'm kinda confused here. According to http://www.asciitable.com/
hyphen is 45 which is not in your list of exclusions, not a control
character, and I might be blind but I don't see it in the http spec
list of separators. Why exactly is hyphen not allowed?
thanks
david jencks
-David
The web-app 2.5 schema says:
xsd:simpleType name=http-methodType
xsd:annotation
xsd:documentation
A HTTP method type as defined in HTTP 1.1 section 2.2.
/xsd:documentation
/xsd:annotation
xsd:restriction base=xsd:token
xsd:pattern value=[\p{L}-[\p{Cc}\p{Z}]]+/
/xsd:restriction
/xsd:simpleType
I have roughly no clue what that means.
Xmlbeans is complaining:
cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not
match patter
n for http-methodType in namespace http://java.sun.com/xml/ns/
javaee, error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not
match pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
I see 3 possiblilites:
1. I'm wrong and http 1.1 spec does not allow hyphens in extension
methods
2. sun is wrong and the regexp in http-methodType means something
other than the definition in the http 1.1 spec
3. xmlbeans is wrong and is not interpreting the regexp in the
schema correctly.
Anyone have a clue?
Help!
thanks
david jencks
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462393
]
Jeff Genender commented on GERONIMO-2695:
-
Ok...this was pointed out to me that we do process the security
attributes...and thus I do believe this is a bug. I'll take a swipe at it.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
[jira] Assigned: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Genender reassigned GERONIMO-2695:
---
Assignee: Jeff Genender
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Assigned To: Jeff Genender
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA,
Re: Annotation processing
Hi David, sorry if I wasn't sufficiently clear. I not suggesting that we redo anything that's already been done for annotations in the other projects (e.g., openejb, openjpa, cfx, axis, etc..). I'm really just suggesting that there is some amount of work remaining in Geronimo related to deployment and annotations (e.g., JSR-88, JSR-77, JSR-250, etc.) and since I've volunteered to be responsible for JSR-88, I thought it might be more efficient to have as many of these changes as possible done as part of the JSR-88 implementation. I believe this is a valid assumption for JSR-77. I'm not as certain about any of the other JSR's though. Thanks David Blevins wrote: On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote: Hi David, thanks for kicking off this discussion and I agree with most of your steps below. However, since it seems that annotations are now pervasive in many of the JSR specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably even more that I personally haven't uncovered) it seems like a concise set of responsibilities for all these annotation-specific JSRs might mitigate some confusion and hopefully prevent overlap and/or conflicts (i.e., who is going to do what). So for example, I'm responsible for the Geronimo JEE5 Deployment JSR (88) and I'm making these three assumptions below: 1 -- The current Geronimo JSR-88 implementation will be enhanced (by me) to provide a metadata-complete XML deployment descriptor, which is essentially what you've described below in steps 1-3. 2 -- The work associated with assumption #1 should encompass as many of the impacted JSRs as possible on the Geronimo side from a deployment perspective to minimize the number of folks making similar changes to the Geronimo builders/deployers. Thus, these JSRs should be encompassed by the JSR-88 implementation for Geronimo: -- JSR 77 (JEE5 management--this JSR in particular has already been mentioned as a candidate by Paul and Chris and I agree with them) -- JSR 88(Deployment) -- JSR 175 (Java annotations) -- JSR 181(Web Services metadata) -- JSR 250 (Common annotations) 3 -- Your step number 4 below (add objects to inject resources) feels like a duplicate of your step 3 (deploy from the modified xml descriptor...) but again will/should be implemented under the auspices of JSR-88. So, if that seems reasonable then I would still have a couple questions: 1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a separate and distinct deployment implementation for annotations in OpenEJB ?? I'm guessing yes based on the OPENEJB-216 JIRA and all its subtasks but just would again like some validation so as to better understand the implications if any from a Geronimo responsibility perspective. 2 -- Are there any other JSRs impacted by annotations for JEE5 compliance ?? Well, that's certainly an interesting idea. There are 149 annotations in all of Java EE 5 [1] and only 10 of them are generic JSR 250 annotations -- and most specs don't use those. Are you sure consolidating all of them into one task is a good idea? You'd be looking at months of work just to catch up to where most projects already are. If this is truly just about getting meta-data complete descriptors, there's really no work for ejbs anyway as there'll be a metadata-complete ejb-jar.xml in the GBeans we produce from deployment which is the way the current integration satisfies the JSR-88 requirement. Thoughts? -David [1] Made a list for you http://cwiki.apache.org/GMOxDEV/java-ee-5-annotations.html -- Thanks, Tim McConnell
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462394
]
Aman Nanner commented on GERONIMO-2695:
---
Yes, this does work on JBoss, and you are correct in your last comment that
Geronimo processes the security attributes. On each HTTP request to the
server, a call is made to TomcatGeronimoRealm.hasResourcePermission(...) to
check if the resource is authorized for the user. I'm pretty sure the issue
has to do with the code fragment that I pointed out originally.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Assigned To: Jeff Genender
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure
Re: Help needed on http methods and regular expressions
On Jan 4, 2007, at 7:35 PM, David Jencks wrote:
On Jan 4, 2007, at 6:12 PM, David Blevins wrote:
On Jan 4, 2007, at 1:27 PM, David Jencks wrote:
Chris Cardona has been trying to test the jacc 1.1 extended http-
method support by deploying slide (GERONIMO-1747) and I don't
know enough about regular expressions to see where the problem is.
The http 1.1 spec says:
(5.1.1) extension-method = token
(2.2)
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
I think this means a hyphen is allowed in an extension-method.
It means hypen is not allowed. I.e. ascii 0-127 is allowed except
0-31,32,34,40,41,44,47,58,59,60,61,62,63,64,91,92,93,123,125
I'm kinda confused here. According to http://www.asciitable.com/
hyphen is 45 which is not in your list of exclusions, not a control
character, and I might be blind but I don't see it in the http spec
list of separators. Why exactly is hyphen not allowed?
Whoop. My bad. Now I'm just as confused as you.
-David
thanks
david jencks
-David
The web-app 2.5 schema says:
xsd:simpleType name=http-methodType
xsd:annotation
xsd:documentation
A HTTP method type as defined in HTTP 1.1 section 2.2.
/xsd:documentation
/xsd:annotation
xsd:restriction base=xsd:token
xsd:pattern value=[\p{L}-[\p{Cc}\p{Z}]]+/
/xsd:restriction
/xsd:simpleType
I have roughly no clue what that means.
Xmlbeans is complaining:
cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not
match patter
n for http-methodType in namespace http://java.sun.com/xml/ns/
javaee, error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not
match pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
I see 3 possiblilites:
1. I'm wrong and http 1.1 spec does not allow hyphens in
extension methods
2. sun is wrong and the regexp in http-methodType means something
other than the definition in the http 1.1 spec
3. xmlbeans is wrong and is not interpreting the regexp in the
schema correctly.
Anyone have a clue?
Help!
thanks
david jencks
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462396
]
Jeff Genender commented on GERONIMO-2695:
-
On each HTTP request to the server, a call is made to
TomcatGeronimoRealm.hasResourcePermission(...) to check if the resource is
authorized for the user. I'm pretty sure the issue has to do with the code
fragment that I pointed out originally.
That wasn't my reference...since I indeed wrote that code. I was referring to
the deployment code, which really is the issue here. You pointed that out via
not needing the auth-constraint. That is a deployment problem, not a realm
issue.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Assigned To: Jeff Genender
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal,
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462401
]
Aman Nanner commented on GERONIMO-2695:
---
Ok, I see what you mean. I tried debugging with the * auth-constraint, and I
noticed that the TomcatGeronimoRealm.hasResourcePermission(...) method is no
longer called on that request to check for authorization.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Assigned To: Jeff Genender
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This
[jira] Assigned: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-2686: -- Assignee: David Jencks database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico Assigned To: David Jencks Priority: Critical Fix For: 1.2, 2.0-M2 From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The terminal shows the following error: ERROR [DatabasePoolPortlet] Unable to save connection pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:325) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:542) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) 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: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: jndi.gif jndiview2689.patch common.patch New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462421 ] Rakesh Midha commented on GERONIMO-2689: Attached is the common.patch and jndiview2689.patch which implements JNDI Viewer console view. The jndi.gif file shows how this view will look. This patch adds console-standard.JMXViewer entity in portlet registry and also adds all the required redirections and entries in web.xml. The approach is to use componentContext gbean attribute from each component to get the context for component and than show it in dojo tree. To load dojo tree nodes lazily, the StringTree instances are converted to JSON string, and setChildren is called to lazy loading of childrens on expension. It adds JNDIViewPortlet.java, which getJSONTrees() build the json tree using kernel getattribute method on component gbeans. To use the patches first apply common.patch which adds StringTree.java and TreeDocIcon.css and than apply jndiview2689.patch. The common patch is also used in JIRA 2690 and 2691. New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: common.patch New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: (was: common.patch) New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: navigation.gif New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Description: So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. was: So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. Patch Info: [Patch Available] Navigation.gif is for just showing purpose, the current patch doesn't put items in debug view but directly in main tree. Marking patch available. New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2690: --- Attachment: classloader.gif classloaderView2690.patch common.patch New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2690: --- Description: Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. was: Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. Patch Info: [Patch Available] New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462425 ] Rakesh Midha commented on GERONIMO-2690: Attached is the common.patch and classloaderview2690.patch which implements classloaderViewer console view. The classloader.gif file shows how this view will look. This view shows all the classloaders and its classes/interfaces in hierarchical fashion in which they are loaded. To facilitate locating of class of interest the tree view can be searched. Tha approach used to keep track of all the class loaders and its parent/childrens is by keeping a registry of classloaders. This is done by uusing ClassloaderRegistry class which keeps WeakReference of all the loaded class loaders. As we are using WeakReferences this registry does not hinder Garbage colection if the classloader is destroyed somewhere else. All the class loaders in Geronimo ie. ConfigurationClassLoader and MultiParentClassLoader are responsible for registering and unregistring of classloaders in registry. (if we forget to unregister, weak reference as well as destroy method takes care of GC). The classloader tree grows like anything, so we are using dojo tree nodes lazly loaded. To load dojo tree nodes lazily, the StringTree instances are converted to JSON string, and setChildren is called to lazy loading of childrens on expension. To use the patches first apply common.patch which adds StringTree.java and TreeDocIcon.css and than apply classloaderView2690.patch. The common patch is also used in JIRA 2689 and 2691. Few points which are worth noticing here : 1. The tree grows like anything and may take some time to intial loading ( for me it is taking 15 secs for full geronimo server for tomcat). 2. Classloader registry is introduced which some people may not like. 3. Please notice addClasses method in ClassLoaderViewPortlet.java, it does something which seem like illigal. It gets names of classes and interfaces from private Vector of Classloader class. This is the only way in which all the classes and interfaces names are available. I have tried this on Sun and IBM JDK and it works fine on it. Sometime later if these JDK's changes the name or type of variable classes in Classloader.java class this functaionality may not work. Thanks New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2691: --- Attachment: dependency.gif dependencyview2691.patch common.patch New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, dependency.gif, dependencyview2691.patch Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462428 ] Rakesh Midha commented on GERONIMO-2691: Attached is the common.patch and dependencyview2691.patch which implements dependencyViewer console view. The dependency.gif file shows how this view will look. This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched. The configuration provided in kernel is used to get dependencies. It is same approach as one used in config section of console, the main difference being, 1. Everything is shown in a dojo tree, which means it is hierarchical and easily traceable. 2. Config section used dependency manager and shows only serviceparents(), where as this view directly list the direct dependencies as well as serviceparents The tree can grow like anything, so we are using dojo tree nodes lazly loaded. To load dojo tree nodes lazily, the StringTree instances are converted to JSON string, and setChildren is called to lazy loading of childrens on expension. To use the patches first apply common.patch which adds StringTree.java and TreeDocIcon.css and than apply dependencyView2691.patch. The common patch is also used in JIRA 2689 and 2690. Clicking the dependency node will select the component so that you can see its further dependencies. Thanks New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, dependency.gif, dependencyview2691.patch Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2691: --- Patch Info: [Patch Available] New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, dependency.gif, dependencyview2691.patch Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
