I've had the same problem in 2.1.5.1. I reported a bug here:
http://archives.real-time.com/pipermail/cocoon-devel/2004-July/035779.ht
ml
I had the problem that when I use:
doSomethingWithClass(Product.class);// fails
doSomethingWithClass(Product.getClass()); // ok, does not
fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27467.
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://issues.apache.org/bugzilla/show_bug.cgi?id=25359.
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://issues.apache.org/bugzilla/show_bug.cgi?id=27467.
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://issues.apache.org/bugzilla/show_bug.cgi?id=25384.
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://issues.apache.org/bugzilla/show_bug.cgi?id=25358.
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://issues.apache.org/bugzilla/show_bug.cgi?id=25384.
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://issues.apache.org/bugzilla/show_bug.cgi?id=25281.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Vadim Gritsenko wrote:
David Crossley wrote:
Also remember that it is the chair's report to the board, so you
don't need agreement from us about what you tell them.
Also remember that chair is chosen by community, and if chair goes
against community will, he will get replaced by community :-)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25325.
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://issues.apache.org/bugzilla/show_bug.cgi?id=25325.
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://issues.apache.org/bugzilla/show_bug.cgi?id=27147.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Il giorno 10/ago/04, alle 04:14, Vadim Gritsenko ha scritto:
even if not - it contains code that was compiled against hibernate
interfaces. Wouldn't this be an issue?
It would not be an issue as long as classes compiled against Hibernate
are not included into Spring JAR which is (in this
I found a workaround for this:
as long as you declare the var global (menas a class var) the error
does not happen.
Maybe this helps you continuing work as long as the bug is not fixed.
CYA
Andreas Schmid
Bart Molenkamp wrote:
I've had the same problem in 2.1.5.1. I reported a bug here:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25359.
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://issues.apache.org/bugzilla/show_bug.cgi?id=27467.
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://issues.apache.org/bugzilla/show_bug.cgi?id=30554.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Monday, August 09, 2004 5:28 PM
To: [EMAIL PROTECTED]
Subject: pluto in Cocoon
We would like to support JSR-168 portlets in Cocoon but do
not want a full-blown portal - i.e. we want to have some
pages
Antonio Gallardo wrote:
Hi Lezsek:
I will talk about my own experience. We already build 2 fairly
semi-complex forms intensive applications with CForms + JX Template
Generator. The idea is that JXG is used only for some special view
purposes. You prepare the data on a java class and JXT just show
:
[cocoon-deprecated]
-DEBUG- Dependency on avalon-framework exists, no need to add for property
avalonapi.jar.
-INFO- Made directory
[/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040810/test]
-INFO- Enable verbose output, due to 3 previous error(s).
-INFO- Failed with reason
Leszek Gawron dijo:
I have implemented only a few small projects using jxtg and found some
live examples of these limitations:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's responsibility to parse XML. Parse it in
the
Antonio Gallardo wrote:
Leszek Gawron dijo:
I have implemented only a few small projects using jxtg and found some
live examples of these limitations:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
Ugo Cei wrote:
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's responsibility to parse XML.
Leszek Gawron wrote:
Ugo Cei wrote:
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30148.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Antonio Gallardo wrote:
Hi:
I started to upgrade the 2.1.6-dev branch and I don't see the point to
upgrade jars there. I feel myself like doing the same work again. My last
commits were just a copy paste from the 2.2 branch:
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109214252606989w=2
Stefano Mazzocchi [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
I saw this go by on the xml-dev list this morning and my
first thought
was boy, there would be a way to make the sitemap even
harder to work
with. After looking at it closer I'm not sure exactly how
you could
Unico Hommes wrote:
Antonio Gallardo wrote:
I started to upgrade the 2.1.6-dev branch and I don't see the point to
upgrade jars there. I feel myself like doing the same work again. My last
commits were just a copy paste from the 2.2 branch:
Hi,
I have with great interest read just about everything regarding the Cocoon
sentiment of moving away from Excalibur Component Manager.
What strikes me with the proposals 'on the table';
* Spring
* Pico
* Merlin
* Fortress
* Geronimo/GBean
* Custom (Kernel)
is that AFAIU only
This problem relates to the POI block. I was configuring an HSSF
transformation (to Excel) and kept getting a NullPointerException. After
some investigation into the source, I discovered the problem was that
EPStyle was assuming a format was specified and I did not have one in my
gmr:Style. I
Il giorno 10/ago/04, alle 16:05, Niclas Hedhman ha scritto:
1. Is compatibility no longer an issue, and that a Cocoon 3 will
emerge from a
clean slate? Or is a 'gradual' evolution from ECM to something new
still the
preferred approach?
It depends on who you ask. Personally, I tend to prefer a
Niclas Hedhman wrote:
Hi,
I have with great interest read just about everything regarding the Cocoon
sentiment of moving away from Excalibur Component Manager.
What strikes me with the proposals 'on the table';
* Spring
* Pico
* Merlin
* Fortress
* Geronimo/GBean
* Custom (Kernel)
is that
Il giorno 10/ago/04, alle 16:32, Sylvain Wallez ha scritto:
So my personal answer is no. Other people here may have a different
opinion though.
Then please disregard the closing sentence in my previous message ;-)
Ugo
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME
On Tuesday 10 August 2004 22:32, Sylvain Wallez wrote:
FYI, planned features for Merlin in the coming 6-12month period;
* Better JMX integration.
* JMS support.
* JTA support.
* IoC Type 2 and Type 3 dependency resolution.
* JavaBeans/Type2 setter injection of parameter values.
*
Niclas Hedhman wrote:
I know far too little about Spring in general (i.e. never worked with it) and GBeans
in particular (i.e. have not read enough), to be able to provide a good answer.
As for Spring, I think the apparent convergence between Merlin and Spring is based on two different starting
Thanks Carsten,
I'm not sure if I want/need to strip it down or not. What we want is a
normal web site that can also display JSR-168 portlets. We'd like a
common layout across all the pages though. I've just started looking at
this, but it looks like most of the portlet functionality is
On 10 Aug 2004, at 15:05, Niclas Hedhman wrote:
2. Is the Spring/Pico/Kernel camps considering classloading mentioned
above
being a non-issue, and delegating the task to Cocoon itself to deal
with it?
Kernel: Class re-Loading already work through the conceptualization and
implementation of
[EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=30148.
--- Additional Comments From [EMAIL PROTECTED] 2004-08-10 11:01 ---
The bug was fixed in 2.1.4. Carsten kindly replaced any reference to the
StaticBucketMap with a synchronized HashMap (not nice, but it
Hi,
It seems the JCS folks are (now) thinking of preparing a release. Given this will be
their first release, and this change will be in the release, does it seem prudent for
Cocoon to track this change now, and get as much testing time as possible?
regards
Adam
--
Have you Gump'ed your code
Nuno Santos dijo:
JXTG is a nice templating tool, but very limited! Why should we be stuck
to it if we have a more powerfull templating stuck in the scratchpad?
Please, can explain more what we have there? Just curious.
Best Regards,
Antonio Gallardo
Halgurt Mustafa-Ali wrote:
hi,
I am tryong to itegrate OWQL in to the cocoon framework, I implemented a
Transformer for that purpose (see the Attachment please).
The OWQL tool has a method printAnswerAsXML (String reqxml, PrintWriter pw)
do you have an idea how can I convert pw to SAX events?
Leszek Gawron wrote:
Is anybody interested in FreeMarker integration with cocoon? There is no
single word (Oh there are some freemarker occurences but they do not
stick to the subject) about FreeMarker on the cocoon-dev list. It is BSD
style licensed so there is no problem with shipping it with
Leszek Gawron wrote:
Let's imagine we base cocoon on spring. There was a discussion about
including hibernate in cocoon and it failed (licensing). Spring being
ASL 2.0 ships with hibernate library, even if not - it contains code
that was compiled against hibernate interfaces. Wouldn't this be
Just Jelly!
It has all functionality that JXTG gives you, plus the fact that you can
build your own tags either as classes or as macros!
On Tue, 2004-08-10 at 16:14, Antonio Gallardo wrote:
Nuno Santos dijo:
JXTG is a nice templating tool, but very limited! Why should we be stuck
to it if
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
rules:
view cannot modify the model
view cannot perform computations upon dependent data values
view cannot compare dependent data values
view cannot
Craig,
There is a sample RequestListener in the src/Samples directory. It isn't
particularly useful, but it is a start. To enable the request listener
add the following to cocoon.xconf:
component class=com.whatever.MyServletRequestListener
logger=core.manager.listener
Hi:
I am trying to build a xul hello world sample. The problem is I need to
setup this doctype using the XML Serializer:
!DOCTYPE window
and I don't know how to manipulate that.
please help.
Best Regards,
Antonio Gallardo
Hunsberger, Peter
Hunsberger, Peter writes:
Sylvain Wallez [EMAIL PROTECTED] asks:
sniporiginal problem description/snip
I went as far as adding my wrapper class to the jar that
contains the
base XSLTProcessor but no matter what I do Cocoon gives:
Vadim Gritsenko wrote:
Though job. The lazy way would be to use a PipeStream to
pipe the content written to the PrintWriter to a SAX parser
running in another thread. That's likely to course trouble
in some circumstances.
I don't see anything lazy about this :)
IMHO, lazy way is to use
Antonio Gallardo wrote:
Hi:
I am trying to build a xul hello world sample. The problem is I need to
setup this doctype using the XML Serializer:
!DOCTYPE window
and I don't know how to manipulate that.
please help.
What about declaring a XUL serializer in the sitemap with the proper
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30046.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
rules:
view cannot modify the model
view cannot perform computations upon dependent data values
view cannot compare dependent
Niclas Hedhman wrote:
On Tuesday 10 August 2004 22:55, Sylvain Wallez wrote:
Niclas Hedhman wrote:
I know far too little about Spring in general (i.e. never worked with it)
and GBeans in particular (i.e. have not read enough), to be able to
provide a good answer.
As for Spring, I think the
Leszek Gawron wrote:
Joerg Heinicke wrote:
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
snip
Jrg
I'll read the document and have more comments tomorrow.
Browsing over the PDF, ahh,
Stefano Mazzocchi wrote:
Leszek Gawron wrote:
Let's imagine we base cocoon on spring. There was a discussion about
including hibernate in cocoon and it failed (licensing). Spring being
ASL 2.0 ships with hibernate library, even if not - it contains code
that was compiled against hibernate
On Wednesday 11 August 2004 04:22, Sylvain Wallez wrote:
Although this is very good from a robustness point of view, I don't feel
at ease with this as it requires to somehow manage dependencies twice:
in the model where they have to be formally expressed, and in the code
where actual lookup
57 matches
Mail list logo
