XMLForm for Cocoon 2.0.4
Hi all Due to heavy demand for the little piece of software developed by other, and amputated to run under Cocoon 2.0.4 by me ;-) I hereby post it to the mailing list. I tried posting the binary and the source code - but due to limits on filesize I can only send one of them :-( It's been a while since I made the chances, so I don't recall exactly what I've removed/changed. Regards Jakob Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 xmlform-cocoon-2.0.4.jar Description: Binary data - 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: XMLForm Wizard alternative?
Hi there I do not know if anyone else has done it - but I was so impressed with xmlform that I took the 2.1 code and hacked it a bit to compile and run on cocoon 2.0.4 - it's working for me - and I can create a source jar file and such for creating a cocoon-xmlform-2.0.4.jar file to put into WEB-INF/lib for cocoon-2.0.4 users that would like to play around with xmlform. If it has your interest send me a mail. Regards Jakob Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 Konstantin Piroumian [EMAIL PROTECTED] 12/18/02 01:39 PM Please respond to cocoon-users To: [EMAIL PROTECTED] cc: Subject:Re: XMLForm Wizard alternative? From: Robert Sösemann [EMAIL PROTECTED] Hy, in our project (CMS) we want to easily generate input fields in a wizard-like interface. It is later used by authors to put different types of articles into a database. As different types of articles have other information needs, we want to provide the user with form field that represent that needs of the specific article. So we need a mechanism to generate steps of our wizard (namely page with form fields) from centralized information (great would be the db) As this XMLWizard mechanism is only available from a cocoon beta, we are not allowed to use it. Can you imagine an alternative way to solve this? You can simply use the XMLForm's syntax for form representation and use a custom action to generate the next step for you. To customize the forms you can either use XSP or a special transformer. Konstantin Thanks in advance, Robert - 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] - 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: No more DTM IDs are available
Hi there Got this one some time ago - I guess some gurus might have a better answer than me, but here goes: You probably have an old Xalan in your JDK shadowing the Xalan in Cocoon. This is due to Java 2 Class Loading. Solution is to add xalan and xerces to the endorsed lib of your JDK (I am assuming some type of JDK 1.4 here). See how on: http://xml.apache.org/cocoon/installing under the subtitle Java 1.4 Configuration. Servlet 2.3 Class Loading is another feature that will help you - but let's leave that for a while since this probably requires editing the servlet container configuration. We tried different versions of System.out.println (org.apache.xalan.processor.XSLProcessorVersion.S_VERSION) in an xsp page to see what version cocoon really ended up using :-) But No more DTM ID's we got rid of by putting the proper xalan and xerces in the endorsed libs ... Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 Sebastian Gil [EMAIL PROTECTED] 01/20/03 01:53 PM Please respond to cocoon-users To: [EMAIL PROTECTED] cc: Subject:No more DTM IDs are available Hi there Sometimes when I modify my huge sitemap - 54Kb (especially when I add some parameters for actions or XSLT transformer) I got a strange message which tells me nothing. Maybe someone of you can give me some hints what could be wrong and how to correct sucha problem. Regards SG. java.lang.RuntimeException: Errors in XSLT transformation: Warning: File jar:file:/C:/Javasoft/Tomcat 4.1/webapps/insert/WEB- INF/lib/cocoon - 2.0.4.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xs l; Line 1822; Column 33; The use of redirect-to resource=dynamic-page/ is deprecated. Please use call resource=dynamic-page/ instead. Warning: File jar:file:/C:/Javasoft/Tomcat 4.1/webapps/insert/WEB- INF/lib/cocoon - 2.0.4.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xs l; Line 1822; Column 33; The use of redirect-to resource=dynamic-page/ is deprecated. Please use call resource=dynamic-page/ instead. Fatal: org.apache.xml.dtm.DTMException: No more DTM IDs are available at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java :3170) at java.lang.Thread.run(Thread.java:536) -- Keep on rolling mailto: [EMAIL PROTECTED] http://create.e-informatyka.pl - 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: XSP Logicsheet Questions...
Not that I have that much experience on this issue, but there is a nice example of various ways to get in contact with a logicsheet in the file: src/webapp/docs/samples/xsp/logicsheet.xsp at least in my Cocoon 2.0.3 ... Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 - 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: Strings to SAX events
I've done that in a generator thing I've made at work, using plain
XMLReader factory (code is off course employers property - but I can
outline the solution)
Problem: you have a string of xml that you need to generate SAX events
from, the string could be anything like:
?xml version=\1.0\ encoding=\iso-8859-1\?\ntagaklsks/tag,
tagaslkfkls/tagtaglaskklfsa/tag,
tag aasdflaskjkkkfl/kkksadkjf /tag
The first string is a valid xml document, the second is missing the
xml-declaration and does not have a single toplevel element, the third one
is just missing the xml-declaration (does this actually make it an invalid
xml?)
Fixing the missing xml declaration can be done by:
if (!xmlstring.startsWith(?xml)) {
xmlstring = ?xml encoding=\iso-8859-1\ version=\1.0\ ? +
xmlstring;
}
Now if the xmlstring does contain the xml-declaration I would presume it
is a valid xml document with one top-level element, else I add a toplevel
element to be sure to have just one, thus fixing both the xml declaration
and the possible multiple toplevel elements is done by:
if (!xmlstring.startsWith(?xml)) {
xmlstring = ?xml encoding=\iso-8859-1\ version=\1.0\ ?dummy +
xmlstring + /dummy;
}
When streaming the SAX Events I will later filter out the toplevel element
again ;-)
To be able to stream all but the toplevel element, you need a custom
ContentHandler; it should proxy all events but the startElement and
endElement of the toplevel tag; I've implemented it in an inner class and
it goes like:
protected class FilterContentHandler
implements ContentHandler
{
private ContentHandler destination;
private int depth = 0;
public FilterContentHandler (ContentHandler adestination)
{
destination = adestination;
}
public void startDocument ()
{
depth = 0;
}
public void endDocument ()
{
}
public void startElement ()
{
if (depth 0) {
destination.startElement (...)
}
depth++;
}
public void endElement (...)
{
depth--;
if (depth 0) {
destination.endElement (...);
}
}
.. and more methods
}
Off course all methods throw the SAXException - methods from the
ContentHandler interface not listed here just proxy to the destination
ContentHandler.
Then I instantiate an XMLReader, let contenthandler be the sink of your
SAX Events:
XMLReader reader = XMLReaderFactory.createXMLReader ();
reader.setContentHandler (new FilterContentHandler (contenthandler));
Make an inputsource:
InputSource inputsource =
new InputSource (new StringReader (xmlstring);
then just do:
reader.parse (inputsource);
If you need a better example I could spent some of my spare time making
it, maybe during the weekend.
Regards Jakob
Jakob Dalsgaard
Udvikler
e-mail: [EMAIL PROTECTED]
Vesterbrogade 149
1620 København V
Tlf.: 70 25 80 30
Fax.: 70 25 80 31
Luca Morandini [EMAIL PROTECTED]
11/08/02 10:55 AM
Please respond to cocoon-users
To: [EMAIL PROTECTED]
cc:
Subject:Strings to SAX events
Folks,
We're in the process of writing a Transformer, which, of course, outputs
SAX
events... but, in the midst of this stream , we need to insert an
XML element stored in a string.
To do this we're groping in the dark trying something like this:
JaxpParser respParser = new JaxpParser();
respParser.parse( new InputSource(new StringReader(str)),
new EmbeddedXMLPipe(contentHandler));
Which fails giving this:
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
java.lang.ClassCastException
...
Caused by: java.lang.ClassCastException
at
com.lucamorandini.charts.ChartTransformer.endElement(ChartTransformer.java:6
55)
at
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteStrea
mInterpreter.java:129)
at
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XMLByt
eStreamInterpreter.java:102)
at
org.apache.cocoon.components.pipeline.CachingEventPipeline.process
(CachingEventPipeline.java:219)
... 44 more
java.lang.ClassCastException
at
com.lucamorandini.charts.ChartTransformer.endElement(ChartTransformer.java:6
55)
at
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteStrea
mInterpreter.java:129)
at
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XMLByt
eStreamInterpreter.java:102)
at
org.apache.cocoon.components.pipeline.CachingEventPipeline.process
(CachingEventPipeline.java:219)
at
org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingS
treamPipeline.java:399)
The classes we use are:
org.apache.avalon.excalibur.xml.JaxpParser;
org.xml.sax.InputSource;
java.io.StringReader;
org.apache.cocoon.xml.EmbeddedXMLPipe;
And the environment is:
Solaris 5.8
JDK 1.4.1_01
Tomcat 4.1.12-LE-jdk14
Cocoon 2.0.3
May someone please help us ?
Thanks in advance,
Piero De Nicola Luca Morandini
We
Re: No more DTM IDs are available
Or you can deploy cocoon with servlet 2.3 class loading instead of java 2 classloading. Java 2 class loading: ask your parent classloader for your class before trying to find it yourself. Servlet 2.3 class loading: see if the class is in the webapp, then in ear scope (if present), then ask container/parent classloader. With Java 2 classloading you end up getting the JDK 1.4 Xalan - or your container Xalan - with servlet 2.3 class loading you get the Xalan supplied with Cocoon; which I think is preferable. I might be wrong on these class loading issues. I am deploying cocoon in the Jetty web container (whithin JBoss) and Jetty has a switch called Java2ClassLoading (I think) that I flip to get servlet 2.3 class loading; and if I remember correctly I flipped an initi-classloader switch in Cocoon as well. It must be possible in Tomcat to get this behaviour, though I know nothing of it. Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 Alex Romayev [EMAIL PROTECTED] 11/06/02 04:15 PM Please respond to cocoon-users To:[EMAIL PROTECTED] cc: Subject:Re: No more DTM IDs are available Take a look at: http://www.mail-archive.com/cocoon-users@xml.apache.org/msg19907.html --- Peter Smink [EMAIL PROTECTED] wrote: during the execution of my xsp page with logicsheets I get the DTMException No more DTM IDs are available how can i prevent this error? Peter Smink Osirion b.v. - 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: Cocoon and EJB
On the subject of Cocoon and EJB: I am developing an application based on JBoss 3.0.3 (with Jetty), Cocoon 2.0.3 and Sun JDK 1.4 - all nicely wrapped up in an InstallAnywhere executable and easy to install on any Linux/Windows box. We are using an almost stock JBoss where the Jetty container is configured to use Servlet 2.3 class loading instead of Java 2 class loading. This way Cocoon gets the Xalan 2.3.1 (actually we just upgraded to 2.4.0 because of weird ArrayIndexOutOfBoundExceptions) it is shipped with, instead of the Xalan 2.2.D11 coming from JDK 1.4 - anyone seeing the No More DTM IDs available exception when running JDK 1.4 should do this, or put xalan-2.3.1+xercesImpl.jar+xml-apis.jar into the JDK endorsed lib. To get Cocoon running with all that, we've set the init-classloader to true in the web.xml deployment descriptor. I am currently looking in to some redirection problems - but otherwise using Jetty as web container is fairly trouble free. We are aiming at being very J2EE spec compliant, but unfortunately we have not yet had the time to deploy the application in other application servers. And now to the more tedious part: To get the data from the EJB Layer I've created an XSLT that reads an XML definition file of a value object and generates a java file. This java class is the value object, and among other things it knows how to stream itself to a ContentHandler. This XSLT is unfortunately the property of my employer - but the idea is free to use ;-) We then have Session Facade Beans (see theserverside.com for EJB design patterns) collecting the data we need from Entity Beans (All Container Managed with only local interfaces and a lot of Container Managed Relations - we have the container do a lot of work here) and building the proper domain value objects. We furthermore have Command Session Beans to execute Command Objects that are initialized in the web tier (read: cocoon) and then passed on to the EJB Container; through Class.forName we have a Cocoon action that maps 1:1 between Cocoon actions and our commands. All that wraps up to a kinda nice MVC pattern; add in a few JMS messages here and there and the caches are cleared when needed... Well that was one messy mail I can hopefully do better next time I post ;-) Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 Piroumian Konstantin [EMAIL PROTECTED] 10/25/02 05:15 PM Please respond to cocoon-users To:'[EMAIL PROTECTED]' [EMAIL PROTECTED] cc: Subject:RE: Cocoon and EJB From: Gustavo Nalle Fernandes [mailto:[EMAIL PROTECTED]] In J2EE world, cocoon would play the role of the presentation tier, same as struts. In some cases, cocoon would bypass EJBs, to provide read-only data-retrieval (faster than instantiate thousands of bean in memory). What about a ValueObject generator, that by reflection generates sax events containing a bean atributes and values, with the option of specifing the depth (number of levels of child beans) wanted ? Value objects can be easily XML-ized using Castor transformer. Take a look at it in Cocoon scratchpad. Somebody suggested already this solution and also the JXPath-based generation or XSP logicsheet generator. -- Konstantin Gustavo -Mensagem original- De: Emmanuil Batsis (Manos) [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 25 de outubro de 2002 11:59 Para: [EMAIL PROTECTED] Assunto: Re: Cocoon and EJB Martin Schimak wrote: Are there any resources available focusing on EJB and Cocoon? The million dollar question. I'm trying to push Cocoon in the company I work for and I keep stumbling upon it. Manos - 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] - 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: Why is my cocoon app an IE6 killer?
More IE troubles. We currently have a problem running: - cocoon 2.0.2 (just the libs in the WEB-INF/lib of our own webapp) - jboss 3.0.1 (with what ever version of jetty is inside it) - jdk 1.4.0 (b92) on windows When run on our W2K professional production server and accessed from IE5.5/6 we get broken images, but only when we hit reload! This also leads to tons of incorrect content-length messages in the cocoon log; we assume that IE closes the connections in some abrupt way. The fun thing is that when run on our dual-athlon linux developer server (with jdk 1.4.0_01-b03) we experience no such thing in our IE's... In the next release we plan on utilizing a non-blocking IO (java.nio.*) socket listener that jetty 3.1+ (I think...) supports when compiled (and run ...) under jdk 1.4 - just to see if this has an effect. We've been fiddling with the http/1.1 switch in IE, with no noticable difference :-( furthermore we've tried to set the Expires header on _all_ images to check if that would force IE to store and not refetch the images, with no luck. On our laptops (P3 / 1 GHz running Win XP Professional / Redhat 7.x / Redhat 8.0) we run the product and do not experience the missing image stuff. We tend to believe that our problem is related to some ressources (?) being exhausted on our production server - but we haven't been successful in solving it. .. and sometimes we get strange No more DTM ids available exception - but that's a whole different issue :-) If someone could show me a http header that would resolve this problem I would be really really happy! Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 Antonio Gallardo Rivera [EMAIL PROTECTED] 10/08/02 06:38 AM Please respond to cocoon-users To:[EMAIL PROTECTED] cc: Subject:Re: Why is my cocoon app an IE6 killer? IE6 SP1 have the same problem. I still have the same problem with it. As you noted before this problem is a combination of IE and Tomcat. Of course if you upgrade or downgrade to a version without the problem, this is gone. Thanks, Antonio Gallardo El Lunes, 07 de Octubre de 2002 15:36, Ryan Agler escribió: I have not upgraded to SP1 yet, but Microsoft probably did fix the problem if yours works. However, my main concern is that most users out there will not have SP1. For me, the solution was using the test HTTP/1.1 connector instead of Coyote. The test connector seems to do something differently, and at this point I really don't have a compelling reason for using Coyote instead. -Original Message- From: Els Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 5:04 AM To: [EMAIL PROTECTED] Subject: RE: Why is my cocoon app an IE6 killer? I'm using IE6SP1 and loaded the site WITH images without any problem. I'm using a fully updated Win2K server version. Did you solve the problem in the mean time? Bert At 11:20 5/10/2002 +0200, you wrote: Ryan, I can confirm your findings, with IE 5.5 and IE 6.0 I've experienced this anomaly even when not using coyote. Actually, I used the ISAPI filter, since my front-end is IIS. BTW, back then (a year ago) I've contacted the Microsoft tech support: they recognized the existence of a problem and were very collaborative, but, in the end, nothing came out of it. Best regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Ryan Agler [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 05, 2002 9:29 AM To: [EMAIL PROTECTED] Subject: RE: Why is my cocoon app an IE6 killer? That could be a clue. However, from testing, I don't think it's limited to the use of HTTP/1.0. I experience the same thing even though I am positive IE6 is using HTTP/1.1 -- both when I visit http://www.helnwein.com/werke/theater/tafel_1.html , and when I enable Coyote and visit my own webapp's pages (and I can even see in the logs that IE6 is using HTTP/1.1) -Original Message- From: Antonio Gallardo Rivera [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 05, 2002 2:00 AM To: [EMAIL PROTECTED] Subject: Re: Why is my cocoon app an IE6 killer? I posted this today: I think I found where the problem is: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12783 It looks like is a Tomcat. Antonio Gallardo. - 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
