You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2006/06/07 10:14:17 UTC
1.1 Candidate releases available
Geronimo Users and Developers,
We've been busy little beavers this evening and would like to share the fruits of our labor.
First, may we present the candidate build of Geronimo in Octographic quality. We have big builds,
little builds, some for Windows and others for Unix and of course the ever enjoyable Tomcat and
Jetty versions. Please take some time to take these builds and verify that they meet your exacting
standards for a Geronimo Release. As we like to say, "Big G, Little G and things that rhyme with G."
*Jetty*
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip
*Tomcat*
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip
Remaining items.
1. We need the ActiveMQ 3.2.4 to be released.
2. Finalize release notes (Hernan...can you pick this one up? A set for today would be good)
3. Move the remainging JIRAs out of 1.1. (Aaron, Dain, anyone ?)
4. Fix OpenEJB Source. I versioned and released it but I haven't fixed the SVN repo yet. I'll do
this in the morning unless someone beats me to it.
5. A vote. I'm note sure if this can qualify for a vote since there is a SNAPSHOT in the release.
It won't change but need to note that. Thoughts?
To complete an official release I need to finalize the project version and rebuild once again.
Its late and I'm probably missing something so if there are barriers to completing the final release
please let me know ASAP.
I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out and going.
Thanks in advance for taking time to review this release of AG 1.1.
The Geronimo Development Team
Re: 1.1 Candidate releases available
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Looks like the console isn't identifying the correct TranQL RAR file,
perhaps? I'll take a look. I guess we better check the JMS resource
screen too, since it also needs a RAR file to work.
John and Guillaume, with regard to the attribute manager problem, I
can't reproduce it -- are you still seeing this? Definitely not a
disk space issue?
Thanks,
Aaron
On 6/8/06, Mario Rübsam <mr...@coderesearch.com> wrote:
> I had no problems deploying the db plan with the command line
> deployer so I assume that this is a problem with the portlet
> when displaying the plan.
>
> Try to modify the XA plan by hand and deploy it with the
> command line deployer. This should work for the moment.
>
> Thanks,
> Mario
>
> Krishnakumar B wrote:
> > hi,
> >
> > Even i have errors using the console to deploy a Pool. I am able to
> > create a Derby embedded XA Pool but not a Derby embedded Pool.
> >
> > Error attached :
> > 14:33:22,204 ERROR [DatabasePoolPortlet] Unable to save connection pool
> > java.lang.NullPointerException
> > at
> > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
> > t.save(DatabasePoolPortlet.java:876)
> > at
> > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
> > t.processAction(DatabasePoolPortlet.java:336)
> > 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:615)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> > at
> > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> >
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> > icationFilterChain.java:252)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> > ilterChain.java:173)
> > at
> > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
> > atcher.java:672)
> > at
> > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
> > ispatcher.java:574)
> > at
> > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
> > patcher.java:499)
> > at
> > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
> > rImpl.java:120)
> > at
> > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke
> > rImpl.java:68)
> > at
> > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon
> > tainerImpl.java:164)
> > at
> > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP
> > ortletAction(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:615)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> > icationFilterChain.java:252)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> > ilterChain.java:173)
> > at
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> > alve.java:213)
> > at
> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> > alve.java:178)
> > at
> > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> > bjectValve.java:52)
> > at
> > org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> > torBase.java:524)
> > at
> > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> > invoke(GeronimoStandardContext.java:342)
> > at
> > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> > nimoBeforeAfterValve.java:31)
> > at
> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> > ava:126)
> > at
> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> > ava:105)
> > at
> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> > ve.java:107)
> > at
> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> > a:148)
> > at
> > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> > :869)
> > at
> > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
> > rocessConnection(Http11BaseProtocol.java:667)
> > at
> > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
> > int.java:527)
> > at
> > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
> > lowerWorkerThread.java:80)
> > at
> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
> > ool.java:684)
> > at java.lang.Thread.run(Thread.java:534)
> >
> >
> > Regards
> > Krish
> >
> > On 6/8/06, Mario Rübsam <mr...@coderesearch.com> wrote:
> >> Hi,
> >>
> >> I constantly have a NPE during the deployment of a database with and
> >> without
> >> the download driver feature using this release candidate. I appears
> >> when I
> >> try to deploy or to show the plan. Testing the connection is successful.
> >>
> >> Exception is attached. Anybody with the same experience?
> >>
> >> Thanks,
> >> Mario
> >>
> >>
> >>
> >> 09:40:40,375 ERROR [DatabasePoolPortlet] Unable to save connection pool
> >> java.lang.NullPointerException
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876)
> >>
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
> >>
> >> 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:615)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> 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:615)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
> >>
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> >> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> >> at
> >> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> >> at
> >> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> >> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> >> at
> >> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> >> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> >> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> >> 09:40:40,406 ERROR [DatabasePoolPortlet] Unable to render portlet
> >> java.lang.NullPointerException
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderPlan(DatabasePoolPortlet.java:831)
> >>
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:679)
> >>
> >> 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:595)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> 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
> >> org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:105)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:254)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
> >>
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> >> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> >> at
> >> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> >> at
> >> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> >> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> >> at
> >> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> >> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> >> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> >>
> >>
> >>
> >
>
Re: 1.1 Candidate releases available
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Looks like the console isn't identifying the correct TranQL RAR file,
perhaps? I'll take a look. I guess we better check the JMS resource
screen too, since it also needs a RAR file to work.
John and Guillaume, with regard to the attribute manager problem, I
can't reproduce it -- are you still seeing this? Definitely not a
disk space issue?
Thanks,
Aaron
On 6/8/06, Mario Rübsam <mr...@coderesearch.com> wrote:
> I had no problems deploying the db plan with the command line
> deployer so I assume that this is a problem with the portlet
> when displaying the plan.
>
> Try to modify the XA plan by hand and deploy it with the
> command line deployer. This should work for the moment.
>
> Thanks,
> Mario
>
> Krishnakumar B wrote:
> > hi,
> >
> > Even i have errors using the console to deploy a Pool. I am able to
> > create a Derby embedded XA Pool but not a Derby embedded Pool.
> >
> > Error attached :
> > 14:33:22,204 ERROR [DatabasePoolPortlet] Unable to save connection pool
> > java.lang.NullPointerException
> > at
> > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
> > t.save(DatabasePoolPortlet.java:876)
> > at
> > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
> > t.processAction(DatabasePoolPortlet.java:336)
> > 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:615)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> > at
> > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> >
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> > icationFilterChain.java:252)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> > ilterChain.java:173)
> > at
> > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
> > atcher.java:672)
> > at
> > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
> > ispatcher.java:574)
> > at
> > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
> > patcher.java:499)
> > at
> > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
> > rImpl.java:120)
> > at
> > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke
> > rImpl.java:68)
> > at
> > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon
> > tainerImpl.java:164)
> > at
> > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP
> > ortletAction(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:615)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> > icationFilterChain.java:252)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> > ilterChain.java:173)
> > at
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> > alve.java:213)
> > at
> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> > alve.java:178)
> > at
> > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> > bjectValve.java:52)
> > at
> > org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> > torBase.java:524)
> > at
> > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> > invoke(GeronimoStandardContext.java:342)
> > at
> > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> > nimoBeforeAfterValve.java:31)
> > at
> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> > ava:126)
> > at
> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> > ava:105)
> > at
> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> > ve.java:107)
> > at
> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> > a:148)
> > at
> > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> > :869)
> > at
> > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
> > rocessConnection(Http11BaseProtocol.java:667)
> > at
> > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
> > int.java:527)
> > at
> > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
> > lowerWorkerThread.java:80)
> > at
> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
> > ool.java:684)
> > at java.lang.Thread.run(Thread.java:534)
> >
> >
> > Regards
> > Krish
> >
> > On 6/8/06, Mario Rübsam <mr...@coderesearch.com> wrote:
> >> Hi,
> >>
> >> I constantly have a NPE during the deployment of a database with and
> >> without
> >> the download driver feature using this release candidate. I appears
> >> when I
> >> try to deploy or to show the plan. Testing the connection is successful.
> >>
> >> Exception is attached. Anybody with the same experience?
> >>
> >> Thanks,
> >> Mario
> >>
> >>
> >>
> >> 09:40:40,375 ERROR [DatabasePoolPortlet] Unable to save connection pool
> >> java.lang.NullPointerException
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876)
> >>
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
> >>
> >> 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:615)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> 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:615)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
> >>
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> >> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> >> at
> >> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> >> at
> >> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> >> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> >> at
> >> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> >> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> >> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> >> 09:40:40,406 ERROR [DatabasePoolPortlet] Unable to render portlet
> >> java.lang.NullPointerException
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderPlan(DatabasePoolPortlet.java:831)
> >>
> >> at
> >> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:679)
> >>
> >> 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:595)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> 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
> >> org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at
> >> org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:105)
> >>
> >> at
> >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> >> at
> >> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> >> at
> >> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> >>
> >> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:254)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >> at
> >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >> at
> >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> >>
> >> at
> >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> >>
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> >>
> >> at
> >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> >> at
> >> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
> >>
> >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> >> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> >> at
> >> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> >> at
> >> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> >> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> >> at
> >> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> >> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> >> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> >>
> >>
> >>
> >
>
Re: 1.1 Candidate releases available
Posted by Mario Rübsam <mr...@coderesearch.com>.
I had no problems deploying the db plan with the command line
deployer so I assume that this is a problem with the portlet
when displaying the plan.
Try to modify the XA plan by hand and deploy it with the
command line deployer. This should work for the moment.
Thanks,
Mario
Krishnakumar B wrote:
> hi,
>
> Even i have errors using the console to deploy a Pool. I am able to
> create a Derby embedded XA Pool but not a Derby embedded Pool.
>
> Error attached :
> 14:33:22,204 ERROR [DatabasePoolPortlet] Unable to save connection pool
> java.lang.NullPointerException
> at
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
> t.save(DatabasePoolPortlet.java:876)
> at
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
> t.processAction(DatabasePoolPortlet.java:336)
> 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:615)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:173)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
> atcher.java:672)
> at
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
> ispatcher.java:574)
> at
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
> patcher.java:499)
> at
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
> rImpl.java:120)
> at
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke
> rImpl.java:68)
> at
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon
> tainerImpl.java:164)
> at
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP
> ortletAction(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:615)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:173)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:178)
> at
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:52)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> torBase.java:524)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:342)
> at
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:31)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:105)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:148)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :869)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
> rocessConnection(Http11BaseProtocol.java:667)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
> int.java:527)
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
> lowerWorkerThread.java:80)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
> ool.java:684)
> at java.lang.Thread.run(Thread.java:534)
>
>
> Regards
> Krish
>
> On 6/8/06, Mario Rübsam <mr...@coderesearch.com> wrote:
>> Hi,
>>
>> I constantly have a NPE during the deployment of a database with and
>> without
>> the download driver feature using this release candidate. I appears
>> when I
>> try to deploy or to show the plan. Testing the connection is successful.
>>
>> Exception is attached. Anybody with the same experience?
>>
>> Thanks,
>> Mario
>>
>>
>>
>> 09:40:40,375 ERROR [DatabasePoolPortlet] Unable to save connection pool
>> java.lang.NullPointerException
>> at
>> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876)
>>
>> at
>> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
>>
>> 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:615)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
>> at
>> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
>> 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:615)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
>> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
>> at
>> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
>>
>> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
>> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
>> at
>> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
>> at
>> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
>> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
>> at
>> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
>> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
>> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
>> 09:40:40,406 ERROR [DatabasePoolPortlet] Unable to render portlet
>> java.lang.NullPointerException
>> at
>> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderPlan(DatabasePoolPortlet.java:831)
>>
>> at
>> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:679)
>>
>> 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:595)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
>> at
>> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
>> 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
>> org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60)
>>
>> at
>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
>> at
>> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
>> at
>> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>>
>> at
>> org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57)
>>
>> at
>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
>> at
>> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
>> at
>> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>>
>> at
>> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
>>
>> at
>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
>> at
>> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
>> at
>> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>>
>> at
>> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
>>
>> at
>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
>> at
>> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
>> at
>> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>>
>> at
>> org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:105)
>>
>> at
>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
>> at
>> org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
>> at
>> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>>
>> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:254)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>> at
>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
>>
>> at
>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
>>
>> at
>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
>>
>> at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
>> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
>> at
>> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
>>
>> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
>> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
>> at
>> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
>> at
>> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
>> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
>> at
>> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
>> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
>> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
>>
>>
>>
>
Re: 1.1 Candidate releases available
Posted by Krishnakumar B <ww...@gmail.com>.
hi,
Even i have errors using the console to deploy a Pool. I am able to
create a Derby embedded XA Pool but not a Derby embedded Pool.
Error attached :
14:33:22,204 ERROR [DatabasePoolPortlet] Unable to save connection pool
java.lang.NullPointerException
at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
t.save(DatabasePoolPortlet.java:876)
at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortle
t.processAction(DatabasePoolPortlet.java:336)
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:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:672)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:574)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:499)
at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
rImpl.java:120)
at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke
rImpl.java:68)
at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon
tainerImpl.java:164)
at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP
ortletAction(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:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
bjectValve.java:52)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:524)
at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
invoke(GeronimoStandardContext.java:342)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
nimoBeforeAfterValve.java:31)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
rocessConnection(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
int.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
lowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:684)
at java.lang.Thread.run(Thread.java:534)
Regards
Krish
On 6/8/06, Mario Rübsam <mr...@coderesearch.com> wrote:
> Hi,
>
> I constantly have a NPE during the deployment of a database with and without
> the download driver feature using this release candidate. I appears when I
> try to deploy or to show the plan. Testing the connection is successful.
>
> Exception is attached. Anybody with the same experience?
>
> Thanks,
> Mario
>
>
>
> 09:40:40,375 ERROR [DatabasePoolPortlet] Unable to save connection pool
> java.lang.NullPointerException
> at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876)
> at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
> 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:615)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> 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:615)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> 09:40:40,406 ERROR [DatabasePoolPortlet] Unable to render portlet
> java.lang.NullPointerException
> at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderPlan(DatabasePoolPortlet.java:831)
> at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:679)
> 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:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> 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 org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> at org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> at org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> at org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:105)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:254)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
>
>
>
Re: 1.1 Candidate releases available
Posted by Mario Rübsam <mr...@coderesearch.com>.
Hi,
I constantly have a NPE during the deployment of a database with and without
the download driver feature using this release candidate. I appears when I
try to deploy or to show the plan. Testing the connection is successful.
Exception is attached. Anybody with the same experience?
Thanks,
Mario
Re: Plugin versioning problems
Posted by Dain Sundstrom <da...@iq80.com>.
GERONIMO-1637
-dain
On Jun 8, 2006, at 6:16 AM, Aaron Mulder wrote:
> Perhaps I was unclear; I didn't mean to say this was a bad idea, only
> that our code doesn't currently support it. I expect version ranges
> are on the road map, but if you want to work on them, you're more than
> welcome to. :)
>
> I don't think this is a G 1.1.x discussion, since AFAIK it would
> require kernel changes.
>
> Thanks,
> Aaron
>
> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> > What I meant by 1.1.* was the Maven behavior of private builds like
>> > 1.1-1 being taken as newer than 1.1. Also, being able to use the
>> > behavior of 1.1-<starting with any alpha> is less than 1.1.
>> Basically,
>> > I should be able to specify 1.1 in the plugin and have it work on
>> > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't
>> on 1.1.1,
>> > then I'd argue that we broke something in 1.1.1, given it should
>> only be
>> > a maintenance release and app/plan breaking changes should only
>> go into 1.2.
>>
>> +1 This approach is similar to how eclipse plugin versioning works.
>>
>> From http://www.eclipse.org/equinox/documents/plugin-
>> versioning.html :
>> "How to specify plug-in requirements
>> Plug-ins that require other plug-ins must qualify their requirements
>> with a version range since the absence of a version range means that
>> any version can satisfy the dependency. Given that all the changes
>> between the version x.0.0 and the version x+1.0.0 excluded must be
>> compatible (given the previous guidelines); the recommended range
>> includes the minimal required version up-to but not including the
>> next
>> major release."
>>
>> IMHO geronimo should adopt eclipse's strategy for plugin versioning
>> where possible since the two sets of base requirements are quite
>> similar and eclipse is a few years ahead in this area. The document
>> referenced above spells out their strategy in detail.
>>
>> Best wishes,
>> Paul
>>
Re: Plugin versioning problems
Posted by Matt Hogstrom <ma...@hogstrom.org>.
OSGI does version ranges :)
Aaron Mulder wrote:
> Perhaps I was unclear; I didn't mean to say this was a bad idea, only
> that our code doesn't currently support it. I expect version ranges
> are on the road map, but if you want to work on them, you're more than
> welcome to. :)
>
> I don't think this is a G 1.1.x discussion, since AFAIK it would
> require kernel changes.
>
> Thanks,
> Aaron
>
> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> > What I meant by 1.1.* was the Maven behavior of private builds like
>> > 1.1-1 being taken as newer than 1.1. Also, being able to use the
>> > behavior of 1.1-<starting with any alpha> is less than 1.1. Basically,
>> > I should be able to specify 1.1 in the plugin and have it work on
>> > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on
>> 1.1.1,
>> > then I'd argue that we broke something in 1.1.1, given it should
>> only be
>> > a maintenance release and app/plan breaking changes should only go
>> into 1.2.
>>
>> +1 This approach is similar to how eclipse plugin versioning works.
>>
>> From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
>> "How to specify plug-in requirements
>> Plug-ins that require other plug-ins must qualify their requirements
>> with a version range since the absence of a version range means that
>> any version can satisfy the dependency. Given that all the changes
>> between the version x.0.0 and the version x+1.0.0 excluded must be
>> compatible (given the previous guidelines); the recommended range
>> includes the minimal required version up-to but not including the next
>> major release."
>>
>> IMHO geronimo should adopt eclipse's strategy for plugin versioning
>> where possible since the two sets of base requirements are quite
>> similar and eclipse is a few years ahead in this area. The document
>> referenced above spells out their strategy in detail.
>>
>> Best wishes,
>> Paul
>>
>
>
>
Re: Plugin versioning problems
Posted by Donald Woods <dr...@yahoo.com>.
So, it definetly doesn't warrent a major last minute rework to 1.1, but
it does worry me that we and our user community may waste a lot of time
creating plugins for 1.1, just to have to rerelease them for 1.1.1. If
we can come up with a patch for 1.1.1 that would allow plugins to
effectively say "I work on Geronimo 1.1*" or "I work on Geronimo 1.2*",
then I think we would have a solution that application and services
providers could really jump on and start using.
For 1.2, we definetly need to discuss this whole plugin feature and
agree on real user application and system upgrade scenarios, so we can
enhance/test/verify the current implementation to support as many
scenarios as possible along with providing much needed docs and tooling...
-Donald
Aaron Mulder wrote:
> Well, if you're going to submit that patch, you need to include a
> change in the annotation in the plugin schema along with it -- it
> specifically says that field is an exact match.
>
> I'm still not sure I'm on board with this, though. I don't feel like
> we can say with confidence that a plugin that works in 1.1 will work
> in all 1.1.x releases. Perhaps if we can articulate the rules for
> what changes are acceptable for 1.1, and that implies that plugins
> shouldn't break, then I'd feel more comfortable with this. We'd also
> have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
> the initial 1.1 release, you could.
>
> Thanks,
> Aaron
>
> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>
>> I definitely agree that a full fledged solution for version ranges is
>> out of scope for G 1.1.x. I was thinking that a minor change to the
>> plugin installer's version checking could at least partially address
>> Donald's concerns and also avoid the version mismatch problem Dave C.
>> found in the candidate build. Here's a patch that makes the plugin
>> installer only check the digits of geronimo's version that the
>> plugin's xml specifies. So if the plugin specifies
>> <geronimo-version>1.1</geronimo-version> then it can be installed into
>> 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>>
>> Best wishes,
>> Paul
>>
>> Index:
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>>
>> ===================================================================
>> ---
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>> (revision
>> 412744)
>> +++
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>> (working
>> copy)
>> @@ -1409,7 +1409,7 @@
>> if(gerVersion == null || gerVersion.equals("")) {
>> throw new IllegalStateException("geronimo-version
>> should not be empty!");
>> }
>> - if(gerVersion.equals(version)) {
>> + if(version.startsWith(gerVersion)) {
>> match = true;
>> break;
>> }
>>
>>
>> On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>> > Perhaps I was unclear; I didn't mean to say this was a bad idea, only
>> > that our code doesn't currently support it. I expect version ranges
>> > are on the road map, but if you want to work on them, you're more than
>> > welcome to. :)
>> >
>> > I don't think this is a G 1.1.x discussion, since AFAIK it would
>> > require kernel changes.
>> >
>> > Thanks,
>> > Aaron
>> >
>> > On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> > > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> > > > What I meant by 1.1.* was the Maven behavior of private builds like
>> > > > 1.1-1 being taken as newer than 1.1. Also, being able to use the
>> > > > behavior of 1.1-<starting with any alpha> is less than 1.1.
>> Basically,
>> > > > I should be able to specify 1.1 in the plugin and have it work on
>> > > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't
>> on 1.1.1,
>> > > > then I'd argue that we broke something in 1.1.1, given it should
>> only be
>> > > > a maintenance release and app/plan breaking changes should only
>> go into 1.2.
>> > >
>> > > +1 This approach is similar to how eclipse plugin versioning works.
>> > >
>> > > From
>> http://www.eclipse.org/equinox/documents/plugin-versioning.html :
>> > > "How to specify plug-in requirements
>> > > Plug-ins that require other plug-ins must qualify their requirements
>> > > with a version range since the absence of a version range means that
>> > > any version can satisfy the dependency. Given that all the changes
>> > > between the version x.0.0 and the version x+1.0.0 excluded must be
>> > > compatible (given the previous guidelines); the recommended range
>> > > includes the minimal required version up-to but not including the
>> next
>> > > major release."
>> > >
>> > > IMHO geronimo should adopt eclipse's strategy for plugin versioning
>> > > where possible since the two sets of base requirements are quite
>> > > similar and eclipse is a few years ahead in this area. The document
>> > > referenced above spells out their strategy in detail.
>> > >
>> > > Best wishes,
>> > > Paul
>> > >
>> >
>>
>
>
Re: Plugin versioning problems
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I think the guiding principle for a plugin should be a lack of version sensitivity so a variety of
ranges would be acceptable. Unfortunately, Geronimo is not in a position technically where it can
be that flexible. I thin avoiding the situation below about having to release a 1.1.0 is a last
resort option. I think that is your intention, is that right Aaron ? Plugins should have the
ability internally to say they only work on a specific release. However, that begs the question
about patched versions. It doesn't seem to me that the project is going to supply patches but will
simply rev the whole server and provide a new pint release. Is that consistent with other people's
thinking ?
Aaron Mulder wrote:
> Well, if you're going to submit that patch, you need to include a
> change in the annotation in the plugin schema along with it -- it
> specifically says that field is an exact match.
>
> I'm still not sure I'm on board with this, though. I don't feel like
> we can say with confidence that a plugin that works in 1.1 will work
> in all 1.1.x releases. Perhaps if we can articulate the rules for
> what changes are acceptable for 1.1, and that implies that plugins
> shouldn't break, then I'd feel more comfortable with this. We'd also
> have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
> the initial 1.1 release, you could.
>
> Thanks,
> Aaron
>
> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> I definitely agree that a full fledged solution for version ranges is
>> out of scope for G 1.1.x. I was thinking that a minor change to the
>> plugin installer's version checking could at least partially address
>> Donald's concerns and also avoid the version mismatch problem Dave C.
>> found in the candidate build. Here's a patch that makes the plugin
>> installer only check the digits of geronimo's version that the
>> plugin's xml specifies. So if the plugin specifies
>> <geronimo-version>1.1</geronimo-version> then it can be installed into
>> 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>>
>> Best wishes,
>> Paul
>>
>> Index:
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>>
>> ===================================================================
>> ---
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>> (revision
>> 412744)
>> +++
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>> (working
>> copy)
>> @@ -1409,7 +1409,7 @@
>> if(gerVersion == null || gerVersion.equals("")) {
>> throw new IllegalStateException("geronimo-version
>> should not be empty!");
>> }
>> - if(gerVersion.equals(version)) {
>> + if(version.startsWith(gerVersion)) {
>> match = true;
>> break;
>> }
>>
>>
>> On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>> > Perhaps I was unclear; I didn't mean to say this was a bad idea, only
>> > that our code doesn't currently support it. I expect version ranges
>> > are on the road map, but if you want to work on them, you're more than
>> > welcome to. :)
>> >
>> > I don't think this is a G 1.1.x discussion, since AFAIK it would
>> > require kernel changes.
>> >
>> > Thanks,
>> > Aaron
>> >
>> > On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> > > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> > > > What I meant by 1.1.* was the Maven behavior of private builds like
>> > > > 1.1-1 being taken as newer than 1.1. Also, being able to use the
>> > > > behavior of 1.1-<starting with any alpha> is less than 1.1.
>> Basically,
>> > > > I should be able to specify 1.1 in the plugin and have it work on
>> > > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't
>> on 1.1.1,
>> > > > then I'd argue that we broke something in 1.1.1, given it should
>> only be
>> > > > a maintenance release and app/plan breaking changes should only
>> go into 1.2.
>> > >
>> > > +1 This approach is similar to how eclipse plugin versioning works.
>> > >
>> > > From
>> http://www.eclipse.org/equinox/documents/plugin-versioning.html :
>> > > "How to specify plug-in requirements
>> > > Plug-ins that require other plug-ins must qualify their requirements
>> > > with a version range since the absence of a version range means that
>> > > any version can satisfy the dependency. Given that all the changes
>> > > between the version x.0.0 and the version x+1.0.0 excluded must be
>> > > compatible (given the previous guidelines); the recommended range
>> > > includes the minimal required version up-to but not including the
>> next
>> > > major release."
>> > >
>> > > IMHO geronimo should adopt eclipse's strategy for plugin versioning
>> > > where possible since the two sets of base requirements are quite
>> > > similar and eclipse is a few years ahead in this area. The document
>> > > referenced above spells out their strategy in detail.
>> > >
>> > > Best wishes,
>> > > Paul
>> > >
>> >
>>
>
>
>
Re: Plugin versioning problems
Posted by David Blevins <da...@visi.com>.
On Jun 8, 2006, at 9:12 AM, Aaron Mulder wrote:
> Well, if you're going to submit that patch, you need to include a
> change in the annotation in the plugin schema along with it -- it
> specifically says that field is an exact match.
>
> I'm still not sure I'm on board with this, though. I don't feel like
> we can say with confidence that a plugin that works in 1.1 will work
> in all 1.1.x releases. Perhaps if we can articulate the rules for
> what changes are acceptable for 1.1, and that implies that plugins
> shouldn't break, then I'd feel more comfortable with this. We'd also
> have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
> the initial 1.1 release, you could.
I'm not sure I'm on board with the plugins claiming knowledge of who
can use it and what versions they are -- seems backwards to me. I'd
rather see each new Geronimo or Geronimo-based platform version
maintain a list of plugins and their versions known to work (and that
list should be updatable post-release). In other words, why not have
the platform track the compatiable plugins rather than the plugins
tracking the compatible platforms?
In either case, a user should be able to say "I don't care, just do
it" if versions don't match up.
It's somewhat a "half a dozen of one" or "six of the other" type of
problem, but in the end i'd opt for making things as easy as possible
for plugin developers even if it makes things more complicated for
us. Ideally, users would make plugins out of everything and go
plugin crazy.
For now, I'd be fine with non-exact matching in the manner proposed.
Maybe with the addition of a wiki page for each plugin where people
can document known compatibility issues.
My $0.02
-David
> Thanks,
> Aaron
>
> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> I definitely agree that a full fledged solution for version ranges is
>> out of scope for G 1.1.x. I was thinking that a minor change to the
>> plugin installer's version checking could at least partially address
>> Donald's concerns and also avoid the version mismatch problem Dave C.
>> found in the candidate build. Here's a patch that makes the plugin
>> installer only check the digits of geronimo's version that the
>> plugin's xml specifies. So if the plugin specifies
>> <geronimo-version>1.1</geronimo-version> then it can be installed
>> into
>> 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>>
>> Best wishes,
>> Paul
>>
>> Index: modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java
>> ===================================================================
>> --- modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java (revision
>> 412744)
>> +++ modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java (working
>> copy)
>> @@ -1409,7 +1409,7 @@
>> if(gerVersion == null || gerVersion.equals("")) {
>> throw new IllegalStateException("geronimo-version
>> should not be empty!");
>> }
>> - if(gerVersion.equals(version)) {
>> + if(version.startsWith(gerVersion)) {
>> match = true;
>> break;
>> }
>>
>>
>> On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>> > Perhaps I was unclear; I didn't mean to say this was a bad idea,
>> only
>> > that our code doesn't currently support it. I expect version
>> ranges
>> > are on the road map, but if you want to work on them, you're
>> more than
>> > welcome to. :)
>> >
>> > I don't think this is a G 1.1.x discussion, since AFAIK it would
>> > require kernel changes.
>> >
>> > Thanks,
>> > Aaron
>> >
>> > On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> > > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> > > > What I meant by 1.1.* was the Maven behavior of private
>> builds like
>> > > > 1.1-1 being taken as newer than 1.1. Also, being able to
>> use the
>> > > > behavior of 1.1-<starting with any alpha> is less than 1.1.
>> Basically,
>> > > > I should be able to specify 1.1 in the plugin and have it
>> work on
>> > > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
>> doesn't on 1.1.1,
>> > > > then I'd argue that we broke something in 1.1.1, given it
>> should only be
>> > > > a maintenance release and app/plan breaking changes should
>> only go into 1.2.
>> > >
>> > > +1 This approach is similar to how eclipse plugin versioning
>> works.
>> > >
>> > > From http://www.eclipse.org/equinox/documents/plugin-
>> versioning.html :
>> > > "How to specify plug-in requirements
>> > > Plug-ins that require other plug-ins must qualify their
>> requirements
>> > > with a version range since the absence of a version range
>> means that
>> > > any version can satisfy the dependency. Given that all the
>> changes
>> > > between the version x.0.0 and the version x+1.0.0 excluded
>> must be
>> > > compatible (given the previous guidelines); the recommended range
>> > > includes the minimal required version up-to but not including
>> the next
>> > > major release."
>> > >
>> > > IMHO geronimo should adopt eclipse's strategy for plugin
>> versioning
>> > > where possible since the two sets of base requirements are quite
>> > > similar and eclipse is a few years ahead in this area. The
>> document
>> > > referenced above spells out their strategy in detail.
>> > >
>> > > Best wishes,
>> > > Paul
>> > >
>> >
>>
>
Re: Plugin versioning problems
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Well, if you're going to submit that patch, you need to include a
change in the annotation in the plugin schema along with it -- it
specifically says that field is an exact match.
I'm still not sure I'm on board with this, though. I don't feel like
we can say with confidence that a plugin that works in 1.1 will work
in all 1.1.x releases. Perhaps if we can articulate the rules for
what changes are acceptable for 1.1, and that implies that plugins
shouldn't break, then I'd feel more comfortable with this. We'd also
have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
the initial 1.1 release, you could.
Thanks,
Aaron
On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
> I definitely agree that a full fledged solution for version ranges is
> out of scope for G 1.1.x. I was thinking that a minor change to the
> plugin installer's version checking could at least partially address
> Donald's concerns and also avoid the version mismatch problem Dave C.
> found in the candidate build. Here's a patch that makes the plugin
> installer only check the digits of geronimo's version that the
> plugin's xml specifies. So if the plugin specifies
> <geronimo-version>1.1</geronimo-version> then it can be installed into
> 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>
> Best wishes,
> Paul
>
> Index: modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
> ===================================================================
> --- modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java (revision
> 412744)
> +++ modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java (working
> copy)
> @@ -1409,7 +1409,7 @@
> if(gerVersion == null || gerVersion.equals("")) {
> throw new IllegalStateException("geronimo-version
> should not be empty!");
> }
> - if(gerVersion.equals(version)) {
> + if(version.startsWith(gerVersion)) {
> match = true;
> break;
> }
>
>
> On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > Perhaps I was unclear; I didn't mean to say this was a bad idea, only
> > that our code doesn't currently support it. I expect version ranges
> > are on the road map, but if you want to work on them, you're more than
> > welcome to. :)
> >
> > I don't think this is a G 1.1.x discussion, since AFAIK it would
> > require kernel changes.
> >
> > Thanks,
> > Aaron
> >
> > On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
> > > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> > > > What I meant by 1.1.* was the Maven behavior of private builds like
> > > > 1.1-1 being taken as newer than 1.1. Also, being able to use the
> > > > behavior of 1.1-<starting with any alpha> is less than 1.1. Basically,
> > > > I should be able to specify 1.1 in the plugin and have it work on
> > > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1,
> > > > then I'd argue that we broke something in 1.1.1, given it should only be
> > > > a maintenance release and app/plan breaking changes should only go into 1.2.
> > >
> > > +1 This approach is similar to how eclipse plugin versioning works.
> > >
> > > From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
> > > "How to specify plug-in requirements
> > > Plug-ins that require other plug-ins must qualify their requirements
> > > with a version range since the absence of a version range means that
> > > any version can satisfy the dependency. Given that all the changes
> > > between the version x.0.0 and the version x+1.0.0 excluded must be
> > > compatible (given the previous guidelines); the recommended range
> > > includes the minimal required version up-to but not including the next
> > > major release."
> > >
> > > IMHO geronimo should adopt eclipse's strategy for plugin versioning
> > > where possible since the two sets of base requirements are quite
> > > similar and eclipse is a few years ahead in this area. The document
> > > referenced above spells out their strategy in detail.
> > >
> > > Best wishes,
> > > Paul
> > >
> >
>
Re: Plugin versioning problems
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Heh heh... you're right.
Thanks,
Aaron
On 6/9/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
>
> > My main objection to that is then there's no way to say "1.1 only".
> > We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
> > different. Or, I suppose, change your patch to gerVersion.length()-1
> > and encourage "1.1*" not "1.1.*"
>
> I guess my code was bad. My intention was you could call out
> specific versions. Here is a table of what I wanted to happen:
>
> Input Version Range
> ----- -------------
> 1.1 1.1
> 1.1.* [1.1-1.2)
> 1.1.1 1.1.1
> 1.1.1.* [1.1.1-1.1.2)
>
> and here is the code I posted for those that don't wan to read back
> in the thread:
>
> if (version.equals(gerVersion) ||
> (gerVersion.endsWith(".*" &&
> version.startsWith(gerVersion.substring(0, gerVersion.length
> () - 2))) {
>
> With that if statement, the "glob" part of the match only executes if
> the version ended with ".*" otherwise it must be an exact match.
>
> -dain
>
>
Re: Plugin versioning problems
Posted by David Jencks <da...@yahoo.com>.
I think this is a good idea.
david jencks
On Jun 9, 2006, at 2:36 PM, Dain Sundstrom wrote:
> On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
>
>> My main objection to that is then there's no way to say "1.1 only".
>> We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
>> different. Or, I suppose, change your patch to gerVersion.length()-1
>> and encourage "1.1*" not "1.1.*"
>
> I guess my code was bad. My intention was you could call out
> specific versions. Here is a table of what I wanted to happen:
>
> Input Version Range
> ----- -------------
> 1.1 1.1
> 1.1.* [1.1-1.2)
> 1.1.1 1.1.1
> 1.1.1.* [1.1.1-1.1.2)
>
> and here is the code I posted for those that don't wan to read back
> in the thread:
>
> if (version.equals(gerVersion) ||
> (gerVersion.endsWith(".*" &&
> version.startsWith(gerVersion.substring(0, gerVersion.length
> () - 2))) {
>
> With that if statement, the "glob" part of the match only executes
> if the version ended with ".*" otherwise it must be an exact match.
>
> -dain
>
Re: Plugin versioning problems
Posted by Donald Woods <dr...@yahoo.com>.
How about the following slight modification, so it would also work for
-SNAPSHOT or private -REVISION builds?
if (version.equals(gerVersion) ||
(gerVersion.endsWith("*") &&
version.startsWith(gerVersion.substring(0, gerVersion.length()-1))) {
The other choice, would be to treat "." and "-" differently, as in
if ( version.equals(gerVersion) ||
((gerVersion.endsWith(".*") &&
version.startsWith(gerVersion.substring(0, gerVersion.length()-2)) ||
((gerVersion.endsWith("-*") &&
version.startsWith(gerVersion.substring(0, gerVersion.length()-2)) ) {
which has the requirement that plugins being developed and tested
against -SNAPSHOT builds be rereleased for the final .rcN or 1.N build....
-Donald
Dain Sundstrom wrote:
> On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
>
>> My main objection to that is then there's no way to say "1.1 only".
>> We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
>> different. Or, I suppose, change your patch to gerVersion.length()-1
>> and encourage "1.1*" not "1.1.*"
>
>
> I guess my code was bad. My intention was you could call out specific
> versions. Here is a table of what I wanted to happen:
>
> Input Version Range
> ----- -------------
> 1.1 1.1
> 1.1.* [1.1-1.2)
> 1.1.1 1.1.1
> 1.1.1.* [1.1.1-1.1.2)
>
> and here is the code I posted for those that don't wan to read back in
> the thread:
>
> if (version.equals(gerVersion) ||
> (gerVersion.endsWith(".*" &&
> version.startsWith(gerVersion.substring(0, gerVersion.length ()
> - 2))) {
>
> With that if statement, the "glob" part of the match only executes if
> the version ended with ".*" otherwise it must be an exact match.
>
> -dain
>
>
>
Re: Plugin versioning problems
Posted by Dain Sundstrom <da...@iq80.com>.
On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
> My main objection to that is then there's no way to say "1.1 only".
> We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
> different. Or, I suppose, change your patch to gerVersion.length()-1
> and encourage "1.1*" not "1.1.*"
I guess my code was bad. My intention was you could call out
specific versions. Here is a table of what I wanted to happen:
Input Version Range
----- -------------
1.1 1.1
1.1.* [1.1-1.2)
1.1.1 1.1.1
1.1.1.* [1.1.1-1.1.2)
and here is the code I posted for those that don't wan to read back
in the thread:
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
With that if statement, the "glob" part of the match only executes if
the version ended with ".*" otherwise it must be an exact match.
-dain
Re: Plugin versioning problems
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
My main objection to that is then there's no way to say "1.1 only".
We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage "1.1*" not "1.1.*"
Thanks,
Aaron
On 6/9/06, Dain Sundstrom <da...@iq80.com> wrote:
> If we really need it, I think the syntax 1.1.* would be ok since it
> would easily be parseable and translated to [1.1-1.2) in a formal
> version syntax. For the patch, I'm thinking of something like
>
> if (version.equals(gerVersion) ||
> (gerVersion.endsWith(".*" &&
> version.startsWith(gerVersion.substring(0, gerVersion.length
> () - 2))) {
>
> match = true;
> break;
> }
>
> Don't trust that code; I free styled it in this email, but you get
> the idea.
>
> I do think this is too risky for 1.1 since this code could easily
> have unintended consequences.
>
> -dain
>
> On Jun 9, 2006, at 5:59 AM, Paul McMahan wrote:
>
> > That's a good idea and it would be pretty straightforward. But now
> > that Dain has brought our attention to GERONIMO-1637 I'm concerned
> > about deviating from the G 1.2 activities where the full syntax of
> > maven version ranges will be introduced. I don't know much about
> > maven version ranges - there may be some subset that can be
> > implemented during G 1.1.x that addresses our specific concerns about
> > forcing plugins to continually update their geronimo-plugin.xml.
> >
> > Best wishes,
> > Paul
> >
> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> >> Paul, what if we tweaked your proposed patch and allowed the
> >> plugin to
> >> provide an optional attribute of exactVersion=required, which would
> >> control the behavior?
> >>
> >> -Donald
> >>
> >> Paul McMahan wrote:
> >> > I definitely agree that a full fledged solution for version
> >> ranges is
> >> > out of scope for G 1.1.x. I was thinking that a minor change to
> >> the
> >> > plugin installer's version checking could at least partially
> >> address
> >> > Donald's concerns and also avoid the version mismatch problem
> >> Dave C.
> >> > found in the candidate build. Here's a patch that makes the plugin
> >> > installer only check the digits of geronimo's version that the
> >> > plugin's xml specifies. So if the plugin specifies
> >> > <geronimo-version>1.1</geronimo-version> then it can be
> >> installed into
> >> > 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
> >> >
> >> > Best wishes,
> >> > Paul
> >> >
> >> > Index:
> >> > modules/system/src/java/org/apache/geronimo/system/plugin/
> >> PluginInstallerGBean.java
> >> >
> >> > ===================================================================
> >> > ---
> >> > modules/system/src/java/org/apache/geronimo/system/plugin/
> >> PluginInstallerGBean.java
> >> > (revision
> >> > 412744)
> >> > +++
> >> > modules/system/src/java/org/apache/geronimo/system/plugin/
> >> PluginInstallerGBean.java
> >> > (working
> >> > copy)
> >> > @@ -1409,7 +1409,7 @@
> >> > if(gerVersion == null || gerVersion.equals("")) {
> >> > throw new IllegalStateException("geronimo-version
> >> > should not be empty!");
> >> > }
> >> > - if(gerVersion.equals(version)) {
> >> > + if(version.startsWith(gerVersion)) {
> >> > match = true;
> >> > break;
> >> > }
> >> >
> >> >
> >> > On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> >> >
> >> >> Perhaps I was unclear; I didn't mean to say this was a bad
> >> idea, only
> >> >> that our code doesn't currently support it. I expect version
> >> ranges
> >> >> are on the road map, but if you want to work on them, you're
> >> more than
> >> >> welcome to. :)
> >> >>
> >> >> I don't think this is a G 1.1.x discussion, since AFAIK it would
> >> >> require kernel changes.
> >> >>
> >> >> Thanks,
> >> >> Aaron
> >> >>
> >> >> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
> >> >> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> >> >> > > What I meant by 1.1.* was the Maven behavior of private
> >> builds like
> >> >> > > 1.1-1 being taken as newer than 1.1. Also, being able to
> >> use the
> >> >> > > behavior of 1.1-<starting with any alpha> is less than 1.1.
> >> >> Basically,
> >> >> > > I should be able to specify 1.1 in the plugin and have it
> >> work on
> >> >> > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
> >> doesn't on
> >> >> 1.1.1,
> >> >> > > then I'd argue that we broke something in 1.1.1, given it
> >> should
> >> >> only be
> >> >> > > a maintenance release and app/plan breaking changes should
> >> only go
> >> >> into 1.2.
> >> >> >
> >> >> > +1 This approach is similar to how eclipse plugin
> >> versioning works.
> >> >> >
> >> >> > From http://www.eclipse.org/equinox/documents/plugin-
> >> versioning.html :
> >> >> > "How to specify plug-in requirements
> >> >> > Plug-ins that require other plug-ins must qualify their
> >> requirements
> >> >> > with a version range since the absence of a version range
> >> means that
> >> >> > any version can satisfy the dependency. Given that all the
> >> changes
> >> >> > between the version x.0.0 and the version x+1.0.0 excluded
> >> must be
> >> >> > compatible (given the previous guidelines); the recommended
> >> range
> >> >> > includes the minimal required version up-to but not including
> >> the next
> >> >> > major release."
> >> >> >
> >> >> > IMHO geronimo should adopt eclipse's strategy for plugin
> >> versioning
> >> >> > where possible since the two sets of base requirements are quite
> >> >> > similar and eclipse is a few years ahead in this area. The
> >> document
> >> >> > referenced above spells out their strategy in detail.
> >> >> >
> >> >> > Best wishes,
> >> >> > Paul
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >>
> >>
>
>
Re: Plugin versioning problems
Posted by Dain Sundstrom <da...@iq80.com>.
If we really need it, I think the syntax 1.1.* would be ok since it
would easily be parseable and translated to [1.1-1.2) in a formal
version syntax. For the patch, I'm thinking of something like
if (version.equals(gerVersion) ||
(gerVersion.endsWith(".*" &&
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
match = true;
break;
}
Don't trust that code; I free styled it in this email, but you get
the idea.
I do think this is too risky for 1.1 since this code could easily
have unintended consequences.
-dain
On Jun 9, 2006, at 5:59 AM, Paul McMahan wrote:
> That's a good idea and it would be pretty straightforward. But now
> that Dain has brought our attention to GERONIMO-1637 I'm concerned
> about deviating from the G 1.2 activities where the full syntax of
> maven version ranges will be introduced. I don't know much about
> maven version ranges - there may be some subset that can be
> implemented during G 1.1.x that addresses our specific concerns about
> forcing plugins to continually update their geronimo-plugin.xml.
>
> Best wishes,
> Paul
>
> On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> Paul, what if we tweaked your proposed patch and allowed the
>> plugin to
>> provide an optional attribute of exactVersion=required, which would
>> control the behavior?
>>
>> -Donald
>>
>> Paul McMahan wrote:
>> > I definitely agree that a full fledged solution for version
>> ranges is
>> > out of scope for G 1.1.x. I was thinking that a minor change to
>> the
>> > plugin installer's version checking could at least partially
>> address
>> > Donald's concerns and also avoid the version mismatch problem
>> Dave C.
>> > found in the candidate build. Here's a patch that makes the plugin
>> > installer only check the digits of geronimo's version that the
>> > plugin's xml specifies. So if the plugin specifies
>> > <geronimo-version>1.1</geronimo-version> then it can be
>> installed into
>> > 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>> >
>> > Best wishes,
>> > Paul
>> >
>> > Index:
>> > modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java
>> >
>> > ===================================================================
>> > ---
>> > modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java
>> > (revision
>> > 412744)
>> > +++
>> > modules/system/src/java/org/apache/geronimo/system/plugin/
>> PluginInstallerGBean.java
>> > (working
>> > copy)
>> > @@ -1409,7 +1409,7 @@
>> > if(gerVersion == null || gerVersion.equals("")) {
>> > throw new IllegalStateException("geronimo-version
>> > should not be empty!");
>> > }
>> > - if(gerVersion.equals(version)) {
>> > + if(version.startsWith(gerVersion)) {
>> > match = true;
>> > break;
>> > }
>> >
>> >
>> > On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>> >
>> >> Perhaps I was unclear; I didn't mean to say this was a bad
>> idea, only
>> >> that our code doesn't currently support it. I expect version
>> ranges
>> >> are on the road map, but if you want to work on them, you're
>> more than
>> >> welcome to. :)
>> >>
>> >> I don't think this is a G 1.1.x discussion, since AFAIK it would
>> >> require kernel changes.
>> >>
>> >> Thanks,
>> >> Aaron
>> >>
>> >> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> >> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> >> > > What I meant by 1.1.* was the Maven behavior of private
>> builds like
>> >> > > 1.1-1 being taken as newer than 1.1. Also, being able to
>> use the
>> >> > > behavior of 1.1-<starting with any alpha> is less than 1.1.
>> >> Basically,
>> >> > > I should be able to specify 1.1 in the plugin and have it
>> work on
>> >> > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
>> doesn't on
>> >> 1.1.1,
>> >> > > then I'd argue that we broke something in 1.1.1, given it
>> should
>> >> only be
>> >> > > a maintenance release and app/plan breaking changes should
>> only go
>> >> into 1.2.
>> >> >
>> >> > +1 This approach is similar to how eclipse plugin
>> versioning works.
>> >> >
>> >> > From http://www.eclipse.org/equinox/documents/plugin-
>> versioning.html :
>> >> > "How to specify plug-in requirements
>> >> > Plug-ins that require other plug-ins must qualify their
>> requirements
>> >> > with a version range since the absence of a version range
>> means that
>> >> > any version can satisfy the dependency. Given that all the
>> changes
>> >> > between the version x.0.0 and the version x+1.0.0 excluded
>> must be
>> >> > compatible (given the previous guidelines); the recommended
>> range
>> >> > includes the minimal required version up-to but not including
>> the next
>> >> > major release."
>> >> >
>> >> > IMHO geronimo should adopt eclipse's strategy for plugin
>> versioning
>> >> > where possible since the two sets of base requirements are quite
>> >> > similar and eclipse is a few years ahead in this area. The
>> document
>> >> > referenced above spells out their strategy in detail.
>> >> >
>> >> > Best wishes,
>> >> > Paul
>> >> >
>> >>
>> >
>> >
>>
>>
>>
Re: Plugin versioning problems
Posted by Paul McMahan <pa...@gmail.com>.
That's a good idea and it would be pretty straightforward. But now
that Dain has brought our attention to GERONIMO-1637 I'm concerned
about deviating from the G 1.2 activities where the full syntax of
maven version ranges will be introduced. I don't know much about
maven version ranges - there may be some subset that can be
implemented during G 1.1.x that addresses our specific concerns about
forcing plugins to continually update their geronimo-plugin.xml.
Best wishes,
Paul
On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> Paul, what if we tweaked your proposed patch and allowed the plugin to
> provide an optional attribute of exactVersion=required, which would
> control the behavior?
>
> -Donald
>
> Paul McMahan wrote:
> > I definitely agree that a full fledged solution for version ranges is
> > out of scope for G 1.1.x. I was thinking that a minor change to the
> > plugin installer's version checking could at least partially address
> > Donald's concerns and also avoid the version mismatch problem Dave C.
> > found in the candidate build. Here's a patch that makes the plugin
> > installer only check the digits of geronimo's version that the
> > plugin's xml specifies. So if the plugin specifies
> > <geronimo-version>1.1</geronimo-version> then it can be installed into
> > 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
> >
> > Best wishes,
> > Paul
> >
> > Index:
> > modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
> >
> > ===================================================================
> > ---
> > modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
> > (revision
> > 412744)
> > +++
> > modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
> > (working
> > copy)
> > @@ -1409,7 +1409,7 @@
> > if(gerVersion == null || gerVersion.equals("")) {
> > throw new IllegalStateException("geronimo-version
> > should not be empty!");
> > }
> > - if(gerVersion.equals(version)) {
> > + if(version.startsWith(gerVersion)) {
> > match = true;
> > break;
> > }
> >
> >
> > On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> >
> >> Perhaps I was unclear; I didn't mean to say this was a bad idea, only
> >> that our code doesn't currently support it. I expect version ranges
> >> are on the road map, but if you want to work on them, you're more than
> >> welcome to. :)
> >>
> >> I don't think this is a G 1.1.x discussion, since AFAIK it would
> >> require kernel changes.
> >>
> >> Thanks,
> >> Aaron
> >>
> >> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
> >> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> >> > > What I meant by 1.1.* was the Maven behavior of private builds like
> >> > > 1.1-1 being taken as newer than 1.1. Also, being able to use the
> >> > > behavior of 1.1-<starting with any alpha> is less than 1.1.
> >> Basically,
> >> > > I should be able to specify 1.1 in the plugin and have it work on
> >> > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on
> >> 1.1.1,
> >> > > then I'd argue that we broke something in 1.1.1, given it should
> >> only be
> >> > > a maintenance release and app/plan breaking changes should only go
> >> into 1.2.
> >> >
> >> > +1 This approach is similar to how eclipse plugin versioning works.
> >> >
> >> > From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
> >> > "How to specify plug-in requirements
> >> > Plug-ins that require other plug-ins must qualify their requirements
> >> > with a version range since the absence of a version range means that
> >> > any version can satisfy the dependency. Given that all the changes
> >> > between the version x.0.0 and the version x+1.0.0 excluded must be
> >> > compatible (given the previous guidelines); the recommended range
> >> > includes the minimal required version up-to but not including the next
> >> > major release."
> >> >
> >> > IMHO geronimo should adopt eclipse's strategy for plugin versioning
> >> > where possible since the two sets of base requirements are quite
> >> > similar and eclipse is a few years ahead in this area. The document
> >> > referenced above spells out their strategy in detail.
> >> >
> >> > Best wishes,
> >> > Paul
> >> >
> >>
> >
> >
>
>
>
Re: Plugin versioning problems
Posted by Donald Woods <dr...@yahoo.com>.
Paul, what if we tweaked your proposed patch and allowed the plugin to
provide an optional attribute of exactVersion=required, which would
control the behavior?
-Donald
Paul McMahan wrote:
> I definitely agree that a full fledged solution for version ranges is
> out of scope for G 1.1.x. I was thinking that a minor change to the
> plugin installer's version checking could at least partially address
> Donald's concerns and also avoid the version mismatch problem Dave C.
> found in the candidate build. Here's a patch that makes the plugin
> installer only check the digits of geronimo's version that the
> plugin's xml specifies. So if the plugin specifies
> <geronimo-version>1.1</geronimo-version> then it can be installed into
> 1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
>
> Best wishes,
> Paul
>
> Index:
> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>
> ===================================================================
> ---
> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
> (revision
> 412744)
> +++
> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
> (working
> copy)
> @@ -1409,7 +1409,7 @@
> if(gerVersion == null || gerVersion.equals("")) {
> throw new IllegalStateException("geronimo-version
> should not be empty!");
> }
> - if(gerVersion.equals(version)) {
> + if(version.startsWith(gerVersion)) {
> match = true;
> break;
> }
>
>
> On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
>> Perhaps I was unclear; I didn't mean to say this was a bad idea, only
>> that our code doesn't currently support it. I expect version ranges
>> are on the road map, but if you want to work on them, you're more than
>> welcome to. :)
>>
>> I don't think this is a G 1.1.x discussion, since AFAIK it would
>> require kernel changes.
>>
>> Thanks,
>> Aaron
>>
>> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
>> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> > > What I meant by 1.1.* was the Maven behavior of private builds like
>> > > 1.1-1 being taken as newer than 1.1. Also, being able to use the
>> > > behavior of 1.1-<starting with any alpha> is less than 1.1.
>> Basically,
>> > > I should be able to specify 1.1 in the plugin and have it work on
>> > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on
>> 1.1.1,
>> > > then I'd argue that we broke something in 1.1.1, given it should
>> only be
>> > > a maintenance release and app/plan breaking changes should only go
>> into 1.2.
>> >
>> > +1 This approach is similar to how eclipse plugin versioning works.
>> >
>> > From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
>> > "How to specify plug-in requirements
>> > Plug-ins that require other plug-ins must qualify their requirements
>> > with a version range since the absence of a version range means that
>> > any version can satisfy the dependency. Given that all the changes
>> > between the version x.0.0 and the version x+1.0.0 excluded must be
>> > compatible (given the previous guidelines); the recommended range
>> > includes the minimal required version up-to but not including the next
>> > major release."
>> >
>> > IMHO geronimo should adopt eclipse's strategy for plugin versioning
>> > where possible since the two sets of base requirements are quite
>> > similar and eclipse is a few years ahead in this area. The document
>> > referenced above spells out their strategy in detail.
>> >
>> > Best wishes,
>> > Paul
>> >
>>
>
>
Re: Plugin versioning problems
Posted by Paul McMahan <pa...@gmail.com>.
I definitely agree that a full fledged solution for version ranges is
out of scope for G 1.1.x. I was thinking that a minor change to the
plugin installer's version checking could at least partially address
Donald's concerns and also avoid the version mismatch problem Dave C.
found in the candidate build. Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies. So if the plugin specifies
<geronimo-version>1.1</geronimo-version> then it can be installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
Best wishes,
Paul
Index: modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
===================================================================
--- modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java (revision
412744)
+++ modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java (working
copy)
@@ -1409,7 +1409,7 @@
if(gerVersion == null || gerVersion.equals("")) {
throw new IllegalStateException("geronimo-version
should not be empty!");
}
- if(gerVersion.equals(version)) {
+ if(version.startsWith(gerVersion)) {
match = true;
break;
}
On 6/8/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> Perhaps I was unclear; I didn't mean to say this was a bad idea, only
> that our code doesn't currently support it. I expect version ranges
> are on the road map, but if you want to work on them, you're more than
> welcome to. :)
>
> I don't think this is a G 1.1.x discussion, since AFAIK it would
> require kernel changes.
>
> Thanks,
> Aaron
>
> On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> > > What I meant by 1.1.* was the Maven behavior of private builds like
> > > 1.1-1 being taken as newer than 1.1. Also, being able to use the
> > > behavior of 1.1-<starting with any alpha> is less than 1.1. Basically,
> > > I should be able to specify 1.1 in the plugin and have it work on
> > > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1,
> > > then I'd argue that we broke something in 1.1.1, given it should only be
> > > a maintenance release and app/plan breaking changes should only go into 1.2.
> >
> > +1 This approach is similar to how eclipse plugin versioning works.
> >
> > From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
> > "How to specify plug-in requirements
> > Plug-ins that require other plug-ins must qualify their requirements
> > with a version range since the absence of a version range means that
> > any version can satisfy the dependency. Given that all the changes
> > between the version x.0.0 and the version x+1.0.0 excluded must be
> > compatible (given the previous guidelines); the recommended range
> > includes the minimal required version up-to but not including the next
> > major release."
> >
> > IMHO geronimo should adopt eclipse's strategy for plugin versioning
> > where possible since the two sets of base requirements are quite
> > similar and eclipse is a few years ahead in this area. The document
> > referenced above spells out their strategy in detail.
> >
> > Best wishes,
> > Paul
> >
>
Re: Plugin versioning problems
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Perhaps I was unclear; I didn't mean to say this was a bad idea, only
that our code doesn't currently support it. I expect version ranges
are on the road map, but if you want to work on them, you're more than
welcome to. :)
I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.
Thanks,
Aaron
On 6/8/06, Paul McMahan <pa...@gmail.com> wrote:
> On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> > What I meant by 1.1.* was the Maven behavior of private builds like
> > 1.1-1 being taken as newer than 1.1. Also, being able to use the
> > behavior of 1.1-<starting with any alpha> is less than 1.1. Basically,
> > I should be able to specify 1.1 in the plugin and have it work on
> > 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1,
> > then I'd argue that we broke something in 1.1.1, given it should only be
> > a maintenance release and app/plan breaking changes should only go into 1.2.
>
> +1 This approach is similar to how eclipse plugin versioning works.
>
> From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
> "How to specify plug-in requirements
> Plug-ins that require other plug-ins must qualify their requirements
> with a version range since the absence of a version range means that
> any version can satisfy the dependency. Given that all the changes
> between the version x.0.0 and the version x+1.0.0 excluded must be
> compatible (given the previous guidelines); the recommended range
> includes the minimal required version up-to but not including the next
> major release."
>
> IMHO geronimo should adopt eclipse's strategy for plugin versioning
> where possible since the two sets of base requirements are quite
> similar and eclipse is a few years ahead in this area. The document
> referenced above spells out their strategy in detail.
>
> Best wishes,
> Paul
>
Re: Plugin versioning problems
Posted by Paul McMahan <pa...@gmail.com>.
On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> What I meant by 1.1.* was the Maven behavior of private builds like
> 1.1-1 being taken as newer than 1.1. Also, being able to use the
> behavior of 1.1-<starting with any alpha> is less than 1.1. Basically,
> I should be able to specify 1.1 in the plugin and have it work on
> 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1,
> then I'd argue that we broke something in 1.1.1, given it should only be
> a maintenance release and app/plan breaking changes should only go into 1.2.
+1 This approach is similar to how eclipse plugin versioning works.
>From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
"How to specify plug-in requirements
Plug-ins that require other plug-ins must qualify their requirements
with a version range since the absence of a version range means that
any version can satisfy the dependency. Given that all the changes
between the version x.0.0 and the version x+1.0.0 excluded must be
compatible (given the previous guidelines); the recommended range
includes the minimal required version up-to but not including the next
major release."
IMHO geronimo should adopt eclipse's strategy for plugin versioning
where possible since the two sets of base requirements are quite
similar and eclipse is a few years ahead in this area. The document
referenced above spells out their strategy in detail.
Best wishes,
Paul
Re: Plugin versioning problems
Posted by Donald Woods <dr...@yahoo.com>.
http://www.javaforge.com/ - It's another opensource based *forge
hosting site, which seems to be open to anyone to use. The only reason
I found it, was the Luntbuild project we use for building
(http://www.javaforge.com/proj/summary.do?proj_id=70) started using it
awhile back. I would rather use the more common sourceforge, even if
its a little slow at times....
-Donald
Aaron Mulder wrote:
> Sourceforge is kind of slow, which is my main objection. But perhaps
> we can use it as a start. What's Javaforge?
>
> Thanks,
> Aaron
>
> On 6/9/06, Donald Woods <dr...@yahoo.com> wrote:
>
>> Inline below.
>>
>> Aaron Mulder wrote:
>> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>> >
>> >> BTW - How can we add new Plugins to the geronimoplugins website?
>> Are we
>> >> going to setup a Geronimo subproject (like Daytrader) with the site
>> >> framework checked into svn, along with any scripts needed to build the
>> >> plugins? It seems convoluted to have samples and plugin builds in the
>> >> main Geronimo tree, which are not shipped with the server or
>> >> automatically pushed to geronimoplugins. Wouldn't it be easier to
>> >> maintain if we moved all the samples out to /trunk/samples/modules and
>> >> all the equivalent plugin configs to /trunk/samples/plugins? That
>> way,
>> >> the Samples and plugins can be built, published and enhanced separate
>> >> from the server development....
>> >
>> >
>> > Currently, to get a plugin added to the web site, you can mail it to
>> > me. If you want to help out there, it would be great to have a script
>> > that read the plugin.xml files and emitted the various PHP files with
>> > all the plugin info! Currently it's a little more manual. :)
>> >
>> > We should definitely have a separate are in the SVN tree for the
>> > samples. There's no reason they should be tied to the Geronimo
>> > release schedule.
>> >
>> > We also need a non-Apache space where we can write the plugin wrappers
>> > for various interesting LGPL projects.
>>
>> If you create a project on Sourceforge or Javaforge, I'll come and help.
>> How about project=geronimoplugins to match the website name?
>>
>> -Donald
>>
>>
>> >
>> > Thanks,
>> > Aaron
>> >
>> >> Aaron Mulder wrote:
>> >> > On 6/7/06, Donald Woods <dr...@yahoo.com> wrote:
>> >> >
>> >> >> Why shouldn't the Plugin support be as robust as module
>> >> dependencies and
>> >> >> allow the user providing the plugin to decide if they can support
>> >> >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only
>> >> support
>> >> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a
>> hack to
>> >> >> me and doesn't follow previous email threads about not deviating
>> from
>> >> >> Maven2 versioning behavior...
>> >> >
>> >> >
>> >> > But what you've said here is "why shouldn't the plugin support be as
>> >> > robust as A and allow B" where A != B. Module dependencies let you
>> >> > specify an exact version or no version. Plugin dependencies also
>> let
>> >> > you specify an exact version or no version. Neither of these
>> support
>> >> > 1.* or 1.1*.
>> >> >
>> >> >> Just as with the Tomcat JSP/Servlet Examples, you could easily
>> >> provide a
>> >> >> Plugin which should work on all 1.x releases....
>> >> >
>> >> >
>> >> > My preference it to opt-in supported version, not opt-out
>> unsupported
>> >> > versions. So I'd like the plugin developer to try a plugin on a
>> >> > Geronimo version and if it works, list that version as
>> supported. The
>> >> > alternative will most likely lead to Geronimo being willing to
>> install
>> >> > a plugin but the plugin not working. If we get fancier version
>> >> > dependencies we can consider things like "1.1.*" but I'm not sure I
>> >> > like that. I'm willing to be convinced, but I'd want to hear from
>> >> > more plugin developers/maintainers.
>> >> >
>> >> > Thanks,
>> >> > Aaron
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
Re: Plugin versioning problems
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Sourceforge is kind of slow, which is my main objection. But perhaps
we can use it as a start. What's Javaforge?
Thanks,
Aaron
On 6/9/06, Donald Woods <dr...@yahoo.com> wrote:
> Inline below.
>
> Aaron Mulder wrote:
> > On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> >
> >> BTW - How can we add new Plugins to the geronimoplugins website? Are we
> >> going to setup a Geronimo subproject (like Daytrader) with the site
> >> framework checked into svn, along with any scripts needed to build the
> >> plugins? It seems convoluted to have samples and plugin builds in the
> >> main Geronimo tree, which are not shipped with the server or
> >> automatically pushed to geronimoplugins. Wouldn't it be easier to
> >> maintain if we moved all the samples out to /trunk/samples/modules and
> >> all the equivalent plugin configs to /trunk/samples/plugins? That way,
> >> the Samples and plugins can be built, published and enhanced separate
> >> from the server development....
> >
> >
> > Currently, to get a plugin added to the web site, you can mail it to
> > me. If you want to help out there, it would be great to have a script
> > that read the plugin.xml files and emitted the various PHP files with
> > all the plugin info! Currently it's a little more manual. :)
> >
> > We should definitely have a separate are in the SVN tree for the
> > samples. There's no reason they should be tied to the Geronimo
> > release schedule.
> >
> > We also need a non-Apache space where we can write the plugin wrappers
> > for various interesting LGPL projects.
>
> If you create a project on Sourceforge or Javaforge, I'll come and help.
> How about project=geronimoplugins to match the website name?
>
> -Donald
>
>
> >
> > Thanks,
> > Aaron
> >
> >> Aaron Mulder wrote:
> >> > On 6/7/06, Donald Woods <dr...@yahoo.com> wrote:
> >> >
> >> >> Why shouldn't the Plugin support be as robust as module
> >> dependencies and
> >> >> allow the user providing the plugin to decide if they can support
> >> >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only
> >> support
> >> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
> >> >> me and doesn't follow previous email threads about not deviating from
> >> >> Maven2 versioning behavior...
> >> >
> >> >
> >> > But what you've said here is "why shouldn't the plugin support be as
> >> > robust as A and allow B" where A != B. Module dependencies let you
> >> > specify an exact version or no version. Plugin dependencies also let
> >> > you specify an exact version or no version. Neither of these support
> >> > 1.* or 1.1*.
> >> >
> >> >> Just as with the Tomcat JSP/Servlet Examples, you could easily
> >> provide a
> >> >> Plugin which should work on all 1.x releases....
> >> >
> >> >
> >> > My preference it to opt-in supported version, not opt-out unsupported
> >> > versions. So I'd like the plugin developer to try a plugin on a
> >> > Geronimo version and if it works, list that version as supported. The
> >> > alternative will most likely lead to Geronimo being willing to install
> >> > a plugin but the plugin not working. If we get fancier version
> >> > dependencies we can consider things like "1.1.*" but I'm not sure I
> >> > like that. I'm willing to be convinced, but I'd want to hear from
> >> > more plugin developers/maintainers.
> >> >
> >> > Thanks,
> >> > Aaron
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
Re: Plugin versioning problems
Posted by Donald Woods <dr...@yahoo.com>.
Inline below.
Aaron Mulder wrote:
> On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
>
>> BTW - How can we add new Plugins to the geronimoplugins website? Are we
>> going to setup a Geronimo subproject (like Daytrader) with the site
>> framework checked into svn, along with any scripts needed to build the
>> plugins? It seems convoluted to have samples and plugin builds in the
>> main Geronimo tree, which are not shipped with the server or
>> automatically pushed to geronimoplugins. Wouldn't it be easier to
>> maintain if we moved all the samples out to /trunk/samples/modules and
>> all the equivalent plugin configs to /trunk/samples/plugins? That way,
>> the Samples and plugins can be built, published and enhanced separate
>> from the server development....
>
>
> Currently, to get a plugin added to the web site, you can mail it to
> me. If you want to help out there, it would be great to have a script
> that read the plugin.xml files and emitted the various PHP files with
> all the plugin info! Currently it's a little more manual. :)
>
> We should definitely have a separate are in the SVN tree for the
> samples. There's no reason they should be tied to the Geronimo
> release schedule.
>
> We also need a non-Apache space where we can write the plugin wrappers
> for various interesting LGPL projects.
If you create a project on Sourceforge or Javaforge, I'll come and help.
How about project=geronimoplugins to match the website name?
-Donald
>
> Thanks,
> Aaron
>
>> Aaron Mulder wrote:
>> > On 6/7/06, Donald Woods <dr...@yahoo.com> wrote:
>> >
>> >> Why shouldn't the Plugin support be as robust as module
>> dependencies and
>> >> allow the user providing the plugin to decide if they can support
>> >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only
>> support
>> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
>> >> me and doesn't follow previous email threads about not deviating from
>> >> Maven2 versioning behavior...
>> >
>> >
>> > But what you've said here is "why shouldn't the plugin support be as
>> > robust as A and allow B" where A != B. Module dependencies let you
>> > specify an exact version or no version. Plugin dependencies also let
>> > you specify an exact version or no version. Neither of these support
>> > 1.* or 1.1*.
>> >
>> >> Just as with the Tomcat JSP/Servlet Examples, you could easily
>> provide a
>> >> Plugin which should work on all 1.x releases....
>> >
>> >
>> > My preference it to opt-in supported version, not opt-out unsupported
>> > versions. So I'd like the plugin developer to try a plugin on a
>> > Geronimo version and if it works, list that version as supported. The
>> > alternative will most likely lead to Geronimo being willing to install
>> > a plugin but the plugin not working. If we get fancier version
>> > dependencies we can consider things like "1.1.*" but I'm not sure I
>> > like that. I'm willing to be convinced, but I'd want to hear from
>> > more plugin developers/maintainers.
>> >
>> > Thanks,
>> > Aaron
>> >
>> >
>>
>>
>>
>
>
Re: Plugin versioning problems
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 6/8/06, Donald Woods <dr...@yahoo.com> wrote:
> BTW - How can we add new Plugins to the geronimoplugins website? Are we
> going to setup a Geronimo subproject (like Daytrader) with the site
> framework checked into svn, along with any scripts needed to build the
> plugins? It seems convoluted to have samples and plugin builds in the
> main Geronimo tree, which are not shipped with the server or
> automatically pushed to geronimoplugins. Wouldn't it be easier to
> maintain if we moved all the samples out to /trunk/samples/modules and
> all the equivalent plugin configs to /trunk/samples/plugins? That way,
> the Samples and plugins can be built, published and enhanced separate
> from the server development....
Currently, to get a plugin added to the web site, you can mail it to
me. If you want to help out there, it would be great to have a script
that read the plugin.xml files and emitted the various PHP files with
all the plugin info! Currently it's a little more manual. :)
We should definitely have a separate are in the SVN tree for the
samples. There's no reason they should be tied to the Geronimo
release schedule.
We also need a non-Apache space where we can write the plugin wrappers
for various interesting LGPL projects.
Thanks,
Aaron
> Aaron Mulder wrote:
> > On 6/7/06, Donald Woods <dr...@yahoo.com> wrote:
> >
> >> Why shouldn't the Plugin support be as robust as module dependencies and
> >> allow the user providing the plugin to decide if they can support
> >> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support
> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
> >> me and doesn't follow previous email threads about not deviating from
> >> Maven2 versioning behavior...
> >
> >
> > But what you've said here is "why shouldn't the plugin support be as
> > robust as A and allow B" where A != B. Module dependencies let you
> > specify an exact version or no version. Plugin dependencies also let
> > you specify an exact version or no version. Neither of these support
> > 1.* or 1.1*.
> >
> >> Just as with the Tomcat JSP/Servlet Examples, you could easily provide a
> >> Plugin which should work on all 1.x releases....
> >
> >
> > My preference it to opt-in supported version, not opt-out unsupported
> > versions. So I'd like the plugin developer to try a plugin on a
> > Geronimo version and if it works, list that version as supported. The
> > alternative will most likely lead to Geronimo being willing to install
> > a plugin but the plugin not working. If we get fancier version
> > dependencies we can consider things like "1.1.*" but I'm not sure I
> > like that. I'm willing to be convinced, but I'd want to hear from
> > more plugin developers/maintainers.
> >
> > Thanks,
> > Aaron
> >
> >
>
>
>
Re: Plugin versioning problems
Posted by Donald Woods <dr...@yahoo.com>.
What I meant by 1.1.* was the Maven behavior of private builds like
1.1-1 being taken as newer than 1.1. Also, being able to use the
behavior of 1.1-<starting with any alpha> is less than 1.1. Basically,
I should be able to specify 1.1 in the plugin and have it work on
1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1,
then I'd argue that we broke something in 1.1.1, given it should only be
a maintenance release and app/plan breaking changes should only go into 1.2.
BTW - How can we add new Plugins to the geronimoplugins website? Are we
going to setup a Geronimo subproject (like Daytrader) with the site
framework checked into svn, along with any scripts needed to build the
plugins? It seems convoluted to have samples and plugin builds in the
main Geronimo tree, which are not shipped with the server or
automatically pushed to geronimoplugins. Wouldn't it be easier to
maintain if we moved all the samples out to /trunk/samples/modules and
all the equivalent plugin configs to /trunk/samples/plugins? That way,
the Samples and plugins can be built, published and enhanced separate
from the server development....
-Donald
Aaron Mulder wrote:
> On 6/7/06, Donald Woods <dr...@yahoo.com> wrote:
>
>> Why shouldn't the Plugin support be as robust as module dependencies and
>> allow the user providing the plugin to decide if they can support
>> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support
>> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
>> me and doesn't follow previous email threads about not deviating from
>> Maven2 versioning behavior...
>
>
> But what you've said here is "why shouldn't the plugin support be as
> robust as A and allow B" where A != B. Module dependencies let you
> specify an exact version or no version. Plugin dependencies also let
> you specify an exact version or no version. Neither of these support
> 1.* or 1.1*.
>
>> Just as with the Tomcat JSP/Servlet Examples, you could easily provide a
>> Plugin which should work on all 1.x releases....
>
>
> My preference it to opt-in supported version, not opt-out unsupported
> versions. So I'd like the plugin developer to try a plugin on a
> Geronimo version and if it works, list that version as supported. The
> alternative will most likely lead to Geronimo being willing to install
> a plugin but the plugin not working. If we get fancier version
> dependencies we can consider things like "1.1.*" but I'm not sure I
> like that. I'm willing to be convinced, but I'd want to hear from
> more plugin developers/maintainers.
>
> Thanks,
> Aaron
>
>
Re: Plugin versioning problems
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 6/7/06, Donald Woods <dr...@yahoo.com> wrote:
> Why shouldn't the Plugin support be as robust as module dependencies and
> allow the user providing the plugin to decide if they can support
> geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support
> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
> me and doesn't follow previous email threads about not deviating from
> Maven2 versioning behavior...
But what you've said here is "why shouldn't the plugin support be as
robust as A and allow B" where A != B. Module dependencies let you
specify an exact version or no version. Plugin dependencies also let
you specify an exact version or no version. Neither of these support
1.* or 1.1*.
> Just as with the Tomcat JSP/Servlet Examples, you could easily provide a
> Plugin which should work on all 1.x releases....
My preference it to opt-in supported version, not opt-out unsupported
versions. So I'd like the plugin developer to try a plugin on a
Geronimo version and if it works, list that version as supported. The
alternative will most likely lead to Geronimo being willing to install
a plugin but the plugin not working. If we get fancier version
dependencies we can consider things like "1.1.*" but I'm not sure I
like that. I'm willing to be convinced, but I'd want to hear from
more plugin developers/maintainers.
Thanks,
Aaron
Plugin versioning problems
Posted by Donald Woods <dr...@yahoo.com>.
Why shouldn't the Plugin support be as robust as module dependencies and
allow the user providing the plugin to decide if they can support
geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support
predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
me and doesn't follow previous email threads about not deviating from
Maven2 versioning behavior...
Just as with the Tomcat JSP/Servlet Examples, you could easily provide a
Plugin which should work on all 1.x releases....
-Donald
Aaron Mulder wrote:
> On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
>> Aaron,
>>
>> Joe put out a thread about the interpretation of versions which I
>> think is exactly this problem. If
>> we have a well understood algorithm for Versions that includes several
>> aspects of the final qualifer
>> (if present) this would solve the issue. So releases is just one of
>> many possible uses. Others
>> include patched versions, SNAPSHOTS, etc.
>>
>> Does this sound right to you?
>
>
> Well, only a little. I would rather agree to use well-defined
> releases beta1-netaN followed by rc1-rcN followed by a final release.
> I don't want to say a plugin will support arbitrary releases
> designated by whatever token someone feels like using so long as it's
> valid according to our version calculation rules -- that seems likely
> to be problematic. But in the plugin context, I'm only talking about
> the "Geronimo version", not the version of individual components like
> geronimo/jetty/1.1.3-patch5/car. I agree that Joe's discussion needs
> to happen in relation to dependencies and versions of specific
> components *within* Geronimo.
>
> I guess I better propose my release versioning issue in a separate
> thread for 1.1.N/1.2.
>
> Thanks,
> Aaron
>
>
>> Aaron Mulder wrote:
>> > OK, so we have a small issue with the plugins.
>> >
>> > They currently list the supported versions of Geronimo in their
>> > metadata. The idea is that we don't state that a plugin will run in
>> > *any* version of Geronimo, we instead add each supported version as it
>> > is released. Currently that list only contains 1.1-SNAPSHOT.
>> >
>> > Now I can go add 1.1-20060607 to the list of supported versions for
>> > the 1.1 plugins, but we'll never be able to do that in advance. It
>> > would be nicer if the release candidates had more predictable names
>> > (rc1, rc2, rc3, etc.) so we could add them to the supported version
>> > list ahead of time.
>> >
>> > We also have to decide how to handle SNAPSHOT versions of Geronimo. I
>> > don't really think we want the released 1.1 plugins to claim that they
>> > support 1.2-SNAPSHOT, which may or may not be true depending on the
>> > extent of the changes. I'm currently planning to have a different
>> > plugin repository for each major version of Geronimo, so the 1.1
>> > plugin repository will be fairly stable and the 1.2 plugin repository
>> > may need to be rebuilt a lot and won't likely have a very complete set
>> > of plugins until the release.
>> >
>> > Thanks,
>> > Aaron
>> >
>> > On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> >> Geronimo Users and Developers,
>> >>
>> >> We've been busy little beavers this evening and would like to share
>> >> the fruits of our labor.
>> >>
>> >> First, may we present the candidate build of Geronimo in Octographic
>> >> quality. We have big builds,
>> >> little builds, some for Windows and others for Unix and of course the
>> >> ever enjoyable Tomcat and
>> >> Jetty versions. Please take some time to take these builds and verify
>> >> that they meet your exacting
>> >> standards for a Geronimo Release. As we like to say, "Big G, Little G
>> >> and things that rhyme with G."
>> >>
>> >> *Jetty*
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip
>>
>> >>
>> >>
>> >> *Tomcat*
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip
>>
>> >>
>> >>
>> >>
>> >> Remaining items.
>> >>
>> >> 1. We need the ActiveMQ 3.2.4 to be released.
>> >> 2. Finalize release notes (Hernan...can you pick this one up? A set
>> >> for today would be good)
>> >> 3. Move the remainging JIRAs out of 1.1. (Aaron, Dain, anyone ?)
>> >> 4. Fix OpenEJB Source. I versioned and released it but I haven't
>> >> fixed the SVN repo yet. I'll do
>> >> this in the morning unless someone beats me to it.
>> >> 5. A vote. I'm note sure if this can qualify for a vote since there
>> >> is a SNAPSHOT in the release.
>> >> It won't change but need to note that. Thoughts?
>> >>
>> >> To complete an official release I need to finalize the project version
>> >> and rebuild once again.
>> >>
>> >> Its late and I'm probably missing something so if there are barriers
>> >> to completing the final release
>> >> please let me know ASAP.
>> >>
>> >> I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out
>> >> and going.
>> >>
>> >> Thanks in advance for taking time to review this release of AG 1.1.
>> >>
>> >> The Geronimo Development Team
>> >>
>> >
>> >
>> >
>>
>
>
Re: 1.1 Candidate releases available
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Aaron,
>
> Joe put out a thread about the interpretation of versions which I think is exactly this problem. If
> we have a well understood algorithm for Versions that includes several aspects of the final qualifer
> (if present) this would solve the issue. So releases is just one of many possible uses. Others
> include patched versions, SNAPSHOTS, etc.
>
> Does this sound right to you?
Well, only a little. I would rather agree to use well-defined
releases beta1-netaN followed by rc1-rcN followed by a final release.
I don't want to say a plugin will support arbitrary releases
designated by whatever token someone feels like using so long as it's
valid according to our version calculation rules -- that seems likely
to be problematic. But in the plugin context, I'm only talking about
the "Geronimo version", not the version of individual components like
geronimo/jetty/1.1.3-patch5/car. I agree that Joe's discussion needs
to happen in relation to dependencies and versions of specific
components *within* Geronimo.
I guess I better propose my release versioning issue in a separate
thread for 1.1.N/1.2.
Thanks,
Aaron
> Aaron Mulder wrote:
> > OK, so we have a small issue with the plugins.
> >
> > They currently list the supported versions of Geronimo in their
> > metadata. The idea is that we don't state that a plugin will run in
> > *any* version of Geronimo, we instead add each supported version as it
> > is released. Currently that list only contains 1.1-SNAPSHOT.
> >
> > Now I can go add 1.1-20060607 to the list of supported versions for
> > the 1.1 plugins, but we'll never be able to do that in advance. It
> > would be nicer if the release candidates had more predictable names
> > (rc1, rc2, rc3, etc.) so we could add them to the supported version
> > list ahead of time.
> >
> > We also have to decide how to handle SNAPSHOT versions of Geronimo. I
> > don't really think we want the released 1.1 plugins to claim that they
> > support 1.2-SNAPSHOT, which may or may not be true depending on the
> > extent of the changes. I'm currently planning to have a different
> > plugin repository for each major version of Geronimo, so the 1.1
> > plugin repository will be fairly stable and the 1.2 plugin repository
> > may need to be rebuilt a lot and won't likely have a very complete set
> > of plugins until the release.
> >
> > Thanks,
> > Aaron
> >
> > On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >> Geronimo Users and Developers,
> >>
> >> We've been busy little beavers this evening and would like to share
> >> the fruits of our labor.
> >>
> >> First, may we present the candidate build of Geronimo in Octographic
> >> quality. We have big builds,
> >> little builds, some for Windows and others for Unix and of course the
> >> ever enjoyable Tomcat and
> >> Jetty versions. Please take some time to take these builds and verify
> >> that they meet your exacting
> >> standards for a Geronimo Release. As we like to say, "Big G, Little G
> >> and things that rhyme with G."
> >>
> >> *Jetty*
> >> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
> >>
> >> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
> >>
> >> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
> >>
> >> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip
> >>
> >>
> >> *Tomcat*
> >> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
> >>
> >> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
> >>
> >> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
> >>
> >> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip
> >>
> >>
> >>
> >> Remaining items.
> >>
> >> 1. We need the ActiveMQ 3.2.4 to be released.
> >> 2. Finalize release notes (Hernan...can you pick this one up? A set
> >> for today would be good)
> >> 3. Move the remainging JIRAs out of 1.1. (Aaron, Dain, anyone ?)
> >> 4. Fix OpenEJB Source. I versioned and released it but I haven't
> >> fixed the SVN repo yet. I'll do
> >> this in the morning unless someone beats me to it.
> >> 5. A vote. I'm note sure if this can qualify for a vote since there
> >> is a SNAPSHOT in the release.
> >> It won't change but need to note that. Thoughts?
> >>
> >> To complete an official release I need to finalize the project version
> >> and rebuild once again.
> >>
> >> Its late and I'm probably missing something so if there are barriers
> >> to completing the final release
> >> please let me know ASAP.
> >>
> >> I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out
> >> and going.
> >>
> >> Thanks in advance for taking time to review this release of AG 1.1.
> >>
> >> The Geronimo Development Team
> >>
> >
> >
> >
>
Re: 1.1 Candidate releases available
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Aaron,
Joe put out a thread about the interpretation of versions which I think is exactly this problem. If
we have a well understood algorithm for Versions that includes several aspects of the final qualifer
(if present) this would solve the issue. So releases is just one of many possible uses. Others
include patched versions, SNAPSHOTS, etc.
Does this sound right to you?
Aaron Mulder wrote:
> OK, so we have a small issue with the plugins.
>
> They currently list the supported versions of Geronimo in their
> metadata. The idea is that we don't state that a plugin will run in
> *any* version of Geronimo, we instead add each supported version as it
> is released. Currently that list only contains 1.1-SNAPSHOT.
>
> Now I can go add 1.1-20060607 to the list of supported versions for
> the 1.1 plugins, but we'll never be able to do that in advance. It
> would be nicer if the release candidates had more predictable names
> (rc1, rc2, rc3, etc.) so we could add them to the supported version
> list ahead of time.
>
> We also have to decide how to handle SNAPSHOT versions of Geronimo. I
> don't really think we want the released 1.1 plugins to claim that they
> support 1.2-SNAPSHOT, which may or may not be true depending on the
> extent of the changes. I'm currently planning to have a different
> plugin repository for each major version of Geronimo, so the 1.1
> plugin repository will be fairly stable and the 1.2 plugin repository
> may need to be rebuilt a lot and won't likely have a very complete set
> of plugins until the release.
>
> Thanks,
> Aaron
>
> On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> Geronimo Users and Developers,
>>
>> We've been busy little beavers this evening and would like to share
>> the fruits of our labor.
>>
>> First, may we present the candidate build of Geronimo in Octographic
>> quality. We have big builds,
>> little builds, some for Windows and others for Unix and of course the
>> ever enjoyable Tomcat and
>> Jetty versions. Please take some time to take these builds and verify
>> that they meet your exacting
>> standards for a Geronimo Release. As we like to say, "Big G, Little G
>> and things that rhyme with G."
>>
>> *Jetty*
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
>>
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
>>
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
>>
>> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip
>>
>>
>> *Tomcat*
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
>>
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
>>
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
>>
>> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip
>>
>>
>>
>> Remaining items.
>>
>> 1. We need the ActiveMQ 3.2.4 to be released.
>> 2. Finalize release notes (Hernan...can you pick this one up? A set
>> for today would be good)
>> 3. Move the remainging JIRAs out of 1.1. (Aaron, Dain, anyone ?)
>> 4. Fix OpenEJB Source. I versioned and released it but I haven't
>> fixed the SVN repo yet. I'll do
>> this in the morning unless someone beats me to it.
>> 5. A vote. I'm note sure if this can qualify for a vote since there
>> is a SNAPSHOT in the release.
>> It won't change but need to note that. Thoughts?
>>
>> To complete an official release I need to finalize the project version
>> and rebuild once again.
>>
>> Its late and I'm probably missing something so if there are barriers
>> to completing the final release
>> please let me know ASAP.
>>
>> I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out
>> and going.
>>
>> Thanks in advance for taking time to review this release of AG 1.1.
>>
>> The Geronimo Development Team
>>
>
>
>
Re: 1.1 Candidate releases available
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
OK, so we have a small issue with the plugins.
They currently list the supported versions of Geronimo in their
metadata. The idea is that we don't state that a plugin will run in
*any* version of Geronimo, we instead add each supported version as it
is released. Currently that list only contains 1.1-SNAPSHOT.
Now I can go add 1.1-20060607 to the list of supported versions for
the 1.1 plugins, but we'll never be able to do that in advance. It
would be nicer if the release candidates had more predictable names
(rc1, rc2, rc3, etc.) so we could add them to the supported version
list ahead of time.
We also have to decide how to handle SNAPSHOT versions of Geronimo. I
don't really think we want the released 1.1 plugins to claim that they
support 1.2-SNAPSHOT, which may or may not be true depending on the
extent of the changes. I'm currently planning to have a different
plugin repository for each major version of Geronimo, so the 1.1
plugin repository will be fairly stable and the 1.2 plugin repository
may need to be rebuilt a lot and won't likely have a very complete set
of plugins until the release.
Thanks,
Aaron
On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Geronimo Users and Developers,
>
> We've been busy little beavers this evening and would like to share the fruits of our labor.
>
> First, may we present the candidate build of Geronimo in Octographic quality. We have big builds,
> little builds, some for Windows and others for Unix and of course the ever enjoyable Tomcat and
> Jetty versions. Please take some time to take these builds and verify that they meet your exacting
> standards for a Geronimo Release. As we like to say, "Big G, Little G and things that rhyme with G."
>
> *Jetty*
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip
>
> *Tomcat*
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip
>
>
> Remaining items.
>
> 1. We need the ActiveMQ 3.2.4 to be released.
> 2. Finalize release notes (Hernan...can you pick this one up? A set for today would be good)
> 3. Move the remainging JIRAs out of 1.1. (Aaron, Dain, anyone ?)
> 4. Fix OpenEJB Source. I versioned and released it but I haven't fixed the SVN repo yet. I'll do
> this in the morning unless someone beats me to it.
> 5. A vote. I'm note sure if this can qualify for a vote since there is a SNAPSHOT in the release.
> It won't change but need to note that. Thoughts?
>
> To complete an official release I need to finalize the project version and rebuild once again.
>
> Its late and I'm probably missing something so if there are barriers to completing the final release
> please let me know ASAP.
>
> I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out and going.
>
> Thanks in advance for taking time to review this release of AG 1.1.
>
> The Geronimo Development Team
>
Re: 1.1 Candidate releases available
Posted by Hernan Cunico <hc...@gmail.com>.
I'll catch up with the release notes :)
Cheers!
Hernan
Matt Hogstrom wrote:
> Geronimo Users and Developers,
>
> We've been busy little beavers this evening and would like to share the
> fruits of our labor.
>
> First, may we present the candidate build of Geronimo in Octographic
> quality. We have big builds, little builds, some for Windows and others
> for Unix and of course the ever enjoyable Tomcat and Jetty versions.
> Please take some time to take these builds and verify that they meet
> your exacting standards for a Geronimo Release. As we like to say, "Big
> G, Little G and things that rhyme with G."
>
> *Jetty*
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
>
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
>
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
>
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip
>
>
> *Tomcat*
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
>
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
>
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
>
> http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip
>
>
>
> Remaining items.
>
> 1. We need the ActiveMQ 3.2.4 to be released.
> 2. Finalize release notes (Hernan...can you pick this one up? A set for
> today would be good)
> 3. Move the remainging JIRAs out of 1.1. (Aaron, Dain, anyone ?)
> 4. Fix OpenEJB Source. I versioned and released it but I haven't fixed
> the SVN repo yet. I'll do this in the morning unless someone beats me
> to it.
> 5. A vote. I'm note sure if this can qualify for a vote since there is
> a SNAPSHOT in the release. It won't change but need to note that.
> Thoughts?
>
> To complete an official release I need to finalize the project version
> and rebuild once again.
>
> Its late and I'm probably missing something so if there are barriers to
> completing the final release please let me know ASAP.
>
> I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out and
> going.
>
> Thanks in advance for taking time to review this release of AG 1.1.
>
> The Geronimo Development Team
>
Re: 1.1 Candidate releases available
Posted by Dave Colasurdo <da...@earthlink.net>.
Guillaume Nodet wrote:
>
> and the plugins portlet does not display hyperlinks, so plugins can not
> be installed...
>
Aaron,
It seems that the plugin problems (installing samples, installing
plugins from the admin console)that we saw last week have reappeared in
the RC build.
These problems originally appeared ...then disappeared for a few builds
but have resurfaced again in the RC build. Is this a geronimo problem
or a plugins regen or plugins website issue? It does not seem to be
related to ibiblio availability..
Here is a link to an earlier append on this subject:
http://www.mail-archive.com/dev@geronimo.apache.org/msg23286.html
Thanks
-Dave-
Re: 1.1 Candidate releases available
Posted by John Sisson <jr...@gmail.com>.
Aaron,
I haven't found any JIRA or changes that mentions this problem
explicitly. Is this still to be fixed?
John
Guillaume Nodet wrote:
> In addition i have the following errors in the console
>
> 13:14:46,546 ERROR [LocalAttributeManager] Error saving attributes
> java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable
> attributes working file to proper file name! Configuration will
> revert to defaults unless this is manually corrected! (could not
> rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to
> C:\tmp\geronimo-1.1-20060607\var\config\config.xml)
> at
> org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449)
>
> at
> org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618)
>
> at java.util.TimerThread.mainLoop(Unknown Source)
> at java.util.TimerThread.run(Unknown Source)
>
> and the plugins portlet does not display hyperlinks, so plugins can
> not be installed...
>
> I guess I should raise jiras for these problems.
>
> Cheers,
> Guillaume Nodet
>
> Guillaume Nodet wrote:
>
>> Shouldn't they include at least the ASF license, a NOTICE file and
>> maybe third party licenses ?
>>
>> Cheers,
>> Guillaume Nodet
>>
>> Jacek Laskowski wrote:
>>
>>> On 6/7/06, Guillaume Nodet <gu...@worldonline.fr> wrote:
>>>
>>>> Where can I find this RC ?
>>>
>>>
>>>
>>> Pick your favorite one at http://people.apache.org/~hogstrom/20060607/
>>>
>>>> Guillaume Nodet
>>>
>>>
>>>
>>> Jacek
>>>
>>
>>
>
Re: 1.1 Candidate releases available
Posted by Guillaume Nodet <gu...@worldonline.fr>.
In addition i have the following errors in the console
13:14:46,546 ERROR [LocalAttributeManager] Error saving attributes
java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable
attributes working file to proper file name! Configuration will revert
to defaults unless this is manually corrected! (could not rename
C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to
C:\tmp\geronimo-1.1-20060607\var\config\config.xml)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449)
at
org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
and the plugins portlet does not display hyperlinks, so plugins can not
be installed...
I guess I should raise jiras for these problems.
Cheers,
Guillaume Nodet
Guillaume Nodet wrote:
> Shouldn't they include at least the ASF license, a NOTICE file and
> maybe third party licenses ?
>
> Cheers,
> Guillaume Nodet
>
> Jacek Laskowski wrote:
>
>> On 6/7/06, Guillaume Nodet <gu...@worldonline.fr> wrote:
>>
>>> Where can I find this RC ?
>>
>>
>>
>> Pick your favorite one at http://people.apache.org/~hogstrom/20060607/
>>
>>> Guillaume Nodet
>>
>>
>>
>> Jacek
>>
>
>
Re: 1.1 Candidate releases available
Posted by Guillaume Nodet <gu...@worldonline.fr>.
Shouldn't they include at least the ASF license, a NOTICE file and
maybe third party licenses ?
Cheers,
Guillaume Nodet
Jacek Laskowski wrote:
> On 6/7/06, Guillaume Nodet <gu...@worldonline.fr> wrote:
>
>> Where can I find this RC ?
>
>
> Pick your favorite one at http://people.apache.org/~hogstrom/20060607/
>
>> Guillaume Nodet
>
>
> Jacek
>
Re: 1.1 Candidate releases available
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/7/06, Guillaume Nodet <gu...@worldonline.fr> wrote:
> Where can I find this RC ?
Pick your favorite one at http://people.apache.org/~hogstrom/20060607/
> Guillaume Nodet
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: 1.1 Candidate releases available
Posted by Guillaume Nodet <gu...@worldonline.fr>.
Where can I find this RC ?
Cheers,
Guillaume Nodet
Jacek Laskowski wrote:
> On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
>> We've been busy little beavers this evening and would like to share
>> the fruits of our labor.
>
> ...
>
>> Its late and I'm probably missing something so if there are barriers
>> to completing the final release
>> please let me know ASAP.
>
>
> Hey Matt,
>
> Hurrrayy! Thanks for your hard work! We (those who don't sleep during
> a day :-)) will look after the puppy.
>
> Jacek
>
Re: 1.1 Candidate releases available
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> We've been busy little beavers this evening and would like to share the fruits of our labor.
...
> Its late and I'm probably missing something so if there are barriers to completing the final release
> please let me know ASAP.
Hey Matt,
Hurrrayy! Thanks for your hard work! We (those who don't sleep during
a day :-)) will look after the puppy.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl