Re: JPA Enhancement Questions
Yes David I really helped me lot to understand this concept. How do we do this runtime enhancement in G for different kind of JPA providers? Isn't this enhancement will be vary according to the JPA provider? Thanks, Lasantha David Jencks wrote: if you pre-enhance the classes during the build then you can start geronimo with java -jar bin/server.jar --long If you don't pre-enhance the classes so you need runtime enhancement you have to start geronimo with the javaagent stuff java -javaagent:bin/jpa.jar -jar bin/server.jar --long AFAICT we support build time enhancement and runtime enhancement. deploy time enhancement would be a good idea IMO but is not supported at the moment. hope this helps... david jencks On Mar 30, 2007, at 6:14 PM, Lasantha Ranaweera wrote: Hi, According to the OpenJPA user guide there are 3 types of JPA enhancement specified. 1. Build time enhancement 2. Deployment enhancement. 3. Runtime enhancement So I have a question regarding JPA enhancement in Geronimo with latest transformation module. 1. Do we need to enhance JPA testsuite classes in both build time (with m2 plugin) and runtime (with jpa.jar) ? If somebody can explain this enhancement work (with new transform module) in G perspective that would be big help. Thanks, Lasantha
Re: JPA Enhancement Questions
if you pre-enhance the classes during the build then you can start geronimo with java -jar bin/server.jar --long If you don't pre-enhance the classes so you need runtime enhancement you have to start geronimo with the javaagent stuff java -javaagent:bin/jpa.jar -jar bin/server.jar --long AFAICT we support build time enhancement and runtime enhancement. deploy time enhancement would be a good idea IMO but is not supported at the moment. hope this helps... david jencks On Mar 30, 2007, at 6:14 PM, Lasantha Ranaweera wrote: Hi, According to the OpenJPA user guide there are 3 types of JPA enhancement specified. 1. Build time enhancement 2. Deployment enhancement. 3. Runtime enhancement So I have a question regarding JPA enhancement in Geronimo with latest transformation module. 1. Do we need to enhance JPA testsuite classes in both build time (with m2 plugin) and runtime (with jpa.jar) ? If somebody can explain this enhancement work (with new transform module) in G perspective that would be big help. Thanks, Lasantha
[jira] Closed: (GERONIMO-3053) OutOfMemoryErrors during deployment
[ https://issues.apache.org/jira/browse/GERONIMO-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-3053. -- Resolution: Fixed First, there was a bug/feature in our ClassLoader cloning algorithm. We weren't properly cloning a ClassLoader DAG. Result was we had multiple copies of the same ClassLoader. Searching this now redundant ClassLoader structure caused a lot of java.util.Zipfile instances to be created. These instances weren't being leaked, and would eventually be GC'ed. So, this was inefficient, but could have worked... However, JRE allocates non-heap memory for each Zipfile. This memory is part of the process memory and is separate from heap/permgen memory. Zipfiles didn't consume a lot of heap memory. So, JRE was not in a big rush to GC the Zipfiles. Eventually, we'd run out of this process memory. When this happens, the JRE throws an OutOfMemoryError, like so: [EMAIL PROTECTED] Exception in thread "Thread-182" java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:75) at java.util.zip.ZipFile.getInflater(ZipFile.java:375) at java.util.zip.ZipFile.getInputStream(ZipFile.java:320) at java.util.zip.ZipFile.getInputStream(ZipFile.java:286) at java.util.jar.JarFile.getInputStream(JarFile.java:387) at sun.misc.URLClassPath$JarLoader$1.getInputStream(URLClassPath.java:620) > OutOfMemoryErrors during deployment > --- > > Key: GERONIMO-3053 > URL: https://issues.apache.org/jira/browse/GERONIMO-3053 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0-M4 > Environment: Linux, Sun JRE >Reporter: Kevan Miller > Assigned To: Kevan Miller > Fix For: 2.0-M5 > > > While running multiple deploy/undeploy commands, you can get > OutOfMemoryErrors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3053) OutOfMemoryErrors during deployment
OutOfMemoryErrors during deployment --- Key: GERONIMO-3053 URL: https://issues.apache.org/jira/browse/GERONIMO-3053 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M4 Environment: Linux, Sun JRE Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 2.0-M5 While running multiple deploy/undeploy commands, you can get OutOfMemoryErrors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2898) Can't edit Jetty SSL Connector in Geronimo console
[ https://issues.apache.org/jira/browse/GERONIMO-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha reassigned GERONIMO-2898: Assignee: Anita Kulshreshtha Patch Applied to trunk rev 524356. Thanks Frank! > Can't edit Jetty SSL Connector in Geronimo console > -- > > Key: GERONIMO-2898 > URL: https://issues.apache.org/jira/browse/GERONIMO-2898 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M2 > Environment: Linux >Reporter: Karthiga Rajeevani Ratnam > Assigned To: Anita Kulshreshtha > Attachments: 2898-new.patch, 2898.patch, JettySSLConnector Error.jpg > > > I tried to edit JettySSLConnector listed under Network Listeners and got the > following error in command prompt. > 15:06:50,729 ERROR [PortletFragment] Error in Portlet > java.lang.IllegalArgumentException: No such method found (getMinThreads on > org.apache.geronimo.jetty6.JettyWebConnector$$EnhancerByCGLIB$$5aaaf276) > at > org.apache.geronimo.console.BasePortlet.getProperty(BasePortlet.java:92) > at > org.apache.geronimo.console.webmanager.ConnectorPortlet.doView(ConnectorPortlet.java:388) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) > at > org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) > at > org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) > at > jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.WebApp
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Congrats Dain. Lasantha Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0 --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.23/740 - Release Date: 3/30/2007 1:15 PM
JPA Enhancement Questions
Hi, According to the OpenJPA user guide there are 3 types of JPA enhancement specified. 1. Build time enhancement 2. Deployment enhancement. 3. Runtime enhancement So I have a question regarding JPA enhancement in Geronimo with latest transformation module. 1. Do we need to enhance JPA testsuite classes in both build time (with m2 plugin) and runtime (with jpa.jar) ? If somebody can explain this enhancement work (with new transform module) in G perspective that would be big help. Thanks, Lasantha
[jira] Created: (SM-914) Exception upon generating a dot file from the apache-servicemix-web distribution in Tomcat
Exception upon generating a dot file from the apache-servicemix-web
distribution in Tomcat
---
Key: SM-914
URL: https://issues.apache.org/activemq/browse/SM-914
Project: ServiceMix
Issue Type: Bug
Affects Versions: 3.1
Environment: MacOS X 10.4.8/Tomcat 5.5.20
Reporter: Bruce Snyder
Upon deploying the {{apache-servicemix-web-3.1-incubating.war}} file in Tomcat
5.5.20 and clicking on the 'View' link in the ServiceMix console, the following
exception is thrown:
{code}
WARN - [dispatcher] - Servlet.service() for servlet
dispatcher threw exception
java.io.IOException: dot: not found
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:52)
at java.lang.ProcessImpl.start(ProcessImpl.java:91)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at java.lang.Runtime.exec(Runtime.java:429)
at java.lang.Runtime.exec(Runtime.java:326)
at
org.apache.servicemix.web.view.DotView.renderMergedOutputModel(DotView.java:71)
at
org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:249)
at
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1105)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:841)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:755)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.servicemix.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:81)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
at
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
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.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.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:664)
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:613)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Congratulations Dain!!! Anita --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > The Apache Geronimo PMC is pleased to announce that Dain Sundstrom > has accepted an invitation to join the PMC. > > Nuf 'said. > > Welcome :-0 > The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
Re: Tomcat m2 repo?
Jason Dillon wrote: Mocking me? Ha... I prolly deserve it a little :-P But I'm here if you need more help. sounds good Filip --jason On Mar 30, 2007, at 4:58 PM, Filip Hanik - Dev Lists wrote: eeeh, and you were asking why we havent got around to this? "lack of expertise" if I remember correctly :) Just messing with you Jason Filip Jason Dillon wrote: Until Jason gets to releasing the updated tasks you will need to build a few bits by hand to use the new antlib attach stuff. First build Maven 2.0.6 from its tag: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ And then build the updated ant tasks from this feature branch: http://svn.apache.org/repos/asf/maven/sandbox/trunk/ant-tasks/install-deploy-attached/ Both should build with no problems with Maven 2.0.5. Then you should have and tasks which support a nested elements as documented in the JIRA issue: http://jira.codehaus.org/browse/MANTTASKS-42 Let me know if you run into any issues and I will do what I can to help you resolve them. Cheers, --jason On Mar 30, 2007, at 1:26 PM, Filip Hanik - Dev Lists wrote: I'll give the antlibs another shot Filip Jason Dillon wrote: FYI the issue + patch to the tasks is here: http://jira.codehaus.org/browse/MANTTASKS-42 --jason On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote: Jason Dillon wrote: On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote: I don't expect that Tomcat will switch to m2, though if they are gonna be publishing m2 repos they should use the m2 antlib for that. But, looks like the m2 antlib is not up to snuff wrt the new? apache requirements to publish .asc files for releases. I think the antlib tasks probably need to be updated to allow extra files to be attached when install/deploying and then ant folks should be sorted... well, that and if they implement a task or macro to sign stuff. we're note even using the antlibs, they were not really working out. It was easier to just exec the mvn script directly. If Maven has the command line option to do what we want, then we can do it. Just curious, what wasn't working out with the antlibs? They should prolly be fixed if they are not usable by ant projects. So if you show me the "$MAVEN_HOME/bin/mvn" command to publish a single JAR(with a POM) and being able to make sure the signature goes with it, then we are fine. GPG signing is a no brainer, we can do that any day. Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to "attach" or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the task and update the task to have a nested set of elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it 2. learning curve, I'm trying to do something really simple 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when using the command line arguments, so I am still running from linux. since all I wanna do is SCP a .jar .pom .md5 and .asc, why does this have to be so complicated :) if I can reverse engineer what it is Maven is doing when publishing a file to a repo, it will be easier for me to implement it in pure ant. Filip --jason --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007 2:31 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.20/737 - Release Date: 3/28/2007 4:23 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.22/739 - Release Date: 3/29/2007 1:36 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.22/739 - Release Date: 3/29/2007 1:36 PM
Re: Tomcat m2 repo?
Mocking me? Ha... I prolly deserve it a little :-P But I'm here if you need more help. --jason On Mar 30, 2007, at 4:58 PM, Filip Hanik - Dev Lists wrote: eeeh, and you were asking why we havent got around to this? "lack of expertise" if I remember correctly :) Just messing with you Jason Filip Jason Dillon wrote: Until Jason gets to releasing the updated tasks you will need to build a few bits by hand to use the new antlib attach stuff. First build Maven 2.0.6 from its tag: http://svn.apache.org/repos/asf/maven/components/tags/ maven-2.0.6/ And then build the updated ant tasks from this feature branch: http://svn.apache.org/repos/asf/maven/sandbox/trunk/ant-tasks/ install-deploy-attached/ Both should build with no problems with Maven 2.0.5. Then you should have and tasks which support a nested elements as documented in the JIRA issue: http://jira.codehaus.org/browse/MANTTASKS-42 Let me know if you run into any issues and I will do what I can to help you resolve them. Cheers, --jason On Mar 30, 2007, at 1:26 PM, Filip Hanik - Dev Lists wrote: I'll give the antlibs another shot Filip Jason Dillon wrote: FYI the issue + patch to the tasks is here: http://jira.codehaus.org/browse/MANTTASKS-42 --jason On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote: Jason Dillon wrote: On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote: I don't expect that Tomcat will switch to m2, though if they are gonna be publishing m2 repos they should use the m2 antlib for that. But, looks like the m2 antlib is not up to snuff wrt the new? apache requirements to publish .asc files for releases. I think the antlib tasks probably need to be updated to allow extra files to be attached when install/ deploying and then ant folks should be sorted... well, that and if they implement a task or macro to sign stuff. we're note even using the antlibs, they were not really working out. It was easier to just exec the mvn script directly. If Maven has the command line option to do what we want, then we can do it. Just curious, what wasn't working out with the antlibs? They should prolly be fixed if they are not usable by ant projects. So if you show me the "$MAVEN_HOME/bin/mvn" command to publish a single JAR(with a POM) and being able to make sure the signature goes with it, then we are fine. GPG signing is a no brainer, we can do that any day. Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/ deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to "attach" or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http://mojo.codehaus.org/build-helper-maven-plugin/attach- artifact-mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the task and update the task to have a nested set of elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it 2. learning curve, I'm trying to do something really simple 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when using the command line arguments, so I am still running from linux. since all I wanna do is SCP a .jar .pom .md5 and .asc, why does this have to be so complicated :) if I can reverse engineer what it is Maven is doing when publishing a file to a repo, it will be easier for me to implement it in pure ant. Filip --jason --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007 2:31 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.20/737 - Release Date: 3/28/2007 4:23 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.22/739 - Release Date: 3/29/2007 1:36 PM
Re: Tomcat m2 repo?
eeeh, and you were asking why we havent got around to this? "lack of expertise" if I remember correctly :) Just messing with you Jason Filip Jason Dillon wrote: Until Jason gets to releasing the updated tasks you will need to build a few bits by hand to use the new antlib attach stuff. First build Maven 2.0.6 from its tag: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ And then build the updated ant tasks from this feature branch: http://svn.apache.org/repos/asf/maven/sandbox/trunk/ant-tasks/install-deploy-attached/ Both should build with no problems with Maven 2.0.5. Then you should have and tasks which support a nested elements as documented in the JIRA issue: http://jira.codehaus.org/browse/MANTTASKS-42 Let me know if you run into any issues and I will do what I can to help you resolve them. Cheers, --jason On Mar 30, 2007, at 1:26 PM, Filip Hanik - Dev Lists wrote: I'll give the antlibs another shot Filip Jason Dillon wrote: FYI the issue + patch to the tasks is here: http://jira.codehaus.org/browse/MANTTASKS-42 --jason On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote: Jason Dillon wrote: On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote: I don't expect that Tomcat will switch to m2, though if they are gonna be publishing m2 repos they should use the m2 antlib for that. But, looks like the m2 antlib is not up to snuff wrt the new? apache requirements to publish .asc files for releases. I think the antlib tasks probably need to be updated to allow extra files to be attached when install/deploying and then ant folks should be sorted... well, that and if they implement a task or macro to sign stuff. we're note even using the antlibs, they were not really working out. It was easier to just exec the mvn script directly. If Maven has the command line option to do what we want, then we can do it. Just curious, what wasn't working out with the antlibs? They should prolly be fixed if they are not usable by ant projects. So if you show me the "$MAVEN_HOME/bin/mvn" command to publish a single JAR(with a POM) and being able to make sure the signature goes with it, then we are fine. GPG signing is a no brainer, we can do that any day. Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to "attach" or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the task and update the task to have a nested set of elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it 2. learning curve, I'm trying to do something really simple 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when using the command line arguments, so I am still running from linux. since all I wanna do is SCP a .jar .pom .md5 and .asc, why does this have to be so complicated :) if I can reverse engineer what it is Maven is doing when publishing a file to a repo, it will be easier for me to implement it in pure ant. Filip --jason --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007 2:31 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.20/737 - Release Date: 3/28/2007 4:23 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.22/739 - Release Date: 3/29/2007 1:36 PM
[jira] Closed: (GERONIMO-3052) injection machinery should throw exceptions when something goes wrong
[ https://issues.apache.org/jira/browse/GERONIMO-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3052. -- Resolution: Fixed rev 524311. Openejb is AFAIK still ignoring injection problems rather than complaining, but this should make problems apparent in app client CallbackHandlers, jetty, tomcat, jasper, and myfaces. > injection machinery should throw exceptions when something goes wrong > - > > Key: GERONIMO-3052 > URL: https://issues.apache.org/jira/browse/GERONIMO-3052 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Jetty, Tomcat >Affects Versions: 2.0-M4 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 2.0-M5 > > > Instead of ignoring problems of jndi lookup, class cast exception, and > missing properties, we should throw exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
G 1.2 && xmlbeans-maven-plugin 2.0.1-20060627.031204-7
Anyone know whats up with the xmlbeans-maven-plugin wrt server/ branches/1.2? Its currently using a pinned snapshot. While this is fine for M/RC releases, its not for officials, since its still a snapshot and the artifact could be removed tomorrow for all we know. We need to get this dependency sorted before we can release 1.2. It appears this is the only dependency using a pinned snapshot like this for 1.2, which is good there aren't more of them. Anyone know? --jason
Re: Surefire build issue
The server/trunk (and server/branches/1.2) codelines inhert configuration from genesis/config/project-config 1.1 ( http:// svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-1.1/config/ project-config/pom.xml ) which currently sets the surefire plugin version to 2.2. I'm unaware of any problems with the build due to surefire problems. What issues are you having? --jason On Mar 30, 2007, at 3:11 PM, Niklas Gustavsson wrote: Hi I'm just starting to play around with building Maven and ran in to some issues. The first was that Surefire complains about Java class file version issues. I've seen this before on other builds (probably because I have a screwed up surefire version as the default) and has been able to fix it by including the surefire plugin version in the pom: maven-surefire-plugin 2.0 Doing this is probably a good idea anyways as it should stabilize builds. Should I report a JIRA issue on this or would this email be okay? /niklas
[jira] Commented: (GERONIMO-2841) Valve reports request method as GET even though POST request was made
[ https://issues.apache.org/jira/browse/GERONIMO-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485667 ] Paul McMahan commented on GERONIMO-2841: Section 9.10 of the 2.4 servlet specification says that requests to /foo should be redirected to /foo/. This prompted Tomcat to remove the code that makes this redirect behavior optional, see http://svn.apache.org/viewvc?view=rev&revision=298787 So it looks our best option is to alter the client so that it uses POST instead of GET when following a redirect. > Valve reports request method as GET even though POST request was made > - > > Key: GERONIMO-2841 > URL: https://issues.apache.org/jira/browse/GERONIMO-2841 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Reporter: Jarek Gawor > Assigned To: Paul McMahan > > The Request of EJBWebServiceValve in Tomcat return the request method as GET > even though POST request was sent. In similar class in Jetty the request > method is reported correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3052) injection machinery should throw exceptions when something goes wrong
injection machinery should throw exceptions when something goes wrong - Key: GERONIMO-3052 URL: https://issues.apache.org/jira/browse/GERONIMO-3052 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty, Tomcat Affects Versions: 2.0-M4 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0-M5 Instead of ignoring problems of jndi lookup, class cast exception, and missing properties, we should throw exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Surefire build issue
Hi I'm just starting to play around with building Maven and ran in to some issues. The first was that Surefire complains about Java class file version issues. I've seen this before on other builds (probably because I have a screwed up surefire version as the default) and has been able to fix it by including the surefire plugin version in the pom: maven-surefire-plugin 2.0 Doing this is probably a good idea anyways as it should stabilize builds. Should I report a JIRA issue on this or would this email be okay? /niklas
Re: What is the Java Version for building source code?
Are you using the latest code from server/trunk? I updated the build
last night to use a previous snapshot version of the maven-enforcer-
plugin to get around this problem until Brian can fix the issue with
the plugin. With the latest in server/trunk you should *not* see
this problem.
--jason
On Mar 30, 2007, at 3:07 PM, Niklas Gustavsson wrote:
Lasantha Ranaweera wrote:
Hi,
What is the recommended Java version to be used with building G
from source code?
At the moment I am having a problem of building G from source code
(maven build fails with complaining incompatible Java version).
I'm running into the same issue with 1.5.0_05. This makes for an
odd error message:
[INFO] [enforcer:enforce {execution: default}]
[INFO] Detected Maven Version: 2.0.5 is allowed in the range [2.0.5,).
[WARNING] Rule 0: RequireJavaVersion failed with message: Detected
JDK Version:
1.5.0-05 is not in the allowed range [1.5,1.6).
Changing the range to [1.4,1.6) let's me pass but that's probably
not a good idea ;-)
/niklas
Re: What is the Java Version for building source code?
Lasantha Ranaweera wrote:
Hi,
What is the recommended Java version to be used with building G from
source code?
At the moment I am having a problem of building G from source code
(maven build fails with complaining incompatible Java version).
I'm running into the same issue with 1.5.0_05. This makes for an odd
error message:
[INFO] [enforcer:enforce {execution: default}]
[INFO] Detected Maven Version: 2.0.5 is allowed in the range [2.0.5,).
[WARNING] Rule 0: RequireJavaVersion failed with message: Detected JDK
Version:
1.5.0-05 is not in the allowed range [1.5,1.6).
Changing the range to [1.4,1.6) let's me pass but that's probably not a
good idea ;-)
/niklas
Re: Restructuring trunk (LONG)
On Mar 30, 2007, at 2:50 PM, David Jencks wrote: This is great! thanks for looking into this! So far I have only a couple minor quibbles. -- connector + transaction should be a component It might actually turn out that more modules that are currently listed in framework/* could be moved to a components/* group too. All depends on how the dependencies are currently for the bits which are really core to the backbone and which are used to add additional and optional features to the server. Anyways, easy to move... svk tracks renames, so I can move them again until the dependencies/layout is sorted. --jason
Re: Restructuring trunk (LONG)
On Mar 30, 2007, at 2:50 PM, David Jencks wrote: This is great! thanks for looking into this! Thanks for taking the time to read what I wrote :-) So far I have only a couple minor quibbles. -- connector + transaction should be a component That should work... though some bits like geronimo-client would need to find another home, since it depends on geronimo-transaction. Though that is probably one of the modules that should move from framework/* into javaee/*. -- I don't understand why you want the "server" in the base groupId. why not o.a.g.activemq, o.a.g.connector, o.a.g.openejb, etc? o.a.g.server.client seems especially odd to me :-) This was to give each of the main top-level projects under our svn root its own groupId. As in: https://svn.apache.org/repos/asf/geronimo/server/ -> org.apache.geronimo.server https://svn.apache.org/repos/asf/geronimo/daytrader/ -> org.apache.geronimo.daytrader https://svn.apache.org/repos/asf/geronimo/genesis/ -> org.apache.geronimo.genesis ... I don't think there would be a _groupId_ o.a.g.server.client, there will probably be: framework/ -> o.a.g.s.framework javaee/ -> o.a.g.s.javaee buildsupport/ -> o.a.g.s.buildsupport testsupport/ -> o.a.g.s.testsupport ... I don't think we want to go any deeper on groupIds, which is why the bits under components/* should probably be treated differently. Giving each component group its own groupId: components/activemq/ -> o.a.g.s.activemq components/axis/ -> o.a.g.s.axis components/axis2/ -> o.a.g.s.axis2 ... --jason
Re: I'm now a dad !
Congratulations! What a cutie! Regards, Alan On Mar 27, 2007, at 8:58 PM, John Sisson wrote: On Tuesday 27th of March at 11am I became the proud father of our first child, a baby girl, Jasmine Mae Sisson, weighing 3.6 kilos ( 7.92 pounds). Lisa and Jasmine are doing well, although now very tired. http://www.youtube.com/watch?v=T_F14GWYzZs Regards, John
Re: Restructuring trunk (LONG)
This is great! thanks for looking into this! So far I have only a couple minor quibbles. -- connector + transaction should be a component -- I don't understand why you want the "server" in the base groupId. why not o.a.g.activemq, o.a.g.connector, o.a.g.openejb, etc? o.a.g.server.client seems especially odd to me :-) thanks david jencks On Mar 30, 2007, at 2:29 PM, Jason Dillon wrote: Awhile back I sent some email [1] about restructuring server/trunk into smaller groups of modules organized by function/feature. I had been waiting for svk2 to be usable enough to manage restructuring in a branch while pulling in new changes to src files, and the latest updates to the svk2 trunk has working support to --track-renames when merging. Last night I spent a few hours and whipped up a POC, using svk to move modules around into groups. I've been tracking changes made to trunk since then and merging them into my local svk repository and it appears that the -- track-rename feature is working... yay! I just wanted to provide a little details on this, how it is working out so far and start up some discussion about eventually making these changes to server/trunk. Right off the bat, I want to mention that these changes should probably be implemented *after* we are done with the bulk of 2.0 work. I don't want to limit this to 2.1, since with the --track-rename feature it may be very feasible to implement this change before we are done with 2.0, but should definitely not be done until we are sorted on the features and TCK muck. When we do decide to implement something like this, I think we should also re-groupId things under org.apache.geronimo.server, and use that namespace for a fresh start... meaning we should not re- groupId to o.a.g.server until then. * * * Below are _examples_ of how modules _might_ be organized, nothing in stone, probably not completely accurate. I did leave the actual names of modules as they were, we can deal with the naming of them later. So far what I have done was to create 2 new top-level modules: * framework * components These are just pom modules which serve to group other modules. The 'framework' module contains the core (code and configuration) modules that make up the backbone of the server. Each of these modules only has dependencies on other modules in this group, or on modules in testsupport or buildsupport, both of which are built prior to building framework (except for a wee bit of magic to get the car-maven-plugin working, see details on that below). For example: framework framework/geronimo-activation framework/geronimo-client framework/geronimo-client-builder framework/geronimo-clustering framework/geronimo-common framework/geronimo-connector framework/geronimo-connector-builder framework/geronimo-core framework/geronimo-deploy-config framework/geronimo-deploy-jsr88 framework/geronimo-deploy-jsr88-bootstrapper framework/geronimo-deploy-tool framework/geronimo-deployment framework/geronimo-gbean-deployer framework/geronimo-interceptor framework/geronimo-j2ee framework/geronimo-j2ee-builder framework/geronimo-j2ee-schema framework/geronimo-jmx-remoting framework/geronimo-kernel framework/geronimo-management framework/geronimo-naming framework/geronimo-naming-builder framework/geronimo-security framework/geronimo-security-builder framework/geronimo-service-builder framework/geronimo-system framework/geronimo-test-ddbean framework/geronimo-timer framework/geronimo-transaction framework/geronimo-transaction-jta11 framework/geronimo-transformer framework/geronimo-util framework/geronimo-web-2.5-builder NOTE: this ^^^ is not a complete list, there are still a bunch of bits in configs/* which I'm trying to figure out where they should live. See the bits below about framework and javaee stuff. The 'components' module contains modules for each of the major non- framework feature components, which in turn contain the (code and configuration) modules that implement/configure that feature. For example: components components/activemq components/axis components/axis2 components/converter components/corba components/cxf components/derby components/directory components/hotdeploy components/jasper components/javamail components/jaxws components/jetty6 components/jetty6-wadi components/jpa components/myfaces components/openejb components/tomcat6 components/upgrade components/wadi components/webservices As mentioned, each of the component modules contains the (code and configuration) modules that implement the feature, so for example for ActiveMQ, we have: components/activemq components/activemq/activemq-broker components/activemq/activemq-ra compon
Re: Tomcat m2 repo?
Until Jason gets to releasing the updated tasks you will need to build a few bits by hand to use the new antlib attach stuff. First build Maven 2.0.6 from its tag: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ And then build the updated ant tasks from this feature branch: http://svn.apache.org/repos/asf/maven/sandbox/trunk/ant-tasks/ install-deploy-attached/ Both should build with no problems with Maven 2.0.5. Then you should have and tasks which support a nested elements as documented in the JIRA issue: http://jira.codehaus.org/browse/MANTTASKS-42 Let me know if you run into any issues and I will do what I can to help you resolve them. Cheers, --jason On Mar 30, 2007, at 1:26 PM, Filip Hanik - Dev Lists wrote: I'll give the antlibs another shot Filip Jason Dillon wrote: FYI the issue + patch to the tasks is here: http://jira.codehaus.org/browse/MANTTASKS-42 --jason On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote: Jason Dillon wrote: On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote: I don't expect that Tomcat will switch to m2, though if they are gonna be publishing m2 repos they should use the m2 antlib for that. But, looks like the m2 antlib is not up to snuff wrt the new? apache requirements to publish .asc files for releases. I think the antlib tasks probably need to be updated to allow extra files to be attached when install/ deploying and then ant folks should be sorted... well, that and if they implement a task or macro to sign stuff. we're note even using the antlibs, they were not really working out. It was easier to just exec the mvn script directly. If Maven has the command line option to do what we want, then we can do it. Just curious, what wasn't working out with the antlibs? They should prolly be fixed if they are not usable by ant projects. So if you show me the "$MAVEN_HOME/bin/mvn" command to publish a single JAR(with a POM) and being able to make sure the signature goes with it, then we are fine. GPG signing is a no brainer, we can do that any day. Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to "attach" or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http:// mojo.codehaus.org/build-helper-maven-plugin/attach-artifact- mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the task and update the task to have a nested set of elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it 2. learning curve, I'm trying to do something really simple 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when using the command line arguments, so I am still running from linux. since all I wanna do is SCP a .jar .pom .md5 and .asc, why does this have to be so complicated :) if I can reverse engineer what it is Maven is doing when publishing a file to a repo, it will be easier for me to implement it in pure ant. Filip --jason --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007 2:31 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.20/737 - Release Date: 3/28/2007 4:23 PM
Restructuring trunk (LONG)
Awhile back I sent some email [1] about restructuring server/trunk into smaller groups of modules organized by function/feature. I had been waiting for svk2 to be usable enough to manage restructuring in a branch while pulling in new changes to src files, and the latest updates to the svk2 trunk has working support to -- track-renames when merging. Last night I spent a few hours and whipped up a POC, using svk to move modules around into groups. I've been tracking changes made to trunk since then and merging them into my local svk repository and it appears that the --track-rename feature is working... yay! I just wanted to provide a little details on this, how it is working out so far and start up some discussion about eventually making these changes to server/trunk. Right off the bat, I want to mention that these changes should probably be implemented *after* we are done with the bulk of 2.0 work. I don't want to limit this to 2.1, since with the --track-rename feature it may be very feasible to implement this change before we are done with 2.0, but should definitely not be done until we are sorted on the features and TCK muck. When we do decide to implement something like this, I think we should also re-groupId things under org.apache.geronimo.server, and use that namespace for a fresh start... meaning we should not re-groupId to o.a.g.server until then. * * * Below are _examples_ of how modules _might_ be organized, nothing in stone, probably not completely accurate. I did leave the actual names of modules as they were, we can deal with the naming of them later. So far what I have done was to create 2 new top-level modules: * framework * components These are just pom modules which serve to group other modules. The 'framework' module contains the core (code and configuration) modules that make up the backbone of the server. Each of these modules only has dependencies on other modules in this group, or on modules in testsupport or buildsupport, both of which are built prior to building framework (except for a wee bit of magic to get the car- maven-plugin working, see details on that below). For example: framework framework/geronimo-activation framework/geronimo-client framework/geronimo-client-builder framework/geronimo-clustering framework/geronimo-common framework/geronimo-connector framework/geronimo-connector-builder framework/geronimo-core framework/geronimo-deploy-config framework/geronimo-deploy-jsr88 framework/geronimo-deploy-jsr88-bootstrapper framework/geronimo-deploy-tool framework/geronimo-deployment framework/geronimo-gbean-deployer framework/geronimo-interceptor framework/geronimo-j2ee framework/geronimo-j2ee-builder framework/geronimo-j2ee-schema framework/geronimo-jmx-remoting framework/geronimo-kernel framework/geronimo-management framework/geronimo-naming framework/geronimo-naming-builder framework/geronimo-security framework/geronimo-security-builder framework/geronimo-service-builder framework/geronimo-system framework/geronimo-test-ddbean framework/geronimo-timer framework/geronimo-transaction framework/geronimo-transaction-jta11 framework/geronimo-transformer framework/geronimo-util framework/geronimo-web-2.5-builder NOTE: this ^^^ is not a complete list, there are still a bunch of bits in configs/* which I'm trying to figure out where they should live. See the bits below about framework and javaee stuff. The 'components' module contains modules for each of the major non- framework feature components, which in turn contain the (code and configuration) modules that implement/configure that feature. For example: components components/activemq components/axis components/axis2 components/converter components/corba components/cxf components/derby components/directory components/hotdeploy components/jasper components/javamail components/jaxws components/jetty6 components/jetty6-wadi components/jpa components/myfaces components/openejb components/tomcat6 components/upgrade components/wadi components/webservices As mentioned, each of the component modules contains the (code and configuration) modules that implement the feature, so for example for ActiveMQ, we have: components/activemq components/activemq/activemq-broker components/activemq/activemq-ra components/activemq/geronimo-activemq components/activemq/geronimo-activemq-management components/activemq/geronimo-activemq-ra Where possible, the configuration for artifacts used by feature components should be put into the component's pom.xml. For example, the components/activemq/pom.xml has: 8< geronimo-activemq-management geronimo-activemq geronimo
[jira] Resolved: (GERONIMO-3048) TomcatEJBWebServiceContext does not like NONE authentication method
[ https://issues.apache.org/jira/browse/GERONIMO-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved GERONIMO-3048. Resolution: Fixed Fix Version/s: 2.0-M5 > TomcatEJBWebServiceContext does not like NONE authentication method > --- > > Key: GERONIMO-3048 > URL: https://issues.apache.org/jira/browse/GERONIMO-3048 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Jarek Gawor > Assigned To: Paul McMahan > Fix For: 2.0-M5 > > Attachments: GERONIMO-3048.patch > > > If I pass authentication method as NONE to Tomcat EJB valve, I get the > following error: > java.lang.IllegalArgumentException: Invalid authMethod: NONE > at > org.apache.geronimo.tomcat.TomcatEJBWebServiceContext.(TomcatEJ > BWebServiceContext.java:120) > at > org.apache.geronimo.tomcat.TomcatGeronimoEmbedded.createEJBWebService > Context(TomcatGeronimoEmbedded.java:68) > at > org.apache.geronimo.tomcat.TomcatContainer.addWebService(TomcatContai > ner.java:367) > Jetty6 seems to support that option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3048) TomcatEJBWebServiceContext does not like NONE authentication method
[ https://issues.apache.org/jira/browse/GERONIMO-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated GERONIMO-3048: --- Attachment: GERONIMO-3048.patch Try out tomcat's NonLoginAuthenticator for auth-type == NONE > TomcatEJBWebServiceContext does not like NONE authentication method > --- > > Key: GERONIMO-3048 > URL: https://issues.apache.org/jira/browse/GERONIMO-3048 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Jarek Gawor > Assigned To: Paul McMahan > Attachments: GERONIMO-3048.patch > > > If I pass authentication method as NONE to Tomcat EJB valve, I get the > following error: > java.lang.IllegalArgumentException: Invalid authMethod: NONE > at > org.apache.geronimo.tomcat.TomcatEJBWebServiceContext.(TomcatEJ > BWebServiceContext.java:120) > at > org.apache.geronimo.tomcat.TomcatGeronimoEmbedded.createEJBWebService > Context(TomcatGeronimoEmbedded.java:68) > at > org.apache.geronimo.tomcat.TomcatContainer.addWebService(TomcatContai > ner.java:367) > Jetty6 seems to support that option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: EJB and JAXWS integration
Ok, thanks. I got code working and ready to be committed once latest OpenEJB snapshot is published. Jarek On 3/30/07, David Blevins <[EMAIL PROTECTED]> wrote: Alright, the web-service address information is ported over from the old plan. There is now a list in the geronimo- openejb.xsd which is now available in that set of XmlBeans objects in the EjbModule. -David On Mar 28, 2007, at 3:49 PM, David Blevins wrote: > > On Mar 28, 2007, at 10:29 AM, Jarek Gawor wrote: > >> David, Dain, >> >> I've been looking more into the OpenEJB and JAX-WS integration and I >> think I identified a few things that I will need from the OpenEJB >> code >> in order to get this integration done. >> >> 1) Handlers and security >> >> After looking at EJB interceptors and JAX-WS handlers and realizing >> that they are not quite the same I decided to let the JAX-WS >> engine to >> invoke its handlers and EJB engine to invoke its interceptors >> (instead >> of somehow wrapping a JAX-WS handler into an EJB interceptor). > > If you could shed some of your insights on how they are the same > and how they are different, that'd be really helpful. Some spec > references would great if you have them. > > I know the data returned from InvocationContext is different but > that part doesn't have an direct affect on the handlers > themselves. Not sure if there are any differing rules on handler > ordering or flow. > >> The >> only thing that I need to do for handlers is ensure that method-level >> authorization is performed before any JAX-WS handlers are executed. >> For that, I believe I need to perform the following check in the very >> first handler: >> >> getSecurityService().isCallerAuthorized(callMethod, null); > > We are already performing an authorization check before invoking > handlers of any kind (i.e. we could never invoke your ws-hanlder- > chain ejb interceptor without a security check). But I do know the > check needs to contain the MessageContext rather than method args, > which is pretty much the same difference in how InvocationContext > works for a ws call vs. an rpc call. There's also a method in > javax.ejb.SessionContext for getting the MessageContext only usable > on a web service call. > > What I can't remember is what JACC permission we're supposed to > construct. Do you know? > >> 2) InvocationContext and delaying deserialization/serialization >> of parameters >> >> If OpenEJB allowed Geronimo to pass a custom implementation of the >> InvocationContext object (e.g. maybe an extension of >> ReflectionInvocationContext) I could modify it so that: >> >> a) getContextData() would return the same object as MessageContext >> (as per spec) >> b) getParameters() would deserialize the SOAP message (delay >> deseralization) >> c) setParameters() would update the SOAP message >> d) proceed() would keep the object returned and the SOAP message >> in synch > > We definitely need to do something along these lines and a new > InvocationContext is not an entirely bad idea. The gotchas that > may prevent us from taking that route exactly are that I'm pretty > sure the full ejb interceptors apply to all calls, not just rpc, > and would need to get invoked too. Would have to verify that, so > any info you have about ejb interceptors as they may differ from > ejb web service handler chains would help. Also there are some > very complex exception handling rules for ejb which might make that > hard -- app exception vs system exception and now in the ejb3 spec > ejbs can throw runtime exceptions as app exceptions on any call if > they've marked them in the deployment descriptor and this directly > affects how interceptors are processed. We also need to handle the > java to xml marshaling of the bean method's return value or > exception. Not sure how that would fit in. > > It's definitely clear we need the MessageContext itself passed in > from the web service layer as it's required in at least three > different places that i can think of. We might be able to get by > with a CXF or Axis Interceptor that we insert into interceptor > stack right before the bean method call. It's job would be to > unmarshall the data in the MessageContext into some known place in > the ContextData so we can invoke the bean, then it would marshal > the return value or exception so it can be passed up the chain > normally. > > That would be assuming of course that ejb rpc and ejb ws handlers > are the same and only the InvocationContext needs to be different. > So I guess that's really the question of the day. > > Will dig around. > > -David >
Re: [CONF] Apache Geronimo: Committers (page edited)
It would be nice to see the comment field being used more when people make changes to pages... --jason On Mar 30, 2007, at 1:23 PM, [EMAIL PROTECTED] wrote: Page Edited : GMOxSITE : Committers Committers has been edited by Hernan Cunico (Mar 30, 2007). (View changes) Content: Apache Geronimo Committers The people listed below have made significant contributions to Geronimo by working long and hard to make quality software for the rest of the world to use. In addition to being commmitters, some of the following people are also members of the Project Management Committee (PMC). Refer to the How the ASF works for details on meritocracy. If you would like to contribute to Geronimo, please check the Get Involved page to see how you can contribute. NameOrganizationPMC Member Aaron MulderChariot Solutions Alan CabreraSimula Labs Anita Kulshreshtha Bruce SnyderLogicBlaze Christopher J. Blythe IBM Christopher M. Cardona IBM Dain Sundstrom IBM Davanum SrinivasWSO2 David Blevins IBM David JencksIBM Donald WoodsIBM Geir Magnusson Jr. Intel Gianny D'Amour Greg WilkinsMortbay Guillaume Nodet LogicBlaze Hernan Cunico IBM Hiram Chirino LogicBlaze Jacek Laskowski James Strachan LogicBlaze Jan Bartel Mortbay Jarek Gawor IBM Jason DillonIBM Jeff Genender Savoir Technologies Jeremy Boynes Joe BohnIBM John R. Sisson Jules Gosnell Kevan MillerIBM Ken CoarIBM Mark DeLaFranier Matt R. HogstromIBM Chair Paul McMahanIBM Prasad Kashyap IBM Rakesh Midha Rick McGuireIBM Sachin P. Patel IBM Srinath Perera Vamsavardhana Reddy Chillakuru IBM Jason van Zyl Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
Re: Tomcat m2 repo?
I'll give the antlibs another shot Filip Jason Dillon wrote: FYI the issue + patch to the tasks is here: http://jira.codehaus.org/browse/MANTTASKS-42 --jason On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote: Jason Dillon wrote: On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote: I don't expect that Tomcat will switch to m2, though if they are gonna be publishing m2 repos they should use the m2 antlib for that. But, looks like the m2 antlib is not up to snuff wrt the new? apache requirements to publish .asc files for releases. I think the antlib tasks probably need to be updated to allow extra files to be attached when install/deploying and then ant folks should be sorted... well, that and if they implement a task or macro to sign stuff. we're note even using the antlibs, they were not really working out. It was easier to just exec the mvn script directly. If Maven has the command line option to do what we want, then we can do it. Just curious, what wasn't working out with the antlibs? They should prolly be fixed if they are not usable by ant projects. So if you show me the "$MAVEN_HOME/bin/mvn" command to publish a single JAR(with a POM) and being able to make sure the signature goes with it, then we are fine. GPG signing is a no brainer, we can do that any day. Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to "attach" or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the task and update the task to have a nested set of elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it 2. learning curve, I'm trying to do something really simple 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when using the command line arguments, so I am still running from linux. since all I wanna do is SCP a .jar .pom .md5 and .asc, why does this have to be so complicated :) if I can reverse engineer what it is Maven is doing when publishing a file to a repo, it will be easier for me to implement it in pure ant. Filip --jason --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007 2:31 PM --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.20/737 - Release Date: 3/28/2007 4:23 PM
[jira] Assigned: (GERONIMO-3046) When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started before its dependencies have been started
[ https://issues.apache.org/jira/browse/GERONIMO-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom reassigned GERONIMO-3046: Assignee: Matt Hogstrom (was: Dain Sundstrom) I believe this is fixed with r524261 > When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started > before its dependencies have been started > - > > Key: GERONIMO-3046 > URL: https://issues.apache.org/jira/browse/GERONIMO-3046 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0-M4, 2.0-M5 >Reporter: Matt Hogstrom > Assigned To: Matt Hogstrom > Fix For: 2.0-M4 > > > Testing deployment of Daytrader on Geronimo 2.0 - M4 (as well as trunk) the > dt-ejb.jar is started before the messaging component it depends on. As a > consequence, startup of the application fails as a dependent resource (a > messaging queue) is not found. > Talked to Dain about this and he thinks he knows where this needs to be > addressed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3039) upgrade to Scout snapshot
[ https://issues.apache.org/jira/browse/GERONIMO-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3039: --- Attachment: G-3039-xmlbean.patch This attachement updated geronimo-gbean-deployer so that it is also dependent upon the new xmlbean config. However, it results in a build error when building jee-specs which depends upon geronimo-gbean-deployer which now depends on the xmlbeans config which for some reason cannot be resolved even though it has already been built and the xmlbeans car is in the local repo. As second mvn from trunk will build jee-specs (now finding xmlbeans in the local repo for some reason). However, even with this change some tests of jaxr still get java.lang.NoClassDefFoundError: org/apache/xmlbeans/XmlObject ... so it doesn't appear that all instances of xmlbeans classes are being loaded from the xmlbean config classloader. > upgrade to Scout snapshot > - > > Key: GERONIMO-3039 > URL: https://issues.apache.org/jira/browse/GERONIMO-3039 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0-M5 >Reporter: Joe Bohn > Assigned To: Joe Bohn >Priority: Minor > Fix For: 2.0-M5 > > Attachments: G-3039-xmlbean.patch > > > Updates have gone into Scout so that it is no longer dependent on JUDDI -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (GERONIMO-2995) Weed out backport-util-concurrent usage for server/trunk
No, I don't expect they will, nor do I think they should. 4.1.x
still runs on JDK 1.4. This dep will be dropped in AMQ 5.0. So G
2.0 will still need to keep this dep in the repo for JMS muck (which
I am okay with).
--jason
On Mar 30, 2007, at 1:02 PM, Donald Woods wrote:
Do we have a commitment from ActiveMQ to remove its backport-util-
concurrent usage in a 4.1 release for our 2.0 release?
-Donald
Jason Dillon (JIRA) wrote:
[ https://issues.apache.org/jira/browse/GERONIMO-2995?
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Dillon closed GERONIMO-2995.
--
Resolution: Fixed
Fix Version/s: 2.0-beta1
This is done, once AMQ removes dependency on this... then we can
get it out of the repository.
Weed out backport-util-concurrent usage for server/trunk
Key: GERONIMO-2995
URL: https://issues.apache.org/jira/browse/
GERONIMO-2995
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)Affects Versions: 2.0
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 2.0-beta1
Now that server/trunk requires 1.5 to build and run, I think we
should start to weed out our usage of the {{backport-util-
concurrent}} library (and concurrent if there is still anything
left of that in our src tree).
I think we may still have to include {{backport-util-concurrent-
\*.jar}} in the assembly until all of our dependencies have
weeded it out too... or perhaps just have to live with that in
the repository. But hopefully we can remove our usage of these
classes and not need to include this puppy in {{lib/\*}} anymore.
Looks like we are currently using {{edu.emory.mathcs.backport}}
in 39 locations (based on imports) which are over 25 files.
Even after weeding out *our* usage, if we still need to include
this jar I recommend we update to the latest release 3.0.
Re: [jira] Closed: (GERONIMO-2995) Weed out backport-util-concurrent usage for server/trunk
Do we have a commitment from ActiveMQ to remove its
backport-util-concurrent usage in a 4.1 release for our 2.0 release?
-Donald
Jason Dillon (JIRA) wrote:
[
https://issues.apache.org/jira/browse/GERONIMO-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed GERONIMO-2995.
--
Resolution: Fixed
Fix Version/s: 2.0-beta1
This is done, once AMQ removes dependency on this... then we can get it out of
the repository.
Weed out backport-util-concurrent usage for server/trunk
Key: GERONIMO-2995
URL: https://issues.apache.org/jira/browse/GERONIMO-2995
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Affects Versions: 2.0
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 2.0-beta1
Now that server/trunk requires 1.5 to build and run, I think we should start to
weed out our usage of the {{backport-util-concurrent}} library (and concurrent
if there is still anything left of that in our src tree).
I think we may still have to include {{backport-util-concurrent-\*.jar}} in the
assembly until all of our dependencies have weeded it out too... or perhaps
just have to live with that in the repository. But hopefully we can remove our
usage of these classes and not need to include this puppy in {{lib/\*}} anymore.
Looks like we are currently using {{edu.emory.mathcs.backport}} in 39 locations
(based on imports) which are over 25 files.
Even after weeding out *our* usage, if we still need to include this jar I
recommend we update to the latest release 3.0.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Welcome aboard! Regards, Alan On Mar 30, 2007, at 11:26 AM, Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
[jira] Resolved: (GERONIMO-2664) Servlet Filter Error
[ https://issues.apache.org/jira/browse/GERONIMO-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved GERONIMO-2664. Resolution: Fixed tomcat applied the patch in rev 504726 > Servlet Filter Error > > > Key: GERONIMO-2664 > URL: https://issues.apache.org/jira/browse/GERONIMO-2664 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Jetty, Tomcat >Affects Versions: 2.0-M1, 2.0-M2, 2.0-M5 >Reporter: Krishnakumar B > Assigned To: Paul McMahan > Fix For: 2.0-M3 > > > Trying out servlet name with a wild card ( * ) in Filter throws exception in > Jetty. In tomcat the filter is not called at all > > Sample Filter > * > > instead of > Sample Filter > > SampleServlet > AnotherSampleServlet > Jetty > 14:21:50,780 ERROR [Deployer] Deployment failed due to > java.lang.AssertionError: > javax.management.MalformedObjectNameException: Invalid character `*' > in value >at > org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:112) >at > org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:80) >at > org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54) >at > org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addFilterMappingsGBeans(JettyModuleBuilder.java:614) >at > org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:483) >at > org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.invoke() >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:124) >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.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans() >at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) >at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke() >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:124) >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.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans() >at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:572) >at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() >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:124) >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.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$c3a6b023.buildConfiguration() >at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) >at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) >at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() >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.GBeanO
[jira] Assigned: (GERONIMO-3048) TomcatEJBWebServiceContext does not like NONE authentication method
[ https://issues.apache.org/jira/browse/GERONIMO-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reassigned GERONIMO-3048: -- Assignee: Paul McMahan > TomcatEJBWebServiceContext does not like NONE authentication method > --- > > Key: GERONIMO-3048 > URL: https://issues.apache.org/jira/browse/GERONIMO-3048 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Jarek Gawor > Assigned To: Paul McMahan > > If I pass authentication method as NONE to Tomcat EJB valve, I get the > following error: > java.lang.IllegalArgumentException: Invalid authMethod: NONE > at > org.apache.geronimo.tomcat.TomcatEJBWebServiceContext.(TomcatEJ > BWebServiceContext.java:120) > at > org.apache.geronimo.tomcat.TomcatGeronimoEmbedded.createEJBWebService > Context(TomcatGeronimoEmbedded.java:68) > at > org.apache.geronimo.tomcat.TomcatContainer.addWebService(TomcatContai > ner.java:367) > Jetty6 seems to support that option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Congrats Dain! Joe Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
[jira] Commented: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485618 ] Donald Woods commented on GERONIMO-3045: Verified the patch fixes the noted problem on the Tomcat assembly when using Axis2. > Unable to run jax-rpc war test with Axis2 > - > > Key: GERONIMO-3045 > URL: https://issues.apache.org/jira/browse/GERONIMO-3045 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0-M5 > Environment: 1.5 SUN SDK + WIN XP >Reporter: Lin Sun > Fix For: 2.0-M5 > > Attachments: G3045.patch > > > When running the jax-rpc war test with axis2, both test failed due to an > exception thrown when parseWebServiceDescriptor is called. > from reading the code, if webservices.xml doesn't exist, we call > discoverwebservices, which will check if the class has annotation. if > webservices.xml exists, we 'll just call parseWebServiceDescriptor, which > caused the error for axis2 because axis2 moved to xbeans. > The fix is to check if annotation exists when webservices.xml exists also. > Tested the fix and able to pass the 2 jax-rpc war test test with them. Will > attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3039) upgrade to Scout snapshot
[ https://issues.apache.org/jira/browse/GERONIMO-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn reopened GERONIMO-3039: The common xmlbeans config added via this JIRA is not yet integrated with geronimo-gbean-deployer. > upgrade to Scout snapshot > - > > Key: GERONIMO-3039 > URL: https://issues.apache.org/jira/browse/GERONIMO-3039 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0-M5 >Reporter: Joe Bohn > Assigned To: Joe Bohn >Priority: Minor > Fix For: 2.0-M5 > > > Updates have gone into Scout so that it is no longer dependent on JUDDI -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DB Viewer portlet error
I just created GERONIMO-3051 for this issue. Cheers! Hernan Hernan Cunico wrote: If it helps, I just tried with an external DB and it works. I can create and test a connection pool (just like before) and also access it via an application. This seems to be just around the embedded Derby. Cheers! Hernan Hernan Cunico wrote: I can deploy the pool just fine but it is the DB creation process the one I have no control. I use the DB manager to create a new DB, that DB is listed in the DB Viewer portlet, when I click that DB I get this error. At this point I only entered the name of a new DB I wanted to create, the rest is just "mouse" clicks ;-) So, when I get the portlet error (still in the DB Manager) I check the logs and see the "...java.sql.SQLException: No suitable driver ..." If I create a connection pool, I will still be able to test the connection (at creation time) and deploy the pool via console (have not tried via command line yet). The pool gets successfully deployed but when I try to access that DB I get a weird error, like the DB does not exist. So this is kind of a second test to see if I can still access the DB (which I can't) but the main issue is that the DB Viewer portlet cannot display any DB content for other than the "SystemDatabase". Cheers! Hernan David Jencks wrote: Did you specify to include the appropriate derby jars as dependencies when you created the module? The tranql connectors don't include the derby jars you need, you have to depend on them for each db pool you set up. thanks david jencks On Mar 29, 2007, at 7:22 AM, Hernan Cunico wrote: Hi All, Just wondering if somebody else is seeing this problem. I create a new DB with the DB manager and the DB is created successfully but when I try to view that DB from the DB Viewer I get a portlet error. When I check the logs I get this: 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error getting connection: "java.sql.SQLException: No suitable driver" ... 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw exception javax.servlet.ServletException ... 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... One interesting this is that I can still create a pool connection and test it (at creation time). But when I try to access that DB from an app I also get a connection error ResourceAllocationException: Unable to obtain physical connection to jdbc:derby:TestDB This is on the M4 branch, any ideas? Cheers! Hernan
[jira] Created: (GERONIMO-3051) DB Viewer portlet error
DB Viewer portlet error --- Key: GERONIMO-3051 URL: https://issues.apache.org/jira/browse/GERONIMO-3051 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, databases Affects Versions: 2.0-M4 Environment: embedded Derby databases Reporter: Hernan Cunico There is a problem when trying to view an embedded Derby database. I am able to successfully create a new DB with the DB manager and a new entry appears in the DB Viewer but when I try to view that DB from the DB Viewer I get a portlet error. When I check the logs I get this: 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error getting connection: "java.sql.SQLException: No suitable driver" ... 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw exception javax.servlet.ServletException ... 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... With the exception of the "SystemDatabase" all the other databases created on the embedded Derby are also unaccessible from other applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3049) Change the usage hint in the common libs console screen
[ https://issues.apache.org/jira/browse/GERONIMO-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485615 ] Jay D. McHugh commented on GERONIMO-3049: - The current usage info provided on the console does not conform to the schema. The patch just makes it so someone could follow the displayed 'usage' code to make entries into their deployment descriptors (or cut/paste). > Change the usage hint in the common libs console screen > --- > > Key: GERONIMO-3049 > URL: https://issues.apache.org/jira/browse/GERONIMO-3049 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2, 2.0-M4, 2.0-M5 >Reporter: Jay D. McHugh > Assigned To: Jay D. McHugh >Priority: Trivial > Attachments: geronimo-3049.patch > > > When you click on one of the libraries listed on the common libs page, a > usage hint pops up. > But, the format of the code to include is old (circa 1.1 days). > Example: > > ... > > ... > > activeio > activeio > 2.0-r118 > jar > > > > This should be updated to show the current format (that includes a namespace): > http://geronimo.apache.org/xml/ns/deployment...> > ... > > ... > > activeio > activeio > 2.0-r118 > jar > > > > Not a 'super big' deal, but if someone new to geronimo tries to just > copy/paste into one of their deployment descriptors, then they will have > problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2916) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hernan Cunico closed GERONIMO-2916. --- Resolution: Fixed Problem fixed in M4 > database creation pool wizzard fails to deploy > -- > > Key: GERONIMO-2916 > URL: https://issues.apache.org/jira/browse/GERONIMO-2916 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, databases >Affects Versions: 2.0-M2, 2.0-M3 > Environment: relates to GERONIMO-2686 >Reporter: Hernan Cunico > Assigned To: Anita Kulshreshtha > Fix For: 2.0-M4 > > Attachments: configs.diff > > > 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. > Similar error conditions were reported in GERONIMO-2686 > The terminal shows the following error: > 15:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection pool > javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer > for module type: rar registered > at > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:343) > 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:687) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) > 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:338) > 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:517) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) > at java.lang.Thread
[jira] Updated: (GERONIMO-2898) Can't edit Jetty SSL Connector in Geronimo console
[ https://issues.apache.org/jira/browse/GERONIMO-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank G updated GERONIMO-2898: -- Attachment: 2898-new.patch Thanks for pointing. My mistake :-(, this is the new patch 2898-new.patch. Please ignore 2898.patch. Thank you very much. > Can't edit Jetty SSL Connector in Geronimo console > -- > > Key: GERONIMO-2898 > URL: https://issues.apache.org/jira/browse/GERONIMO-2898 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M2 > Environment: Linux >Reporter: Karthiga Rajeevani Ratnam > Attachments: 2898-new.patch, 2898.patch, JettySSLConnector Error.jpg > > > I tried to edit JettySSLConnector listed under Network Listeners and got the > following error in command prompt. > 15:06:50,729 ERROR [PortletFragment] Error in Portlet > java.lang.IllegalArgumentException: No such method found (getMinThreads on > org.apache.geronimo.jetty6.JettyWebConnector$$EnhancerByCGLIB$$5aaaf276) > at > org.apache.geronimo.console.BasePortlet.getProperty(BasePortlet.java:92) > at > org.apache.geronimo.console.webmanager.ConnectorPortlet.doView(ConnectorPortlet.java:388) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) > at > org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) > at > org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) > at > jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.We
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Awesome! Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
[jira] Assigned: (GERONIMO-2991) Axis2: supports service-ref overwrite
[ https://issues.apache.org/jira/browse/GERONIMO-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMO-2991: - Assignee: Lin Sun > Axis2: supports service-ref overwrite > -- > > Key: GERONIMO-2991 > URL: https://issues.apache.org/jira/browse/GERONIMO-2991 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0-M5 >Reporter: Lin Sun > Assigned To: Lin Sun > Fix For: 2.0-M5 > > > From Jeff on dev list - > The service-ref override is in the web.xml from the client side. The > service-ref can have a tag that is supposed to override > what comes from the wsdl. > Per Jarek, this is working for CXF... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Congrats Dain! --kevan On Mar 30, 2007, at 2:26 PM, Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Congrats Dain!!! Cheers! Hernan Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
[jira] Created: (GERONIMO-3050) Create a JPA persistence unit view for the console
Create a JPA persistence unit view for the console -- Key: GERONIMO-3050 URL: https://issues.apache.org/jira/browse/GERONIMO-3050 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0-M5 Reporter: Jay D. McHugh Assigned To: Jay D. McHugh Create one or more JPA views that show: - View of loaded persistence units (tree format with persistable classes under each unit) - View of loaded persistence units detailing their properties (back-end database, transaction mode, ...) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
AWESOME. Congrats Dain! Best wishes, Paul On Mar 30, 2007, at 2:26 PM, Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Congrats! Matt Hogstrom wrote: > The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has > accepted an invitation to join the PMC. > > Nuf 'said. > > Welcome :-0
[jira] Commented: (GERONIMO-3049) Change the usage hint in the common libs console screen
[ https://issues.apache.org/jira/browse/GERONIMO-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485601 ] Paul McMahan commented on GERONIMO-3049: my eyeballs got crossed a little bit when I stared at this :-) Is the net effect of this JIRA/patch just to explicitly define the xmlns? or does the current usage info provided in the console not conform to the deployment schema? > Change the usage hint in the common libs console screen > --- > > Key: GERONIMO-3049 > URL: https://issues.apache.org/jira/browse/GERONIMO-3049 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2, 2.0-M4, 2.0-M5 >Reporter: Jay D. McHugh > Assigned To: Jay D. McHugh >Priority: Trivial > Attachments: geronimo-3049.patch > > > When you click on one of the libraries listed on the common libs page, a > usage hint pops up. > But, the format of the code to include is old (circa 1.1 days). > Example: > > ... > > ... > > activeio > activeio > 2.0-r118 > jar > > > > This should be updated to show the current format (that includes a namespace): > http://geronimo.apache.org/xml/ns/deployment...> > ... > > ... > > activeio > activeio > 2.0-r118 > jar > > > > Not a 'super big' deal, but if someone new to geronimo tries to just > copy/paste into one of their deployment descriptors, then they will have > problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
[jira] Updated: (GERONIMO-3049) Change the usage hint in the common libs console screen
[ https://issues.apache.org/jira/browse/GERONIMO-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3049: Attachment: geronimo-3049.patch > Change the usage hint in the common libs console screen > --- > > Key: GERONIMO-3049 > URL: https://issues.apache.org/jira/browse/GERONIMO-3049 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2, 2.0-M4, 2.0-M5 >Reporter: Jay D. McHugh > Assigned To: Jay D. McHugh >Priority: Trivial > Attachments: geronimo-3049.patch > > > When you click on one of the libraries listed on the common libs page, a > usage hint pops up. > But, the format of the code to include is old (circa 1.1 days). > Example: > > ... > > ... > > activeio > activeio > 2.0-r118 > jar > > > > This should be updated to show the current format (that includes a namespace): > http://geronimo.apache.org/xml/ns/deployment...> > ... > > ... > > activeio > activeio > 2.0-r118 > jar > > > > Not a 'super big' deal, but if someone new to geronimo tries to just > copy/paste into one of their deployment descriptors, then they will have > problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3049) Change the usage hint in the common libs console screen
Change the usage hint in the common libs console screen --- Key: GERONIMO-3049 URL: https://issues.apache.org/jira/browse/GERONIMO-3049 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.2, 2.0-M4, 2.0-M5 Reporter: Jay D. McHugh Assigned To: Jay D. McHugh Priority: Trivial Attachments: geronimo-3049.patch When you click on one of the libraries listed on the common libs page, a usage hint pops up. But, the format of the code to include is old (circa 1.1 days). Example: ... ... activeio activeio 2.0-r118 jar This should be updated to show the current format (that includes a namespace): http://geronimo.apache.org/xml/ns/deployment...> ... ... activeio activeio 2.0-r118 jar Not a 'super big' deal, but if someone new to geronimo tries to just copy/paste into one of their deployment descriptors, then they will have problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3017) Web Apps (WAR files) that directly contain JPA entities cannot be deployed
[ https://issues.apache.org/jira/browse/GERONIMO-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3017: --- Assignee: Jay D. McHugh > Web Apps (WAR files) that directly contain JPA entities cannot be deployed > -- > > Key: GERONIMO-3017 > URL: https://issues.apache.org/jira/browse/GERONIMO-3017 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.0-M5 >Reporter: Jay D. McHugh > Assigned To: Jay D. McHugh > Attachments: geronimo-jira-3017.patch > > > There is still a find and parse problem with persistence.xml in war files. > It seems to work if you have your jpa entities in a jar file. > But, if you have a WEB-INF/lib/META-INF/persistence.xml file, it finds it and > dies with a substring error. > I have not tested to see if this is a problem for WAR files contained in an > EAR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3048) TomcatEJBWebServiceContext does not like NONE authentication method
TomcatEJBWebServiceContext does not like NONE authentication method --- Key: GERONIMO-3048 URL: https://issues.apache.org/jira/browse/GERONIMO-3048 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Jarek Gawor If I pass authentication method as NONE to Tomcat EJB valve, I get the following error: java.lang.IllegalArgumentException: Invalid authMethod: NONE at org.apache.geronimo.tomcat.TomcatEJBWebServiceContext.(TomcatEJ BWebServiceContext.java:120) at org.apache.geronimo.tomcat.TomcatGeronimoEmbedded.createEJBWebService Context(TomcatGeronimoEmbedded.java:68) at org.apache.geronimo.tomcat.TomcatContainer.addWebService(TomcatContai ner.java:367) Jetty6 seems to support that option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Geronimo Java EE 5.0 Report Card updated for 2.0-M4
I've updated the Geronimo Java EE 5.0 Report card on the wiki to reflect the latest 2.0-M4 information including milestone contents and package upgrades. http://cwiki.apache.org/GMOxPMGT/geronimo-java-ee-50-report-card.html Feel free to update any inaccuracies. -Dave-
[jira] Closed: (GERONIMO-3047) EJB .create() calls causing marshalling exceptions when invoked through CORBA.
[ https://issues.apache.org/jira/browse/GERONIMO-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3047. -- Resolution: Fixed Committed revision 524183. > EJB .create() calls causing marshalling exceptions when invoked through CORBA. > -- > > Key: GERONIMO-3047 > URL: https://issues.apache.org/jira/browse/GERONIMO-3047 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: CORBA >Affects Versions: 2.0-M5 >Reporter: Rick McGuire > Assigned To: Rick McGuire > Fix For: 2.0-M5 > > > An EJB container create() call coming in through the invoke() method is > returning an instance of a ProxyInfo object. When the corba StandardServant > tries to serialize that and return it back to the caller as the result, it's > getting a marshaling failure because the ProxyInfo object cannot be > serialized. The StandardServant needs to detect this situation and convert > the ProxyInfo object into a corba proxy object that can be passed back to the > caller. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3047) EJB .create() calls causing marshalling exceptions when invoked through CORBA.
EJB .create() calls causing marshalling exceptions when invoked through CORBA. -- Key: GERONIMO-3047 URL: https://issues.apache.org/jira/browse/GERONIMO-3047 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: CORBA Affects Versions: 2.0-M5 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 2.0-M5 An EJB container create() call coming in through the invoke() method is returning an instance of a ProxyInfo object. When the corba StandardServant tries to serialize that and return it back to the caller as the result, it's getting a marshaling failure because the ProxyInfo object cannot be serialized. The StandardServant needs to detect this situation and convert the ProxyInfo object into a corba proxy object that can be passed back to the caller. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3044) Common Libs portlet does not split the file name correctly on linux
[ https://issues.apache.org/jira/browse/GERONIMO-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3044: Attachment: geronimo-3044-2.patch You're right Anita. My patch was a bit of overkill that took advantage of the fact that windows paths start with a drive letter. So the location of the first slash will never be 0. Resubmitting with simple correction of indexOf check. > Common Libs portlet does not split the file name correctly on linux > --- > > Key: GERONIMO-3044 > URL: https://issues.apache.org/jira/browse/GERONIMO-3044 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2, 2.0-M4, 2.0-M5 >Reporter: Jay D. McHugh >Priority: Minor > Attachments: geronimo-3044-2.patch, geronimo-3044.patch > > > Determining the appropriate path delimiter doesn't work - so every path is > split as though it is on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
2.0-M4 Status
I've been playing with M4 and from what I can tell DT will deploy (without web services or MDBs) and seems ok. The MDB issue is a timing issue in terms of starting the modules that Dain thinks he can hammer out. Given the code drop towards the end I spect there are lots of pieces that will need to get shaken out so an M4 driver sooner than later will work I think. I'll troll for some more feedback today and package up something for a vote tomorrow. Anybody have any last minute things / fixes they want to drop in ? Matt
Re: JPA Usability in Geronimo
Didn't mean to oversell (and put pressure on you or anyone else) - I was mainly just trying to find out what type of instrumentation people wanted/needed for JPA. Jay Lasantha Ranaweera wrote: Jacek Laskowski wrote: On 3/29/07, Jay D. McHugh <[EMAIL PROTECTED]> wrote: 1) View of loaded persistence units (tree format with persistable classes under each unit) 2) View of loaded persistence units detailing their properties (back-end database, transaction mode, ...) ... Anyone else have wishlists for JPA? If both were available in Geronimo, I'd be the happiest man in the world! Are you going to give them a shot? Great! Looking forward to presenting them at one of the upcoming conferences. I can imagine how furious the audience is going to be when they're showcased. Still we are not yet there with Cayenne work and hoping to have a go in this week end (GERONIMO-2898). If somebody is willing to contribute it more than welcome :-) . Thanks, Lasantha Jacek
[jira] Commented: (GERONIMO-3044) Common Libs portlet does not split the file name correctly on linux
[
https://issues.apache.org/jira/browse/GERONIMO-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485531
]
Anita Kulshreshtha commented on GERONIMO-3044:
--
some nit picking...
As you noticed the problem is here if(localFile.indexOf("/") > 0). The
correct comparison is if(localFile.indexOf("/") >= 0)
This is because an absolute path name in unix starts with a "/". The patch
you supplied works because the absolute pathname in windows do not start with
"\" and the comparison (> 0) works.
> Common Libs portlet does not split the file name correctly on linux
> ---
>
> Key: GERONIMO-3044
> URL: https://issues.apache.org/jira/browse/GERONIMO-3044
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: console
>Affects Versions: 1.2, 2.0-M4, 2.0-M5
>Reporter: Jay D. McHugh
>Priority: Minor
> Attachments: geronimo-3044.patch
>
>
> Determining the appropriate path delimiter doesn't work - so every path is
> split as though it is on windows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2898) Can't edit Jetty SSL Connector in Geronimo console
[ https://issues.apache.org/jira/browse/GERONIMO-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485506 ] Anita Kulshreshtha commented on GERONIMO-2898: -- This patch seems to be missing a java file. > Can't edit Jetty SSL Connector in Geronimo console > -- > > Key: GERONIMO-2898 > URL: https://issues.apache.org/jira/browse/GERONIMO-2898 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M2 > Environment: Linux >Reporter: Karthiga Rajeevani Ratnam > Attachments: 2898.patch, JettySSLConnector Error.jpg > > > I tried to edit JettySSLConnector listed under Network Listeners and got the > following error in command prompt. > 15:06:50,729 ERROR [PortletFragment] Error in Portlet > java.lang.IllegalArgumentException: No such method found (getMinThreads on > org.apache.geronimo.jetty6.JettyWebConnector$$EnhancerByCGLIB$$5aaaf276) > at > org.apache.geronimo.console.BasePortlet.getProperty(BasePortlet.java:92) > at > org.apache.geronimo.console.webmanager.ConnectorPortlet.doView(ConnectorPortlet.java:388) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) > at > org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) > at > org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) > at > jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at org.mortbay.jetty.ser
[jira] Updated: (GERONIMO-2898) Can't edit Jetty SSL Connector in Geronimo console
[ https://issues.apache.org/jira/browse/GERONIMO-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank G updated GERONIMO-2898: -- Attachment: 2898.patch I think the property MinThreads has been removed from Jetty6, so I removed the codes of editing this property in the jsp files. > Can't edit Jetty SSL Connector in Geronimo console > -- > > Key: GERONIMO-2898 > URL: https://issues.apache.org/jira/browse/GERONIMO-2898 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M2 > Environment: Linux >Reporter: Karthiga Rajeevani Ratnam > Attachments: 2898.patch, JettySSLConnector Error.jpg > > > I tried to edit JettySSLConnector listed under Network Listeners and got the > following error in command prompt. > 15:06:50,729 ERROR [PortletFragment] Error in Portlet > java.lang.IllegalArgumentException: No such method found (getMinThreads on > org.apache.geronimo.jetty6.JettyWebConnector$$EnhancerByCGLIB$$5aaaf276) > at > org.apache.geronimo.console.BasePortlet.getProperty(BasePortlet.java:92) > at > org.apache.geronimo.console.webmanager.ConnectorPortlet.doView(ConnectorPortlet.java:388) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) > at > org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) > at > org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) > at > jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) > at > org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) > at > org.mortbay.jetty.webapp.WebAppContext.hand
Re: geronimo-web-builder & geronimo-web-2.5-builder
Done in rev. 524055. Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: > Why do we still have both of these modules? Looks like geronimo-web- > > builder is commented out of the build. Can we remove it? > > --jason > Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097
[jira] Commented: (SM-884) New exchanges should have a lesser priority compared to older exchanges
[ https://issues.apache.org/activemq/browse/SM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38932 ] Guillaume Nodet commented on SM-884: URL: http://svn.apache.org/viewvc?view=rev&rev=523988 > New exchanges should have a lesser priority compared to older exchanges > --- > > Key: SM-884 > URL: https://issues.apache.org/activemq/browse/SM-884 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-core >Affects Versions: 3.1 >Reporter: Guillaume Nodet > > This would reduce the chances of locking / resource starvation, > and would help reducing the memory footprint by allowing exchanges > to be GCed asap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-912) DOMStreamReader does not need to report namespaces as events
[ https://issues.apache.org/activemq/browse/SM-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-912. Resolution: Fixed URL: http://svn.apache.org/viewvc?view=rev&rev=523986 > DOMStreamReader does not need to report namespaces as events > > > Key: SM-912 > URL: https://issues.apache.org/activemq/browse/SM-912 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-core >Affects Versions: 3.1 >Reporter: Guillaume Nodet > Assigned To: Guillaume Nodet >Priority: Minor > Fix For: 3.2 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: EJB and JAXWS integration
Alright, the web-service address information is ported over from the old plan. There is now a list in the geronimo- openejb.xsd which is now available in that set of XmlBeans objects in the EjbModule. -David On Mar 28, 2007, at 3:49 PM, David Blevins wrote: On Mar 28, 2007, at 10:29 AM, Jarek Gawor wrote: David, Dain, I've been looking more into the OpenEJB and JAX-WS integration and I think I identified a few things that I will need from the OpenEJB code in order to get this integration done. 1) Handlers and security After looking at EJB interceptors and JAX-WS handlers and realizing that they are not quite the same I decided to let the JAX-WS engine to invoke its handlers and EJB engine to invoke its interceptors (instead of somehow wrapping a JAX-WS handler into an EJB interceptor). If you could shed some of your insights on how they are the same and how they are different, that'd be really helpful. Some spec references would great if you have them. I know the data returned from InvocationContext is different but that part doesn't have an direct affect on the handlers themselves. Not sure if there are any differing rules on handler ordering or flow. The only thing that I need to do for handlers is ensure that method-level authorization is performed before any JAX-WS handlers are executed. For that, I believe I need to perform the following check in the very first handler: getSecurityService().isCallerAuthorized(callMethod, null); We are already performing an authorization check before invoking handlers of any kind (i.e. we could never invoke your ws-hanlder- chain ejb interceptor without a security check). But I do know the check needs to contain the MessageContext rather than method args, which is pretty much the same difference in how InvocationContext works for a ws call vs. an rpc call. There's also a method in javax.ejb.SessionContext for getting the MessageContext only usable on a web service call. What I can't remember is what JACC permission we're supposed to construct. Do you know? 2) InvocationContext and delaying deserialization/serialization of parameters If OpenEJB allowed Geronimo to pass a custom implementation of the InvocationContext object (e.g. maybe an extension of ReflectionInvocationContext) I could modify it so that: a) getContextData() would return the same object as MessageContext (as per spec) b) getParameters() would deserialize the SOAP message (delay deseralization) c) setParameters() would update the SOAP message d) proceed() would keep the object returned and the SOAP message in synch We definitely need to do something along these lines and a new InvocationContext is not an entirely bad idea. The gotchas that may prevent us from taking that route exactly are that I'm pretty sure the full ejb interceptors apply to all calls, not just rpc, and would need to get invoked too. Would have to verify that, so any info you have about ejb interceptors as they may differ from ejb web service handler chains would help. Also there are some very complex exception handling rules for ejb which might make that hard -- app exception vs system exception and now in the ejb3 spec ejbs can throw runtime exceptions as app exceptions on any call if they've marked them in the deployment descriptor and this directly affects how interceptors are processed. We also need to handle the java to xml marshaling of the bean method's return value or exception. Not sure how that would fit in. It's definitely clear we need the MessageContext itself passed in from the web service layer as it's required in at least three different places that i can think of. We might be able to get by with a CXF or Axis Interceptor that we insert into interceptor stack right before the bean method call. It's job would be to unmarshall the data in the MessageContext into some known place in the ContextData so we can invoke the bean, then it would marshal the return value or exception so it can be passed up the chain normally. That would be assuming of course that ejb rpc and ejb ws handlers are the same and only the InvocationContext needs to be different. So I guess that's really the question of the day. Will dig around. -David
