RE: Giving up! Cocoon too big, slow and confusing
This is both a serious problem in terms of documantation/tools etc.. But
also in terms of cocoon itself. Some of the points are valid, not just in
terms of whether it's documented or not, but in terms of the actual system.
You know how much most people on this list love and respect cocoon, but
sometimes it does seem over complex and dense - even to those who have been
around the project for some time.
I know I started a thread talking about developing a front end content
management app (really a cocoon management app) and didn't have the
time/resources to properly follow up - but without serious consideration to
how end-users sre going to use the product, it's almost inevitable that
Cocoon will end up being a specialist product mainly for the people who
have been involved increating it.
I reckon either:
1/ Cocoon config (sitemap etc) is radically simplified
2/ Tools are created to create the config
Otherwise the great potential of the project may end up unfulfilled.
Re: a previous mail on this subject:
Genius level people not understanding other's inability to memorise
aspects of the project! RUBBISH, people who have inside knowledge often
appear to be geniuses and magicians, it's a mirage! True genius
communicates - which is precisely the problem highlighted on this thread -
the relatively poor documentation/tools regarding Cocoon against the
fabulous technology.
Once someone said: UNIX is not NOT user-friendly, it's just choosy about
its friends!
I reckon the time has past when we can be choosy - otherwise .NET rubbish
will start becoming another cross we all have to bear (as developers), when
properly presented, Cocoon could provide a real way forwards to the web-app
community!
Regards
Anthony Aldridge
Application Development
Managed Intranet Hosting
JPMorganChase
PS I've developed an alternative way to use cocoon, based on what I call
'JBXSP' (JavaBeanExtensibleServerPages). ALL the logic, and the xml is
generated via introspection from pure java (no embedding java logic in
xml-style files). All that's required then is the xslt stylesheets to
translate, and a single xml file to call the basic java system. Ultimtely I
want to keep the xslt files as fragments in a database to be called by the
JBXSP system as required.
For me (as a java programmer) this is perfect - it may not suit everyone's
needs but I'll be happy to share the ideas with the community, if anyone's
interested.
Matthew Langham [EMAIL PROTECTED] on 06/28/2002 07:45:14 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: Giving up! Cocoon too big, slow and confusing
A few comments on various raised points:
3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking
at the change logs for potential hints at what was necessary was a
non-starter.
Changes between releases must be documented so that the migration is a
painless as _possible_. But if 2.0 provides what is needed then perhaps
upgrading is not always the best idea. We don't upgrade all our production
installations of Cocoon each time there is a new release. We have Cocoon
based sites that are happily running a pre-2.0 version of Cocoon.
this will be since there have been significant changes (forms and
authentication system to just name a few at the feature level) since
those books have gone to publishing.
Unfortunately this is _always_ the case. We finished our book in March (!)
and the printing process is such that it just takes that long before the
book hits the shelves. There is nothing we (as the authors) can do about it
(apart from preventing new Cocoon releases :-)). On the other hand we
decided to include a CD containing a defined version of Cocoon so that the
details in the book match the software. The concepts have not changed
between 2.0 and 2.0.x - but things have been added.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Giving up! Cocoon too big, slow and confusing
Absolutely! BUT, the point isn't that everyone's dissing Cocoon, it's that a weakness has been identified, and is being discussed. No need to be defensive about it - that's what will drive people to amend the situation. Regards Anthony Aldridge Application Development Managed Intranet Hosting JPMorganChase David Crossley [EMAIL PROTECTED] on 06/28/2002 10:12:54 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Giving up! Cocoon too big, slow and confusing Everyone stop, take a breathe, get a cup of coffee and go read The Cathedral and the Bazaar http://tuxedo.org/~esr/writings/cathedral-bazaar/ or similar writings about how Open Source Software operates. It seems that many people here are missing the point. It amazes me that people have the time to compose email to the mailing list to tell us that they are too busy, and then have the hide to tell us that documentation is poor. If each of us add one FAQ to the document collection, then the lack will be addressed very quickly. That is OSS. If you see an issue, the onus is on you to help remedy that. Everyone benefits from the work of each one. There is no such separate thing as they, the developers. Rather it is we the community. Anyone who contributes a patch (code or doc) is instantly transformed from being a user into a developer. Users use, contributers build projects. Thanks for raising this topic. I do sympathise with you about the complexities and inadequacies. We have all been though that and still do. None of us know all of Cocoon capabilities and would all benefit from doc contributions. Please help. --David - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I cannae dae it (the woes of Weblogic 6.0sp2 and Cocoon) :(
Not sure if WL 6.0 is different, but on previous versions of WL there is a lot of confusion surrounding where jars are kept. It basically has 2 separate classpaths - 1 for WL itself, and 1 for the webapps. If the jars are in the wrong classpath you can get the kind of messages you see below - even worse, if the jar - or any of it's classes - appear in both classpaths, you also get the kind of error you specify. I had exactly that problem with xerces in WL 5.x - and had to remove some of the classes from the WL System jars - quite a pain. I know they said this wold be sorted in v.6.x - but I've heard that before. If you like I can forward you the analysis we did at the time - if I can find it. Tony [EMAIL PROTECTED] on 04/26/2002 11:54:31 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: I cannae dae it (the woes of Weblogic 6.0sp2 and Cocoon) :( Hi I've been trying to get cocoon to deploy under Weblogic for some time now, and it isn't working The system is a Solaris machine, Java 1.3.1, Weblogic 6.0 sp2. I have followed the instructions concisely from the cocoon site, and used the cocoon.war file that came with the binary distribution of Cocoon 2.0.2, but if I try to get it running, I get the following message on startup: BEGIN Apr 26, 2002 12:48:25 PM CEST Error Management Error initializing module cocoon of application vodafone:Name=Cocoon,Type=Application from path ./config/vodafone/applicatio ns: weblogic.management.MBeanCreationException: cannot find referenced module cocoon Apr 26, 2002 12:48:25 PM CEST Error Management Error preparing application compone nt cocoon of application vodafone:Name=Cocoon,Type=Application: java.io.FileNotFoundExcep tion: ./config/vodafone/applications/cocoon (No such file or directory) ((localPath: java .io.FileNotFoundException: ./config/vodafone/applications/cocoon (No such file or directo ry)) Apr 26, 2002 12:48:25 PM CEST Error J2EE Error deploying application cocoon: error retrieving component [Caching Stub]Proxy for vodafone:Name=cocoon,Location=eservices,Typ e=WebAppComponentConfig,ApplicationConfig=Cocoon Apr 26, 2002 12:48:32 PM CEST Error HTTP [WebAppServletContext(661879,cocoon)] Error loadi ng servlet: 'Cocoon2' java.lang.NoSuchMethodError at org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.init (DefaultCo nfigurationBuilder.java:88) at org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.init (DefaultCo nfigurationBuilder.java:64) at org.apache.cocoon.servlet.CocoonServlet.initLogger(CocoonServlet.java:772) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:241) at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java :638) at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.ja va:581) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.jav a:526) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletC ontext.jav a:1078) at weblogic.servlet.internal.WebAppServletContext.preloadServlets(WebAppServlet Context.ja va:1022) at weblogic.servlet.internal.HttpServer.loadWARContext(HttpServer.java:468) at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:404) at weblogic.j2ee.WebAppComponent.deploy(WebAppComponent.java:74) at weblogic.j2ee.Application.addComponent(Application.java:133) at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT arget.java :327) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT arget.java :143) at weblogic.management.mbeans.custom.WebServer.addWebDeployment(WebServer.java: 76) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl .java:562) at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5 48) at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea nImpl.java :285) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439) at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180) at $Proxy29.addWebDeployment(Unknown Source) at weblogic.management.configuration.WebServerMBean_CachingStub.addWebDeploymen t(WebServe rMBean_CachingStub.java:1012) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT arget.java :313) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT arget.java :143) at
Re: The woes of Weblogic 6.0sp2 and Cocoon - found the problem at last :)
v6.1 is out now - and BEA are not the quickest. You could always remove WLs
version of avalon and replace it, or remove it form the system classpath
and leave only in the webapp classpath (if that's still how WL 6.0 works -
see my previous email).
Good luck,
Tony
PS What's wrong with tomcat?
[EMAIL PROTECTED] on 04/26/2002 02:33:10 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: The woes of Weblogic 6.0sp2 and Cocoon - found the problem at las
t :)
Hi there
good news and bad news -
I have found the reason why the NoSuchMethodException is being thrown -
I first dug out the source of the Avalon class that was throwing the
exception,
to find out what method was being expected.
Here is the 'offending' method, which is found in the class
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder
(inside Avalon version 4.1.2, which is used in Cocoon 2.0.2):
public DefaultConfigurationBuilder( final boolean enableNamespaces )
{
//yaya the bugs with some compilers and final variables ..
try
{
final SAXParserFactory saxParserFactory =
SAXParserFactory.newInstance();
if ( enableNamespaces )
{
saxParserFactory.setNamespaceAware(true);
}
final SAXParser saxParser = saxParserFactory.newSAXParser();
this.setParser(saxParser.getXMLReader()); --- THE PROBLEM
}
catch( final Exception se )
{
throw new Error( Unable to setup SAX parser + se );
}
}
Note that the class expects there to be a method 'getXMLReader' available
in
the SAXParser object (javax.xml.parsers.SAXParser) - this is logical,
because in
the version of Xerces Cocoon was built against, this method exists.
I then looked at the structure of the SAXParser class that Weblogic 6.0 SP2
uses, and found out that there is no 'getXMLReader' method!!!
So who is to blame?
Well, the offender is BEA - their JAXP API is broken, because it does
not comply with the defacto standard, the one in the Java 1.4.0 API -
whereas
Avalon itself is completely justified in expecting the getXMLReader
method, because it *should* be there according to Sun's API docs.
Oh well, I'll have to work out how to bypass BEA's XML crud until a new
service pack comes out for 6.0, I guess p
Thanks to all the folks who tried to help me with my problem :)
-
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: The woes of Weblogic 6.0sp2 and Cocoon - found the problem at last:)
Removing the packages fron the jars was how I got round my WL issues - a bit of a pain - but it did the trick. Tony Konstantin Piroumian [EMAIL PROTECTED] on 04/26/2002 02:49:06 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: The woes of Weblogic 6.0sp2 and Cocoon - found the problem at last :) Hi good news and bad news - ... Note that the class expects there to be a method 'getXMLReader' available in the SAXParser object (javax.xml.parsers.SAXParser) - this is logical, because in the version of Xerces Cocoon was built against, this method exists. I then looked at the structure of the SAXParser class that Weblogic 6.0 SP2 uses, and found out that there is no 'getXMLReader' method!!! So who is to blame? Well, the offender is BEA - their JAXP API is broken, because it does not comply with the defacto standard, the one in the Java 1.4.0 API - whereas Avalon itself is completely justified in expecting the getXMLReader method, because it *should* be there according to Sun's API docs. Oh well, I'll have to work out how to bypass BEA's XML crud until a new service pack comes out for 6.0, I guess p You can try to place Xerces and Xalan in weblogic6.1/lib and rename them to something like a_xerces.jar and a_xalan.jar. Also you can try to remove certain packages (org.apache.**) from weblogic.jar and xmlx.jar archives. -- Konstantin Thanks to all the folks who tried to help me with my problem :) - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
