You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Marc Jeffrey Driftmeyer <mj...@reanimality.com> on 2002/05/10 10:31:18 UTC
ExcaliburComponentManager.java still missing from Latest Snapshot
breaks /cocoon/ and throwing ERRORS
Vadim - Are you obtuse on purpose?
Its the one throwing the error in the process of mapping /cocoon/
Logic dictates one reduces errors from the first one thrown to the last
one thrown.
2.1 dev has been in the tree for the past month, atleast. If its Alpha
than someone should make separate branches for the alpha and then the
maintenance branch for 2.0.2 so it can work seemlessly with SDK 1.4.
Or perhaps I'm just highly critical? No. I'm driven by wanting to get
this stuff working smoothly so average folks, like myself, who can
articulate technology to inepts with money can find it as an useful
means of development and worth investing.
And if you think Technology sells itself you wouldn't be working on Open
Source software and dealing with an Troglodyte like M$ dictating the
Market landscape.
And after just getting a clean snapshot and rebuilding the cocoon.war it
still fails. with the Avalon Framework specifically referencing
ExcaliburComponentManager.java.
Here is the error.log.
ERROR (2002-05-10) 01:22.48:604 [core.manager](Unknown-URI)
Unknown-thread/ExcaliburComponentManager: Could not get class
org.apache.cocoon.components.store.impl.FilesystemStore for role
org.apache.excalibur.store.Store on configuration element persistent-store
java.lang.ClassNotFoundException:
org.apache.cocoon.components.store.impl.FilesystemStore
at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:435)
at org.apache.cocoon.Cocoon.configure(Cocoon.java:408)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:270)
at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1214)
at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:415)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:918)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:810)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3274)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3416)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:478)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:738)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:324)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:389)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:155)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:638)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
ERROR (2002-05-10) 01:22.48:614 [access](Unknown-URI)
Unknown-thread/CocoonServlet: Exception reloading
org.apache.avalon.framework.configuration.ConfigurationException: Could
not get class
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:448)
at org.apache.cocoon.Cocoon.configure(Cocoon.java:408)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:270)
at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1214)
at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:415)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:918)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:810)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3274)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3416)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:478)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:738)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:324)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:389)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:155)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:638)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
Caused by: java.lang.ClassNotFoundException:
org.apache.cocoon.components.store.impl.FilesystemStore
at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:435)
... 29 more
java.lang.ClassNotFoundException:
org.apache.cocoon.components.store.impl.FilesystemStore
at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:435)
at org.apache.cocoon.Cocoon.configure(Cocoon.java:408)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:270)
at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1214)
at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:415)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:918)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:810)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3274)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3416)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:478)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:738)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:324)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:389)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:155)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:638)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
I was hoping it would be fixed so I could just work with the 2.1 dev
stuff since when it does load it is snappier than the 2.0.2 release, in
general.
Here is to wishful thinking, and reversion back to 2.0.2.
Finally, if this is an SDK 1.4 issue, great I'll build against 1.3.1 but
I have yet to get an answer as to how come this class since it seems to
be ignored during the build process leading one to conclude with build
success there will be /cocoon/ servlet success.
Sincerely Yours,
Marc J. Driftmeyer
Vadim Gritsenko wrote:
>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
>>
>>Here is an excerpt of my error log..
>>
>>ERROR (2002-05-08) 14:36.33:921 [core.manager](Unknown-URI)
>>Unknown-thread/ExcaliburComponentManager: Could not get class
>>org.apache.cocoon.components.store.impl.FilesystemStore for role
>>org.apache.excalibur.store.Store on configuration element
>>
>>
>persistent-store
>
>
>>java.lang.ClassNotFoundException:
>>org.apache.cocoon.components.store.impl.FilesystemStore
>>
>>
>
>Why do you think that arbitrarily taken snapshot of Cocoon Alpha CVS
>should work?
>
>PS What this has to do with ExcaliburComponentManager?
>
>Vadim
>
>
>
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
>> at
>>
>>
>>
>org.apache.avalon.excalibur.component.ExcaliburComponentManager.configur
>e(Exca
>
>
>>liburComponentManager.java:435)
>> at org.apache.cocoon.Cocoon.configure(Cocoon.java:408)
>> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:270)
>>
>>
>>-Marc
>>
>>Vadim Gritsenko wrote:
>>
>>
>>
>>>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
>>>>
>>>>ExcaliburComponentManager.java missing from the results in our
>>>>infamous.
>>>>
>>>>
>>>Don't know what you mean:
>>>xml-cocoon2\lib\core\avalon-excalibur-20020506.jar happily contains
>>>org\apache\avalon\excalibur\component\ExcaliburComponentManager.class
>>>file.
>>>
>>>ExcaliburComponentManager.java never was part of the Cocoon CVS
>>>
>>>
>and/or
>
>
>>>any Cocoon distro.
>>>
>>>Vadim
>>>
>>>
>>>
>>>
>>>>How does this shit continue to happen? SQA is about hammering out
>>>>bugs
>>>>and cross-referencing known workarounds by level of severity and
>>>>
>>>>
>then
>
>
>>>>prioritizing the order in which such "human mistakes" get hammered
>>>>out.
>>>>
>>>>
>>>
>>>
>>>>Cocoon 2 - Internal servlet error
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>-----------------------------------------------------------------------
>>
>>
>-
>
>
>>>------
>>>
>>>
>>>
>>>
>>>>--
>>>>
>>>>type fatal
>>>>
>>>>message Cocoon was not initialized.
>>>>
>>>>description Cocoon was not initialized. Cannot process request.
>>>>
>>>>sender org.apache.cocoon.servlet.CocoonServlet
>>>>
>>>>source Cocoon servlet
>>>>
>>>>request-uri
>>>>
>>>>/cocoon/
>>>>
>>>>
>>>>
>>>>Sincerely Yours,
>>>>
>>>>Marc J. Driftmeyer
>>>>
>>>>//
>>>>
>>>>
>
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
>To unsubscribe, e-mail: <co...@xml.apache.org>
>For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
//
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: ExcaliburComponentManager.java still missing from Latest Snapshot
breaks /cocoon/ and throwing ERRORS
Posted by Marc Jeffrey Driftmeyer <mj...@reanimality.com>.
Jump in all you want. More suggestions the better. I'll check into it.
-Marc
Torsten Curdt wrote:
>Sorry, for jumping in here...
>
><snip/>
>
>
>
>>And after just getting a clean snapshot and rebuilding the cocoon.war it
>>still fails. with the Avalon Framework specifically referencing
>>ExcaliburComponentManager.java.
>>
>>
>
>..
>
>
>
>>Here is the error.log.
>>
>>ERROR (2002-05-10) 01:22.48:604 [core.manager](Unknown-URI)
>>Unknown-thread/ExcaliburComponentManager: Could not get class
>>org.apache.cocoon.components.store.impl.FilesystemStore for role
>>org.apache.excalibur.store.Store on configuration element persistent-store
>>java.lang.ClassNotFoundException:
>>org.apache.cocoon.components.store.impl.FilesystemStore
>>
>>
>
>
>AFAICS it is referencing the role "org.apache.excalibur.store.Store"
>..so better check you store setup in cocoon.xconf. As Vadim pointed out: this
>should have nothing to do with the ECM except seeing the ECM complaining...
>--
>Torsten
>
>
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
>To unsubscribe, e-mail: <co...@xml.apache.org>
>For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: ExcaliburComponentManager.java still missing from Latest Snapshot breaks /cocoon/ and throwing ERRORS
Posted by Torsten Curdt <tc...@dff.st>.
Sorry, for jumping in here...
<snip/>
> And after just getting a clean snapshot and rebuilding the cocoon.war it
> still fails. with the Avalon Framework specifically referencing
> ExcaliburComponentManager.java.
..
> Here is the error.log.
>
> ERROR (2002-05-10) 01:22.48:604 [core.manager](Unknown-URI)
> Unknown-thread/ExcaliburComponentManager: Could not get class
> org.apache.cocoon.components.store.impl.FilesystemStore for role
> org.apache.excalibur.store.Store on configuration element persistent-store
> java.lang.ClassNotFoundException:
> org.apache.cocoon.components.store.impl.FilesystemStore
AFAICS it is referencing the role "org.apache.excalibur.store.Store"
..so better check you store setup in cocoon.xconf. As Vadim pointed out: this
should have nothing to do with the ECM except seeing the ECM complaining...
--
Torsten
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: ExcaliburComponentManager.java still missing from Latest Snapshot breaks /cocoon/ and throwing ERRORS
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
>
> Vadim,
>
> I discovered the culprit and it is NOT Cocoon's, hence you developers
> mistakes at all.
>
> During one of my CVS HEAD fetches Windblows XP Professional through
one
> of its already noted NTFS.sys Kernel Panicks leaving an incomplete
update.
>
> WinCVS unless forced to check for missing directories, etc will just
> Prune any empty directories by default which is what happened.
>
> After a clean removal of a previous HEAD Update it XP crashed and I
> investigated the possibility of an incomplete directory mapping, etc
and
> forced it to do a complete index check and then update accordingly.
>
> Since then the War compiles and runs. Yes it has a few Mappings that
> are not there but those are known and have workarounds.
Glad you were able to solve the issue. Nobody could expect that you have
incomplete tree cause of XP crash.
Vadim
> I just thought perhaps with my experience using XP someone might note
> that when using WinCVS force it to verify a complete HEAD and do not
> Prune the directories by mistake.
>
> -Marc
>
>
> Vadim Gritsenko wrote:
>
> >>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
> >>
> >>Vadim - Are you obtuse on purpose?
> >>
> >>
> >
> >1a or 2c?
> >http://www.dictionary.com/cgi-bin/dict.pl?term=obtuse
> >
> >
> >
> >
> >>Its the one throwing the error in the process of mapping /cocoon/
> >>
> >>
> >
> >It is logging the error, yes, which means that it is physically
> >*present* in your setup so your saying "it's absent" is wrong.
> >
> >
> >
> >
> >>Logic dictates one reduces errors from the first one thrown to the
> >>
> >>
> >last
> >
> >
> >>one thrown.
> >>
> >>2.1 dev has been in the tree for the past month, atleast.
> >>
> >>
> >
> >And during these months, it entered alpha stage, it got WARNING in
the
> >root, and announcement had been made on the list(s).
> >
> >
> >
> >
> >>If its Alpha
> >>than someone should make separate branches for the alpha and then
the
> >>maintenance branch for 2.0.2 so it can work seemlessly with SDK 1.4.
> >>
> >>
> >
> >The branch was created some time ago, cocoon_2_0_3_branch, and it was
> >several times explained on the list how to get it for CVS newbies.
> >Please refer to the archive.
> >
> >
> >
> >
> >>Or perhaps I'm just highly critical? No. I'm driven by wanting to
> >>
> >>
> >get
> >
> >
> >>this stuff working smoothly so average folks, like myself, who can
> >>articulate technology to inepts with money can find it as an useful
> >>means of development and worth investing.
> >>
> >>
> >
> >Then please do download 2.0.3 CVS, don't be on the "bleeding edge".
Even
> >stable branch of CVS is too extreme for many - most of the users (I
> >guess) are on the one of the releases, not on the CVS.
> >
> >
> >
> >
> >>And if you think Technology sells itself you wouldn't be working on
> >>
> >>
> >Open
> >
> >
> >>Source software and dealing with an Troglodyte like M$ dictating the
> >>Market landscape.
> >>
> >>
> >
> >Why do you think so? :)
> >
> >
> >
> >
> >>And after just getting a clean snapshot and rebuilding the
cocoon.war
> >>
> >>
> >it
> >
> >
> >>still fails. with the Avalon Framework specifically referencing
> >>ExcaliburComponentManager.java.
> >>
> >>Here is the error.log.
> >>
> >>ERROR (2002-05-10) 01:22.48:604 [core.manager](Unknown-URI)
> >>Unknown-thread/ExcaliburComponentManager: Could not get class
> >>org.apache.cocoon.components.store.impl.FilesystemStore for role
> >>org.apache.excalibur.store.Store on configuration element
> >>
> >>
> >persistent-store
> >
> >
> >>java.lang.ClassNotFoundException:
> >>org.apache.cocoon.components.store.impl.FilesystemStore
> >>
> >>
> >
> >Make sure you have this class.
> >
> ><snip/>
> >
> >
> >
> >
> >>I was hoping it would be fixed so I could just work with the 2.1 dev
> >>
> >>
> >
> >Don't know is it 2.1 error or issue with your setup, but...
> >
> >
> >
> >>stuff since when it does load it is snappier than the 2.0.2 release,
> >>
> >>
> >in
> >
> >
> >>general.
> >>
> >>
> >
> >You can get 2.0.3, change sitemap engine from compiled to interpreted
> >(read cocoon.xconf), and you will have same performance as 2.1 has.
> >
> >
> >
> >
> >>Here is to wishful thinking, and reversion back to 2.0.2.
> >>
> >>Finally, if this is an SDK 1.4 issue, great I'll build against 1.3.1
> >>
> >>
> >but
> >
> >1.4 vs 1.3.1 differences are XML, SQL, and headless AWT stuff.
> >
> >
> >
> >
> >>I have yet to get an answer as to how come this class since it seems
> >>
> >>
> >to
> >
> >
> >>be ignored during the build process leading one to conclude with
build
> >>success there will be /cocoon/ servlet success.
> >>
> >>
> >
> >Then it might be simple build.xml bug.
> >
> >Vadim
> >
> >
> >
> >
> >
> >>Sincerely Yours,
> >>
> >>Marc J. Driftmeyer
> >>
> >>Vadim Gritsenko wrote:
> >>
> >>
> >>
> >>>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
> >>>>
> >>>>Here is an excerpt of my error log..
> >>>>
> >>>>ERROR (2002-05-08) 14:36.33:921 [core.manager](Unknown-URI)
> >>>>Unknown-thread/ExcaliburComponentManager: Could not get class
> >>>>org.apache.cocoon.components.store.impl.FilesystemStore for role
> >>>>org.apache.excalibur.store.Store on configuration element
> >>>>
> >>>>
> >>>>
> >>>>
> >>>persistent-store
> >>>
> >>>
> >>>
> >>>
> >>>>java.lang.ClassNotFoundException:
> >>>>org.apache.cocoon.components.store.impl.FilesystemStore
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Why do you think that arbitrarily taken snapshot of Cocoon Alpha
CVS
> >>>should work?
> >>>
> >>>PS What this has to do with ExcaliburComponentManager?
> >>>
> >>>Vadim
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
> >>>> at java.security.AccessController.doPrivileged(Native Method)
> >>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
> >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
> >>>> at
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
>
>>org.apache.avalon.excalibur.component.ExcaliburComponentManager.config
u
> >>
> >>
> >r
> >
> >
> >>>e(Exca
> >>>
> >>>
> >>>
> >>>
> >>>>liburComponentManager.java:435)
> >>>> at org.apache.cocoon.Cocoon.configure(Cocoon.java:408)
> >>>> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:270)
> >>>>
> >>>>
> >>>>-Marc
> >>>>
> >>>>Vadim Gritsenko wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
> >>>>>>
> >>>>>>ExcaliburComponentManager.java missing from the results in our
> >>>>>>infamous.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Don't know what you mean:
> >>>>>xml-cocoon2\lib\core\avalon-excalibur-20020506.jar happily
contains
> >>>>>
> >>>>>
>
>>>>org\apache\avalon\excalibur\component\ExcaliburComponentManager.clas
s
> >>>>
> >>>>
> >>>>>file.
> >>>>>
> >>>>>ExcaliburComponentManager.java never was part of the Cocoon CVS
> >>>>>and/or any Cocoon distro.
> >>>>>
> >>>>>Vadim
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>How does this shit continue to happen? SQA is about hammering
out
> >>>>>>bugs
> >>>>>>and cross-referencing known workarounds by level of severity and
> >>>>>>then
> >>>>>>prioritizing the order in which such "human mistakes" get
hammered
> >>>>>>out.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>>Cocoon 2 - Internal servlet error
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
>
>>>---------------------------------------------------------------------
-
> >>>
> >>>
> >-
> >
> >
> >>>>
> >>>>
> >>>-
> >>>
> >>>
> >>>
> >>>
> >>>>>------
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>--
> >>>>>>
> >>>>>>type fatal
> >>>>>>
> >>>>>>message Cocoon was not initialized.
> >>>>>>
> >>>>>>description Cocoon was not initialized. Cannot process request.
> >>>>>>
> >>>>>>sender org.apache.cocoon.servlet.CocoonServlet
> >>>>>>
> >>>>>>source Cocoon servlet
> >>>>>>
> >>>>>>request-uri
> >>>>>>
> >>>>>>/cocoon/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Sincerely Yours,
> >>>>>>
> >>>>>>Marc J. Driftmeyer
> >>>>>>
> >>>>>>//
> >>>>>>
> >>>>>>
> >
> >
> >---------------------------------------------------------------------
> >Please check that your question has not already been answered in the
> >FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> >
> >To unsubscribe, e-mail: <co...@xml.apache.org>
> >For additional commands, e-mail: <co...@xml.apache.org>
> >
> >
> //
>
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: ExcaliburComponentManager.java still missing from Latest Snapshot
breaks /cocoon/ and throwing ERRORS
Posted by Marc Jeffrey Driftmeyer <mj...@reanimality.com>.
Vadim,
I discovered the culprit and it is NOT Cocoon's, hence you developers
mistakes at all.
During one of my CVS HEAD fetches Windblows XP Professional through one
of its already noted NTFS.sys Kernel Panicks leaving an incomplete update.
WinCVS unless forced to check for missing directories, etc will just
Prune any empty directories by default which is what happened.
After a clean removal of a previous HEAD Update it XP crashed and I
investigated the possibility of an incomplete directory mapping, etc and
forced it to do a complete index check and then update accordingly.
Since then the War compiles and runs. Yes it has a few Mappings that
are not there but those are known and have workarounds.
I just thought perhaps with my experience using XP someone might note
that when using WinCVS force it to verify a complete HEAD and do not
Prune the directories by mistake.
-Marc
Vadim Gritsenko wrote:
>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
>>
>>Vadim - Are you obtuse on purpose?
>>
>>
>
>1a or 2c?
>http://www.dictionary.com/cgi-bin/dict.pl?term=obtuse
>
>
>
>
>>Its the one throwing the error in the process of mapping /cocoon/
>>
>>
>
>It is logging the error, yes, which means that it is physically
>*present* in your setup so your saying "it's absent" is wrong.
>
>
>
>
>>Logic dictates one reduces errors from the first one thrown to the
>>
>>
>last
>
>
>>one thrown.
>>
>>2.1 dev has been in the tree for the past month, atleast.
>>
>>
>
>And during these months, it entered alpha stage, it got WARNING in the
>root, and announcement had been made on the list(s).
>
>
>
>
>>If its Alpha
>>than someone should make separate branches for the alpha and then the
>>maintenance branch for 2.0.2 so it can work seemlessly with SDK 1.4.
>>
>>
>
>The branch was created some time ago, cocoon_2_0_3_branch, and it was
>several times explained on the list how to get it for CVS newbies.
>Please refer to the archive.
>
>
>
>
>>Or perhaps I'm just highly critical? No. I'm driven by wanting to
>>
>>
>get
>
>
>>this stuff working smoothly so average folks, like myself, who can
>>articulate technology to inepts with money can find it as an useful
>>means of development and worth investing.
>>
>>
>
>Then please do download 2.0.3 CVS, don't be on the "bleeding edge". Even
>stable branch of CVS is too extreme for many - most of the users (I
>guess) are on the one of the releases, not on the CVS.
>
>
>
>
>>And if you think Technology sells itself you wouldn't be working on
>>
>>
>Open
>
>
>>Source software and dealing with an Troglodyte like M$ dictating the
>>Market landscape.
>>
>>
>
>Why do you think so? :)
>
>
>
>
>>And after just getting a clean snapshot and rebuilding the cocoon.war
>>
>>
>it
>
>
>>still fails. with the Avalon Framework specifically referencing
>>ExcaliburComponentManager.java.
>>
>>Here is the error.log.
>>
>>ERROR (2002-05-10) 01:22.48:604 [core.manager](Unknown-URI)
>>Unknown-thread/ExcaliburComponentManager: Could not get class
>>org.apache.cocoon.components.store.impl.FilesystemStore for role
>>org.apache.excalibur.store.Store on configuration element
>>
>>
>persistent-store
>
>
>>java.lang.ClassNotFoundException:
>>org.apache.cocoon.components.store.impl.FilesystemStore
>>
>>
>
>Make sure you have this class.
>
><snip/>
>
>
>
>
>>I was hoping it would be fixed so I could just work with the 2.1 dev
>>
>>
>
>Don't know is it 2.1 error or issue with your setup, but...
>
>
>
>>stuff since when it does load it is snappier than the 2.0.2 release,
>>
>>
>in
>
>
>>general.
>>
>>
>
>You can get 2.0.3, change sitemap engine from compiled to interpreted
>(read cocoon.xconf), and you will have same performance as 2.1 has.
>
>
>
>
>>Here is to wishful thinking, and reversion back to 2.0.2.
>>
>>Finally, if this is an SDK 1.4 issue, great I'll build against 1.3.1
>>
>>
>but
>
>1.4 vs 1.3.1 differences are XML, SQL, and headless AWT stuff.
>
>
>
>
>>I have yet to get an answer as to how come this class since it seems
>>
>>
>to
>
>
>>be ignored during the build process leading one to conclude with build
>>success there will be /cocoon/ servlet success.
>>
>>
>
>Then it might be simple build.xml bug.
>
>Vadim
>
>
>
>
>
>>Sincerely Yours,
>>
>>Marc J. Driftmeyer
>>
>>Vadim Gritsenko wrote:
>>
>>
>>
>>>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
>>>>
>>>>Here is an excerpt of my error log..
>>>>
>>>>ERROR (2002-05-08) 14:36.33:921 [core.manager](Unknown-URI)
>>>>Unknown-thread/ExcaliburComponentManager: Could not get class
>>>>org.apache.cocoon.components.store.impl.FilesystemStore for role
>>>>org.apache.excalibur.store.Store on configuration element
>>>>
>>>>
>>>>
>>>>
>>>persistent-store
>>>
>>>
>>>
>>>
>>>>java.lang.ClassNotFoundException:
>>>>org.apache.cocoon.components.store.impl.FilesystemStore
>>>>
>>>>
>>>>
>>>>
>>>Why do you think that arbitrarily taken snapshot of Cocoon Alpha CVS
>>>should work?
>>>
>>>PS What this has to do with ExcaliburComponentManager?
>>>
>>>Vadim
>>>
>>>
>>>
>>>
>>>
>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
>>>> at
>>>>
>>>>
>>>>
>>>>
>>>>
>>org.apache.avalon.excalibur.component.ExcaliburComponentManager.configu
>>
>>
>r
>
>
>>>e(Exca
>>>
>>>
>>>
>>>
>>>>liburComponentManager.java:435)
>>>> at org.apache.cocoon.Cocoon.configure(Cocoon.java:408)
>>>> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:270)
>>>>
>>>>
>>>>-Marc
>>>>
>>>>Vadim Gritsenko wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
>>>>>>
>>>>>>ExcaliburComponentManager.java missing from the results in our
>>>>>>infamous.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Don't know what you mean:
>>>>>xml-cocoon2\lib\core\avalon-excalibur-20020506.jar happily contains
>>>>>
>>>>>
>>>>org\apache\avalon\excalibur\component\ExcaliburComponentManager.class
>>>>
>>>>
>>>>>file.
>>>>>
>>>>>ExcaliburComponentManager.java never was part of the Cocoon CVS
>>>>>and/or any Cocoon distro.
>>>>>
>>>>>Vadim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>How does this shit continue to happen? SQA is about hammering out
>>>>>>bugs
>>>>>>and cross-referencing known workarounds by level of severity and
>>>>>>then
>>>>>>prioritizing the order in which such "human mistakes" get hammered
>>>>>>out.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>>Cocoon 2 - Internal servlet error
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>----------------------------------------------------------------------
>>>
>>>
>-
>
>
>>>>
>>>>
>>>-
>>>
>>>
>>>
>>>
>>>>>------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>--
>>>>>>
>>>>>>type fatal
>>>>>>
>>>>>>message Cocoon was not initialized.
>>>>>>
>>>>>>description Cocoon was not initialized. Cannot process request.
>>>>>>
>>>>>>sender org.apache.cocoon.servlet.CocoonServlet
>>>>>>
>>>>>>source Cocoon servlet
>>>>>>
>>>>>>request-uri
>>>>>>
>>>>>>/cocoon/
>>>>>>
>>>>>>
>>>>>>
>>>>>>Sincerely Yours,
>>>>>>
>>>>>>Marc J. Driftmeyer
>>>>>>
>>>>>>//
>>>>>>
>>>>>>
>
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
>To unsubscribe, e-mail: <co...@xml.apache.org>
>For additional commands, e-mail: <co...@xml.apache.org>
>
>
//
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: ExcaliburComponentManager.java still missing from Latest Snapshot breaks /cocoon/ and throwing ERRORS
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
>
> Vadim - Are you obtuse on purpose?
1a or 2c?
http://www.dictionary.com/cgi-bin/dict.pl?term=obtuse
> Its the one throwing the error in the process of mapping /cocoon/
It is logging the error, yes, which means that it is physically
*present* in your setup so your saying "it's absent" is wrong.
> Logic dictates one reduces errors from the first one thrown to the
last
> one thrown.
>
> 2.1 dev has been in the tree for the past month, atleast.
And during these months, it entered alpha stage, it got WARNING in the
root, and announcement had been made on the list(s).
> If its Alpha
> than someone should make separate branches for the alpha and then the
> maintenance branch for 2.0.2 so it can work seemlessly with SDK 1.4.
The branch was created some time ago, cocoon_2_0_3_branch, and it was
several times explained on the list how to get it for CVS newbies.
Please refer to the archive.
> Or perhaps I'm just highly critical? No. I'm driven by wanting to
get
> this stuff working smoothly so average folks, like myself, who can
> articulate technology to inepts with money can find it as an useful
> means of development and worth investing.
Then please do download 2.0.3 CVS, don't be on the "bleeding edge". Even
stable branch of CVS is too extreme for many - most of the users (I
guess) are on the one of the releases, not on the CVS.
> And if you think Technology sells itself you wouldn't be working on
Open
> Source software and dealing with an Troglodyte like M$ dictating the
> Market landscape.
Why do you think so? :)
> And after just getting a clean snapshot and rebuilding the cocoon.war
it
> still fails. with the Avalon Framework specifically referencing
> ExcaliburComponentManager.java.
>
> Here is the error.log.
>
> ERROR (2002-05-10) 01:22.48:604 [core.manager](Unknown-URI)
> Unknown-thread/ExcaliburComponentManager: Could not get class
> org.apache.cocoon.components.store.impl.FilesystemStore for role
> org.apache.excalibur.store.Store on configuration element
persistent-store
> java.lang.ClassNotFoundException:
> org.apache.cocoon.components.store.impl.FilesystemStore
Make sure you have this class.
<snip/>
> I was hoping it would be fixed so I could just work with the 2.1 dev
Don't know is it 2.1 error or issue with your setup, but...
> stuff since when it does load it is snappier than the 2.0.2 release,
in
> general.
You can get 2.0.3, change sitemap engine from compiled to interpreted
(read cocoon.xconf), and you will have same performance as 2.1 has.
> Here is to wishful thinking, and reversion back to 2.0.2.
>
> Finally, if this is an SDK 1.4 issue, great I'll build against 1.3.1
but
1.4 vs 1.3.1 differences are XML, SQL, and headless AWT stuff.
> I have yet to get an answer as to how come this class since it seems
to
> be ignored during the build process leading one to conclude with build
> success there will be /cocoon/ servlet success.
Then it might be simple build.xml bug.
Vadim
> Sincerely Yours,
>
> Marc J. Driftmeyer
>
> Vadim Gritsenko wrote:
>
> >>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
> >>
> >>Here is an excerpt of my error log..
> >>
> >>ERROR (2002-05-08) 14:36.33:921 [core.manager](Unknown-URI)
> >>Unknown-thread/ExcaliburComponentManager: Could not get class
> >>org.apache.cocoon.components.store.impl.FilesystemStore for role
> >>org.apache.excalibur.store.Store on configuration element
> >>
> >>
> >persistent-store
> >
> >
> >>java.lang.ClassNotFoundException:
> >>org.apache.cocoon.components.store.impl.FilesystemStore
> >>
> >>
> >
> >Why do you think that arbitrarily taken snapshot of Cocoon Alpha CVS
> >should work?
> >
> >PS What this has to do with ExcaliburComponentManager?
> >
> >Vadim
> >
> >
> >
> >> at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
> >> at java.security.AccessController.doPrivileged(Native Method)
> >> at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
> >> at
> >>
> >>
> >>
>
>org.apache.avalon.excalibur.component.ExcaliburComponentManager.configu
r
> >e(Exca
> >
> >
> >>liburComponentManager.java:435)
> >> at org.apache.cocoon.Cocoon.configure(Cocoon.java:408)
> >> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:270)
> >>
> >>
> >>-Marc
> >>
> >>Vadim Gritsenko wrote:
> >>
> >>
> >>
> >>>>From: Marc Jeffrey Driftmeyer [mailto:mjd@reanimality.com]
> >>>>
> >>>>ExcaliburComponentManager.java missing from the results in our
> >>>>infamous.
> >>>>
> >>>>
> >>>Don't know what you mean:
> >>>xml-cocoon2\lib\core\avalon-excalibur-20020506.jar happily contains
>
>>>org\apache\avalon\excalibur\component\ExcaliburComponentManager.class
> >>>file.
> >>>
> >>>ExcaliburComponentManager.java never was part of the Cocoon CVS
> >>>and/or any Cocoon distro.
> >>>
> >>>Vadim
> >>>
> >>>
> >>>>How does this shit continue to happen? SQA is about hammering out
> >>>>bugs
> >>>>and cross-referencing known workarounds by level of severity and
> >>>>then
> >>>>prioritizing the order in which such "human mistakes" get hammered
> >>>>out.
> >>>>
> >>>
> >>>
> >>>>Cocoon 2 - Internal servlet error
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
>
>>----------------------------------------------------------------------
-
> >>
> >>
> >-
> >
> >
> >>>------
> >>>
> >>>
> >>>
> >>>
> >>>>--
> >>>>
> >>>>type fatal
> >>>>
> >>>>message Cocoon was not initialized.
> >>>>
> >>>>description Cocoon was not initialized. Cannot process request.
> >>>>
> >>>>sender org.apache.cocoon.servlet.CocoonServlet
> >>>>
> >>>>source Cocoon servlet
> >>>>
> >>>>request-uri
> >>>>
> >>>>/cocoon/
> >>>>
> >>>>
> >>>>
> >>>>Sincerely Yours,
> >>>>
> >>>>Marc J. Driftmeyer
> >>>>
> >>>>//
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>