Sylvain Wallez wrote:
After looking carefully, the interpreter must be SingleThreaded, even if
thread safe...
This is because although an intepreter can handle concurrent requests,
each sitemap must have a different instance, since the interpreter holds
the scripts defined in a
Hi,
if you have a patch, I really would like to have a look at it.
Thanks
Carsten
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Yannick Menager
Sent: Monday, October 20, 2003 7:03 PM
To: [EMAIL PROTECTED]
Subject: RoleFilterTransformer and authentication-fw
Sylvain Wallez wrote:
After looking carefully, the interpreter must be SingleThreaded, even if
thread safe...
This is because although an intepreter can handle concurrent requests,
each sitemap must have a different instance, since the interpreter holds
the scripts defined in a map:flow
From: Ugo Cei
[Is a vote needed before changing a public interface, even if
it's in an
unstable block?
I don't think a vote is needed.
And, by the way, where are the rules detailing what
needs a vode and what doesn't?]
Don't know :-(
Steven, do you have a pointer for us?
I'd like
Ok, I think we have enough votes with +(0), I didn't count a -1 for
this order of execution:
- MIME type declared on the reader instance
- MIME type declared for the reader component
- Ask the Reader for a MIME type. A *.doc reader could peek
into the file
and return either text/plain or
Sylvain Wallez wrote:
I am strongly -1 to resolve relative URIs relatively to the position of
a component in the container hierarchy.
I totally agree here.
SNIP/
IMO, we must keep the current behaviour. This allows all components to
automatically adapt to the mount point of the current
Hi,
I just reverted the change. The behaviour now should be as you
descripe it. But this means, that you get your NPE again if you
don't take care of it.
Carsten
-Original Message-
From: Tuomo L [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 9:14 AM
To: [EMAIL
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=23921.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Ugo Cei wrote:
Sylvain Wallez wrote:
After looking carefully, the interpreter must be SingleThreaded, even
if thread safe...
This is because although an intepreter can handle concurrent
requests, each sitemap must have a different instance, since the
interpreter holds the scripts defined in
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=15843.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Christopher Oliver wrote:
Again I know nothing about Avalon, but there seems to be some
conceptual confusion between Stateless and ThreadSafe. Stateless
objects are of course thread-safe but stateful objects may be also. A
container that automatically turns a ThreadSafe component into a
After (nearly) finishing a project where we implemented our own little
forms frameworks (... we had already started when Woody became part of
Cocoon) I want to share some ideas with you.
To be able to make a comparisons I dived into the current implementation
of Woody. Now I can say that I'm
Ugo Cei wrote:
[Is a vote needed before changing a public interface, even if it's in
an unstable block? And, by the way, where are the rules detailing what
needs a vode and what doesn't?]
I'd like to propose changing the signature of two interface methods:
I use Checkstyle (http://checkstyle.sourceforge.net/)
for our projects.
You could check the formatting of your code and
find bugs as well.
I use it as a plugin in Eclipse.
Juergen
BASF IT Services GmbH
EC-TP - DANHO
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=23625.
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=23625.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Can anyone please give me short hint/pointer why we have
so two classes that look very identical?
Thanks
Carsten
On Tue, 21 Oct 2003, Carsten Ziegeler wrote:
There is one thing we forgot :) Is this a change for 2.2 or for 2.1.x?
This change is (a little bit) incompatible, so it might be a
candidate for 2.2.
Not sure of the status of 2.1 now - is it simply in bugfixing mode, with
all new features in 2.2?
Carsten Ziegeler wrote:
Can anyone please give me short hint/pointer why we have so two classes that look very identical?
FOM_JavaScriptInterpreter is the one that implements the FOM (Flow
Object Model), and the only one that should actually be used.
A good thing would be to remove the current
Thank you!
On Tue, 21 Oct 2003, Carsten Ziegeler wrote:
Hi,
I just reverted the change. The behaviour now should be as you
descripe it. But this means, that you get your NPE again if you
don't take care of it.
Carsten
-Original Message-
From: Tuomo L [mailto:[EMAIL PROTECTED]
On Tue, 2003-10-21 at 11:45, Carsten Ziegeler wrote:
Can anyone please give me short hint/pointer why we have
so two classes that look very identical?
I thought (when looking for a solution to my ClassCastException) that
this was intentional in order to be able to migrate a complete and
[EMAIL PROTECTED] wrote:
cziegeler2003/10/20 06:39:10
Modified:src/java/org/apache/cocoon/servlet CocoonServlet.java
Log:
Making servlet config available via context
A bit out of my league, but now it seems like Bruno was sharing my
trouble in understanding, too, so here's my:
Carsten Ziegeler wrote:
Ok, I think we have enough votes with +(0), I didn't count a -1 for
this order of execution:
- MIME type declared on the reader instance
- MIME type declared for the reader component
- Ask the Reader for a MIME type. A *.doc reader could peek
into the file
and
From: Carsten Ziegeler
Can anyone please give me short hint/pointer why we have
so two classes that look very identical?
The Javascript-Interpreter is the *old* one that doesn't implement the
later introduced FOM. For compatibility reasons I haven't deleted it yet
although it has never been
Reinhard Poetz wrote:
From: Carsten Ziegeler
Can anyone please give me short hint/pointer why we have
so two classes that look very identical?
The Javascript-Interpreter is the *old* one that doesn't implement the
later introduced FOM. For compatibility reasons I haven't deleted it yet
Steven Noels wrote:
[EMAIL PROTECTED] wrote:
cziegeler2003/10/20 06:39:10
Modified:src/java/org/apache/cocoon/servlet CocoonServlet.java
Log:
Making servlet config available via context
A bit out of my league, but now it seems like Bruno was sharing my
trouble in
From which version did you upgrade? Did you read the
updating instructions?
Carsten
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 11:31 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Portal framework and new Cocoon 2.1.2
Sylvain Wallez wrote:
Can you explain in more details what's the purpose of the jxpathContext
here and where its value come from? Adding a dependency on JXPath so
high in Woody interfaces doesn't seem good to me.
The value comes from WoodyTemplateTransformer:
Object flowContext =
Hello Carsten,
From 2.1-dev (April or June 2003 I think).
No, I didn't read them. Where could I find these instructions?
Regards
Sylvain
-Message d'origine-
De: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Date: mardi, 21. octobre 2003 12:11
À: [EMAIL PROTECTED]
Objet: RE: Portal
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=23796.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
It's in the installing section of the cocoon docs.
Carsten
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 12:45 PM
To: [EMAIL PROTECTED]
Subject: RE: Portal framework and new Cocoon 2.1.2
Hello Carsten,
From 2.1-dev (April
Ugo Cei wrote:
Sylvain Wallez wrote:
Can you explain in more details what's the purpose of the
jxpathContext here and where its value come from? Adding a dependency
on JXPath so high in Woody interfaces doesn't seem good to me.
The value comes from WoodyTemplateTransformer:
Object
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=23855.
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=23700.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Steven Noels wrote:
A bit out of my league, but now it seems like Bruno was sharing my
trouble in understanding, too, so here's my: why?
No problem, it's allowed to ask :)
Now, according to the GT panel, I could answer with Why not?...
No, this was regarded as 'not
Steven Noels wrote:
A bit out of my league, but now it seems like Bruno was sharing my
trouble in understanding, too, so here's my: why?
No problem, it's allowed to ask :)
Now, according to the GT panel, I could answer with Why not?...
No, this was regarded as 'not being a
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=10277.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Steven Noels wrote:
If others are happy, I'm perfectly fine with this. It just felt as being
too much of a core change to be silently injected into the CVS commit
mails stream without prior notification/discussion on the list.
You are joking, aren't you? This is not a
Tuomo L wrote:
Answering to my own question: I had an error in the build file, and the
jar file was constructed with a wrong directory sctructure. It's ok now.
Sorry for this! :|
Also don't forget that classes/ is loaded before lib/ so be sure to
remove your old versions from WEB-INF/classes or
Sylvain Wallez wrote:
Ok, I understand. I encountered a somehow similar problem and came to
the conclusion that what we need is actually to have wd:selection-list
a pluggable component.
snip/
What do you think?
I think that what you're proposing looks interesting and certainly more
elegant than
Steven Noels wrote:
Carsten Ziegeler wrote:
Steven Noels wrote:
If others are happy, I'm perfectly fine with this. It just felt
as being
too much of a core change to be silently injected into the CVS commit
mails stream without prior notification/discussion on the list.
You are
Christopher Oliver wrote:
Again I know nothing about Avalon, but there seems to be some conceptual
confusion between Stateless and ThreadSafe. Stateless objects are of
course thread-safe but stateful objects may be also. A container that
automatically turns a ThreadSafe component into a
Tuomo L wrote:
Hi,
I used to have all my custom components in WEB-INF/classes which worked
fine, but now that my project grows, I packed them up in a jar and dropped
the whole thing in WEB-INF/lib. It just doesn't work anymore. I tried using
ParanoidServlet and that init-classloader parameter
Carsten,
I have found this change description in the Cocoon 2.1.2 doc about the portal below
but it doesn't help me a lot.
Session, Authentication and Portal:
The session framework (sunShine), the authentication framework (sunRise) and the
portal framework (sunSpot) are now blocks
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=23700.
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=23700.
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=23299.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
doable? digest this first
http://citeseer.nj.nec.com/sun98operational.html
Ok; this is going to sound silly, I know.
I was thinking of sending keystrokes to different span's when a message is catched by
the HTTP call. Should be easy enough. Next would be an algorithm that is able of
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=23299.
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=23299.
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=23299.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Ugo Cei wrote:
Sylvain Wallez wrote:
Ok, I understand. I encountered a somehow similar problem and came to
the conclusion that what we need is actually to have
wd:selection-list a pluggable component.
snip/
What do you think?
I think that what you're proposing looks interesting and
[EMAIL PROTECTED] wrote:
The transformer namespace has changed from
http://cocoon.apache.org/sunshine/1.0 to
http://apache.org/cocoon/session/1.0 and the context names have
changed from sunshine to session and from sunrise to authentication.
I only find namespace
like
Joerg Heinicke wrote:
Reinhard Poetz wrote:
From: Carsten Ziegeler
Can anyone please give me short hint/pointer why we have
so two classes that look very identical?
The Javascript-Interpreter is the *old* one that doesn't implement the
later introduced FOM. For compatibility
Carsten,
That was the problem!
Thanks for your help.
Regards
Sylvain
-Message d'origine-
De: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Date: mardi, 21. octobre 2003 15:31
À: [EMAIL PROTECTED]
Objet: RE: Portal framework and new Cocoon 2.1.2
[EMAIL PROTECTED] wrote:
The
Sylvain Wallez wrote:
Mmmh... as I also need this for my current project, let's make a deal: I
componentize selection-list in the coming days, not later than the end
of this week, so you can use it for your FlowJXPathSelectionList.
How does it sound?
It sounds like an offer I cannot refuse ;-).
I had the same problem - as the mocks are missing, this block
is excluded by default, so you don't get build problems
using ant. Only with Eclipse you have the problem, I removed
by hand the jms block from the source list of Eclipse.
But yes, adding mocks is a better way!
Carsten
-Original
Carsten Ziegeler wrote:
Ok, sorry I'm currently doing way too many things at the same time, which
results in such comments. I think I need vacation...
Oh - no need for feeling sorry, Carsten.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source
Steven Noels wrote:
Carsten Ziegeler wrote:
Ok, sorry I'm currently doing way too many things at the same time, which
results in such comments. I think I need vacation...
Oh - no need for feeling sorry, Carsten.
You guys might want to doublecheck what I did just now to CocoonServlet.
--
They
Carsten Ziegeler wrote:
I had the same problem - as the mocks are missing, this block is excluded by default, so you don't get build problems using ant.
Ah, ok. But it is a bad thing to have code that's not compiled in the
default build...
Only with Eclipse you have the problem, I removed by
Sylvain Wallez wrote:
Hi team,
Today I did a fresh build eclipse-project, and found that the JMS
block doesn't compile because there are no javax.jms mock classes.
Am I missing something?
No, that's why the jms block is disabled by default. When Chris first
committed the jms block there was
Hi team,
I'd like to add the use of leniency to JXPath expressions in
JXTemplateGenerator: currently, if a path does not exist, a nice
exception is thrown. This may be good in some circumstances (avoids
endless hair pulling sessions to finally discover a small typo), but is
also required in
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=23700.
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=23969.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I had the same problem - as the mocks are missing, this block is
excluded by default, so you don't get build problems using ant.
Ah, ok. But it is a bad thing to have code that's not compiled in the
default build...
Only with Eclipse you have the
Berin Loritsch wrote:
You guys might want to doublecheck what I did just now to CocoonServlet.
Afaik, you are callen setProperty for each context information, right?
My version of the CocoonBean currently has no setProperty method,
so I stay curious :)
Carsten
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=23700.
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=23700.
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=23700.
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=23969.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Michael Hartle wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I had the same problem - as the mocks are missing, this block is
excluded by default, so you don't get build problems using ant.
Ah, ok. But it is a bad thing to have code that's not compiled in the
default build...
Only
For my application I am writing an XMLDB transformer. Any such thing
already? Anyone have any requests for functionality?
--
Javier del Gesu - [EMAIL PROTECTED]
Sylvain Wallez wrote:
Michael Hartle wrote:
Just a question, those mock classes, are they created manually or do
you already use some tool to generate them ?
In order to be compliant with the licence, they should
_theroretically_ be written by hand from a publicly available
information such
Sylvain Wallez wrote:
Michael Hartle wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I had the same problem - as the mocks are missing, this block is
excluded by default, so you don't get build problems using ant.
Ah, ok. But it is a bad thing to have code that's not compiled in the
Michael Hartle wrote:
Sylvain Wallez wrote:
Michael Hartle wrote:
Just a question, those mock classes, are they created manually or do
you already use some tool to generate them ?
In order to be compliant with the licence, they should
_theroretically_ be written by hand from a publicly
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=23949.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I would like to make the following changes to the 2.1 repo and will go
ahead if noone objects (as soon I find some time):
-Creating a repository block and moving there all source interfaces not
part of excalibur's sourceresolve package.
-Moving there the SourceInspector interface and
Joerg Heinicke wrote:
No one really missed it until now
This isn't quite correct. :-)
However, it isn't actually a really incompatible change, at least
for the provided Reader classes, it just adds a feature.
J.Pietschmann
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=23796.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Guido Casper wrote:
I would like to make the following changes to the 2.1 repo and will go
ahead if noone objects (as soon I find some time):
-Creating a repository block and moving there all source interfaces
not
part of excalibur's sourceresolve package.
+1
-Moving there the
Geoff, all,
I'm very sorry I haven't followed up on this issue. It's just that I
have started a new job last thursday and it's currently eating up a lot
time :-| Good news is, I'm working with Cocoon :-)
Geoff Howard wrote:
So, anyone have an opinion on including the Geronimo jms jar? It's at
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=23796.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Unico Hommes [EMAIL PROTECTED] wrote:
Guido Casper wrote:
I would like to make the following changes to the 2.1 repo and will
go ahead if noone objects (as soon I find some time):
-Creating a repository block and moving there all source interfaces
not part of excalibur's sourceresolve
On 21 Oct 2003 13:23:49 -
[EMAIL PROTECTED] wrote:
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=23299.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN
Stefano Mazzocchi wrote:
On Monday, Oct 20, 2003, at 14:07 Europe/Rome, Arje Cahn wrote:
I'm dreaming of an open source-Javascript
based-crossbrowser-SubEthaEdit-kinda editing tool.
MultiLinotype?
If we put the document inside a 'contenteditable' field, and let some
Mozilla/IE compatible
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I use Checkstyle (http://checkstyle.sourceforge.net/)
for our projects.
You could check the formatting of your code and
find bugs as well.
I use it as a plugin in Eclipse.
which one?
You could download the plugin at:
Sylvain Wallez wrote:
Go to http://java.sun.com/products/jms/docs.html then click on the
continue button below Download the version 1.1 API... and read
section 2 of the licence: you may not modify, decompile, or reverse
engineer Software.
Auto-generating mocks from a jar file definitely looks
Reinhard Poetz wrote:
After (nearly) finishing a project where we implemented our own little
forms frameworks (... we had already started when Woody became part of
Cocoon) I want to share some ideas with you.
..another one ;)
snip/
The global widget repository contains widgets that can be
On Tuesday, Oct 21, 2003, at 23:19 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
On Monday, Oct 20, 2003, at 14:07 Europe/Rome, Arje Cahn wrote:
I'm dreaming of an open source-Javascript
based-crossbrowser-SubEthaEdit-kinda editing tool.
MultiLinotype?
If we put the document inside a
On Tuesday, Oct 21, 2003, at 15:19 Europe/Rome, Arje Cahn wrote:
doable? digest this first
http://citeseer.nj.nec.com/sun98operational.html
Ok; this is going to sound silly, I know.
I was thinking of sending keystrokes to different span's when a
message is catched by the HTTP call. Should
oops, it actually does have a serializer which i accidentally clipped off
when removing an extraneous transform
-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Monday, October 20, 2003 6:10 PM
To: [EMAIL PROTECTED]
Subject: RE: NPE While Redirecting
One
Hello,
I'm using the portal framework for almost one year and I have just updated my
application to Cocoon 2.1.2 last stable release.
My problem is that now the Save function in Customize doesn't work anymore. The
user-profile file is not updated anymore.
If There is already a profile for a
I have obtained cocoon-2.2 from the cvs repository.
When I attempt to do a build I receive 63 errors. The first is:
[javac]
C:\cocoon-2.2\src\java\org\apache\cocoon\components\language\generator\GeneratorSelector.java:79:
cannot resolve symbol [javac] symbol : class
93 matches
Mail list logo
