You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by anita kulshreshtha <a_...@yahoo.com> on 2005/01/09 21:58:11 UTC
Re: Build Failure - org/apache/geronimo/deployment/service/GBeanAdapter
Hi,
After some investigation, I was able to
generate some useful messages. A have attached patches
to reproduce these messages. Here is the problem -
1. During bootstraping, OpenEJBModuleBuilder class is
loaded by the java.net.URLClassLoader@ae1cf
classloader in GBeanInfo. When an attempt is made to
get the "getGBeanInfo" method of this class,
getDeclared Method(.,.) throws
java.lang.NoClassDefFoundError! The GBeanInfo.patch
contains the code to catch this error. What is more
surprising is that getDeclaredMethod is trying to find
org.apache.geronimo.deployment.service.GBeanAdapter
class to accomplish this! This class obviously does
not exist. Is this an expected behavior?
2. A 'catch' seems to be missing in Bootstrap.java.
Although it is not critical to this problem.
3. Is anyone else having the same problem? It might be
possible to reproduce this without building openejb
etc.
Any ideas?
comments?
Thanks
Anita
here is the build output for revision 124726 -
...........
............
[echo] Preprocessing client-system-plan.xml
[echo] Preprocessing default-database-plan.xml
[echo] Preprocessing deployer-system-plan.xml
[echo] Preprocessing j2ee-client-plan.xml
[echo] Preprocessing j2ee-deployer-plan.xml
[echo] Preprocessing
j2ee-runtime-deployer-plan.xml
[echo] Preprocessing j2ee-secure-plan.xml
[echo] Preprocessing j2ee-server-plan.xml
[echo] Preprocessing j2ee-server-tomcat-plan.xml
[echo] Preprocessing system-activemq-plan.xml
[echo] Preprocessing system-database-plan.xml
[echo] Preprocessing system-jms-plan.xml
[echo] Preprocessing system-plan.xml
[echo] Bootstrapping service deployer
********ERROR from getDeclaredMethod of class : =
class org.openejb.deployment.O
penEJBModuleBuilderclassloader =
java.net.URLClassLoader@95f290
java.lang.NoClassDefFoundError:
org/apache/geronimo/deployment/service/GBeanAdap
ter
at java.lang.Class.getDeclaredMethods0(Native
Method)
at
java.lang.Class.privateGetDeclaredMethods(Class.java:1655)
at
java.lang.Class.getDeclaredMethod(Class.java:1262)
at
org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:60)
at
org.apache.geronimo.deployment.service.GBeanBuilder.<init>(GBeanBuild
er.java:52)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.getGBeanD
ata(ServiceConfigBuilder.java:195)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans
(ServiceConfigBuilder.java:187)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConf
iguration(ServiceConfigBuilder.java:122)
at
org.apache.geronimo.deployment.Bootstrap.bootstrap(Bootstrap.java:185
)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.jav
a:230)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.jav
a:145)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa
g.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor
mAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai
nGoalTag.java:127)
at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
com.werken.werkz.jelly.PreGoalTag$1.firePreGoal(PreGoalTag.java:87)
at
com.werken.werkz.Goal.firePreGoalCallbacks(Goal.java:691)
at com.werken.werkz.Goal.fire(Goal.java:616)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai
nGoalTag.java:127)
at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa
g.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor
mAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai
nGoalTag.java:127)
at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa
g.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor
mAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
671)
at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at
org.apache.maven.cli.App.doMain(App.java:488)
at
org.apache.maven.cli.App.main(App.java:1239)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
com.werken.forehead.Forehead.run(Forehead.java:551)
at
com.werken.forehead.Forehead.main(Forehead.java:581)
*********missing catch in bootstrap
BUILD FAILED
File......
D:\anita\geronimo\incubator-geronimo\modules\assembly\maven.xml
Element... bootstrap:bootstrap
Line...... 213
Column.... 15
Unable to create GBean from class
org.openejb.deployment.OpenEJBModuleBuilder
Total time: 11 seconds
Finished at: Sun Jan 09 15:33:57 EST 2005
--- anita kulshreshtha <a_...@yahoo.com> wrote:
> Hi,
> I am using windows xp-sp2, and jdk 1.5.0. I have
> updated geronimo source (rev 123715). Some code is
> still referencing
> org/apache/geronimo/deployment/service/GBeanAdapter
> class. Velocity has problem finding
> VM_global_library.vm (see attached velocity.log) and
> can not process *-plan.xmls properly. I googled
> VM_global_library.vm, this problem seems to occur
> with
> many other projects. I am not sure which is the
> cause
> and which is the effect in our case. Last week I was
> having similar problem with another class that was
> moved. Any tip on how to avoid it or how to get to
> the
> bottom of it will be greatly appreciated.
>
> Thanks
> Anita
> [mkdir] Created dir:
>
D:\anita\geronimo\incubator-geronimo\modules\assembly\t
> arget\plan
> [echo] basedir*******
>
D:\anita\geronimo\incubator-geronimo\modules\assembly
> [echo] Preprocessing client-system-plan.xml
> [echo] Preprocessing default-database-plan.xml
> [echo] Preprocessing deployer-system-plan.xml
> [echo] Preprocessing j2ee-client-plan.xml
> [echo] Preprocessing j2ee-deployer-plan.xml
> [echo] Preprocessing
> j2ee-runtime-deployer-plan.xml
> [echo] Preprocessing j2ee-secure-plan.xml
> [echo] Preprocessing j2ee-server-plan.xml
> [echo] Preprocessing j2ee-server-tomcat-plan.xml
> [echo] Preprocessing system-activemq-plan.xml
> [echo] Preprocessing system-database-plan.xml
> [echo] Preprocessing system-jms-plan.xml
> [echo] Preprocessing system-plan.xml
> [echo] Bootstrapping service deployer
> [mkdir] Created dir:
>
D:\anita\geronimo\incubator-geronimo\modules\assembly\t
> arget\geronimo-1.0-SNAPSHOT\bin
> [mkdir] Created dir:
>
D:\anita\geronimo\incubator-geronimo\modules\assembly\t
> arget\geronimo-1.0-SNAPSHOT\config-store
>
> BUILD FAILED
> File......
>
D:\anita\geronimo\incubator-geronimo\modules\assembly\maven.xml
> Element... bootstrap:bootstrap
> Line...... 213
> Column.... 15
> org/apache/geronimo/deployment/service/GBeanAdapter
> Total time: 1 minutes 29 seconds
> Finished at: Thu Dec 30 08:28:35 EST 2004
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
> ATTACHMENT part 2 application/octet-stream name=velocity.log
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
Re: Build Failure - org/apache/geronimo/deployment/service/GBeanAdapter
Posted by anita kulshreshtha <a_...@yahoo.com>.
Dain,
Thanks.
--- Dain Sundstrom <ds...@gluecode.com> wrote:
> On Jan 10, 2005, at 5:11 AM, anita kulshreshtha
> wrote:
>
> > Let me rephrase this question. Is
> getDeclaredMethod
> > supposed to behave like this? Why is it trying to
> find
> > GBeanAdaptor class. Shouldn't it give
> > NoSuchMethodException? In that case the build will
> > fail gracefully indicating that it is time to
> build
> > openejb! I hope my question is not out of scope of
> > Geronimo.
>
> Yes this is expected. Normally when a class, is
> loaded in Java it is
> not fully resolved. This means that the byte code
> was loaded and
> verified, but not all classes the loaded class
> depends on were loaded.
> This is an optimization by the VM engineers to even
> out load time of an
> application. When you call getDeclatedMethod, the
> class is fully
> resolved, which mean that all dependency classes are
> loaded and this
> can cause a NoClassDefFoundError.
>
> In this case this is caused by an inconsistent build
> which is a very
> abnormal case, so IMO not beneficial to add such a
> check to the code as
> it complicates the code. If this could happen in an
> official release
> (even if it were rare), I would support adding a
> check.
I agree it is not likely to happen in an official
release.
Thanks
Anita
>
> -dain
>
>
__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com
Re: Build Failure - org/apache/geronimo/deployment/service/GBeanAdapter
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Jan 10, 2005, at 5:11 AM, anita kulshreshtha wrote:
> Let me rephrase this question. Is getDeclaredMethod
> supposed to behave like this? Why is it trying to find
> GBeanAdaptor class. Shouldn't it give
> NoSuchMethodException? In that case the build will
> fail gracefully indicating that it is time to build
> openejb! I hope my question is not out of scope of
> Geronimo.
Yes this is expected. Normally when a class, is loaded in Java it is
not fully resolved. This means that the byte code was loaded and
verified, but not all classes the loaded class depends on were loaded.
This is an optimization by the VM engineers to even out load time of an
application. When you call getDeclatedMethod, the class is fully
resolved, which mean that all dependency classes are loaded and this
can cause a NoClassDefFoundError.
In this case this is caused by an inconsistent build which is a very
abnormal case, so IMO not beneficial to add such a check to the code as
it complicates the code. If this could happen in an official release
(even if it were rare), I would support adding a check.
-dain
Re: Build Failure - org/apache/geronimo/deployment/service/GBeanAdapter
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- David Blevins <db...@gluecode.com> wrote:
> On Jan 9, 2005, at 1:37 PM, David Jencks wrote:
>
> >
> > On Jan 9, 2005, at 12:58 PM, anita kulshreshtha
> wrote:
> >
> >> Hi,
> >> After some investigation, I was able to
> >> generate some useful messages. A have attached
> patches
> >> to reproduce these messages. Here is the problem
> -
> >> 1. During bootstraping, OpenEJBModuleBuilder
> class is
> >> loaded by the java.net.URLClassLoader@ae1cf
> >> classloader in GBeanInfo. When an attempt is made
> to
> >> get the "getGBeanInfo" method of this class,
> >> getDeclared Method(.,.) throws
> >> java.lang.NoClassDefFoundError! The
> GBeanInfo.patch
> >> contains the code to catch this error. What is
> more
> >> surprising is that getDeclaredMethod is trying to
> find
> >>
> org.apache.geronimo.deployment.service.GBeanAdapter
> >> class to accomplish this! This class obviously
> does
> >> not exist. Is this an expected behavior?
Let me rephrase this question. Is getDeclaredMethod
supposed to behave like this? Why is it trying to find
GBeanAdaptor class. Shouldn't it give
NoSuchMethodException? In that case the build will
fail gracefully indicating that it is time to build
openejb! I hope my question is not out of scope of
Geronimo.
> >> 2. A 'catch' seems to be missing in
> Bootstrap.java.
> >> Although it is not critical to this problem.
> >> 3. Is anyone else having the same problem? It
> might be
> >> possible to reproduce this without building
> openejb
> >> etc.
> >> Any ideas?
> >> comments?
> >
> > I't's not clear to me whether you built yourself
> an up to date copy of
> > openejb. If not, I think that has caused the
> problems you are seeing.
> >
> > I don't remember if the committers all agreed to
> update all the jars
> > whenever we update svn/cvs/any of the dependendent
> projects. I
> > certainly never remember to. I keep expecting
> some automated process
> > to occur but I don't think it does :-(
> >
>
> I published new jars earlier today, so things should
> be good--finally
> got my internet services hooked up in the new
> apartment.
Thanks. I do not expect the jars to be constantly
updated, just a message indicating that the build
failed in org.openejb.deployment.OpenEJBModuleBuilder.
Thanks again
Anita
>
> > Can publishing up to date jars be automated
> reliably?
> >
>
> Any attempts I've come up with to automate this
> hoop-jumping has never
> failed to create more manual work keeping it all
> running and fixing
> issues. One of the issues is that no one else can
> build on a box that
> is automatically running build/tests because of port
> conflicts.
>
> My hopes are in Continuum and a smart svn hook,
> though we'd still have
> the port issue.
>
> -David
>
> > thanks
> > david jencks
> >
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
Re: Build Failure - org/apache/geronimo/deployment/service/GBeanAdapter
Posted by David Blevins <db...@gluecode.com>.
On Jan 9, 2005, at 1:37 PM, David Jencks wrote:
>
> On Jan 9, 2005, at 12:58 PM, anita kulshreshtha wrote:
>
>> Hi,
>> After some investigation, I was able to
>> generate some useful messages. A have attached patches
>> to reproduce these messages. Here is the problem -
>> 1. During bootstraping, OpenEJBModuleBuilder class is
>> loaded by the java.net.URLClassLoader@ae1cf
>> classloader in GBeanInfo. When an attempt is made to
>> get the "getGBeanInfo" method of this class,
>> getDeclared Method(.,.) throws
>> java.lang.NoClassDefFoundError! The GBeanInfo.patch
>> contains the code to catch this error. What is more
>> surprising is that getDeclaredMethod is trying to find
>> org.apache.geronimo.deployment.service.GBeanAdapter
>> class to accomplish this! This class obviously does
>> not exist. Is this an expected behavior?
>> 2. A 'catch' seems to be missing in Bootstrap.java.
>> Although it is not critical to this problem.
>> 3. Is anyone else having the same problem? It might be
>> possible to reproduce this without building openejb
>> etc.
>> Any ideas?
>> comments?
>
> I't's not clear to me whether you built yourself an up to date copy of
> openejb. If not, I think that has caused the problems you are seeing.
>
> I don't remember if the committers all agreed to update all the jars
> whenever we update svn/cvs/any of the dependendent projects. I
> certainly never remember to. I keep expecting some automated process
> to occur but I don't think it does :-(
>
I published new jars earlier today, so things should be good--finally
got my internet services hooked up in the new apartment.
> Can publishing up to date jars be automated reliably?
>
Any attempts I've come up with to automate this hoop-jumping has never
failed to create more manual work keeping it all running and fixing
issues. One of the issues is that no one else can build on a box that
is automatically running build/tests because of port conflicts.
My hopes are in Continuum and a smart svn hook, though we'd still have
the port issue.
-David
> thanks
> david jencks
>
Re: Build Failure - org/apache/geronimo/deployment/service/GBeanAdapter
Posted by David Jencks <dj...@gluecode.com>.
On Jan 9, 2005, at 12:58 PM, anita kulshreshtha wrote:
> Hi,
> After some investigation, I was able to
> generate some useful messages. A have attached patches
> to reproduce these messages. Here is the problem -
> 1. During bootstraping, OpenEJBModuleBuilder class is
> loaded by the java.net.URLClassLoader@ae1cf
> classloader in GBeanInfo. When an attempt is made to
> get the "getGBeanInfo" method of this class,
> getDeclared Method(.,.) throws
> java.lang.NoClassDefFoundError! The GBeanInfo.patch
> contains the code to catch this error. What is more
> surprising is that getDeclaredMethod is trying to find
> org.apache.geronimo.deployment.service.GBeanAdapter
> class to accomplish this! This class obviously does
> not exist. Is this an expected behavior?
> 2. A 'catch' seems to be missing in Bootstrap.java.
> Although it is not critical to this problem.
> 3. Is anyone else having the same problem? It might be
> possible to reproduce this without building openejb
> etc.
> Any ideas?
> comments?
I't's not clear to me whether you built yourself an up to date copy of
openejb. If not, I think that has caused the problems you are seeing.
I don't remember if the committers all agreed to update all the jars
whenever we update svn/cvs/any of the dependendent projects. I
certainly never remember to. I keep expecting some automated process
to occur but I don't think it does :-(
Can publishing up to date jars be automated reliably?
thanks
david jencks
> Thanks
> Anita
>
> here is the build output for revision 124726 -
> ...........
> ............
> [echo] Preprocessing client-system-plan.xml
> [echo] Preprocessing default-database-plan.xml
> [echo] Preprocessing deployer-system-plan.xml
> [echo] Preprocessing j2ee-client-plan.xml
> [echo] Preprocessing j2ee-deployer-plan.xml
> [echo] Preprocessing
> j2ee-runtime-deployer-plan.xml
> [echo] Preprocessing j2ee-secure-plan.xml
> [echo] Preprocessing j2ee-server-plan.xml
> [echo] Preprocessing j2ee-server-tomcat-plan.xml
> [echo] Preprocessing system-activemq-plan.xml
> [echo] Preprocessing system-database-plan.xml
> [echo] Preprocessing system-jms-plan.xml
> [echo] Preprocessing system-plan.xml
> [echo] Bootstrapping service deployer
> ********ERROR from getDeclaredMethod of class : =
> class org.openejb.deployment.O
> penEJBModuleBuilderclassloader =
> java.net.URLClassLoader@95f290
> java.lang.NoClassDefFoundError:
> org/apache/geronimo/deployment/service/GBeanAdap
> ter
> at java.lang.Class.getDeclaredMethods0(Native
> Method)
> at
> java.lang.Class.privateGetDeclaredMethods(Class.java:1655)
> at
> java.lang.Class.getDeclaredMethod(Class.java:1262)
> at
> org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:60)
> at
> org.apache.geronimo.deployment.service.GBeanBuilder.<init>(GBeanBuild
> er.java:52)
> at
> org.apache.geronimo.deployment.service.ServiceConfigBuilder.getGBeanD
> ata(ServiceConfigBuilder.java:195)
> at
> org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans
> (ServiceConfigBuilder.java:187)
> at
> org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConf
> iguration(ServiceConfigBuilder.java:122)
> at
> org.apache.geronimo.deployment.Bootstrap.bootstrap(Bootstrap.java:185
> )
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at
> java.lang.reflect.Method.invoke(Method.java:324)
> at
> org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.jav
> a:230)
> at
> org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.jav
> a:145)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa
> g.java:79)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor
> mAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at
> com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
> at
> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai
> nGoalTag.java:127)
> at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
> at
> com.werken.werkz.jelly.PreGoalTag$1.firePreGoal(PreGoalTag.java:87)
> at
> com.werken.werkz.Goal.firePreGoalCallbacks(Goal.java:691)
> at com.werken.werkz.Goal.fire(Goal.java:616)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at
> com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at
> com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
> at
> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai
> nGoalTag.java:127)
> at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa
> g.java:79)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor
> mAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at
> com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
> at
> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai
> nGoalTag.java:127)
> at
> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa
> g.java:79)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor
> mAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at
> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
> 671)
> at
> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
> at
> org.apache.maven.cli.App.doMain(App.java:488)
> at
> org.apache.maven.cli.App.main(App.java:1239)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at
> java.lang.reflect.Method.invoke(Method.java:324)
> at
> com.werken.forehead.Forehead.run(Forehead.java:551)
> at
> com.werken.forehead.Forehead.main(Forehead.java:581)
> *********missing catch in bootstrap
>
> BUILD FAILED
> File......
> D:\anita\geronimo\incubator-geronimo\modules\assembly\maven.xml
> Element... bootstrap:bootstrap
> Line...... 213
> Column.... 15
> Unable to create GBean from class
> org.openejb.deployment.OpenEJBModuleBuilder
> Total time: 11 seconds
> Finished at: Sun Jan 09 15:33:57 EST 2005
>
> --- anita kulshreshtha <a_...@yahoo.com> wrote:
>
>> Hi,
>> I am using windows xp-sp2, and jdk 1.5.0. I have
>> updated geronimo source (rev 123715). Some code is
>> still referencing
>> org/apache/geronimo/deployment/service/GBeanAdapter
>> class. Velocity has problem finding
>> VM_global_library.vm (see attached velocity.log) and
>> can not process *-plan.xmls properly. I googled
>> VM_global_library.vm, this problem seems to occur
>> with
>> many other projects. I am not sure which is the
>> cause
>> and which is the effect in our case. Last week I was
>> having similar problem with another class that was
>> moved. Any tip on how to avoid it or how to get to
>> the
>> bottom of it will be greatly appreciated.
>>
>> Thanks
>> Anita
>> [mkdir] Created dir:
>>
> D:\anita\geronimo\incubator-geronimo\modules\assembly\t
>> arget\plan
>> [echo] basedir*******
>>
> D:\anita\geronimo\incubator-geronimo\modules\assembly
>> [echo] Preprocessing client-system-plan.xml
>> [echo] Preprocessing default-database-plan.xml
>> [echo] Preprocessing deployer-system-plan.xml
>> [echo] Preprocessing j2ee-client-plan.xml
>> [echo] Preprocessing j2ee-deployer-plan.xml
>> [echo] Preprocessing
>> j2ee-runtime-deployer-plan.xml
>> [echo] Preprocessing j2ee-secure-plan.xml
>> [echo] Preprocessing j2ee-server-plan.xml
>> [echo] Preprocessing j2ee-server-tomcat-plan.xml
>> [echo] Preprocessing system-activemq-plan.xml
>> [echo] Preprocessing system-database-plan.xml
>> [echo] Preprocessing system-jms-plan.xml
>> [echo] Preprocessing system-plan.xml
>> [echo] Bootstrapping service deployer
>> [mkdir] Created dir:
>>
> D:\anita\geronimo\incubator-geronimo\modules\assembly\t
>> arget\geronimo-1.0-SNAPSHOT\bin
>> [mkdir] Created dir:
>>
> D:\anita\geronimo\incubator-geronimo\modules\assembly\t
>> arget\geronimo-1.0-SNAPSHOT\config-store
>>
>> BUILD FAILED
>> File......
>>
> D:\anita\geronimo\incubator-geronimo\modules\assembly\maven.xml
>> Element... bootstrap:bootstrap
>> Line...... 213
>> Column.... 15
>> org/apache/geronimo/deployment/service/GBeanAdapter
>> Total time: 1 minutes 29 seconds
>> Finished at: Thu Dec 30 08:28:35 EST 2004
>>
>>
>>
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! Mail - You care about security. So do we.
>> http://promotions.yahoo.com/new_mail
>
>> ATTACHMENT part 2 application/octet-stream name=velocity.log
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250<GBeanInfo.patch><Bootstrap.patch>