Pier Fumagalli wrote:
I agree wholeheartedly... My personal problem is that we don't
release often enough, and in maintaining my system, too many things
change from one release to another... 2.1.5 was released 2 years ago
now and that's what I use on production.
There are non-trivial
Andrew Savory wrote:
Hi,
On 31 Aug 2005, at 12:22, Pier Fumagalli wrote:
So, even if cforms are still unstable, frankly, 2.1.8 shouldn't be
blocked by it at all...
Or am I the only one seeing it this way?
I'd agree ... doing a release before the GT and then one after with
all the
Vadim Gritsenko wrote:
Ralph Goers wrote:
My employer REQUIRES a stable forms framework, therefore I require a
Cocoon release with a stable forms framework.
Just a reminder [1]:
All of the ASF including the board, the other officers, the
committers, and the members, are participating
Vadim Gritsenko wrote:
You are here to help grow and maintain community as a whole, and
community currently needs more often releases much more than a stable
cforms block (which is just a bit of software, at the end of the day).
Vadim
Vadim,
I guess I have to more completely respond to
Mark Lundquist wrote:
Ralph isn't trying to represent his employer in the Cocoon
community. He's just saying that speaking /just for himself/ it is a
PITA for his job that CForms isn't stable yet, because that prevents
him from using it. I don't think Ralph's employer gives a rat's ass
Vadim Gritsenko wrote:
Ralph Goers wrote:
My opinion is that a community that releases software that it
won't stand behind has a significant problem.
I think you just mis-interpreted semantics of the 'unstable flag'.
See, actual meaning is:
unstable:
Supported by the community
Vadim Gritsenko wrote:
And seriously, I'd argue that your -1 on releases actually *delays*
maturity of cforms.
Vadim
Also, please note that I am not springing this on anybody at the last
minute. I believe I first brought up CForms being marked stable in
February and then in June. Since
Mark Lundquist wrote:
On Aug 31, 2005, at 9:27 AM, Ralph Goers wrote:
My opinion is that a community that releases software that it
won't stand behind has a significant problem.
Won't stand behind seems like too strong/loaded of a
characterization for this CForms thing. Support
If it is an older copy then what does moving the code from the portal
to the core mean? Does the core already contain all the same
functionality and the portal version should just be removed? I'll be
happy to do it if I know what to do.
Ralph
Carsten Ziegeler wrote:
Yepp, it's an older
OK. It should be easy enough to test with the portal sample site.
Ralph
Carsten Ziegeler wrote:
The core is the most recent version. The only thing that has to be
done is remove the code from the portal and make the core version usable
and use it then in the portal (or whereever).
Carsten
Daniel Fagerstrom wrote:
Agree about that as well ;) Carsten seem sometimes to assume that
major changes imply breaking stuff, I don't think that have to be the
case. Working carefully and incremental steps reduces the risk. But of
course, anyone can make mistakes and we of course must
A word of caution. One thing we ran into with Maven 1 was that we ended
up splitting individual components into 3 parts; api, impl and test. As
you start moving from one monolithic project into smaller subcomponents
which are compiled separately you will soon find that you have
circularity
Vadim Gritsenko wrote:
(PS: when is 2.1.8 expected? /me is starting a new big-ish project)
Soonish... I guess as soon as Carsten starts VOTE :-)
Vadim
Just so you know, if Cocoon Forms is still marked unstable I'll be
voting -1.
Ralph
Sylvain Wallez wrote:
(PS: when is 2.1.8 expected? /me is starting a new big-ish project)
Soon :-)
Seriously, what about right after the GT, once we have squashed a few
bugs and patches during the hackathon?
I should also be able to commit some time in the second half of
September to
Vadim Gritsenko wrote:
Ralph Goers wrote:
Just so you know, if Cocoon Forms is still marked unstable I'll be
voting -1.
Does it mean Cocoon should go without release for a year? Would you
still vote -1 if CForms is not marked stable after 2 years? 3?
Yes. Cocoon without a stable
don't want to do if they are truly independent blocks.
Ralph
Joerg Heinicke wrote:
On 30.08.2005 17:31, Ralph Goers wrote:
A word of caution. One thing we ran into with Maven 1 was that we
ended up splitting individual components into 3 parts; api, impl and
test. As you start moving from one
I'm a little confused. In treeprocessor we have
class NOPVariableResolver
class PreparedVariableResolver
class VariableResolver
class VariableResolverFactory
In the portal block we have
class DefaultVariableResolverFactory
class NOPVariableResolver
class
Well, Jorg, we are glad to have you here!
Ralph
Jorg Heymans wrote:
it seems that the account creation process is still ongoing, in the
meantime here are some random trivia about my current and past person.
I am of Belgium nationality and currently living in a little town near
Brussels. In
Thanks.
Ralph
Joerg Heinicke wrote:
Is there a cost for the hackathon?
See the button of the registration page.
Ouch! *Bottom* of course.
Joerg
I'd move it out if keeping it in is going to keep CForms from being
marked stable in 2.1.8.
Sylvain Wallez wrote:
Actually, Ajax in Cocoon should be separated from CForms, and this is
why the BrowserUpdateTransformer is in core and not in CForms. Now if
we're to add more Ajax-related
Wow. It is always a surprise when I wake up in the morning! I'm +5 to this.
Carsten Ziegeler wrote:
Actually I'm a little bit tired of the ongoing Maven discussion.
Why can't we just switch the trunk to Maven NOW? Who really cares if
trunk is not buildable/working for the next days until the
Jorg Heymans wrote:
remarks:
- Will 2.1.x branch also be moved to m2 or is this for trunk only ?
I would wait and see what it takes to convert trunk. As much as I would
like to switch I would wait and see what the impact will be. However,
it might be much easier to convert 2.1.x once
+1
Carsten Ziegeler wrote:
So far the response was positiv, so I think we should just vote about it
and then do it. If you have any questions, please use the proposal thread.
So please cast your votes for switching to Maven2 NOW as
outlined/discussed in the proposal thread.
Thanks
Carsten
night and I didn't see anything to support roles
or permission.
Ralph
Leszek Gawron wrote:
Ralph Goers wrote:
The only concern I would have in bringing CoWarp into Cocoon (beside
the name making me think it is an add-on for OS/2 :-) ) is that I'd
want to evaluate it against using acegi
Stefano Mazzocchi wrote:
one more thing, though, don't lose gump! doesn't have to work right
away, but keep it in mind.
maven 1 has a goal to build the gump.xml (see
http://maven.apache.org/reference/plugins/gump/) , so I would expect
maven 2 would as well.
Ralph
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out of our download.
Ralph
Carsten Ziegeler wrote:
If there is *high* community interest in hosting it at Apache I'm willing to
move. In fact, lack of a community was one of the main reasons in
creating Cowarp outside of Apache.
I have no idea how to become part of a community at sourceforge. Most
seem to have no
Carsten Ziegeler wrote:
Ralph Goers schrieb:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out
I'm trying to get approval from my employer to attend. Do you know what
the conference cost will be? Can you recommend any hotels? I've never
been to Amsterdam (or Europe for that matter) so any help is appreciated.
Ralph
Arje Cahn wrote:
Cocoon
Vadim Gritsenko wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
need to get the 3rd party jars out of our
Leszek Gawron wrote:
-(-(-1)) ! :)
I am often working using a lousy GPRS internet connection (like now
:)). I download big things while connected to LAN and I need to be
sure that I have all deps fetched when going on holiday. If I had to
fetch all dependencies manually (and not only from
hepabolu wrote:
Guys,
I don't know if a vote for this is required, but I'd like to have
consensus/feedback, before I do something drastic.
As written earlier today there are gaps in the current version of the
website, e.g. FAQs are missing. What I'd like to do is restore the
current
Is there something more detailed about what this enhancement provides?
It sounds interesting.
Ralph
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Mon Aug 15 11:57:55 2005
New Revision: 232855
URL: http://svn.apache.org/viewcvs?rev=232855view=rev
Log:
Portal block: Add support for portal
I doubt that there is anything in the works on this. I remember running
into this problem when I was first learning Cocoon. I had to go to the
Avalon site to get basic lifecycle information (this is now at the
Excalibur site). But I had to figure out what the point of cocoon.roles
was on my
One of our production servers is getting this exception repeatedly. Can
someone clue me in on what to do to correct it? The code base was at
svn revision 122686 which, as I recall, was slightly before 2.1.7 was
released.
Ralph
- cocoon-ehcache-1Cache: Could not read disk store element for
, Ralph Goers [EMAIL PROTECTED] wrote:
One of our production servers is getting this exception repeatedly. Can
someone clue me in on what to do to correct it? The code base was at
svn revision 122686 which, as I recall, was slightly before 2.1.7 was
released.
Ralph
- cocoon-ehcache-1Cache
Hunsberger wrote:
On 8/12/05, Ralph Goers [EMAIL PROTECTED] wrote:
Thanks, Peter. I suspected it was a corruption. I didn't know the
names of the files. Frankly, I'm not even sure we need external caching
enabled for this application. Will it provide any better performance
than re-reading
Kees Broenink wrote:
Thanks Joerg and Vadim for your input.
I am a big fan of the basic concepts of Cocoon and I do not tend to add
a MVC layer on top of it. The power of Cocoon in my opinion is that it
is not religic about the MVC pattern. It tries to do the job of building
data driven
I had the same problem. I have no idea what caused it. I ended up
completely restructuring my javaflow. I think it had to do with having
try catch blocks and returning from them, but I really don't have any
idea what caused it.
roy huang wrote:
Hi:
I try to switch flowscript to javaflow and
Thorsten Scherler wrote:
Hello devs,
snip
Another question is the portal view.
http://cocoon.apache.org/2.1/developing/portal/profiles.html#The+Portal
+View
Does that mean we can have
a) user based portal
b) role based portal
c) global based portal
views?
Would it be possible to extend
Antonio Gallardo wrote:
Hi folks,
Jorg Heymans has been around for more than 2 years now, and has
contributed with comments on the dev, help on the user list and
several patches along the way, [grep -i heymans status.xml] will
tell you more), all of good quality.
So, I'm pleased to propose
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
Apart from that, my impression is that the biggest impact might be on
the build system and on the directory structure of our code: separating
the code in a way that makes sense for bundles (separate interfaces
from implementations,
Joerg Heinicke wrote:
But I came across a strange thing: There is no scratchpad block in
the branch. Why? And why are the blocks in the branch not handled in
the same way (svn:external) as in trunk? Couldn't this be done
transparent to the users? And while we are at it: From what I see the
Michael Wechner wrote:
Hi
I would like to suggest that we move the TraversableGenerator into
Cocoon core.
It seems to me that the TraversableGenerator is very useful, because
it supports
the excalibur Source in general and not just the FileSource like the
DirectoryGenerator.
Otherwise
PROTECTED]
Until this proposal has been accepted by the Apache Incubator PMC, these
lists
are provisional.
Ralph
Reinhard Poetz wrote:
Ralph Goers wrote:
Well, I'm very much in favor of this. Unfortunately, my messages sent
to [EMAIL PROTECTED] are failing with no such
mailbox.
The project
Can someone point me at the doc that accurately describes how to add a
new block to Cocoon (for both 2.1.x and trunk). My stumbling block
seems to be that I have no idea how gump resolves the depend elements.
Also, doesn't it strike anyone as strange that the blocks are now off in
their own
Well, I'm very much in favor of this. Unfortunately, my messages sent to
[EMAIL PROTECTED] are failing with no such mailbox.
Ralph
Reinhard Poetz wrote:
Alex Karasulu has proposed Oscar as Apache Projekt to the Incubator
project. For those who don't know Oscar: Oscar is one of the
Reinhard Poetz wrote:
As you all know, Max Pfingsthorn is one of our Google Summer of Code
students and he will work on the implementation of the cforms library.
In order to make his life and the life of his two mentors (Sylvain and
I) easier, I want to give him *temporary* and
Wow!
Ugo Cei wrote:
I have one overwhelming reaction to the difference between Cocoon
then, and Cocoon now. Fundamentally it seems to have evolved from
science experiment to professional product - there is now a clarity of
purpose and design simplicity that promises to make it a joy to work
I haven't looked deeply into what has changed in trunk here, but I
suspect that this change will cause me problems. My Logger
implementation needs to get the objectModel from the contextMap and is
expecting it to be there.
Ralph
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Thu Jun 30
I would have no problem with that if LoggerManager had a method that was
called at the beginning of a request. If that was the case I wouldn't
even be using the Cocoon ContextMap as our LoggingFramework has its own
equivalent (for Log4J NDC type stuff). This would actually simplify my
code.
Daniel Fagerstrom wrote:
For block development we should only depend on official APIs. But the
way you start an OSGi server is not standardized in R3. And as we want
to be able to continue to have the option of having Cocoon packaged as
a servlet (or at least some of you, I don't care), we
Vadim Gritsenko wrote:
Hey All,
Lazy vote here on the subject of adding getSitemapURIPrefix method to
the Request interface. Details are in the bug mentioned below.
Vadim
[EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35435
+1 but can we make the method
Torsten Curdt wrote:
Sorry, nothing but the javadocs and samples in 2.1.
It's not considered stable yet. Although changes
will probably not affect the users point of view
...more under the hood.
The javaflow API is meant to mime the javascript
flow API as close as possible.
Seems like some
I believe you asked this question on 6/20. Did you ask on the Tomcat
list? Cocoon does not perform load balancing. The container and the
http server do.
Ralph
Ralph Lange wrote:
Dear Cocoon users,
Our setup: cocon 2.1.5.1, tomcat 5.5.4, jdk 1.5.0.
In order to manage much more requests, I
You can try adding Cocoon's version of Rhino to the classpath before
weblogic.jar. However, this may very well cause weblogic itself to have
errors, depending on what you are doing. I only experienced problems
when I was trying to use weblogic portal (8.1.2).
As Tony suggested, you will
One other thing. The version of Rhino in 2.1.x almost certainly won't
work with weblogic. However, I believe the Rhino version in 2.2 might
work better since it comes straight from mozilla. Give that a try (you
still need to override weblogics Rhino). Let us know how it goes.
Ralph
Irv
Well, I've already spoken to my boss and have tentatively worked
something out with him. Mon - Wed would probably be better for me as I
plan to stay a few extra days as I've never been to Europe at all, so
I'll do a little sight seeing afterwards. I'd appreciate any advice
regarding car
Helma van der Linden wrote:
Apart from my fulltime job I have a husband and two boys of 6 and 8.
I would have thought the husband and two boys were the fulltime job!
Ralph
Sylvain Wallez wrote:
Glen Ezkovich wrote:
Cocooners,
Working on some introductory documentation I ran into a slight
dilemma. I want to mention how Cocoon is able to access either the
model or a database in response to a request and produce a response
based on the result. Because of
Pretty cool, but will it support versioning. IMO, that is the biggest
problem in Java at the moment.
Ralph
Steven Noels wrote:
This just popped up in my mailbox: http://jcp.org/en/jsr/detail?id=277
/Steven
Sylvain Wallez wrote:
Glen Ezkovich wrote:
Yes, changes are possible, and each time some have occured we have
made sure that existing code will either run in compatibility mode
(with the appropriate deprectation logs) or fail hard by explaining
what's happening.
The problem here is that
Sylvain Wallez wrote:
A problem though: these names are good for methods, but what about
attributes?
fd:field localName=bar leading to a fi:field fullName=foo.bar?
Hmm... doesn't look that good...
Sylvain
Very true. A name attribute on both would look better, but then you'd
need to be
Sylvain Wallez wrote:
Same concerns as Ugo. We should IMO document 2.1 and use specially
labelled sections and pages for what's different in 2.2. We could also
uses Daisy branches, but I don't think it's a good idea to start a
multi-branch effort right now.
I agree with this also.
-
Linden H van der (MI) wrote:
Based on some comments I would like to revise the proposal. Let's focus
first on what info goes where and what the general direction will be.
As things progress, we can focus on explicit processes and, given the
current discussion, the roles/rights.
- the current
Sylvain Wallez wrote:
Hi all,
As part of the stabilization work on CForms, there are a couple of
changes I'd like to do on the naming-related methods of the Widget
interface.
Today we have:
- getId() which returns the local name of widget.
- getRequestParameterName() which returns the
Glen Ezkovich wrote:
2-Should we want to encourage people to write Javaflow instead of
JSFlow?
No. While I plan on using Javaflow going forward, JSFlow makes flow
available to Javascript programers (web masters).
Interesting that you should say that because that is exactly the reason
Reinhard Poetz wrote:
2-Should we want to encourage people to write Javaflow instead of
JSFlow?
no, I think offering both options is enough. People can decide
themselves.
Actually, I think we need a third option, but I don't know what it is.
I've heard the desire to have something
I use maven to do my builds. The jars are all in our local repository.
These are the dependencies I have in my project.xml to compile:
dependency
groupIdcocoon/groupId
artifactIdcocoon/artifactId
urlhttp://cocoon.apache.org/2.1//url
/dependency
dependency
We have used JavaFlow lightly and have not had any problems. We plan to
use it more heavily. I don't know if that helps.
Lutz Thomas wrote:
Hi !
I followed your discussion about the CForm flowscript API. Does this
affect JavaFlow ?
And, as I am in the startup of major project, and want to
I believe I just saw something today in Daisy that documented that and I
think it was copied from the Wiki. I'd look there.
Ralph
Lars Huttar wrote:
Ralph Goers wrote:
I use maven to do my builds. The jars are all in our local
repository. These are the dependencies I have in my project.xml
Ben Pope wrote:
It makes very little sense to mark it stable without it actually being
what is generally considered (by this community) as stable.
You might as well just throw away all semantics, I doubt there are
many people here who want to release something whose API they know
will
Reinhard Poetz wrote:
The current situation is that the implementation (runs in many
projects) and the community (large developer and user community) are
stable, but the interfaces are *not*. I tried to express this with the
hypothetical block descriptor fragment:
state
community=stable
Carsten Ziegeler wrote:
We recently discussed the famous logging topic [1] and it seems
that we agree to reduce the dependencies to LogKit.
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through
We have a project that needs to use a forms framework that is more
advanced than what SimpleForms provides. However, it is difficult on
selling cforms simply because they are marked unstable. What is it
going to take to mark it stable in 2.1.8? Can we simply identify the
known bugs in
Sylvain Wallez wrote:
Ralph Goers wrote:
Reinhard Poetz wrote:
Do we have something else on our wishlists (some fancy cforms
features, etc.)?
What about some ajax stylings for cforms? Some I'd love to have are:
- cocoon suggests ajax styling for cforms fields providing
Antonio Gallardo wrote:
On Mar, 31 de Mayo de 2005, 14:05, Vadim Gritsenko dijo:
Is time to moving setup log4j as our default logging package.
Is that OK?
-1
I'm also -1. I might consider replacing logkit with UGLI, but not LOG4J
directly. However, (a) UGLI is part of
Carsten Ziegeler wrote:
Antonio Gallardo wrote:
Well, I think it is time to discuss again.
I still think we should remove the dependency to LogKit in 2.2 - we all
see now that it's a dead project. So is there any reason to keep it?
Noone else is using it and removing
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Wed Jun 1 12:40:16 2005
New Revision: 179405
URL: http://svn.apache.org/viewcvs?rev=179405view=rev
Log:
Start new, simpler event infrastructure
Do you have any details of where you want to go with this? Is it safe
to assume you want to
Sebastien Arbogast wrote:
Mark's initiative is fully coherent with our motivation at Planet
Cocoon : making Cocoon documentation closer to its users (and once
again, its users are not only its developers).
We are trying to make a documentation platform which is simpler to use
and write for.
Antonio Gallardo wrote:
Hi:
I am not really sure if this is viable and how much time we can save using
a short lived cache. But somehow we need to improve the cforms
performance.
WDYT?
Best Regards,
Antonio Gallardo.
Well, I'm not really familiar with CForms, but FWIW my first thought
Antonio Gallardo wrote:
OK. Perhaps the sample is not the best, lets forget about the database.
The fact is that selection list is requesting the pipeline per row. Hence,
triggering all the pipeline and all the process that it involves. And
there is where I see a waste of time. In the static
Nathaniel Alfred wrote:
Instead of a micro kernel which is going to have again a large footprint to do
anything useful I'd rather prefer a small kernel to do just what Cocoon needs.
After all Cocoon is just a super-servlet which needs a bit of container
services for managing component reuse
Niclas Hedhman wrote:
Cocoon community is IMHO too focused of NOT releasing something BAD, instead
of focusing on releasing the new and good stuff.
If releases came out on a bi-weekly basis, who would be worried that a bug or
two sneaked in. Patch and it will be fixed in days. And with so many
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Uh? What are these features? Would you mind sharing this with us?
Sure; I already mentioned this months ago and even asked on this list
for help; but noone was interested :(
Actually, I was and am interested. I just can't get my boss
Bertrand Delacretaz wrote:
Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit :
...It would require quite a lot of work to give a fair overview of
what we have discussed about this in the last three or so years. You
find some info in http://wiki.apache.org/cocoon/Blocks...
Would it be
Carsten Ziegeler wrote:
Ralph Goers wrote:
Why is updating more difficult. We have MBeans that do both. Creating an
operation that updates isn't that hard. The hard part is figuring out
what you want to manage.
And what happens after you updated a value. Changing pool sizes
Niclas Hedhman wrote:
Listen to the founding fathers of this project, who declared (and lived by it
in the 1.x days) Release Early, Release Often. Everyone here talks about
it, but doesn't live by it.
I have no problem with release early, release often. I just have a
problem with code
I believe it is the bug you reported.
Paul Crabtree wrote:
As a matter of fact, Leszek
provided a fix last week for what seems to me to be a pretty serious bug
in flow and this alone should warrant a 2.1.8 release.
Hi Ralph,
We are about to go to production with an application built on
Daniel Fagerstrom wrote:
snip
Since 2000 we have managed to ship a handfull of 2.0 and a handfull of
2.1 releases. Considering the amount of activity and the volume and
quality of what have done during that period it must be a hard to beat
record in conservative version numbering ;)
Daniel Fagerstrom wrote:
OSGi specification is currently at its 3rd release. It is used as
kernel for Eclipse (since 3.0), each plugin is a bundle. It is used
for embeded applications e.g. BMWs 5 series, mobile phones etc.
There are 12 compliant implementations and at least 3 with friendly
Leszek,
I suspect Paul will want to patch 2.1.7 since that is what he has been
testing with (I doubt he wants to go into production with a snapshot).
Is there a possibility you can forward the svn email to him so he can
patch it himself?
Paul - If I misread you please speak up.
Ralph
Leszek
See http://cocoon.apache.org/community/contrib.html. Specifically the
section How to generate differences. Just attach the file to the
bugzilla report.
Ralph
Paul Crabtree wrote:
Actually i submitted a fix for something else on to the list yesterday
but only in an explanatory way with a
running windows/VSS here and to get cocoon i
simply downloaded the source and built it.
On 5/18/05, *Ralph Goers* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
See http://cocoon.apache.org/community/contrib.html. Specifically the
section How to generate differences. Just attach
Please update from svn and review the changes.
Ralhp
Jochen Kuhnle wrote:
Am I not getting it, or is the implementation broken (see below)?
/** The map to assure 1:1-mapping of server sessions and Cocoon session
wrappers */
private static final Map sessions = Collections.synchronizedMap(new
Yes, there was considerable discussion about this.
Yes, the version in svn is wrong. I was hoping it would get fixed after
our discussion, but that hasn't happened, so I'll try to commit
something tonight (it is still Sunday night here in California).
Ralph
Jochen Kuhnle wrote:
Am I not
Fine. Leave the WeakHashmap the way it is. But synchronizing on the
servlet session is a -1 for me. That could have unknown consequences
since the object is owned by the container, not Cocoon. See my other
post. Sorry - my ISP has had severe email problems the last few days
and so I have
Nathaniel Alfred wrote:
One must synchonize the put and get operation on the map itself
in order to protect its internal consistency.
Well, yeah. A synchronized block that synchronizes on the map
accomplishes that.
Map map = Collections.synchronizedMap(new HashMap());
...
map.put(key,
Nathaniel Alfred wrote:
You must have synchronized(serverSession) (or block all threads) to
avoid calling sessions.put twice for the same serverSession.
Sorry. I misread that sentence. Yes, this statement is quite true.
Ralph
Joerg Heinicke wrote:
It would work, but IMO the current implementation is better because it is
more
fine-grained. Synchronizing the block on the map (yes, you don't need a
synchronized map then) blocks all requests for the execution of this block while
this impl blocks only the requests for the
701 - 800 of 1276 matches
Mail list logo
