geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Testsuite module, with basic/crude Selenium support
Date Thu, 07 Sep 2006 21:56:08 GMT
Please review the latest patch at
http://issues.apache.org/jira/browse/GERONIMO-2359#action_12433253

I have worked on all but one of the issues we discussed here. The
remaning issue is the one of delegating stuff to a JMXProxy.

I have issues getting my geronimo server to start. So I shall go and
chase that problem for now.
Module 18/20 org.apache.geronimo.configs/webconsole-jetty/1.2-SNAPSHOT/car
      17:27:31,528 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName="org.apache.geronimo.configs/webconsole-jetty/1.2-SNAPSHOT/car?J2EEApplication=org.apache.geronimo.configs/webconsole-jetty/1.2-SNAPSHOT/car,WebModule=framework.war,j2eeType=Servlet,name=car-export-forward"
java.lang.ClassNotFoundException:
org.apache.geronimo.console.servlet.ContextForwardServlet in
classloader org.apache.geronimo.configs/webconsole-jetty_framework.war/1.2-SNAPSHOT/car
	at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:249)

Cheers
Prasad


On 9/6/06, Jason Dillon <jason@planet57.com> wrote:
> On Sep 6, 2006, at 8:03 PM, Prasad Kashyap wrote:
> > Here are the use case scenarios I thought of  -
> >
> > UC #1 : use goal in testsuites. The modules for deployment in this
> > execution typically comes from the testsupport project. For most
> > testcases we can build the modules with the plans inside them. A few
> > testcases that need to test a deployment with an external plan can
> > specify the plan in the config.
> >
> > UC #2: use goal by others. The modules for deployment in this
> > execution may come from a repository or be specified as a non-artifact
> > archive. Even here, the plan, if need be, can be specified in the
> > config along with the <modules>. However what I'd eventually like to
> > do here is be able to deploy a list of modules.
> >
> > To be able to deploy a list of modules, the #plan param needs to get
> > inside the #module param so that there can be a plan specified for
> > every module config.
>
> None of these cases require the moduleId and defaultModuleId bits,
> which was what I was hinting at.  A list of modules, with optional
> plan such be fine.
>
> Sounds like that if you did want to do some selection, that it would
> be over one set of modules or another... but I still don't see the
> need for that.
>
>
> >> Why do we have 'distribute' and 'undeploy'?  Why not 'deploy' and
> >> 'undeploy'?
> >
> > "distribute" and "deploy" are some of the options passed to the deploy
> > tool. The former option just "installs" the modules into G while the
> > latter "installs" and starts it.  Now I went with distribute +  start
> > sequence since that is what G had in the old itests. If we think we
> > can get rid of it and just use deploy, then I'll be glad to change it.
>
> I'd say, call the goal deploy, and add an optional startModule flag
> to indicate if distribute() or deploy() should be used.
>
>
> >> In DistributeModuleMojo, why is #plan a String and not a File?  The
> >> plexus container will perform the equiv of your getFile() for you.
> >
> > I thought about it. But eventually I wanted to move the #plan inside
> > the #module. So I left it as String.
>
> You can still have a File in a helper object and Plexus will inject
> it.  We should create a ModuleConfig, that extends from ArtifactItem
> (like AssemblyConfig) and add that field.
>
>
> >> Any reason why we have explicitly set the TCL in getDeploymentManager
> >> (), was the TCL that maven setup not correct?
> >
> > Hmm.. Not that I know of.  Must be from legacy code. But I'll reserve
> > judgement on it until I investigate that further.
>
> Well, if we don't need to set it... lets not.
>
> --jason
>
>

Mime
View raw message