Re: [Website] Project homepage
I have stopped reading the Apache Incubator mailing list some time ago due to such debates. If you think that it is important to create new senseless rules for new projects - do so. But please do not create new useless work for those projects which already exist in the Incubator. Thanks, Andreas - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 7:15 PM Subject: RE: [Website] Project homepage Dion Gillard wrote: James Strachan wrote: Lenya, which has a URI, http://cocoon.apache.org/lenya/, outside of the incubator domain. Hmmm, how come Lenya got a URI? Can we have one too? I guess so if Lenya already has? As an outsider, this is very confusing. Lenya 'is not an ASF project', as it's being incubated, but the URL sure makes it seem like it is a sub project of cocoon. In total fairness to Lenya, the first paragraph of their home page talks about incubation. However, I agree as a policy matter that the site should be moved, with a redirect put in place, as described below. After a project leaves the incubator, a redirect can be put in the incubator's .htaccess to reference its new location. To demonstrate the technique, and further illustrating why web-sites should be maintained in CVS (as Lenya's is :-)), I just issued the following command: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic \ checkout -d lenya cocoon-site/site/lenya from /www/incubator.apache.org. You will notice that a copy of the lenya site is now at http://incubator.apache.org/lenya. All that is left for the Cocoon project to do now is to place: Redirect Permanent /lenya http://incubator.apache.org/lenya in .htaccess in their site root, and the location change should be transparent to all. I won't do that, though. That is a change for them to make. When the lenya site is updated, someone just needs to do: cd /www/incubator.apache.org/lenya cvs update -Pd rather than doing the exact same thing in /www/cocoon.apache.org/lenya. The process is simple, and should not be disruptive to their progress at all. It is actually rather cool that things can be this simple. --- Noel cc: lenya-dev@ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSP official position
On 18 Nov 2003, at 13:57, Joerg Heinicke wrote: But in fact it seems like XSP is being disliked by many developers. And I have to admit: I don't really like much anymore, too. But the question is whether it is because of the syntax or the heavy machinery or it's maintainability. IMO it's obvious: the mixture of coding languages (Java + XML) and the mixture of abstraction levels. But this abstraction does not make the coding easier, you have to know the implementation details to work around all possible mistakes: How often it is suggested to have a look at the generated Java files! In general we need a XML only XSP (i.e. without any Java written by hand) with minimum of flow support: xsp:if, xsp:for-each, etc. This level of change to XSP should be discussed on [EMAIL PROTECTED], fwiw. I personally would be against this kind of logic control in XSP. Especially since it's perfectly possible to add this in as a tag library. Yes, afterwards it's very similar to XSLT or other template languages as JXTemplate. The power of XSP is not XSP itself, but the further abstraction levels as esql as Leszek pointed out. This would make an XML only XSP to a really powerful template language in contrary to a programming language with nasty syntax at the moment. This isn't XSP's fault that it gets (ab)used this way. It's perfectly possible *today* to write XSPs that have no programming code in them. If Cocoon makes that hard I would consider it a bug (or at minimum a required feature for making XSP a reasonable framework to work with). Certainly it's very easy in AxKit - you just create a class and tell AxKit what methods are tags (sort of like SiLLy, but easier). Matt.
Re: [RT] SAX stream buffering
Torsten Curdt wrote:
Hi, folks!
The numbers of the XMLByteStreamCompilerInterpreterTestCase and the
SaxBufferTestCase gave me some RT
--
If you have a look at the testcases it's quite obvious that the
SaxBuffer is *much* faster than the XMLByteStream classes. As a thumb
rule -just to get the dimensions- we could say:
XMLC/XMLI is about 15 times faster than Xerces SaxBuffer is about 100
times faster than Xerces
Of course this depends heavily on the document. But it should be
enough to grasp the magnitude. Which was a bit of a surprise for me. I
personally did not expect this *huge* difference. Especially because
the SaxBuffer creates much more objects than the XMLC.
I'm not very surprised by these numbers: XMLC does a pretty heavy job to
serialize Strings to bytes.
Furthermore, I just looked at the XMLByteStreamCompiler.write() which
shows that it spends most of its time resizing the byte buffer, as
resizing is limited to the actual number of bytes needed for the current
write, and not by a larger growth increment.
It would be interesting to redo the test by introducing this growth
increment. BTW, I don't understand the this.buf.length 1 in the
write() method.
But the huge difference between the SaxBuffer and the XMLC is that the
XMLC serializes the SAX event on the fly. The SaxBuffer does not
support serialization but keeps the events as objects.
IMO spending time on the serialization only makes sense if
a) the memory consumption is too high otherwise
b) the SAX stream is being saved to disk
Maybe we can extend the testcases to compare the memory consumption.
For the question of the destination we could let the store decide.
Anyway both classes make sense. But maybe they would make even more
sense if they would share the same interface and would become
interchangeable.
The SAX stream buffering is a vital component of cocoon. Looking at
the numbers the impact on the performance could be tremendous.
What do you think?
Can't we merge both: use SAXBuffer for in-memory storage, and use
XMLC/XMLI to serialize it? This could even be done transparently by
having SAXBuffer implementing Serializable and use XMLC/XMLI to
implement readObject() and writeObject().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: cvs commit: cocoon-2.1/src/blocks/woody/samples/resources woody-field-styling.xsl
Vadim Gritsenko wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
N!!
I spent a large part of the afternoon and all this evening on these
issues and just solved them!
I was just doing the final polishing before committing. Please wait
a few minutes.
It's so complicated! I'd not be able to do it as I don't know
javascript that well :)
Well, flowscript allowed me to increase my JS knowledge a lot! Using the
same language client-side and server-side shows some benefits here.
Do you mind some simplifications? I.e.:
* Move all div/s just right after (or before) calendar div (in
woody-field-body, apply-templates select=//wi:help mode=popup-div/
After some thinking... I like this placing of divs. The only problem
might be in woody-lib.js, line 72:
var element = document.getElementById(this.id);
AFAIU, not all currently used browsers supporting this ... At least in
Matt's library there are checks like:
if(document.getElementById){use_gebi=
Yep, some polishing is needed to support some older browsers. I have to
install a NN 4.7 to see how all this behaves.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: rich clients and macromedia flex
Bertrand Delacretaz wrote:
Le Mardi, 18 nov 2003, à 17:27 Europe/Zurich, Robert Koberg a écrit :
...checkout Flex and MXML:
http://www.macromedia.com/devnet/flex
Thanks Robert, this is very interesting.
I'm currently using Flash, remote-controlled from java code, for an
interactive exhibition display project and the combination is killer,
I'm sure we will hear more about this!
Interesting. Is Cocoon involved in this?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Website] Project homepage
Stefano Mazzocchi wrote: ... The process is simple, yes, but it would break all the links to Lenya. When we started lenya, the rules of the incubator were not there yet, so we took lenya closer to the community that it depends on. Before breaking all the links, I would like to know if the above is just a suggestion or a rule that incubated projects have to follow. We have decided that this is the policy that has to be used for all projects that still have to setup a website. We have not decided what to do with current projects, although we would certainly appreciate if something like this can be done. As for the implementation of it for projects that already have a site, Noel's was just an example of what can be done, not of what has to be done. More sophisticated things can be done with mod_rewrite: http://httpd.apache.org/docs-2.0/misc/rewriteguide.html Practically publishing under the incubator rather than under Cocoon is really trivial, it just needs to do the CVS update from the incubator dir on the web server, but the problem is with legacy links, and AFAIK it can be solved. What do others think? I'm personally fine with either solution for projects in the same situation as Lenya (ie publishing under incubator or current place and redirecting from the other site), as long as the logo is changed to be the one of the Incubator Project and not that of the final proposed destination. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Website] Project homepage
On 18 Nov 2003, at 10:15, Noel J. Bergman wrote: Dion Gillard wrote: James Strachan wrote: Lenya, which has a URI, http://cocoon.apache.org/lenya/, outside of the incubator domain. Hmmm, how come Lenya got a URI? Can we have one too? I guess so if Lenya already has? As an outsider, this is very confusing. Lenya 'is not an ASF project', as it's being incubated, but the URL sure makes it seem like it is a sub project of cocoon. In total fairness to Lenya, the first paragraph of their home page talks about incubation. However, I agree as a policy matter that the site should be moved, with a redirect put in place, as described below. After a project leaves the incubator, a redirect can be put in the incubator's .htaccess to reference its new location. To demonstrate the technique, and further illustrating why web-sites should be maintained in CVS (as Lenya's is :-)), I just issued the following command: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic \ checkout -d lenya cocoon-site/site/lenya from /www/incubator.apache.org. You will notice that a copy of the lenya site is now at http://incubator.apache.org/lenya. All that is left for the Cocoon project to do now is to place: Redirect Permanent /lenya http://incubator.apache.org/lenya in .htaccess in their site root, and the location change should be transparent to all. I won't do that, though. That is a change for them to make. When the lenya site is updated, someone just needs to do: cd /www/incubator.apache.org/lenya cvs update -Pd rather than doing the exact same thing in /www/cocoon.apache.org/lenya. The process is simple, and should not be disruptive to their progress at all. It is actually rather cool that things can be this simple. --- Noel cc: lenya-dev@ The process is simple, yes, but it would break all the links to Lenya. When we started lenya, the rules of the incubator were not there yet, so we took lenya closer to the community that it depends on. Before breaking all the links, I would like to know if the above is just a suggestion or a rule that incubated projects have to follow. NOTE: I'm just wondering. I'm not criticizing or anything, just curious. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DynamicSelectionListTestCase
Ugo Cei wrote: Torsten Curdt wrote: Could someone more into woody please check the DynamicSelectionListTestCase ...it causes a NPE http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106750239117652w=2 Thanks! ...I missed that one -- Torsten
Re: [RT] SAX stream buffering
I'm not very surprised by these numbers: XMLC does a pretty heavy job to serialize Strings to bytes. Furthermore, I just looked at the XMLByteStreamCompiler.write() which shows that it spends most of its time resizing the byte buffer, as resizing is limited to the actual number of bytes needed for the current write, and not by a larger growth increment. It would be interesting to redo the test by introducing this growth increment. BTW, I don't understand the this.buf.length 1 in the write() method. Well, thats not exactly true: buf.length 1 is a shift operation which is the same as buf.length*2. The Max() chooses the bigger value. So that method is fine ;) But the huge difference between the SaxBuffer and the XMLC is that the XMLC serializes the SAX event on the fly. The SaxBuffer does not support serialization but keeps the events as objects. IMO spending time on the serialization only makes sense if a) the memory consumption is too high otherwise b) the SAX stream is being saved to disk Maybe we can extend the testcases to compare the memory consumption. For the question of the destination we could let the store decide. Anyway both classes make sense. But maybe they would make even more sense if they would share the same interface and would become interchangeable. The SAX stream buffering is a vital component of cocoon. Looking at the numbers the impact on the performance could be tremendous. What do you think? Can't we merge both: use SAXBuffer for in-memory storage, and use XMLC/XMLI to serialize it? This could even be done transparently by having SAXBuffer implementing Serializable and use XMLC/XMLI to implement readObject() and writeObject(). Hm... I don't know if I like that. Although it also came to my mind. That way we *always* have the memory consumption. It sounds reasonable from a OOP POV but it might not be a good choice in terms of scaleability ...I assume :-/ -- Torsten
Re: DynamicSelectionListTestCase
Torsten Curdt wrote: Ugo Cei wrote: Torsten Curdt wrote: Could someone more into woody please check the DynamicSelectionListTestCase ...it causes a NPE http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106750239117652w=2 Thanks! ...I missed that one ...wait a minute: shouldn't our build system be using the versions from the endorsed dir??? -- Torsten
Re: DynamicSelectionListTestCase
...wait a minute: shouldn't our build system be using the versions from the endorsed dir??? Of course, but cocoon.sh explicitly does: ENDORSED_LIBS=$COCOON_HOME/lib/endorsed ENDORSED=-Djava.endorsed.dirs=$ENDORSED_LIBS whereas build.sh does: ANT_OPTS=-Djava.endorsed.dirs=lib/endorsed export ANT_OPTS Probably the latter is not enough, sincerely I don't know. Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
Re: cvs commit: cocoon-2.1/tools/targets compile-build.xml
[EMAIL PROTECTED] wrote: unico 2003/11/19 06:59:07 Modified:tools/targets compile-build.xml Log: add call-block-target utitlity target for calling specific targets on blocks for example: $ build -Dblock.name=repository -Dtarget.name=lib call-block-target will compile repository block code and create the repository-block.jar That's a good one. Thanks. Geoff
Re: DynamicSelectionListTestCase
Joerg Heinicke wrote:
On 19.11.2003 14:34, Ugo Cei wrote:
...wait a minute: shouldn't our build system be using the versions
from the endorsed dir???
Of course, but cocoon.sh explicitly does:
ENDORSED_LIBS=$COCOON_HOME/lib/endorsed
ENDORSED=-Djava.endorsed.dirs=$ENDORSED_LIBS
whereas build.sh does:
ANT_OPTS=-Djava.endorsed.dirs=lib/endorsed
export ANT_OPTS
Probably the latter is not enough, sincerely I don't know.
AFAICS the above would be enough, if the JVM were not forked
(test-build.xml).
So the problem was in the generated block-build.xml
junit fork=yes haltonfailure=yes printsummary=yes
classpath
path refid=test.classpath/
path refid=fop.classpath/
pathelement location=${build.test}/
pathelement location=${build.blocks}/fop/test/
/classpath
formatter usefile=no type=plain/
batchtest
fileset dir=${build.blocks}/fop/test
include name=**/*TestCase.class/
include name=**/*Test.class/
exclude name=**/AllTest.class/
exclude name=**/*$$*Test.class/
exclude name=**/Abstract*.class/
/fileset
/batchtest
/junit
The junit fork missed the
jvmarg value=-Djava.endorsed.dirs=.../
So the woody tests are fine now :)
But the XMidiGeneratorTestCase still fails :(
Plus I guess in the block-anteater-tests the
the following line might be wrong, too:
jvmarg value=-Djava.endorsed.dirs=${anteater.home}/lib/
cheers
--
Torsten
RE: MountTableMatcher
Nice article! We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. It is too bad that Ant does not itself support a pluggable architecture. Now you end up replicating such a build environment in every new project. If something changes in cocoon that impacts the build system you need to update all those separate instances. I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. Regards, Unico -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: woensdag 19 november 2003 16:41 To: [EMAIL PROTECTED] On 17 Nov 2003, at 23:03, Geoff Howard wrote: Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Sure, but some people prefer to integrate Cocoon into their build - and generally want to do so with as little building of Cocoon as possible. Either way works well. With this recent change to XConfPatchTask, I have been able to refactor the way we build our Projects 'into' Cocoon. I attempt to describe the process here: http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding HTH regards Jeremy
New woody multivaluefield styling: the double listbox
Hi all,
Woody goodie of the day, I wrote a new styling for multivalue fields. We
already had list-type=checkbox, list-type=listbox and we now have
list-type=double-listbox.
This displays two lists with buttons between them to switch items
between the lists. The selected values are on the left.
This again relies on Matt Kruse's JS libraries (thanks Matt!) and
required to add a generic infrastructure in the woody JS library to
register handlers that are called either during onload of the
document or onsubmit of the form.
You can have a look at it in the Boolean fields tab in the Various
example.
Enjoy ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: MountTableMatcher
On 19 Nov 2003, at 16:19, Unico Hommes wrote: Nice article! Thanks Unico ! We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. It was a toss-up between patching the root sitemap, or patching the mount-table.xml ;) Basically I still needed the same dynamic parameters from the users environment It is too bad that Ant does not itself support a pluggable architecture. Too true Now you end up replicating such a build environment in every new project. If something changes in cocoon that impacts the build system you need to update all those separate instances. exactly I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. interesting ... I have done very little with Maven ... regards Jeremy -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: woensdag 19 november 2003 16:41 To: [EMAIL PROTECTED] On 17 Nov 2003, at 23:03, Geoff Howard wrote: Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Sure, but some people prefer to integrate Cocoon into their build - and generally want to do so with as little building of Cocoon as possible. Either way works well. With this recent change to XConfPatchTask, I have been able to refactor the way we build our Projects 'into' Cocoon. I attempt to describe the process here: http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding HTH regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: MountTableMatcher
Jeremy Quinn wrote:
snip/
We do basically the same thing. Note that with MountTableMatcher you no
longer need to patch the cocoon root sitemap.
It was a toss-up between patching the root sitemap, or patching the
mount-table.xml ;)
Do you need to patch mount-table.xml? This file is not stored in the CVS
and is not in build/ and therefore isn't impacted neither by cvs
update nor build clean.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: DB support in flowscript (was: XSP official position)
From: Leszek Gawron On Wed, Nov 19, 2003 at 12:01:41PM +0100, Reinhard Poetz wrote: From: Leszek Gawron On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote: I really no wonder why peope still think XSP is the great Gig in the Cocoon town, because if you google around you will feel this is the way Cocoon goes. To be honest I don't google about this for a long time but still early this year this was the tendency. xsp is very powerful if you use it with esql. - very fast custom database action creation (xsp actions) - nice syntax, no need for enormous amount of JDBC code needed, no need to handle exceptions - esql is customized transparently for several databases ( i.e. max-rows, skip-rows) - very useful for me because I connect cocoon to existing database installations so I do not have the comfort to choose one that fits the best. while the flow: - has some database support but is really poor I wouldn't code my DB support in Javascript I'm not advising that also. I am talking about providing an easy framework for database operations that would be available from flow. and really: why not ? I usually make two scripts : controller.js and persistence.js. JS has a great feature: it is interpreted so all you need is a text editor. You just apply changes and everything works without - building new classes - jar packaging - stopping the container - replacing the jar - starting the container - you have to catch exceptions yourself who else should catch them for you? SQLExceptions should be beclared or thrown. Simple JDBC wrappers usually convert almost all of them to RuntimeExceptions. 90% of exceptions usually denote a design time or fatal error so there is really no point to recover from them - it just should be simply logged - no database customizations I think flowscript shouldn't support DB access directly Maybe you're right but if you drop XSP what database support you have? Actions? Then can be used for really simple processing as using them for more advanced features makes it harder than using pure JDBC. Please note also that the biggest cocoon application example - Petstore - accesses database directly from JS. - O/R support is still pre-alpha and even if it was already mature - the overhead is much too big comparing to pure JDBC for projects not-enterprise size This is valid for your first project but it's like with Cocoon: After your first Cocoon project many of us also take it as platform for very simple projects. The last few weeks I learned more and more about OJB and you can be sure I'll take it in many projects in the future - also in projects where I wouldn't have taken it in the past because I *thought* it is too complicated (in opposite - using OJB makes it much easier!) - you cannot use it for web applications that use already ready database schema - try to add some functionality to big accounting system - you would have to map almost whole existing db even if you need access to 3-4 tables I think if you can remove all those SQL-statements out of your code which is IMO very ugly it's worth doing it. That's not the point - if you have an accounting system there are usually about 150 tables (very large). If you implement a simple plugin to that system you usually are concerned about a few of them while the OJB would need to map ALL refences between database tables. Continuing the example: cocoon is very powerful in presenting reports. I haven't seen a single report tool that does O/R mapping. Continuing II: I still cannot picture retrieving 5000 of objects via O/R and showing them on paginated view - the performance would be tragical. - sometimes the db schema makes it impossible to use O/R tools that's possible ... - in 2 years I haven't found a single project that does not fall under one of above conditions I would really like to contribute to some flow-db block that does not involve O/R mapping but do not know where to start from. Maybe this helps - I like the idea but don't know if this will work ... but I think it worth following it. http://marc.theaimsgroup.com/?t=10676139446r=1w=2 (... but it would be OJB based) What I don't want to see in a flow-db block is SQL statements ... I think that it should be possible to choose between O/R and pure database access. O/R could be a proposed solution and JDBC wrapper a backup one. I separate between applications which are more 'publishing-centric' and which are more 'transaction-centric'. 'publishing-centric'-applications usually don't need flowscript. Your example (reporting tools) is of course a representative of the this type and XSP(using ESQL) or SQL-Transformer
Re: DB support in flowscript
Tony Collen dijo: Ugo Cei wrote: Leszek Gawron wrote: I'm not advising that also. I am talking about providing an easy framework for database operations that would be available from flow. I had thought about this for a while... a lightweight JDBC wrapper for the Flow. Then I thought about it more... although it might encourage people to start writing more things in Flowscript, I think the Correct Way(tm) would be to write your business logic in a real Java class and access it from the Flow that way. Remember, the Flow is just for controlling the application. I suppose then the question is, what happens when your logic depends on something in a database? +1 Best Regards, Antonio Gallardo
Re: DB support in flowscript (was: XSP official position)
Ugo Cei wrote: Upayavira wrote: 1) The most complicated bit I have found in building Cocoon sites is handling Java classes. If deployed in a jar, it always seems to require a server/app restart to take on the changes. For trivial things (e.g. sending a simple email), I wouldn't want to have to get all this Java stuff going. Then you should: A) test your classes in isolation _before_ debugging them in Cocoon Yup. Will get into doing that some day soon. B) get yourself a fast machine and with the cocoon servlet task, restarting the container is a breeze, especially if you tune your Cocoon to have only the minimum set of blocks needed. Still a hassle to switch to another window, shut it down, wait., restart, then connect your debugger to the waiting instance, then request a page from Cocoon and wait...:-( I'll get there. But then again, YMMV ;-) Ugo P.S.: by the way, is it possible to restart a context with Jetty like it is with Tomcat, and how? Do cocoon servlet-admin and go to http://localhost:8889/ It seems you can do a standard http request to, for example http://localhost:8889/?A=StartID=1:null:/:0 (note, I removed the T parameter, which changes every time, and it still seemed to work). I believe you could put this HTTP request into an Ant script using the get task. I wonder if there might be a need for a cocoon servlet-debug-admin that allows both debugging and admin (e.g. to allow you to automatically restart your jetty for debugging). Regards, Upayavira
Re: DB support in flowscript (was: XSP official position)
Ugo Cei wrote: P.S.: by the way, is it possible to restart a context with Jetty like it is with Tomcat, and how? I've found: http://groups.yahoo.com/group/jetty-support/message/1622 http://jetty.mortbay.org/jetty/doc/reloadServlets.html Tony
Re: Web Service Transformers in Cocoon (Re: [article] XML.com: EAI using Apache Cocoon 2.1)
Daniel, I have attached the latest WSIncludeTransformer. Further to the discussion, however, we are doing our SOAP calls up front now, calling our SOAPController directly from Flow Script. The SOAP controller is literally the SOAP calls from the WSIncludeTransformer removed from the transformer. If anything goes wrong with the call we can take appropriate action (server down, session timeout, incorrect password etc etc). Our Woody binding file binds the returned xml to our beans which do a lot of the logic needed. Joe - Original Message - From: Daniel Fagerstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 9:48 PM Subject: Re: Web Service Transformers in Cocoon (Re: [article] XML.com: EAI using Apache Cocoon 2.1) Joe Latty wrote: We are using the Web Service Transformer, discussed in the XML.com article, here (where it was originally written) in a production environment. So far we have had no problems with it. I can post the latest version of the WSIncludeTransformer if anyone is interested. Please do! As soon as I find time for it I will make an effort to combine the best festures from the various implementations. However, having said that, we have found problems with doing SOAP/HTTP Calls during pipeline processing. When something goes wrong it is difficult to recover gracefully. rant Agree, in the past I tried in vain to convince the community that there is a need for selection based on sitemap content and state (http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=pipe-awareq=b). Now you can achieve something similar witing three pipelines. One that construct the input to the soap transformer and uses the soap transformer, one for handling the output if everything wents well and one for error handling then you call the first one from a flowscript with processPipelineTo, and streams the output of it into a dom tree. Then you can analyze the reusult in it and make a senPage to one of the result handling pipelines. I must admit that I am not jumping up and down, shouting out my joy, when I think of the elegance of this solution ;). But it does it work, and after a while I even might start to think of it as an idiom or design pattern ;) Or I find the energy for fighting for what is good and right again ;) /rant And most of our SOAP/HTTP calls are being now done using the Flow controller and Woody. SOAP/HTTP calls return XML which then populates forms/beans using woody binding. var xml = Packages.org.apache.cocoon.util.SOAPController.call(soapCall, uri, soapMethod, params, timeout); form.load(xml); // form.save(bean); Joe I could not find the o.a.c.util.SOAPController in the Cocoon repository, is it something you have developed? And if that is the case it would be nice if you could commit that component as well. /Daniel WSIncludeTransformer.java Description: Binary data
Re: DB support in flowscript (was: XSP official position)
Upayavira wrote: Still a hassle to switch to another window, shut it down, wait., restart, then connect your debugger to the waiting instance, then request a page from Cocoon and wait...:-( Then you don't have a fast enough machine ;-), And if you wrote more tests, you wouldn't need a debugger so often. It seems you can do a standard http request to, for example http://localhost:8889/?A=StartID=1:null:/:0 Ah OK, actually I knew about that, but I tend to forget. Another question, if you don't mind, isn't it possible to use Jetty's admin interface from a host different from localhost? Ugo
Re: SVGSerializer patch
Borges Charles wrote: Hi, Here's proposed SVGSerializer patch to support request parameters. ... or samples/batik/batikLogo.png?width=200height=100indexed=2 ... ugly! Or samples/batik/batikLogo.png?width=1000height=1000 samples/batik/batikLogo.png?width=1000height=1001 samples/batik/batikLogo.png?width=1000height=1002 ... in the loop and your server is down. No, thank you, I'll pass on this particular parameter! Vadim
Re: DB support in flowscript (was: XSP official position)
Upayavira wrote: I have logged into another PC with PCAnywhere and tried http://charya:8889. (My PC is charya). It didn't work. I removed the Host line, and restarted, and it did. I guess that is reasonably conclusive, isn't it? ;-) Mmmh. Not neccessarily. If the default is to bind to your NIC's public IP (i.e. with no host line), then you'd be able to access Jetty from any computer that can reach that public IP address. As a test I set the host to my public IP address, and I get the following message when I start Jetty: 17:55:04.016 EVENT Started SocketListener on 0.0.0.0: 17:55:04.016 EVENT Started [EMAIL PROTECTED] 17:55:04.086 EVENT Starting Jetty/4.2.9 17:55:04.096 EVENT Started ServletHttpContext[/] 17:55:04.106 EVENT Started SocketListener on [MY_PUBLIC_IP_ADDRESS]:8889 17:55:04.106 EVENT Started [EMAIL PROTECTED] And I was able to access the admin servlet from over the Internet. Likewise, when i set it to 127.0.0.1: 17:56:17.511 EVENT Started SocketListener on 127.0.0.1:8889 And I can only reach the machine from localhost (aka 127.0.0.1) It's the IP address it binds to, I tell you! :) Tony
DO NOT REPLY [Bug 24844] New: - XMLByteStreamCompiler.getSAXFragment() shouldn't return whole array
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24844.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24844
XMLByteStreamCompiler.getSAXFragment() shouldn't return whole array
Summary: XMLByteStreamCompiler.getSAXFragment() shouldn't return
whole array
Product: Cocoon 2
Version: Current CVS 2.1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
XMLByteStreamCompiler.getSAXFragment() has been changed recently to return the
whole array instead of creating a new array trimmed to the appropriate length.
This causes problems for (at least) XMLByteStreamInterpreter which spews as many
startDocument() events as there are zeroes at the end of the array. This causes
Saxon to throw an exception.
I first noticed the problem with a transform like this:
map:transform src=cocoon:/generate-page
map:parameter name=dn value={request-param:dn} /
/map:transform
This still works fine though (???):
map:match pattern=test
map:generate src=test.xml /
map:transform src=test.xslt /
map:serialize /
/map:match
Re: SVGSerializer patch
Tony Collen wrote: Vadim Gritsenko wrote: Borges Charles wrote: Hi, Here's proposed SVGSerializer patch to support request parameters. ... or samples/batik/batikLogo.png?width=200height=100indexed=2 ... ugly! Or samples/batik/batikLogo.png?width=1000height=1000 samples/batik/batikLogo.png?width=1000height=1001 samples/batik/batikLogo.png?width=1000height=1002 ... in the loop and your server is down. No, thank you, I'll pass on this particular parameter! Shouldn't this be a concern of a transformer or the generator, anyway, and not the serializer?? Just pass the request parameters to an XSLT to change the svg height or width, then output the image. Even better: pass via sitemap parameter (I like this way more :) Vadim
