But seriously: I tried to explain why you cannot
remove the parent continuation :-)
some experiments showed me that it is possible to remove parent
continuations in flowscript.
Hm... if the flowscript implementation only stores
modifications this should not be possible :-/
One
Le 11 mai 05, à 21:10, Sebastien Arbogast a écrit :
...So WDYT ? Stefano ? Bertrand ? Sylvain ? Upayavira ? Helma ? Others
I
forgot ? ...
My position has not changed: I think our documentation tools are
adequate today (I didn't say perfect), see [1].
But if people don't contribute
...I've been thinking about ways we can keep documentation current:
* It strikes me that folksonomy offers developer communities some help
here. If documentation can be continuously re-tagged then it's
usefulness will evolve...
This is maybe the one tool that we're missing: a way to add
Le 12 mai 05, à 06:33, Sebastien Arbogast a écrit :
...FYI we have already come up with 13 very interesting ideas about a
potention new common documentation effort for Cocoon..
Would you guys be able to at least try writing/reorganizing some docs
in the current system [1] before inventing
Bertrand Delacretaz wrote:
Le 12 mai 05, à 06:33, Sebastien Arbogast a écrit :
...FYI we have already come up with 13 very interesting ideas about a
potention new common documentation effort for Cocoon..
Would you guys be able to at least try writing/reorganizing some docs in
the current system
You gonna do this with a Yahoo poll? Seems like a lot of work to
manually tabulate this. But I'd be interested in the results.
Ralph
Mark Leicester wrote:
Hi everyone,
Here is a first draft of a questionnaire that I intend to distribute
on the Cocoon Users' and Developers' mailing lists
Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
is there a common line width to be kept? 78 characters in one line
is hell of a readability problem and a little bit archaic.
WDYT?
+1, I use 150 :-)
me too :) eclipse creates a total mess when formatting the code with
78
Ralph Goers wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
is there a common line width to be kept? 78 characters in one line
is hell of a readability problem and a little bit archaic.
WDYT?
+1, I use 150 :-)
me too :) eclipse creates a total mess when formatting the
But if people don't contribute content/reviews/reorganization, nothing
happens. More tools with no one to use them won't bring anything, in
the end someone has to do the work and this is not happening ATM.
But if people don't contribute content/reviews/reorganization I see
two conclusions to
Nathaniel Alfred wrote:
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 11. Mai 2005 18:04
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
Joerg Heinicke wrote:
Sylvain Wallez sylvain at apache.org writes:
It suddenly dawned on me that the code below is synchronizing on the
session, not a local object. Duh! Still, this seems like a very, very
bad idea to me, as I'm not sure how that would impact the servlet container.
public Session getSession(boolean create) {
// we must assure a 1:1-mapping
Daniel Fagerstrom wrote:
In the current #{$cocoon/request/request/protocol} thread we (again)
discuss problems with the environment access in JXTG. The problems
comes from that we have copied part of the servlet api in our
environment abstraction and that it contains methods of the type
Object
I ran through this thread and made some observations:
1. There can only be one Cocoon Session per HttpSession. Creation of
this must be thread safe.
2. The code propsed will not work:
public Session getSession(boolean create) {
// we must assure a 1:1-mapping of server session to cocoon
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
and why producing SAX events is a mixing of concerns?
It would not nececarilly be a mix of concern, but in CForms it IMO is
because the Widget mainly is about content in the form of Java data
structures, but it also make
I have the need for using form macros but my application doesn't use flowscript
as controller. AFAICS
line 11: jx:set var=form value=${CocoonFormsInstance}/
makes it impossible to access the form object as my controller (an action)
doesn't set the variable CocoonFormsInstance. Is there any way
Reinhard Poetz wrote:
I have the need for using form macros but my application doesn't use
flowscript as controller. AFAICS
line 11: jx:set var=form value=${CocoonFormsInstance}/
makes it impossible to access the form object as my controller (an
action) doesn't set the variable
Ralph Goers Ralph.Goers at dslextreme.com writes:
serverSession is a local variable. Synchronizing it accomplishes nothing
since every caller gets their own copy. Sytnchronizing on a member of
the HttpRequest object also accomplishes nothing.
Huh? Why shall synchronization not work? It is
Sylvain Wallez sylvain at apache.org writes:
This approach has the problem of entering a synchronized block each time
getSession is called. Although this may not that be much a problem in
this particular case because it's unlikely that many parallel requests
exist for a single request, we
Sylvain Wallez sylvain at apache.org writes:
Or more simply we could store the wrapper in the session itself using an
attribute. That way it would be guaranteed to be created only once.
Yes, that's another possibility I also had in mind. But on the one hand
this smells a bit
Does it answer your need?
Yes it does, thank you!
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
Bart.
I'd come earlier if we start earlier. :-) (after all it is just a two
hours drive from here).
Speaking of a location:
The KDE people were at the Filmakademie Ludwigsburg
(http://www.filmakademie.de/) for their last KDE summit (which is quite
close to Stuttgart). They even got some support from
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=33637.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
Sylvain Wallez sylvain at apache.org writes:
Or more simply we could store the wrapper in the session itself using an
attribute. That way it would be guaranteed to be created only once.
Yes, that's another possibility I also had in mind. But on the one
-Original Message-
From: Sebastien Arbogast [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 11. Mai 2005 23:16
To: dev@cocoon.apache.org
Subject: Re: Community health
Personally I think of mailing lists as really old-fashioned ways of
communicate, all the more so as they are more and more often
Can it be that difficult to stream a string as SAX events in JXTemplate, or did
I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a streamer object to JXTemplate
- assign this object to a variable
- call the toSAX method and pass the content
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in JXTemplate,
or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a streamer object to JXTemplate
- assign this object to a variable
- call the toSAX method and
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in
JXTemplate, or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a streamer object to JXTemplate
- assign this object to a variable
-
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in
JXTemplate, or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a streamer object to JXTemplate
- assign this
As explained in a private mail to Sebastien, I've taken up the
http://www.cocoondev.org/handbook site that Steven graciously set up for me. I
intend to work on the mid-level tutorial that was the initial goal for the
Cocoon In Action project.
Doing it in Daisy is much easier for me, since it
Leszek Gawron wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
If you want to make it even simpler we could either have another
instruction that parses strings to SAX, or have some attribute on
jx:out for parsing the argument.
jx:out value=${str} xmlize=true/ ? Almost one liner.. some users
Leszek Gawron wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in
JXTemplate, or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a streamer object to
Linden H van der (MI) wrote:
As explained in a private mail to Sebastien, I've taken up the http://www.cocoondev.org/handbook site that Steven graciously set up for me. I intend to work on the mid-level tutorial that was the initial goal for the Cocoon In Action project.
Doing it in Daisy is much
Sylvain Wallez wrote:
Leszek Gawron wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in
JXTemplate, or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a
Sylvain Wallez wrote:
Leszek Gawron wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in
JXTemplate, or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
If you want to make it even simpler we could either have another
instruction that parses strings to SAX, or have some attribute on
jx:out for parsing the argument.
jx:out value=${str} xmlize=true/ ? Almost
Daniel Fagerstrom wrote:
Agree, but we should implement them first ;)
one question only:
what do we do with
jx:out value=roottagbroken/mispelledtag/root parse=xml/
1. generate SAX events - if value is invalid this breaks the whole view
2. parse to DOM, catch exceptions, use @lenient to throw or
Sylvain Wallez wrote:
or even better: jx:out value=${str} xmlize=true strip-root=true/
Ahem... back to another hot thread: would be good to update the docs to
mention these two little attributes I wasn't aware of and can be s
useful.
I think they haven't been implemented yet, at least if I
Il giorno 12/mag/05, alle 14:08, Leszek Gawron ha scritto:
what do we do with
jx:out value=roottagbroken/mispelledtag/root parse=xml/
1. generate SAX events - if value is invalid this breaks the whole view
2. parse to DOM, catch exceptions, use @lenient to throw or silently
omit.
Either 1 or give
Ugo Cei wrote:
Il giorno 12/mag/05, alle 14:08, Leszek Gawron ha scritto:
what do we do with
jx:out value=roottagbroken/mispelledtag/root parse=xml/
1. generate SAX events - if value is invalid this breaks the whole view
2. parse to DOM, catch exceptions, use @lenient to throw or silently
omit.
Ugo Cei wrote:
Il giorno 12/mag/05, alle 14:08, Leszek Gawron ha scritto:
what do we do with
jx:out value=roottagbroken/mispelledtag/root parse=xml/
1. generate SAX events - if value is invalid this breaks the whole view
2. parse to DOM, catch exceptions, use @lenient to throw or silently
omit.
Sylvain Wallez sylvain at apache.org writes:
This solution looks really cool and elegant. Unfortunately
HttpSessionActivationListener is Servlet Spec 2.3. In Cocoon 2.1. we are
still on 2.2 and I guess (and suggest) we will stay with that. So only the
WeakHashMap solution remains.
2.2,
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
or even better: jx:out value=${str} xmlize=true strip-root=true/
xinclude has parse attribute:
jx:out value=${str} parse=xml/
where parse is either text or xml.
what about @strip-root attribute? Is there an equivalent?
No :-)
As explained in a private mail to Sebastien, I've taken up the
http://www.cocoondev.org/handbook site that Steven
graciously set up for me. I intend to work on the mid-level
tutorial that was the initial goal for the Cocoon In Action project.
Doing it in Daisy is much easier for me, since
On 12 May 2005, at 14:01, Sylvain Wallez wrote:
Linden H van der (MI) wrote:
As explained in a private mail to Sebastien, I've taken up the
http://www.cocoondev.org/handbook site that Steven graciously set up
for me. I intend to work on the mid-level tutorial that was the
initial goal for the
Leszek Gawron wrote:
Sylvain Wallez wrote:
Ahem... back to another hot thread: would be good to update the docs
to mention these two little attributes I wasn't aware of and can be
s useful.
not implemented yet :)) I will commit that ASAP.
Oooops, sorry!! I though it was already there!!!
Linden H van der (MI) wrote:
As explained in a private mail to Sebastien, I've taken up the http://www.cocoondev.org/handbook site that Steven graciously set up for me. I intend to work on the mid-level tutorial that was the initial goal for the Cocoon In Action project.
Doing it in Daisy is much
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Donnerstag, 12. Mai 2005 11:16
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
I have an implementation with map in HttpRequest and without
double-checked
Well, I still have a little problem. Your solution works fine, as long
as I add submit widgets to the form definition. This works fine for many
case for me, but I still have a case where this isn't a solution.
I have a form, and on that form there are two date fields, and an update
action. Every
Hi Bertrand,
I for one have been looking at the wiki regularly, making little tweaks
here and there: nothing major, but it's a regular haunt of mine. You
can verify this at: http://wiki.apache.org/cocoon/RecentChanges
(Sébastien seems to have contributed a fair bit recently too!)
Back when
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Can you elaborate? What should be the view model
The view model should IMO be a (minimal) read only subset of
o.a.c.forms.formmodel.Widget and ContainerWidget, preferably POJO
friendly. From such a view point the widget hierarchy is a simple
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
As Vadim pointed out in an earlier discussion this is done in Java
faces:
http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/api/javax/faces/context/ExternalContext.html
So what I propose is that we extend o.a.c.environment.Request with:
Map
On 10 May 2005, at 19:20, Mark Leicester wrote:
Steven, it occurs to me that Drupal may be well suited to the CocoonGT
site. Drupal offers ecommerce modules (Worldpay, Paypal, invoicing
etc.) and plenty of people have used Drupal for exactly this kind of
purpose (see
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
In the current #{$cocoon/request/request/protocol} thread we (again)
discuss problems with the environment access in JXTG. The problems
comes from that we have copied part of the servlet api in our
environment abstraction and that it contains
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
Depending on how it's done, it can be a good thing. IMHO,
public XMLizable getLabel();
seems like a right approach to me; and templating language should be
more than happy to work with XMLizable objects, so to render a label
you don't need
Mark Leicester wrote:
Hi Bertrand,
I for one have been looking at the wiki regularly, making little
tweaks here and there: nothing major, but it's a regular haunt of
mine. You can verify this at:
http://wiki.apache.org/cocoon/RecentChanges (Sébastien seems to have
contributed a fair bit
Great! Thanks for the offer, but let's wait until there is more than one
or two pages of information.
Bye, Helma
-Original Message-
From: Ross Gardler [mailto:[EMAIL PROTECTED]
Sent: Thursday, 12 May, 2005 14:48
To: dev@cocoon.apache.org
Subject: Re: Cocoon documentation (was: RE:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
In the current #{$cocoon/request/request/protocol} thread we (again)
discuss problems with the environment access in JXTG. The problems
comes from that we have copied part of the servlet api in our
environment abstraction
Sebastien Arbogast wrote:
Can it be shown that this downward trend is not a result of improving
documentation?
Or maybe it's because the documentation is still so messy (I'm sure
it's going to change with the new effort but it's still the case) that
more and more people try Cocoon, don't
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
Depending on how it's done, it can be a good thing. IMHO,
public XMLizable getLabel();
seems like a right approach to me; and templating language should be
more than happy to work with XMLizable objects, so to render a
On 12 May 2005, at 15:56, Sylvain Wallez wrote:
- inline WYSIWYS (what you see is what you structure, i.e. htmlarea or
something similar, but no wiki or XML syntax)
Check.
- version management, so that validated content can be published on
cocoon.apache.org while newer versions are being written
Steven Noels wrote:
On 12 May 2005, at 15:56, Sylvain Wallez wrote:
- inline WYSIWYS (what you see is what you structure, i.e. htmlarea or
something similar, but no wiki or XML syntax)
Check.
- version management, so that validated content can be published on
cocoon.apache.org while newer
To simplify and make the environment handling in flow, jxtg, modules and
possibly other places more coherent, I propose that we extend the Cocoon
environment apis with some utility methods that makes the environment
more reflection friendly. See
Messy or poor documentation is a reason why some open-source software
around here at my new job (a large regional medical care network) gets
disqualified from use. If it takes the devs around here too long to
figure out how to use it, out the door it goes.
And it's totally normal because the
More specifically I propose is that we extend
o.a.c.environment.Request with:
Map getAttributes();
Map getParameters();
Map getHeaders();
and o.a.c.environment.Session and o.a.c.environment.Context with:
Map getAttributes();
[+1] Go ahead and implement the environment extensions proposed
Daniel Fagerstrom wrote:
To simplify and make the environment handling in flow, jxtg, modules and
possibly other places more coherent, I propose that we extend the Cocoon
environment apis with some utility methods that makes the environment
more reflection friendly. See
Niclas Hedhman wrote:
On Thursday 12 May 2005 10:56, Stefano Mazzocchi wrote:
So, stop wasting your words ranting and tell me how you would solve the
problems we have if you had commit access.
Although I sympathize with your situation, but the 'tone' is a bit harsh,
wouldn't you say.
FYI, approx
Steven Noels wrote:
On 12 May 2005, at 15:56, Sylvain Wallez wrote:
- inline WYSIWYS (what you see is what you structure, i.e. htmlarea
or something similar, but no wiki or XML syntax)
Check.
- version management, so that validated content can be published on
cocoon.apache.org while newer
Linden H van der (MI) wrote:
As explained in a private mail to Sebastien, I've taken up the http://www.cocoondev.org/handbook site that Steven graciously set up for me. I intend to work on the mid-level tutorial that was the initial goal for the Cocoon In Action project.
Doing it in Daisy is much
On 12 May 2005, at 16:36, Upayavira wrote:
To validate whether a document should be published, i.e. to review it,
which involves clearly seeing what the author changed.
Check.
A document has been updated:
http://cocoondev.org/daisydocs-1_3/37
Document ID: 37
Branch: daisydocs-1_3
Language: en
Such management tools should allow people that have the responsibility
to validate and publish content on the website to quickly grasp the job
they have to do. For example, I may want to have a quick look at all
changed documents that have the forms flowscript or sitemap tags,
without having
Sebastien Arbogast wrote:
snip
And have you tried, Cocoon/Hibernate/Spring designed with AndroMDA ?
This is wonderful the time you save. You just compile your UML model,
write your business methods, create your forms, templates and
flowscript and there you go. It's high-level, it's wonderful... as
Mark Leicester wrote:
I think you are right, I probably have dismissed the existing stuff a
bit early. In that case, I pledge to keep in touch with the current
effort. I certainly value ongoing dialogue. However, I wonder out loud:
should we be putting documentation behind the barrier of
Sebastien Arbogast wrote:
Such management tools should allow people that have the responsibility
to validate and publish content on the website to quickly grasp the job
they have to do. For example, I may want to have a quick look at all
changed documents that have the forms flowscript or sitemap
Hi,
I'm currently developing a website which has some forms and of course
I'm using CForms (2.1.7). The webapp uses the XHTML serializer (XHTML
1.0 transitional) and this breaks completely the rendering of forms (at
least using Firefox). if I use the HTML serializer, forms are displayed
OK but
Steven Noels wrote:
On 12 May 2005, at 16:36, Upayavira wrote:
...
I was just chatting with Sylvain about this. We don't have time to
create an xdocs export for Daisy, but if all goes well, we'll be doing
Daisy Books (aggregation and book-like publishing) over summer. Those
would target XSL-FO
http://www.mail-archive.com/dev@cocoon.apache.org/msg05839.html
http://marc.theaimsgroup.com/?t=11056873003r=1w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106691291922337w=2
Thanks for the link, we gonna use it as an idea-source.
There is very little that you guys said that hasn't
Sebastien Arbogast wrote:
Such management tools should allow people that have the responsibility
to validate and publish content on the website to quickly grasp the job
they have to do. For example, I may want to have a quick look at all
changed documents that have the forms flowscript or sitemap
Ugo Cei wrote:
Hi,
I'm currently developing a website which has some forms and of course
I'm using CForms (2.1.7). The webapp uses the XHTML serializer (XHTML
1.0 transitional) and this breaks completely the rendering of forms
(at least using Firefox). if I use the HTML serializer, forms are
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
The case of parameters however should be considered carefully, as
ServletRequest provides getParameterMap() since servlet 2.4 (or 2.3?).
Having it named getParameter() in our environment may be confusing for
people used to the servlet API.
That
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
As Vadim pointed out in an earlier discussion this is done in Java
faces:
http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/api/javax/faces/context/ExternalContext.html
So what I propose is that we extend
Tony Collen wrote:
I asked, Why don't we just use Castor XML?, but the main arguments I
got were A two-step process isn't neccesarily bad and Castor's
documentation was bad. Perhaps I should have asked why we were using
XML to interface with Oracle in the first place ;)
Answer: This part of
Bart Molenkamp wrote:
Well, I still have a little problem. Your solution works fine, as long
as I add submit widgets to the form definition. This works fine for many
case for me, but I still have a case where this isn't a solution.
I have a form, and on that form there are two date fields, and an
Stefano Mazzocchi wrote:
I like the notion of
daisy - forrest - out
makes very good sense.
Now we just need to find a way to automate a little that workflow, but
without introducing security vulnerabilities.
How about this (bullet summaries followed by textual description.
Daisy as editing
Nathaniel Alfred Alfred.Nathaniel at swx.com writes:
I think there is a memory leak in
http://svn.apache.org/viewcvs?rev=169806view=rev.
There is a strong reference session.wrappedSession from value to key in
// create new wrapper
session = new
hi,
encountered the same problem. my rough idea, before also switching to
the html serializer, was that somehow the order of stuff in head seems
to be important, and using cforms the stylesheets wildly mixed links
and scripts.
Ugo Cei schrieb:
Hi,
I'm currently developing a website which has
Daniel Fagerstrom wrote:
To simplify and make the environment handling in flow, jxtg, modules and
possibly other places more coherent, I propose that we extend the Cocoon
environment apis with some utility methods that makes the environment
more reflection friendly. See
Reinhard Poetz wrote:
Maybe we should talk about our goals for the Blockathon first. From my POV
these
are:
- What's a block?
- What's Cocoon core?
- How to implement real blocks? Consider different alternatives like
Eclipse OSGi implementation, Pier's kernel, etc. talk
[+1 ] Go ahead and implement the environment extensions proposed above.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Daniel Fagerstrom wrote:
More specifically I propose is that we extend o.a.c.environment.Request
with:
Map getAttributes();
Map getParameters();
Map getHeaders();
What about cookies? (There is Map getCookieMap() but naming convention is
different).
and o.a.c.environment.Session and
Le 12 mai 05, à 16:48, Daniel Fagerstrom a écrit :
[+1 ] Go ahead and implement the environment extensions proposed above.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Le 12 mai 05, à 15:04, Mark Leicester a écrit :
...As I said above, over the next few weeks I'll attempt to
demonstrate what I imagine to be the myriad of potential benefits of
the Drupal approach...
Sounds interesting - I'll stay tuned!
-Bertrand
smime.p7s
Description: S/MIME cryptographic
Daniel Fagerstrom wrote:
Please cast your votes:
[X] Go ahead and implement the environment extensions proposed above.
[ ] Implement the environment extensions but use the *Map() syntax
instead.
[ ] Don't extend the environment.
Sylvain
--
Sylvain WallezAnyware
In addition, I really don't like the implementation that was checked
in. Frankly, this is a case where I would look into leveraging
backport-util-concurrent
(http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) if that
code can be made to work in JDK 1.3.
What I would look to do
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
More specifically I propose is that we extend
o.a.c.environment.Request with:
Map getAttributes();
Map getParameters();
Map getHeaders();
What about cookies? (There is Map getCookieMap() but naming convention
is different).
It would be natural
In addition, I really don't like the implementation that was checked
in. Frankly, this is a case where I would look into leveraging
backport-util-concurrent
(http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) if that
code can be made to work in JDK 1.3.
What I would look to do
I seem to be having serious problems with this mailing list. Yesterday
I noticed I seemed to be getting messages twice and the volume seemed a
little low. Last night I posted a few messages, the first of which
showed up in my in box 4 hours after sending them. This morning I woke
up to
Le 12 mai 05, à 18:38, Ralph Goers a écrit :
...Is it just me? I'm able to send messages to other places just
fine...
I haven't noticed any problems yesterday or today.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Daniel Fagerstrom wrote:
More specifically I propose is that we extend o.a.c.environment.Request
with:
Map getAttributes();
Map getParameters();
Map getHeaders();
What about cookies? (There is Map getCookieMap() but naming convention is
different).
and o.a.c.environment.Session and
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
More specifically I propose is that we extend
o.a.c.environment.Request with:
Map getAttributes();
Map getParameters();
Map getHeaders();
What about cookies? (There is Map getCookieMap() but naming convention
is
Ross Gardler wrote:
Stefano Mazzocchi wrote:
I like the notion of
daisy - forrest - out
makes very good sense.
Now we just need to find a way to automate a little that
workflow, but
without introducing security vulnerabilities.
How about this (bullet summaries
1 - 100 of 108 matches
Mail list logo
