Sounds great to me. I'm assuming that on top of what you have
working locally we could copy geronimo/plugins/console/trunk into
geronimo/server/trunk/plugins/console (or wherever you had in mind)
and tweak the poms accordingly for an interim solution. That will
provide our pre-assembled servers with a base console that contains a
plugin installer for installing the other server plugins and console
extensions like the dojo viewers, system DB and activemq portlets,
etc. Those plugins would still need to be built, released, and
installed separately unless we wanted to move them under server/trunk
as well as part of this interim solution. Depends on how far we
want to go with reflecting the modularity of the server in how we
structure SVN and handle release management.
Best wishes,
Paul
On Sep 28, 2007, at 2:50 PM, David Jencks wrote:
I think that we should approach the "assemble server from plugins"
idea in stages:
1. build all the plugins inside the current server/trunk build
framework and assemble the server from these. This is almost
working locally.... maybe this weekend.
2. distribute the sets of related plugins into a different svn
layout with unconnected release cycles and figure out how to end up
with a usable server with so many moving parts. :-)
So in line with (1) I'd like to see the new console move ASAP,
perhaps temporarily, into maybe server/trunk/plugins where we can
immediately start including it in servers without having to solve (2).
thanks
david jencks
On Sep 28, 2007, at 9:44 AM, David Jencks wrote:
On Sep 28, 2007, at 9:35 AM, Paul McMahan wrote:
The old admin console in trunk still has a few loose ends after
the schema changes in GERONIMO-3330. Right now we're fixing/
improving the plugin management portlet in the new admin console
based on the ppt I sent out the other day and it should work OK
for you. It's pretty easy to install into a minimal assembly
using:
% bin/deploy.sh search-plugins http://geronimo.apache.org/
plugins/geronimo-2.1/
Administration Console :: Tomcat plugin
63: (1.0-SNAPSHOT)
Administration Console :: Jetty plugin
64: (1.0-SNAPSHOT)
You can install it into a jee5 assembly if you uninstall the old
admin console first (they both want to use /console context root).
As indicated above, the new pluggable admin console is itself a
plugin and is not kept in server/trunk. So when we start
building the full-sized assemblies from framework+plugins we can
replace the old admin console. I left the old one in place to
minimize disruption while we figure out how we want to build
servers using the more modular approach.
BTW I've made a lot of progress on this locally.... I have a jetty
server that's assembled from plugins that starts and shows the
(old) admin console that's assembled from plugins. I'm hoping to
get the other servers assembled this way this weekend and then
commit.
david jencks
Best wishes,
Paul
On Sep 28, 2007, at 6:23 AM, Jeff Genender wrote:
Is the plugin installer broke? Duno if a java 1.4 dependency
got in or
not, but I am unable to install plugins from the console:
java.lang.IllegalArgumentException: Cannot convert [1.5] of type
class
java.util.ArrayList to class [Ljava.lang.String;
at org.apache.el.lang.ELSupport.coerceToType
(ELSupport.java:374)
at org.apache.el.parser.AstFunction.getValue
(AstFunction.java:86)
at
org.apache.el.ValueExpressionImpl.getValue
(ValueExpressionImpl.java:186)
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate
(PageContextImpl.java:923)
at
jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fother
wise_005f2(viewForDownload_jsp.java:488)
at
jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fchoos
e_005f2(viewForDownload_jsp.java:435)
at
jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspService
(viewForDownload_jsp.java:136)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke
(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude
(ApplicationDispatcher.java:557)
at
org.apache.catalina.core.ApplicationDispatcher.include
(ApplicationDispatcher.java:481)
at
org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include
(PortletRequestDispatcherImpl.java:65)
at
org.apache.geronimo.console.MultiPagePortlet.doView
(MultiPagePortlet.java:153)
at javax.portlet.GenericPortlet.doDispatch
(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render
(GenericPortlet.java:175)
at
org.apache.pluto.core.PortletServlet.dispatch
(PortletServlet.java:218)
at
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:806)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:
153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke
(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude
(ApplicationDispatcher.java:557)
at
org.apache.catalina.core.ApplicationDispatcher.include
(ApplicationDispatcher.java:481)
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.render
Portlet(PortletContainerWrapperImpl.java:70)
at
org.apache.pluto.portalImpl.aggregation.PortletFragment.service
(PortletFragment.java:168)
at
jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService
(ColumnFragment_jsp.java:70)
