Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you will get an Exception in the initialization phase
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you will get an
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
Very likely char[] or byte[].
It could be at a very low level, such as Readers
and InputStreams.
Could also be this:
http://developer.java.sun.com/developer/bugParade/bugs/4724129.html
Bug Id 4724129
SynopsisMemory leak in
On Tue, 2003-03-18 at 17:46, Unico Hommes wrote:
I am getting:
E:\projects\hippo-y!\src\cocoon-xhive\java\nl\hippo\cocoon\source\XhiveSource.java:109:
cannot resolve symbol
symbol : constructor AbstractSAXSource (nulltype,org.apache.avalon.framework.compo
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-19/cocoon-block-databases.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-19/cocoon-block-fop.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-19/cocoon-block-jsp.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-19/cocoon-block-php.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-19/cocoon-block-web3.html
Buildfile: build.xml
init:
prepare:
[echo]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-19/cocoon-block-xmldb.html
Buildfile: build.xml
init:
prepare:
[echo]
ccing [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote, On 19/03/2003 11.02:
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-03-19/cocoon-block-php.html
Folks,
I'm experiencing problems while updating cocoon-2.1 (cocoon-2.0 is
fine). I get the following messages and then CVS seems to hang :
cvs update: Dropping data: posvec-nlines
cvs update: invalid change text in src/idl/cocoon/_module.idl
cvs server: cannot open directory
Had the same yesterday. You simply must delete one of the ancestor
directories of the file and update again.
Joerg
Sylvain Wallez wrote:
Folks,
I'm experiencing problems while updating cocoon-2.1 (cocoon-2.0 is
fine). I get the following messages and then CVS seems to hang :
cvs update:
Joerg Heinicke wrote:
Had the same yesterday. You simply must delete one of the ancestor
directories of the file and update again.
That solved the problem, although it doesn't explain how my CVS repo got
corrupted...
Anyway, thanks a lot for the trick !
Sylvain
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 18/03/2003 13.05:
Nicola Ken Barozzi wrote:
...
So, how would you tackle the above real-world problem?
I would not write a transformer but a serializer. In fact, a chart
package image rendere *is* a serializer, since the output of a
Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/xmlForm.js?rev=1.3content-type=text/plain
In order to communicate with XMLFormTransformer and to handle
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard to
write sophisticated Serializers.
We worked around this by using it in conjunction with a Transformer that
was given the environment and simply passed it
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you
Leo Sutic wrote:
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
Very likely char[] or byte[].
It could be at a very low level, such as Readers
and InputStreams.
Could also be this:
http://developer.java.sun.com/developer/bugParade/bugs/4724129.html
Bug Id 4724129
Synopsis
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
snip/
Only because of the design of XMLForm: it stores the form view in
the object model and several of the methods of
org.apache.cocoon.component.xmlform.Form require the object model as
a parameter.
Ah, ok.
Regardless of the flow,
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=17063.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to the
environment (Request / Response). This means that it is very hard to
write sophisticated Serializers.
For example? (I think FOP and batik are both pretty sofisticated
serializers)
We worked around this
Hi,
Generator, Reader and Transformer all inherit from
SitemapModelComponent, which declares the setup() method:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel
* codeMap/code, the source and sitemap codeParameters/code
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both pretty sofisticated
Jeff Turner wrote:
Hi,
Generator, Reader and Transformer all inherit from
SitemapModelComponent, which declares the setup() method:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel
* codeMap/code, the source and sitemap
hi all,
I found the following problem when compiling the whole cocoon-2.1-dev:
blocks that have no configuration files in their /conf directory result
in no conf directory at all in the ${build.blocks}/name directory.
this again results in a NullPointerException in the XConfTool ant task,
since
Stefano Mazzocchi wrote:
Leo Sutic wrote:
From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Very likely
char[] or byte[].
It could be at a very low level, such as Readers and InputStreams.
Could also be this:
http://developer.java.sun.com/developer/bugParade/bugs/4724129.html
Bug Id
Vadim Gritsenko wrote:
Holy shit! This is a *HUGE* bug. We (and Xerces) use StringBuffers all
over the place!!! In fact, it seems that StringBuffer.toString() is
our hotspot.
I'll come up with more profile information soon.
Why don't you switch to 1.3.1?
For that matter, 1.4.0 would behave
Stefano Mazzocchi wrote, On 19/03/2003 14.41:
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 18/03/2003 13.05:
Nicola Ken Barozzi wrote:
...
So, how would you tackle the above real-world problem?
I would not write a transformer but a serializer.
...
What's wrong with this?
I cannot
From: Jeff Turner [EMAIL PROTECTED]
Hi,
Generator, Reader and Transformer all inherit from
SitemapModelComponent, which declares the setup() method:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel
* codeMap/code,
Stefano Mazzocchi wrote:
I personally don't like it. Adding fake facades for just one thing
doesn't sound right at all.
I think that Carsten's problem is to have an external dependency on the
rhino jar. Please, Carsten, correct me if I'm wrong.
Not exactly. Yes, I don't want to have the
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both pretty sofisticated
Vadim Gritsenko wrote:
Jeff Turner wrote:
Hi,
Generator, Reader and Transformer all inherit from
SitemapModelComponent, which declares the setup() method:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel
* codeMap/code, the
Vadim Gritsenko wrote:
One word: CacheableProcessingComponent. IIRC, cache was aware of
cacheable serializers some time ago. The only missing piece is to add
SitemapModelComponent support for Serializers.
Yes, the caching algorithm queries serializers if they support caching
since more
On Wed, Mar 19, 2003 at 09:29:05AM -0500, Vadim Gritsenko wrote:
Jeff Turner wrote:
...
void setup(SourceResolver resolver, Map objectModel, String src,
Parameters par)
...
If there's no objections, I would like to:
- assert in the Javadoc that 'src' will never be null
Some
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
Thanks
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
Jeff Turner wrote:
At that level, there isn't enough info to provide a user-friendly error
message. I think the best solution is to add a check in the
treeprocessor's ReadNodeBuilder. I've now got it displaying:
Reader at
Bruno Dumon wrote:
Are you talking about Cocoon 2.0 or 2.1?
Cocoon 2.1.
I don't think we support that level of compatibility between
Cocoon 2.0 and 2.1
Fair enough.
-- you'll probably find that other stuff also changed (e.g.
Parser being split in SAXParser and DOMParser, changes in
Unico Hommes wrote:
OK. I think I'll wait for SourceResolving to have solidified into
a proper release.
The source resolving should be solidifed now; I don't expect any
changes before a release of the sourceresolving package
which will happen sometime soon.
Carsten
Carsten Ziegeler
Open
Carsten Ziegeler [EMAIL PROTECTED] wrote:
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
b implies beta... We go straight to beta without an alpha???
Pier
From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
Carsten Ziegeler [EMAIL PROTECTED] wrote:
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
b implies beta... We go straight to beta without an alpha???
Not
Sylvain Wallez wrote:
Now, if my sitemap doesn't use *any* flow elements, would the jar need
to be in the classloader?
Nope, since the flow-related treeprocessor classes deal with flow
interfaces rather than with the JS implementation. So we need the
flow-related interfaces (only
Carsten Ziegeler [EMAIL PROTECTED] wrote:
From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
Carsten Ziegeler [EMAIL PROTECTED] wrote:
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
b implies beta... We go
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both
Jeff Turner wrote:
Hi,
Generator, Reader and Transformer all inherit from
SitemapModelComponent, which declares the setup() method:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel
* codeMap/code, the source and sitemap
Jakob Praher wrote:
Index: blocks-build.xsl
===
RCS file: /home/cvspublic/xml-cocoon2/tools/src/blocks-build.xsl,v
retrieving revision 1.26
diff -u -r1.26 blocks-build.xsl
--- blocks-build.xsl 3 Mar 2003 14:03:34 - 1.26
+++
Niclas Hedhman [EMAIL PROTECTED] wrote:
On Wednesday 19 March 2003 04:14, Tony Collen wrote:
Reading this great article [1] (Thanks Pier!), I realized that the
mod_rewrite stuff could possibly be worked around using virtualhosts. I'm
not too familliar with Apache HTTPD 2, but I assume
Gianugo Rabellino wrote:
Vadim Gritsenko wrote:
Holy shit! This is a *HUGE* bug. We (and Xerces) use StringBuffers
all over the place!!! In fact, it seems that StringBuffer.toString()
is our hotspot.
I'll come up with more profile information soon.
Why don't you switch to 1.3.1?
Oh, sure,
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
One word: CacheableProcessingComponent. IIRC, cache was aware of
cacheable serializers some time ago. The only missing piece is to add
SitemapModelComponent support for Serializers.
Yes, the caching algorithm queries serializers if they support
Pier Fumagalli wrote:
Carsten Ziegeler [EMAIL PROTECTED] wrote:
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
b implies beta... We go straight to beta without an alpha???
yes, we have never released alpha code.
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
I personally don't like it. Adding fake facades for just one thing
doesn't sound right at all.
I think that Carsten's problem is to have an external dependency on the
rhino jar. Please, Carsten, correct me if I'm wrong.
Not exactly. Yes, I
Stefano Mazzocchi wrote:
If you start adding the environment, this is not true anymore and we
must cache *BOTH* the pipeline output (as xml) and the serializer output
(as binary) because their ergodicity can be different.
This is the only concern I'm having.
If enough people believe this is a
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
It's already not easy to separate! I can think of how to resolve
issue 1 (dedicated FlowObjectModelHelper: ugly, but works)
yuck!
So, what do we do? Carsten, may I have your blessing for adding helper
methods to ObjectModelHelper? I can even
Do this:
1) ./cocoon.sh servlet-profile
2) when you want to make a profile dump kit CTRL-\ on UNIX and
CTRL-Break on Win32
3) this will save a file called java.hprof.txt in the directory
now go to
http://www.hp.com/products1/unix/java/hpjmeter/downloads/license_hpjmeter.html
and download
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
If you start adding the environment, this is not true anymore and we
must cache *BOTH* the pipeline output (as xml) and the serializer
output (as binary) because their ergodicity can be different.
This is the only concern I'm having.
If
Uh, Rhino isn't only used by the flow. It appears to also be used by:
JSGenerator.java
CompiledJavaScriptLanguage.java
Also, for what it's worth, although the jxpath jar is in lib/optional
there seem to be dependencies on it elsewhere in the core (not just in
flow code), e.g:
Am Mit, 2003-03-19 um 17.17 schrieb Stefano Mazzocchi:
Jakob Praher wrote:
Index: blocks-build.xsl
===
RCS file: /home/cvspublic/xml-cocoon2/tools/src/blocks-build.xsl,v
retrieving revision 1.26
diff -u -r1.26
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=18131.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
I'm playing and digging in flow-enabled petstore (BTW, so nice, I love
it), and experienced some problems with the continutation-enabled
prev/next navigation.
To reproduce it, go to the dogs area, click next once and then hit
the browser's reload button. The prev and next links are now
Sylvain Wallez wrote:
Hi,
I'm playing and digging in flow-enabled petstore (BTW, so nice, I love
it), and experienced some problems with the continutation-enabled
prev/next navigation.
To reproduce it, go to the dogs area, click next once and then hit
the browser's reload button. The prev and
Hi All!
Jumping into this thread a bit late...
On Tue, Mar 18, 2003 at 10:31:03AM -0800, Christopher Oliver wrote:
You're not abusing sessions. cocoon.createSession() exists exactly for
the purpose you mention. Nobody is suggesting that we remove it. What at
least I was
Christopher Oliver wrote:
Sylvain Wallez wrote:
Hi,
I'm playing and digging in flow-enabled petstore (BTW, so nice, I
love it), and experienced some problems with the
continutation-enabled prev/next navigation.
To reproduce it, go to the dogs area, click next once and then
hit the browser's
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Moreover, AFAIU, the productList variable in viewCategory() is
stored in the continuation, and so if we hit next and then prev,
the first list exists twice (in different continuations). Isn't there
a potential memory
I have quite unusual situation.
The requests to my site is being made to http://host:7723 which is being
redirected to http:/otherhost:80. These both addreses are Apaches while the
second one uses mod_jk to connect to tomcat on the same maching. And now
the problem:
GET /polka-kp/ HTTP/1.1
Host:
On ro, mar 19, 2003 at 08:38:30 +0100, Leszek Gawron wrote:
I have quite unusual situation.
The requests to my site is being made to http://host:7723 which is being
redirected to http:/otherhost:80. These both addreses are Apaches while the
second one uses mod_jk to connect to tomcat on the
On ro, mar 19, 2003 at 08:38:30 +0100, Leszek Gawron wrote:
I have quite unusual situation.
The requests to my site is being made to http://host:7723 which is being
redirected to http:/otherhost:80. These both addreses are Apaches while the
gosh I must be brainwashed .. of course there is only
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=18131.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18164.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18164.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=18164.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Moreover, AFAIU, the productList variable in viewCategory() is
stored in the continuation, and so if we hit next and then
prev, the first list exists twice (in different continuations).
Isn't
On Montag, März 17, 2003, at 04:37 Uhr, Christopher Oliver wrote:
Does Xsp have some way of doing number formatting? The numeric values
you receive from JavaScript are of type java.lang.Double.
it's done in the xsl-stylesheet now.
The XSP view is now up to date with your vm templates. All new
On 14/03/2003 19:18 Christopher Oliver wrote:
Here's a summary of some of the recent issues with the Flow for discussion:
Completely unrelated to the technical discussion which is way above my
head, I found a nice weblog discussing graphical depictions of flow -
with a well-known and not too
On 19/03/2003 23:42 Steven Noels wrote:
Completely unrelated to the technical discussion which is way above my
head, I found a nice weblog discussing graphical depictions of flow -
with a well-known and not too easy example:
Some further linking: http://www.jjg.net/ia/visvocab/
/Steven
--
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=18164.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Wed, Mar 19, 2003 at 04:40:20PM +0100, Sylvain Wallez wrote:
Jeff Turner wrote:
At that level, there isn't enough info to provide a user-friendly error
message. I think the best solution is to add a check in the
treeprocessor's ReadNodeBuilder. I've now got it displaying:
Reader at
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
The call frames that represent the calls to f() and g() are shared
between all continuations captured inside h(). But when a continuation
escapes the while loop and returns
Can somebody knowledgable comment on the following method? Local
variable scope is not used...
private Script compileScript(Context cx, Scriptable scope,
Source src) throws Exception {
InputStream is = src.getInputStream();
Reader reader = new
Hold on, Vadim. I'll fix that shortly. It's only there for testing
compiling with different scopes. I think it's good that you're visually
inspecting the code for problems, but I think we should focus more on
externally visible problems rather than code inspection at this point.
What I'm
Hi Marcus,
Those are very good questions. And I don't know the answer. See my
response to Vadim about scopes and compiling scripts. We need to
partition the scripts by application somehow.
What defines an application in Cocoon. For example, does each get a
separate class loader? Is there a
I'm combining two emails into one...
Christopher Oliver wrote:
What defines an application in Cocoon.
Some (not necessarily root) sitemap and all of its subsitemaps can be
seen as one application. Sub-sitemaps can be seen as sub-applications...
For example, does each get a separate class
Hi Vadim, many thanks to you for fixing the build test.
--David
Thanks for these changes, Vadim.
[EMAIL PROTECTED] wrote:
vgritsenko2003/03/19 20:12:49
Modified:src/java/org/apache/cocoon/components/language/programming/java
EclipseJavaCompiler.java JavaLanguage.java
Log:
Fix source dir parameter: point to source
We have had the conversation buried under an obscure thread name.
Re: Finishing Deprecation Package
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104763803628330
Would people please report whether the Catalog Entity Resolver
samples work for them. There are two samples at
Thank you very much, Leo. I've committed your changes and I made some
modifications so that you can dynamically select the view from the
webapp: either Velocity or Xsp.
Regards,
Chris
leo leonid wrote:
On Montag, März 17, 2003, at 04:37 Uhr, Christopher Oliver wrote:
Does Xsp have some way
Le Jeudi, 20 mars 2003, à 07:15 Europe/Zurich, David Crossley a écrit :
...There are two samples at
http://localhost:/samples/catalog/welcome
Hi David,
catalog-demo works fine here (mac osx 10.2.3, JDK 1.4.1_01) as far as I
can tell: all five entities in catalog-demo.xml are resolved
Stefano Mazzocchi wrote:
Why can't se simply postpone module-creation this after 2.1? I don't
think it's worth delaying further for a simple 50kb less of cocoon.jar
I agreed that we move this issue into 2.2 or whatever and that this
should not delay 2.1 - so for me, it's pretty clear that
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
It's already not easy to separate! I can think of how to resolve
issue 1 (dedicated FlowObjectModelHelper: ugly, but works)
yuck!
So, what do we do? Carsten, may I have your blessing for adding helper
Bertrand Delacretaz wrote:
David Crossley a écrit :
...There are two samples at
http://localhost:/samples/catalog/welcome
Hi David,
catalog-demo works fine here (mac osx 10.2.3, JDK 1.4.1_01) as far as I
can tell: all five entities in catalog-demo.xml are resolved correctly,
Got carried away, it's [EMAIL PROTECTED] ;-)
Original Message
Subject: Re: [GUMP] Build Failure - cocoon-block-php
Date: Wed, 19 Mar 2003 11:20:06 +0100
From: Nicola Ken Barozzi [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED],[EMAIL PROTECTED]
Organization: Apache Software
92 matches
Mail list logo
