Re: A note about the best(?) (cocoon-) development environment ...
On Sunday 09 February 2003 05:59, Robert Simmons wrote: Sun JDO JSR-12. And I thought this is a Java specific specification of the ODMG model. No? - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka JBossWeb). No nasty must copy things to endorsed directories, etc.). You take Cocoon (2.0/2.1) and drop it in your deploy directory and POOF it's there. It's nice when the servlet engine actually uses the libs you define and not its own first as the default ... isn't that in the spec ... and will be available in Tomcat at some point. If you want any extra libs in cocoon-2.1 you add them in the lib tree, add them to jars.xml and the cocoon build adds them to the Manifest ... Jetty/Jboss just eats 'em up in the right place. I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and not Sun's) ... how does this rank against Castor or Jakarta-OJB ? Cheers, Thor HW On Saturday, February 8, 2003, at 11:42 AM, Robert Simmons wrote: Hy, all; During the last months of activities i learned a lot from this mailing list. while i followed the discussions i started getting my development environment a bit up to date. I plan to setup a Wiki page on this theme. Although this may be a bit off topic, it still would be great, if someone could comment on this issue. the tools collection Here is what i have put together so far. Of course this is driven at least partially by what i do for my customers... free tools: 1.) OS: linux and solaris (maybe a mater of taste) Go linux. Instead of spending money on licenses, you spend money on support contracts. Cheaper. In addition, Solaris is primitive compared to Linux. 2.) apache 1.3.26 (mod_jk2, mod_SSL) Duh ;) 3.) tomcat 4.1.18 Yes, but you can go one step further. Get JBoss with integrated tomcat. JBoss will handle all sorty of nasty things like deploying to clusters for you. As a bonus, you get the ability to integrate with EJB based programs. 4.) cocoon-2.0.4 2.1 Hopefully soon! 5.) eclipse See my previous message about eclopse vs netbeans. 6.) sunbow eclipse tools (xml/sitemap) URL ? 7.) ant I have 15 million of them in my damn appartment, want a few? Oh ... you mean Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis' extensions to ant. http://www.krysalis.org/centipede/quickstart.html 8.) java-1.3.1 (sun JDK on all platforms) No no .. 1.4.1!! In 1.4 there are so many COOOL things that I couldnt live without anymore. 9.) Secureway LDAP Server (i'll switch to Open LDAP soon) Im an LDAP idiot so Ill trust you there. Tools you didnt talk about: CVS - Use it over clearcase. its powerful, free, and a pleasure to use. BugZilla - Great program! Lousy looking interface. We should start a project to port it to cocoon. =) However bugzilla is a great and free bugtracking
Re: A note about the best(?) (cocoon-) development environment ...
On Saturday, Feb 8, 2003, at 19:28 Europe/London, Robert Simmons wrote: The only other comment I have is that I'm still searching for a content editor for Static XML. I'm currently investigating using adobe FrameMaker. The idea being that I would have a WYSIWYG way of editing documents that any one of my clients could use and I could write XSLT processors to convert that to the web format using cocoon. Right now the current XML editors are too primitive. Usable for a programmer but for a corporate document jockey, no chance. I don't have the $$$ to try Framemaker, but if you are prepared to put in the work, you could try XMLMind XMLEditor (XXE). http://www.xmlmind.com/xmleditor/ You need to write a config for XXE, for your docset. You need to write CSS to display your XML. You can use either XSD or DTD for validation. If you want to use XSD (and use the editor for free) you must have a default namespace starting with 'http://xmlmind.com/xmleditor/Schema/[yourdoc]', in your document root. I have managed to produce a satisfactory environment for 'corporate document jockeys' to use. regards Jeremy - 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: Cinclude issues...
On Fri, Feb 07, 2003 at 09:00:19PM -0500, Ben Young wrote:
I've recently attempted to use the cinclude to aggregate some files that I'm
currently aggregating with the map:aggregate command, but I've run into some
issues that I'm not sure how to resolve.
My current map:match section looks like this:
map:match pattern=**/index.htm*
map:act type=sourcetype src=/home/htdocs/content/{1}/index.xml
map:aggregate element=document
map:part src=cocoon:/{../1}/../_navigation.xml
element=navigation/
map:part src=cocoon:/{../1}/index.{sourcetype}/
/map:aggregate
/map:act
map:transform src=/home/htdocs/design/shell.xsl
map:parameter name=nav_filename
value=/home/htdocs/content/nav_home.xml/
map:parameter name=path value={1}/
/map:transform
map:serialize/
/map:match
I use an internal-only pipeline to find the nearest _navigation.xml file
in existence.
map:pipeline internal-only=true
map:match pattern=**/_navigation.xml
map:act type=resource-exists
map:parameter name=url
value=/home/htdocs/content/{1}/_navigation.xml/
map:generate src=/home/htdocs/content/{../1}/_navigation.xml/
map:serialize type=xml/
/map:act
map:redirect-to uri=cocoon:/{1}/../_navigation.xml/
/map:match
/map:pipeline
I'd like to move the aggregation step after the shell.xsl is applied. The
plan is to have the shell.xsl output a cinclude tag that uses the
cocoon:// psuedo-protocol in the appropriate place using the $path
parameter plus _navigation.xml
My current trouble is that the cinclude only runs through the internal
pipeline once.
Perhaps my brain slipped out of gear, but that seems a bit cryptic..
Don't you need a map:transform type=cinclude/ tag somewhere to get
cinclude processing?
--Jeff
PS: in case you didn't know: Forrest does this kind of nav + body
integration to generate pages like http://xml.apache.org/forrest/
Thank you for any help you might be able to give,
Ben
-
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: A note about the best(?) (cocoon-) development environment ...
Your classpath issue won't be fixed by other combinations. It's not a tomcat problem. The only thing that will fix the problem is fixing the java compiler in Cocoon to not use a classpath, but use the classloader instead. For this two fixes have been suggested on the mailing list: - Fixing the piza compiler (I think this was done bij Jakob Dalsgaard) I tried the fix, but couldn't get it to work in my Cocoon setup. - Using the eclipse java compiler in Cocoon (suggested by Christopher Oliver). The compiler he tested should be integrated in Cocoon. Because I am not working on a cocoon project right now, I cannot spend time on it. I guess if it bothers someone enough he will fix it? HTH, Michael -Original Message- From: Robert Simmons To: [EMAIL PROTECTED] Sent: 8-2-2003 10:05 Subject: Re: A note about the best(?) (cocoon-) development environment ... I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka JBossWeb). No nasty must copy things to endorsed directories, etc.). You take Cocoon (2.0/2.1) and drop it in your deploy directory and POOF it's there. It's nice when the servlet engine actually uses the libs you define and not its own first as the default ... isn't that in the spec ... and will be available in Tomcat at some point. If you want any extra libs in cocoon-2.1 you add them in the lib tree, add them to jars.xml and the cocoon build adds them to the Manifest ... Jetty/Jboss just eats 'em up in the right place. I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and not Sun's) ... how does this rank against Castor or Jakarta-OJB ? Cheers, Thor HW On Saturday, February 8, 2003, at 11:42 AM, Robert Simmons wrote: Hy, all; During the last months of activities i learned a lot from this mailing list. while i followed the discussions i started getting my development environment a bit up to date. I plan to setup a Wiki page on this theme. Although this may be a bit off topic, it still would be great, if someone could comment on this issue. the tools collection Here is what i have put together so far. Of course this is driven at least partially by what i do for my customers... free tools: 1.) OS: linux and solaris (maybe a mater of taste) Go linux. Instead of spending money on licenses, you spend money on support contracts. Cheaper. In addition, Solaris is primitive compared to Linux. 2.) apache 1.3.26 (mod_jk2, mod_SSL) Duh ;) 3.) tomcat 4.1.18 Yes, but you can go one step further. Get JBoss with integrated tomcat. JBoss will handle all sorty of nasty things like deploying to clusters for you. As a bonus, you get the ability to integrate with EJB based programs. 4.) cocoon-2.0.4 2.1 Hopefully soon! 5.) eclipse See my previous message about eclopse vs netbeans. 6.) sunbow eclipse tools (xml/sitemap) URL ? 7.) ant I have 15 million of them in my damn appartment, want a few? Oh ... you mean Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis' extensions to ant. http://www.krysalis.org/centipede/quickstart.html 8.) java-1.3.1 (sun JDK on all platforms) No no .. 1.4.1!! In 1.4 there are so many COOOL things that I couldnt live without anymore. 9.) Secureway LDAP Server (i'll switch to Open LDAP soon) Im an LDAP idiot so Ill trust you there. Tools you didnt talk about: CVS - Use it over clearcase. its powerful, free, and a pleasure to use. BugZilla - Great program! Lousy looking interface. We should start a project to port it to cocoon. =) However bugzilla is a great and free bugtracking system. commercial tools: 10.) clearcase cms (see below) Garbage. 11.) xml-spy Good but confusing. 12.) several DB-Systems all you need is Mysql baby. Ones you didnt talk about: 13) Together control center. If you can afford it, it absolutely kills any other IDE on the planet. 14) eXcelon Stylus Studio. A great XML editor. It has a bonus of being easy
Re: A note about the best(?) (cocoon-) development environment ...
Nope. 100% pure Java specification. Give it a read. The first couple chapters will give you a good idea of its meaning. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 09, 2003 9:30 AM Subject: Re: A note about the best(?) (cocoon-) development environment ... On Sunday 09 February 2003 05:59, Robert Simmons wrote: Sun JDO JSR-12. And I thought this is a Java specific specification of the ODMG model. No? - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka JBossWeb). No nasty must copy things to endorsed directories, etc.). You take Cocoon (2.0/2.1) and drop it in your deploy directory and POOF it's there. It's nice when the servlet engine actually uses the libs you define and not its own first as the default ... isn't that in the spec ... and will be available in Tomcat at some point. If you want any extra libs in cocoon-2.1 you add them in the lib tree, add them to jars.xml and the cocoon build adds them to the Manifest ... Jetty/Jboss just eats 'em up in the right place. I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and not Sun's) ... how does this rank against Castor or Jakarta-OJB ? Cheers, Thor HW On Saturday, February 8, 2003, at 11:42 AM, Robert Simmons wrote: Hy, all; During the last months of activities i learned a lot from this mailing list. while i followed the discussions i started getting my development environment a bit up to date. I plan to setup a Wiki page on this theme. Although this may be a bit off topic, it still would be great, if someone could comment on this issue. the tools collection Here is what i have put together so far. Of course this is driven at least partially by what i do for my customers... free tools: 1.) OS: linux and solaris (maybe a mater of taste) Go linux. Instead of spending money on licenses, you spend money on support contracts. Cheaper. In addition, Solaris is primitive compared to Linux. 2.) apache 1.3.26 (mod_jk2, mod_SSL) Duh ;) 3.) tomcat 4.1.18 Yes, but you can go one step further. Get JBoss with integrated tomcat. JBoss will handle all sorty of nasty things like deploying to clusters for you. As a bonus, you get the ability to integrate with EJB based programs. 4.) cocoon-2.0.4 2.1 Hopefully soon! 5.) eclipse See my previous message about eclopse vs netbeans. 6.) sunbow eclipse tools (xml/sitemap) URL ? 7.) ant I have 15 million of them in my damn appartment, want a few? Oh ... you mean Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis' extensions to ant. http://www.krysalis.org/centipede/quickstart.html 8.) java-1.3.1 (sun JDK on all platforms) No no .. 1.4.1!! In 1.4 there are so many COOOL things that I couldnt live without anymore. 9.) Secureway LDAP Server (i'll switch to Open LDAP
Re: A note about the best(?) (cocoon-) development environment ...
Point of correction. Class enhancement is not generation per se. The actual class files are enhanced in place. In other words the byte code enhancers go into the class files and alter them. The solution elegantly solves some nasty problems. -- Robert - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:59 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Sun JDO JSR-12. - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka JBossWeb). No nasty must copy things to endorsed directories, etc.). You take Cocoon (2.0/2.1) and drop it in your deploy directory and POOF it's there. It's nice when the servlet engine actually uses the libs you define and not its own first as the default ... isn't that in the spec ... and will be available in Tomcat at some point. If you want any extra libs in cocoon-2.1 you add them in the lib tree, add them to jars.xml and the cocoon build adds them to the Manifest ... Jetty/Jboss just eats 'em up in the right place. I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and not Sun's) ... how does this rank against Castor or Jakarta-OJB ? Cheers, Thor HW On Saturday, February 8, 2003, at 11:42 AM, Robert Simmons wrote: Hy, all; During the last months of activities i learned a lot from this mailing list. while i followed the discussions i started getting my development environment a bit up to date. I plan to setup a Wiki page on this theme. Although this may be a bit off topic, it still would be great, if someone could comment on this issue. the tools collection Here is what i have put together so far. Of course this is driven at least partially by what i do for my customers... free tools: 1.) OS: linux and solaris (maybe a mater of taste) Go linux. Instead of spending money on licenses, you spend money on support contracts. Cheaper. In addition, Solaris is primitive compared to Linux. 2.) apache 1.3.26 (mod_jk2, mod_SSL) Duh ;) 3.) tomcat 4.1.18 Yes, but you can go one step further. Get JBoss with integrated tomcat. JBoss will handle all sorty of nasty things like deploying to clusters for you. As a bonus, you get the ability to integrate with EJB based programs. 4.) cocoon-2.0.4 2.1 Hopefully soon! 5.) eclipse See my previous message about eclopse vs netbeans. 6.) sunbow eclipse tools (xml/sitemap) URL ? 7.) ant I have 15 million of them in my damn appartment, want a few? Oh ... you mean Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis' extensions to ant. http://www.krysalis.org/centipede/quickstart.html 8.) java-1.3.1 (sun JDK on all platforms) No no .. 1.4.1!! In 1.4 there are so many COOOL things that I couldnt live without anymore. 9.) Secureway LDAP Server (i'll switch to Open LDAP soon)
howto get the context-root in a component registered incocoon.xconf
hi all, I want to load a component-manager from a selector, that I registered in cocoon.xconf. The problem is, that at configuration( .. ) time I have no way to access the objectModel, like for instance in an Action. But in order to get the configuration files properly, I somehow must have access to the location of the Webapp-Context. The problem is that the Context of the cocoon.xconf ComponentManager does not have the Webapp Context Information, since it is a separate (as far as I have read in the source code) one from the CocoonComponentManager, which is used to process the request. It would be great if the $context-root variable would be set for cocoon.xconf like it works within logkit.xconf ... - Why is this not done - is this a code smell? The other thing I come to like is to use the JNDI Environmental Context comp/env, which would be insofar great, as the components could be easier portable to other environments, e.g. no webapp environments, since JNDI comp/env is not servlet specific, or cocoon specific like org.apache.cooon.environment.* package. any hint is appreciated. thanks -- Jakob - 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: Using Cocoon and ($tool) to generate static pages.
On Thu, Feb 06, 2003 at 06:07:02PM +0100, Andrea Censi wrote: Which is the best tool to create an offline copy of a cocoon live site? It should spider through the pages, follow every link and gather both html and images/css/pdf. Then it should rearrange internal links from absolute to relative (http://site/page; - page.html, / - index.html). The result is to be loaded on a low-spec [ = no cocoon :( ] webserver. I don't consider the batch use from command line to be a viable alternative, because: - There are different views of single xml files. Don't the different views have different URLs? If so, and if you link to those different URLs, then they will each have a file written. - I don't want to explicitly change the internal URL format used by the site (/ ... /page/ with a final slash) I think the crawler will convert links to a directory, eg 'foo/' to 'foo/index.html'. - (not sure) Would it work with dynamic SVG-gif? Yes. I'd say, give it a try. Works fine rendering Forrest sites. Alternatively, you could try spidering tools like 'wget'. --Jeff - 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]
cocoon classloader problem
while trying to get the cocoon command line interface to work, i stumbled across this odd problem: Object o = Class.forName(org.apache.avalon.excalibur.xml.JaxpParser).newInstance(); org.apache.cocoon.util.ClassUtils.loadClass(org.apache.avalon.excalibur.xml.JaxpParser).newInstance(); the JaxpParser class obviously is in the class path, since the first line gets executed without problems... but when trying to use the cocoon class loader, i get this: java.lang.ClassNotFoundException: org.apache.avalon.excalibur.xml.JaxpParser 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:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at org.netbeans.core.modules.ProxyClassLoader.loadInOrder(ProxyClassLoader.java:472) at org.netbeans.core.modules.ProxyClassLoader.smartLoadClass(ProxyClassLoader.java:452) at org.netbeans.core.modules.ProxyClassLoader.loadClass(ProxyClassLoader.java:124) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at org.apache.cocoon.util.ClassUtils.loadClass(ClassUtils.java:88) at com.rauser_ag.website.tests.Spool.main(Spool.java:24) 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.openide.execution.ThreadExecutor.executeClass(ThreadExecutor.java:117) at org.openide.execution.ThreadExecutor$TERunnable.run(ThreadExecutor.java:184) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:119) anybody got a clue why it can't find a class that's available in the classpath? i'm wondering because the build script for the docs seems to manage this, while this code doesn't. thanks in advance. - 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: A note about the best(?) (cocoon-) development environment...
On Sun, 9 Feb 2003 12:26:50 + Jeremy Quinn [EMAIL PROTECTED] wrote: ... I don't have the $$$ to try Framemaker, but if you are prepared to put in the work, you could try XMLMind XMLEditor (XXE). http://www.xmlmind.com/xmleditor/ You need to write a config for XXE, for your docset. You need to write CSS to display your XML. You can use either XSD or DTD for validation. If you want to use XSD (and use the editor for free) you must have a default namespace starting with 'http://xmlmind.com/xmleditor/Schema/[yourdoc]', in your document root. I have managed to produce a satisfactory environment for 'corporate document jockeys' to use. regards Jeremy Hi, I'm just curious. I assume you XXE used only with UTF-8 or ascii. I also gave XXE a short whirl, but I was unable to load documents with encoding=ISO-8859-1 that contained german öäü... characters. The documents were originally created with XEmacs and styled with Saxon and the DOCBOOK stylesheet from Norman Walsh. And this worked flawlessly. So I think, there might be an issue with XXE and with non-standard character sets. Well, I don't assume I must explicitly start Java with an encoding defined (I haven't tried this yet). -- MfG/Regards Frank Ridderbusch Since I have taken all the Gates out of my computer, it finally works!! - 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]
Help - Trying to fit the text to fit the page
Request some help in formatting the displayed document to fint in one page. For example the http://localhost:8080/cocoon/documents/userdocs/xsp/esql.html does not fit in a page and I have the scroll bar in the bottom. Is there a way to make the body part fit the remaining space and I would not like to have any horizontal scroll bars. I have looked at the stylesheets use, like the doclist2document.xsl and document2html.xsl and I dont know which attribute I can set so the display does not have horizontal scroll bars. I tried adding width=100 attribute on the div tag and nothing much change. Any tips? Regards, e nio __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - 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: Instal Cocoon on Mac OS X
Check out the instructions for the installation: http://xml.apache.org/cocoon/installing/index.html depending on the version of Tomcat you are using you'll have to copy files into different directories. Now, if you use Jetty, you don't have to copy any directories. If you want to use Jetty/\Jboss you can follow these directions to get everything downloaded and setup on your Mac http://developer.apple.com/internet/java/enterprisejava.html Cheers, Thor HW On Saturday, February 8, 2003, at 06:23 PM, Ross wrote: I have installed the tomcat server on Mac OS X and it works fine. I downloaded cocoon and put the cocoon.war file in webapps. I stopped and started tomcat and it created the cocoon folder in webapps. When I go to http://localhost:8080/cocoon the browser does not respond for a long time. Do I have to move some .jar files? Any assistance is appreciated. Thanks, Ross.
Re: A note about the best(?) (cocoon-) development environment ...
Possibly, but when I went to Sun's announcement of JDO at JavaOne they had post-processing of the *.class files with some funky stuff so that the classloaders wouldn't reject the *.class files to allow loading of the data. Castor, et al. was following the ODMG much closer and didn't try to hide the fact the the classes were persistent and made the programmer do a little work. I found that approach much more in keeping with where I wanted to go. I guess that's why I like Jini and the new RMI stuff as they don't try and hide the network, as much as abstract it for you. Cheers, Thor HW On Sunday, February 9, 2003, at 12:30 AM, Niclas Hedhman wrote: On Sunday 09 February 2003 05:59, Robert Simmons wrote: Sun JDO JSR-12. And I thought this is a Java specific specification of the ODMG model. No? - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka JBossWeb). No nasty must copy things to endorsed directories, etc.). You take Cocoon (2.0/2.1) and drop it in your deploy directory and POOF it's there. It's nice when the servlet engine actually uses the libs you define and not its own first as the default ... isn't that in the spec ... and will be available in Tomcat at some point. If you want any extra libs in cocoon-2.1 you add them in the lib tree, add them to jars.xml and the cocoon build adds them to the Manifest ... Jetty/Jboss just eats 'em up in the right place. I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and not Sun's) ... how does this rank against Castor or Jakarta-OJB ? Cheers, Thor HW On Saturday, February 8, 2003, at 11:42 AM, Robert Simmons wrote: Hy, all; During the last months of activities i learned a lot from this mailing list. while i followed the discussions i started getting my development environment a bit up to date. I plan to setup a Wiki page on this theme. Although this may be a bit off topic, it still would be great, if someone could comment on this issue. the tools collection Here is what i have put together so far. Of course this is driven at least partially by what i do for my customers... free tools: 1.) OS: linux and solaris (maybe a mater of taste) Go linux. Instead of spending money on licenses, you spend money on support contracts. Cheaper. In addition, Solaris is primitive compared to Linux. 2.) apache 1.3.26 (mod_jk2, mod_SSL) Duh ;) 3.) tomcat 4.1.18 Yes, but you can go one step further. Get JBoss with integrated tomcat. JBoss will handle all sorty of nasty things like deploying to clusters for you. As a bonus, you get the ability to integrate with EJB based programs. 4.) cocoon-2.0.4 2.1 Hopefully soon! 5.) eclipse See my previous message about eclopse vs netbeans. 6.) sunbow eclipse tools (xml/sitemap) URL ? 7.) ant I have 15 million of them in my damn appartment, want a few? Oh ... you mean Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis' extensions to ant. http://www.krysalis.org/centipede/quickstart.html 8.) java-1.3.1 (sun JDK on all
Re: A note about the best(?) (cocoon-) development environment ...
Have you found that it works well for you across JVM versions and implementations? The ODMG JDO works everywhere. On Sunday, February 9, 2003, at 05:22 AM, Robert Simmons wrote: Point of correction. Class enhancement is not generation per se. The actual class files are enhanced in place. In other words the byte code enhancers go into the class files and alter them. The solution elegantly solves some nasty problems. -- Robert - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:59 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Sun JDO JSR-12. - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka JBossWeb). No nasty must copy things to endorsed directories, etc.). You take Cocoon (2.0/2.1) and drop it in your deploy directory and POOF it's there. It's nice when the servlet engine actually uses the libs you define and not its own first as the default ... isn't that in the spec ... and will be available in Tomcat at some point. If you want any extra libs in cocoon-2.1 you add them in the lib tree, add them to jars.xml and the cocoon build adds them to the Manifest ... Jetty/Jboss just eats 'em up in the right place. I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and not Sun's) ... how does this rank against Castor or Jakarta-OJB ? Cheers, Thor HW On Saturday, February 8, 2003, at 11:42 AM, Robert Simmons wrote: Hy, all; During the last months of activities i learned a lot from this mailing list. while i followed the discussions i started getting my development environment a bit up to date. I plan to setup a Wiki page on this theme. Although this may be a bit off topic, it still would be great, if someone could comment on this issue. the tools collection Here is what i have put together so far. Of course this is driven at least partially by what i do for my customers... free tools: 1.) OS: linux and solaris (maybe a mater of taste) Go linux. Instead of spending money on licenses, you spend money on support contracts. Cheaper. In addition, Solaris is primitive compared to Linux. 2.) apache 1.3.26 (mod_jk2, mod_SSL) Duh ;) 3.) tomcat 4.1.18 Yes, but you can go one step further. Get JBoss with integrated tomcat. JBoss will handle all sorty of nasty things like deploying to clusters for you. As a bonus, you get the ability to integrate with EJB based programs. 4.) cocoon-2.0.4 2.1 Hopefully soon! 5.) eclipse See my previous message about eclopse vs netbeans. 6.) sunbow eclipse tools (xml/sitemap) URL ? 7.) ant I have 15 million of them in my damn appartment, want a few? Oh ... you mean Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis' extensions to ant. http://www.krysalis.org/centipede/quickstart.html 8.) java-1.3.1 (sun JDK on all platforms) No no .. 1.4.1!! In 1.4 there are so many COOOL things that I couldnt live without anymore. 9.) Secureway LDAP Server (i'll switch to Open
Re: A note about the best(?) (cocoon-) development environment ...
Yes. That is part of the specification. The enhancement is to byte code, not to native versions of the code. Therefore any JVM can read the enhanced files. You might look at Jakarta's BCEL project to get an idea about how byte code enhancement works. As for the ODMG vs. byte code enhancement, Id have to disagree. The thing I want out of a persistence project is a fire and forget solution. As a consultant, I don't get paid for providing persistence solutions. I get paid for working on what makes my clients money. Be that web purchasing or genetic engineering. I am far better off having solutions where I need to invest only small amounts of thought in how to persist data and do object to relational mapping. In addition, there are instances, many of them, where you have neither control of the data that needs to be stored, nor access to the class files defining these data objects. At which point the JDO approach is far superior. Lastly the JDO approach provides the ability to reverse engineer schemas into the cross JDO vendor portable JDO metadeta files. This gives enormous power when working with legacy databases. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 10, 2003 1:37 AM Subject: Re: A note about the best(?) (cocoon-) development environment ... Have you found that it works well for you across JVM versions and implementations? The ODMG JDO works everywhere. On Sunday, February 9, 2003, at 05:22 AM, Robert Simmons wrote: Point of correction. Class enhancement is not generation per se. The actual class files are enhanced in place. In other words the byte code enhancers go into the class files and alter them. The solution elegantly solves some nasty problems. -- Robert - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:59 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Sun JDO JSR-12. - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka JBossWeb). No nasty must copy things to endorsed directories, etc.). You take Cocoon (2.0/2.1) and drop it in your deploy directory and POOF it's there. It's nice when the servlet engine actually uses the libs you define and not its own first as the default ... isn't that in the spec ... and will be available in Tomcat at some point. If you want any extra libs in cocoon-2.1 you add them in the lib tree, add them to jars.xml and the cocoon build adds them to the Manifest ... Jetty/Jboss just eats 'em up in the right place. I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and not Sun's) ... how does this rank against Castor or Jakarta-OJB ? Cheers, Thor HW On Saturday, February 8, 2003, at 11:42 AM, Robert Simmons wrote: Hy, all; During the last months of activities i learned a lot from this mailing list. while i followed the discussions i started getting my development
Re: A note about the best(?) (cocoon-) development environment ...
I'm familiar with BCEL and have used it to speed up JMX and reflection based applications. I haven't found the ODMG way to be very slow. Are we comparing specs to tools? Most things can auto-deploy schemas, but very few of my clients will use such a feature. We've used several ODMG based solutions to take advantage of a particular vendors enhancements, or J2C connectors. I can say that in the past my team of 3 have used these techniques to deliver maintainable, workable solutions very quickly. If you're persisting classes that you don't have control over, nor access to the class files (don't you need access to manipulate them?) then I'd be worried about version management and coupling. But, I'll have another look. Last thing, it's too bad that with JDO they have introduced 3 query languages, rather than have one that works for JDO, CMP-EJB, etc. Cheers, Thor HW On Sunday, February 9, 2003, at 04:56 PM, Robert Simmons wrote: Yes. That is part of the specification. The enhancement is to byte code, not to native versions of the code. Therefore any JVM can read the enhanced files. You might look at Jakarta's BCEL project to get an idea about how byte code enhancement works. As for the ODMG vs. byte code enhancement, Id have to disagree. The thing I want out of a persistence project is a fire and forget solution. As a consultant, I don't get paid for providing persistence solutions. I get paid for working on what makes my clients money. Be that web purchasing or genetic engineering. I am far better off having solutions where I need to invest only small amounts of thought in how to persist data and do object to relational mapping. In addition, there are instances, many of them, where you have neither control of the data that needs to be stored, nor access to the class files defining these data objects. At which point the JDO approach is far superior. Lastly the JDO approach provides the ability to reverse engineer schemas into the cross JDO vendor portable JDO metadeta files. This gives enormous power when working with legacy databases. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 10, 2003 1:37 AM Subject: Re: A note about the best(?) (cocoon-) development environment ... Have you found that it works well for you across JVM versions and implementations? The ODMG JDO works everywhere. On Sunday, February 9, 2003, at 05:22 AM, Robert Simmons wrote: Point of correction. Class enhancement is not generation per se. The actual class files are enhanced in place. In other words the byte code enhancers go into the class files and alter them. The solution elegantly solves some nasty problems. -- Robert - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:59 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Sun JDO JSR-12. - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules. Go through the tutorials and you will love it. Create an object model using your favorite problem domain. Then create the JDO mapping file (raw XML or with IDE plug-in) and then just say uhh, make a schema for me and it just does it. Its amazing! No more screwing around with persistence and schema manipulation. I have the commercial version of that product and will be talking about using it in the book that I am writing. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 9:47 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Robert: Have a look at Jetty, or JBoss/Jetty (aka
Re: A note about the best(?) (cocoon-) development environment ...
Well, I don't want to debate JDO vs. ODMG object mapping. I use JDO as will a very large amount of other people. Don't judge it when you know little about it. As for the query language, it blasts any other object based query language to hell. As for CMP and BMP, you can toss those out the window. Entity beans are the one blemish to EJB in my opinion. They are poorly thought out and poorly implemented. In short, all entity beans are basically crap. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 10, 2003 2:25 AM Subject: Re: A note about the best(?) (cocoon-) development environment ... I'm familiar with BCEL and have used it to speed up JMX and reflection based applications. I haven't found the ODMG way to be very slow. Are we comparing specs to tools? Most things can auto-deploy schemas, but very few of my clients will use such a feature. We've used several ODMG based solutions to take advantage of a particular vendors enhancements, or J2C connectors. I can say that in the past my team of 3 have used these techniques to deliver maintainable, workable solutions very quickly. If you're persisting classes that you don't have control over, nor access to the class files (don't you need access to manipulate them?) then I'd be worried about version management and coupling. But, I'll have another look. Last thing, it's too bad that with JDO they have introduced 3 query languages, rather than have one that works for JDO, CMP-EJB, etc. Cheers, Thor HW On Sunday, February 9, 2003, at 04:56 PM, Robert Simmons wrote: Yes. That is part of the specification. The enhancement is to byte code, not to native versions of the code. Therefore any JVM can read the enhanced files. You might look at Jakarta's BCEL project to get an idea about how byte code enhancement works. As for the ODMG vs. byte code enhancement, Id have to disagree. The thing I want out of a persistence project is a fire and forget solution. As a consultant, I don't get paid for providing persistence solutions. I get paid for working on what makes my clients money. Be that web purchasing or genetic engineering. I am far better off having solutions where I need to invest only small amounts of thought in how to persist data and do object to relational mapping. In addition, there are instances, many of them, where you have neither control of the data that needs to be stored, nor access to the class files defining these data objects. At which point the JDO approach is far superior. Lastly the JDO approach provides the ability to reverse engineer schemas into the cross JDO vendor portable JDO metadeta files. This gives enormous power when working with legacy databases. -- Robert - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 10, 2003 1:37 AM Subject: Re: A note about the best(?) (cocoon-) development environment ... Have you found that it works well for you across JVM versions and implementations? The ODMG JDO works everywhere. On Sunday, February 9, 2003, at 05:22 AM, Robert Simmons wrote: Point of correction. Class enhancement is not generation per se. The actual class files are enhanced in place. In other words the byte code enhancers go into the class files and alter them. The solution elegantly solves some nasty problems. -- Robert - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:59 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Sun JDO JSR-12. - Original Message - From: Thor Heinrichs-Wolpert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 10:22 PM Subject: Re: A note about the best(?) (cocoon-) development environment ... Which JDO? The ODMG JDO (like what Castor uses) or the after class generation muck about that is in the Sun JDO? Jetty has been using JMX long before Tomcat, it fully supports the spec ... and I'm thinking it supports it before the reference implementation does (like the classpath stuff). Is it superior, I can't say for sure (but it is the default / preferred servlet engine in JBoss. I like it because it takes me less screwing around with jar clashes between applications and what the server itself uses (making me less dependent on their support cycle and changes in where the JDK wants things). Cheers, Thor HW On Saturday, February 8, 2003, at 01:05 PM, Robert Simmons wrote: I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it will fix my classpath in XSP issue. Bugzilla Reference: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Kodo JDO is an implementation of the JDO specification and MORE. It basically rules.
