date:20070404


On 4/4/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:


Alexander Klimetschek napisał(a):
 Grzegorz Kossakowski schrieb:

 We do need the circular dependency: the basic principle is a super
 block that runs cforms that are mainly defined in a child block - the
 model lies in the child block and it contains a selection-list whose
 source is block:child:/some/matcher - hence the circle, because the
 selection-list will be resolved inside the super block.

Let me tell you how i *imagine* servlet-service-fw should deal super
calls and tell me how it's different from current situation. This should
help us both.
Let's have two blocks, one named base and one extending, base is
super block for extending. I've imagined (before using super calls) that
it would work that way:
extending block is requested for someResource and suppose it has not
any matching pattern for it, then super (base in our case) block is
automatically asked for the same. You don't have to provide any generic
matcher that redirects processing to super block.
Now someResource is catched by base block but it asks for
internalResource by calling servlet:internalResource. Given that
base block is called as super of extending, first extending block is
asked for this resource (because it may override it) and if it does not
provide one, it's taken from base block.

In short: I mean that super should work as fallback mechanism. I guess



The idea directly applies to OO's inheritance definition. However,
it might not be easy to implement because it is hard to define the
looked-up resource does not exist in the extending servlet. Take flowscript
as example, it is usually a javascript error when calling a method of a
non-existent javascript object which exists in the super servlet but matched
in the extending servlet's sitemap.


it does not work that way now. However, this would eliminate need for

circular dependencies and give cleaner design.

What do you think?

--
Grzegorz Kossakowski

[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable

2007-04-04 Thread Reinhard Poetz (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486579
 ] 

Reinhard Poetz commented on COCOON-1425:


Does session replication work for you as expected? Have you been able to see a 
session, that was created by app server A being used from app server B?

 Sessions that use Flowscript are not serializable
 -

 Key: COCOON-1425
 URL: https://issues.apache.org/jira/browse/COCOON-1425
 Project: Cocoon
  Issue Type: Bug
  Components: - Flowscript
Affects Versions: 2.2-dev (Current SVN)
 Environment: Operating System: All
 Platform: PC
Reporter: Reinhard Poetz
 Assigned To: Cocoon Developers Team

 The scopes of Flowscripts are  not serializable. The same is valid for the
 continuation objects. This requires a more sophisticated serialization 
 process.
 See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Continuation looks for wrong interpreter when using servlet protocol


Hi,
 Here is another problem when using servlet protocol. A servlet S1 extends
another servlet S2. A web continuation k is generated in S2. When k returns
back, k is matched in S1 with match pattern *.continue which exists in S2
also. Then comes an error with message like k bound to S2, but looked up in
S1. The following is a real error message:


btpool0-2 ERROR cocoon - WK: Continuation
(3301103c195d12467754350a192304881845061d) lookup for wrong interpreter.
Bound to:
file:/C:/projects/XS/party/xs-party/target/classes/COB-INF/sitemap.xmap,
looked up for:
file:/C:/projects/XS/school/xs-school-party/target/classes/COB-INF/sitemap.xmap

btpool0-2 ERROR cocoon - Internal Cocoon Problem
org.apache.cocoon.components.flow.InvalidContinuationException: The
continuation ID 3301103c195d12467754350a192304881845061d is invalid.
   at map:call -
file:/C:/projects/XS/school/xs-school-party/target/classes/COB-INF/sitemap.xmap:27:35

   at map:match -
file:/C:/projects/XS/school/xs-school-party/target/classes/COB-INF/sitemap.xmap:26:36
   at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:632)

   at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(
CallFunctionNode.java:94)

Rice

Re: Continuation looks for wrong interpreter when using servlet protocol


Rice Yeh wrote:

Hi,
  Here is another problem when using servlet protocol. A servlet S1 
extends another servlet S2. A web continuation k is generated in S2. 
When k returns back, k is matched in S1 with match pattern *.continue 
which exists in S2 also. Then comes an error with message like k bound 
to S2, but looked up in S1.


I wonder if this really increases the security of Cocoon apps which was the 
original reason why this feature was introduced. Can somebody comment on this?


As a quick work-around you could use a different pattern that matches your 
continuation continue pipelines in S2. It might be that the strict mode is 
configureable somehow but can't rememeber.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

RE: StoreJanitor


 
 Reinhard Poetz wrote:
 
  P.S. Ard, answering to your mails is very difficult because 
 there are no 

I am very sorry...I hardly dare saying i am using outlook :-) 
I'll try to find a way in the stupid program for linebreaks or make the switch 
to Thunderbird.

Ard

  line breaks. Is anybody else experiencing the same problem 
 or is it only 
  me?
 
 Jörg pointed me to the rewrap function of Thunderbird. 
 Using it fixes all my 
 problems with never ending lines. Thanks Jörg!
 
 -- 
 Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 
 
 {Software Engineering, Open Source, Web Applications, Apache Cocoon}
 
 web(log): http://www.poetz.cc

email formatting

 
 Reinhard Poetz wrote:
 
  P.S. Ard, answering to your mails is very difficult because 
 there are no 
  line breaks. Is anybody else experiencing the same problem 
 or is it only 
  me?
 
 Jörg pointed me to the rewrap function of Thunderbird. 
 Using it fixes all my 
 problems with never ending lines. Thanks Jörg!

Reading this again, is it an error from my mail settings or was it something in 
Thunderbird? I am always complaining when people send html, so...if my mails 
are wrong as well in format...I should definitely do something about it

Ard

[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable

2007-04-04 Thread Michael Mest (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486586
 ] 

Michael Mest commented on COCOON-1425:
--

I'm sorry. Seems that it was an error in Testing. Doesn't really work. :-(

I get invalid Continuations on Tomcat Cluster.

 Sessions that use Flowscript are not serializable
 -

 Key: COCOON-1425
 URL: https://issues.apache.org/jira/browse/COCOON-1425
 Project: Cocoon
  Issue Type: Bug
  Components: - Flowscript
Affects Versions: 2.2-dev (Current SVN)
 Environment: Operating System: All
 Platform: PC
Reporter: Reinhard Poetz
 Assigned To: Cocoon Developers Team

 The scopes of Flowscripts are  not serializable. The same is valid for the
 continuation objects. This requires a more sophisticated serialization 
 process.
 See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Parameters in request get lost when using servlet: protocol


Not only  request.getParameter(String name) has problem but
request.getLocale() has problem too. So I decide to modify some methods in
BlockCallHttpServletRequest. My logic is as follows:

For parameters:
 First ask the request in the current call frame. If a parameter is not
found in the current request,  ask the request in the previous call frame.

For locale:
 Directly ask the request in previous call frame and eventually the request
in the first call frame, which is not an instance of
BlockCallHttpServletRequest,   answer the question.

With such logic, a parameter in current request can override the previous
one for the time in current call frame. Once leaving current call frame, the
overriding effect disappear.

I test it in my application. It works for me now. But do not know such logic
applies to others' use cases.

Rice

On 4/3/07, Alexander Klimetschek [EMAIL PROTECTED]
wrote:


Rice Yeh schrieb:
 Thank you for your solution. But I still feel weird for a brand new
request
 being created for a called block (servlet), at least for a super block
 (servlet). Having a look at the source code, each new brand request and
 response are supposed to be stored in its call frame (actually, this
 feature
 is not implemented yet, but api for retrieving these two objects are
 provided). If such design is intended, why not just treat request and
 response as part of servlet (block) context. And a way for passing a
 request's attributes or parameters must be provided. My real opinion is
 that
 request should be pass through all servlets invoked, instead of creating
a
 new one.

You are right, as far Cocoon's internal blocks with Sitemap servlets are
involved. In that case one can optimize the calls and provide the original
context (request, sitemap parameters etc.) to the callee. The only problem
you have is how to handle the different parameter levels you have: you
might
want to have global but sometimes only local parameters, eg. when setting
some value in a called block, you don't want it to override a parameter
with
the same name in the calling block.

The advantage of the servlet protocol internally is that you can mount any
servlet as a block, not only cocoon's sitemap servlet. We for example have
mounted the Solr servlets (for indexing and searching with lucene) as
normal
blocks. This is a nice feature that allows you to manage your complex web
application solely with Cocoon and Spring.

Alex

--
Alexander Klimetschek
http://www.mindquarry.com

Re: email formatting


Ard Schrijvers wrote:

Reinhard Poetz wrote:

P.S. Ard, answering to your mails is very difficult because 
there are no 
line breaks. Is anybody else experiencing the same problem 
or is it only 

me?
Jörg pointed me to the rewrap function of Thunderbird. 
Using it fixes all my 
problems with never ending lines. Thanks Jörg!


Reading this again, is it an error from my mail settings 


Your lines are nearly endless, without any line breaks

or was it something in Thunderbird? 


Thunderbird offers a soltion for this kind of problems. The funktion is called 
rewrap which adds line breaks at the right places.



I am always complaining when people send html, so...if my mails are wrong as 
well in format...I should definitely do something about it


Thanks!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable

2007-04-04 Thread Reinhard Poetz (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486589
 ] 

Reinhard Poetz commented on COCOON-1425:


The problem is that the Continuations object has object references that are not 
serializeable. That's the reason why the WebContinuationsHolder doesn't 
implement Serializeable.

 Sessions that use Flowscript are not serializable
 -

 Key: COCOON-1425
 URL: https://issues.apache.org/jira/browse/COCOON-1425
 Project: Cocoon
  Issue Type: Bug
  Components: - Flowscript
Affects Versions: 2.2-dev (Current SVN)
 Environment: Operating System: All
 Platform: PC
Reporter: Reinhard Poetz
 Assigned To: Cocoon Developers Team

 The scopes of Flowscripts are  not serializable. The same is valid for the
 continuation objects. This requires a more sophisticated serialization 
 process.
 See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: email formatting


 Ard Schrijvers wrote:
  Reinhard Poetz wrote:
 
  P.S. Ard, answering to your mails is very difficult because 
  there are no 
  line breaks. Is anybody else experiencing the same problem 
  or is it only 
  me?
  Jörg pointed me to the rewrap function of Thunderbird. 
  Using it fixes all my 
  problems with never ending lines. Thanks Jörg!
  
  Reading this again, is it an error from my mail settings 
 
 Your lines are nearly endless, without any line breaks
 
  or was it something in Thunderbird? 
 
 Thunderbird offers a soltion for this kind of problems. The 
 funktion is called 
 rewrap which adds line breaks at the right places.
 
  I am always complaining when people send html, so...if my 
 mails are wrong as well in format...I should definitely do 
 something about it
 
 Thanks!

There will probably be coming a mail in just a moment which won't make you 
happy regarding formatting,
but I'll ask around here if somebody knows a solution for me :-)



 
 -- 
 Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 
 
 {Software Engineering, Open Source, Web Applications, Apache Cocoon}
 
 web(log): http://www.poetz.cc

[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable

2007-04-04 Thread Michael Mest (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486596
 ] 

Michael Mest commented on COCOON-1425:
--

Ok, I see.

So there seems to be no possibility to Cluster an Application using 
Continuations?

 Sessions that use Flowscript are not serializable
 -

 Key: COCOON-1425
 URL: https://issues.apache.org/jira/browse/COCOON-1425
 Project: Cocoon
  Issue Type: Bug
  Components: - Flowscript
Affects Versions: 2.2-dev (Current SVN)
 Environment: Operating System: All
 Platform: PC
Reporter: Reinhard Poetz
 Assigned To: Cocoon Developers Team

 The scopes of Flowscripts are  not serializable. The same is valid for the
 continuation objects. This requires a more sophisticated serialization 
 process.
 See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Parameters in request get lost when using servlet: protocol

Sounds good. We had this discussion a few months ago, where Daniel explained 
the problems with the parameters:


http://thread.gmane.org/gmane.text.xml.cocoon.devel/68157

I'd like to mention that there are two things we are talking about (I was 
mixing them up in my first post ;-):


1) the original HTTP request parameters
2) cocoon attributes that can be set by the caller

The first was solved by you easily since it is static and overriding works 
as expected. But with setting attributes (eg. by an action in a sitemap), 
the separation between global attributes (for any block) and local 
attributes (only for the current block and maybe the one's called by him) is 
needed.


There is also the request-scoped bean mentioned, where some work has 
happened in the last time (regarding cocoon Environment). But I don't know 
if this is in a state that allows you to do new things or at least implement 
the 2nd point more easily.


Alex

Rice Yeh schrieb:

Not only  request.getParameter(String name) has problem but
request.getLocale() has problem too. So I decide to modify some methods in
BlockCallHttpServletRequest. My logic is as follows:

For parameters:
 First ask the request in the current call frame. If a parameter is not
found in the current request,  ask the request in the previous call frame.

For locale:
 Directly ask the request in previous call frame and eventually the request
in the first call frame, which is not an instance of
BlockCallHttpServletRequest,   answer the question.

With such logic, a parameter in current request can override the previous
one for the time in current call frame. Once leaving current call frame, 
the

overriding effect disappear.

I test it in my application. It works for me now. But do not know such 
logic

applies to others' use cases.

Rice



--
Alexander Klimetschek
http://www.mindquarry.com

[jira] Commented: (COCOON-1425) Sessions that use Flowscript are not serializable

2007-04-04 Thread Reinhard Poetz (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486601
 ] 

Reinhard Poetz commented on COCOON-1425:


I believe that Javaflow would be the best bet to use continuations together 
with replicated sessions. Though it still needs some work to get it working.

 Sessions that use Flowscript are not serializable
 -

 Key: COCOON-1425
 URL: https://issues.apache.org/jira/browse/COCOON-1425
 Project: Cocoon
  Issue Type: Bug
  Components: - Flowscript
Affects Versions: 2.2-dev (Current SVN)
 Environment: Operating System: All
 Platform: PC
Reporter: Reinhard Poetz
 Assigned To: Cocoon Developers Team

 The scopes of Flowscripts are  not serializable. The same is valid for the
 continuation objects. This requires a more sophisticated serialization 
 process.
 See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: StoreJanitor


 
 AFAICS there are two freeing algorithms in trunk: round-robin 
 and all-stores.

I already thought it would be something like this

/snip

 and this is IMO one of the major weakenesses of ehcache (or I 
 missed it 
 completely), I did not find any way to limit the number of 
 disk store entries.
 
 Actually we don't configure this value. According to 
 http://ehcache.sourceforge.net/documentation/configuration.htm
 l the default 
 value is 0 meaning unlimited. We should use the 1.2.4 
 constructor that allows to 
 set a maxElementsOnDisk parameter.

That is added lately to ehcache right? I never saw this one, but it is 
extremely important to set it to a sensible value in my opinion. Cocoon
uses some quite ingenious caching tricks, but the everage user won't be 
aware of the millions of cache entries you can leave behind (like when putting
a timestamp in a cachekey). 

 
 I wonder what StoreJanitor is good for at all. EHCache takes 
 care that the 
 number of items in the memory cache doesn't grow indefinitly 
 and starts its own 
 cleanup threads for the disc store 
 (http://ehcache.sourceforge.net/documentation/storage_options.
 html#DiskStore). 
 JCS will probably do the same. 

Yes, this is exactly my point. The extra problem is that the StoreJanitor never 
has
access to the eviction policy of the cache, and just starts throwing out 
entries at random.
From my experience, is that my app will only run solid, when the StoreJanitor 
never runs :-) 
Therefor, I have created a few store size options to choose from, matching 
different
JVM memory sizes. Then, when app is finished I start crawling the site (xenu 
[1]) for an hour 
and look at status generator mem useage or yourkit profiler or something. If I 
see the 
nice shaped sawtooth (is this only dutch? :-) ) of memory useage, the stores 
are configured correctly 


 I guess that original purpose 
 of StoreJanitor was 
 when Cocoon had its own store implementations (transient, 
 persistent) and we had 
 to take care of cleaning them up in our code.

That must indeed have been the reason (I did not know this one, before my time, 
so I have 
never understood how the StoreJanitor would ever help me out)

 Only the persistent store can grow unlimited but since it 
 should only be used 
 for special usecases, it shouldn't be a real problem.
 

/snip

 
 
 What do we want to do in order to improve the situation? 
 After reading your mail 
 and from my own experience I'd say
 
   - introduce a maxPersistentObjects parameter and use it in 
 EHDefaultCache to set maxElementsOnDisk

+1 

   - make the registration of stores at StoreJanitor configureable
 (Though I wonder what the default value should be, true or false?)

0 : I would avoid the StoreJanitor to run anyway

   - fix EventRegistry

+1: I have fixed this locally to let it work also when cache entries are 
removed by the internals of the cache
I did this, by instead of using the AbstractDoubleMapEventRegistry use 
WeakReferences, so that when the cache keys
aren't present anymore, the JVM itself cleans the Registry. Two problems:

1: I removed the persistent cache between JVM retarts, but could rebuild this 
(at the cost of long start up times though)
2: With former versions of EHCache, my weakreferences where not honoured when 
cache entries where overflowed to disk.
Therefor, I thought EHCache might be doing something with the cachekey when 
moving to the disk cachekey map. I could only see this behavior in combination 
with Cocoon, and not when I tested EHCache seperatly. 
On the EHCache userlist, Greg told me that it was not possible, and also showed 
it. 
I am using now JCSCache, which I am pretty ok with (only hard configuration)

If by the way, we start fixing the others, like setting a maxdiskobjects, the 
OOM due to event registry will increase. 
This is a problem from MultiHashMap (also the not deprecated replacer) that 
when you do:
map.put(1,test);
map.put(1,test);

you have two values for key 1. 


 
 Any further ideas?

Hmmm, yes, but I am not sure wether others like it: I think, it might be good, 
that
when the StoreJanitor runs, there should be at least an info (error level...? I 
frequently want to 
give info in messages which is so important, that it must be at error level to 
not be missed, but this
is stupid, right?) message about possible problems:

either:
1) your JVM memory settings are too low
2) your stores are configured to have too many memory items
3) your cached objects are very large
4) you have a memory leak in some custom component (a little vague yes :-) )
etc
Try runnning a crawler (xenu) and watch your status page memory useage.

Another improvement might be trying to avoid binary readers putting entries in 
memory cache. But, this might 
be to complex for the average user. In principal, I have have been bugging 
everybody here to:

1) use readers in *noncaching* pipelines, and use appropriate expires times in 
the readers, very important
for fast pages

Re: StoreJanitor

Ard Schrijvers wrote:

snip/
- introduce a maxPersistentObjects parameter and use it in
EHDefaultCache to set maxElementsOnDisk

that's easy

- make the registration of stores at StoreJanitor configureable
(Though I wonder what the default value should be, true or false?)

0 : I would avoid the StoreJanitor to run anyway

I suggest that we don't register them at StoreJanitor by default anymore but
make it configureable for users who rely on it in their custom Store
implementations/configurations.

AFAIU, StoreJanitor only runs if at least one store is registered so we don't
have to remove it.

- fix EventRegistry

+1: I have fixed this locally to let it work also when cache entries are
removed by the internals of the cache
I did this, by instead of using the AbstractDoubleMapEventRegistry use
WeakReferences, so that when the cache keys
aren't present anymore, the JVM itself cleans the Registry. Two problems:

1: I removed the persistent cache between JVM retarts, but could rebuild this
(at the cost of long start up times though)
2: With former versions of EHCache, my weakreferences where not honoured when
cache entries where overflowed to disk.
Therefor, I thought EHCache might be doing something with the cachekey when moving to the disk cachekey map. I could only see this behavior in combination with Cocoon, and not when I tested EHCache seperatly.
On the EHCache userlist, Greg told me that it was not possible, and also showed it.
I am using now JCSCache, which I am pretty ok with (only hard configuration)

If by the way, we start fixing the others, like setting a maxdiskobjects, the OOM due to event registry will increase.
This is a problem from MultiHashMap (also the not deprecated replacer) that when you do:

map.put(1,test);
map.put(1,test);

you have two values for key 1.

I have to learn more about the EventRegistry in order to comment on your
suggestions.

Any further ideas?

Hmmm, yes, but I am not sure wether others like it: I think, it might be good,
that
when the StoreJanitor runs, there should be at least an info (error level...? I frequently want to
give info in messages which is so important, that it must be at error level to not be missed, but this
is stupid, right?)

WARN should be good enough IMO.

message about possible problems:

either:
1) your JVM memory settings are too low

2) your stores are configured to have too many memory items

3) your cached objects are very large

4) you have a memory leak in some custom component (a little vague yes :-) )
etc

hehe, if we can implement an algorithm that can provide such analysis reliably,
why not ;-)

Are you suggesting some kind of online monitor? I think having a seperate
component would be better than merging it into StoreJanitor. This component
could also be made available as MBean.

Try runnning a crawler (xenu) and watch your status page memory useage.

Another improvement might be trying to avoid binary readers putting entries in memory cache. But, this might
be to complex for the average user. In principal, I have have been bugging everybody here to:

1) use readers in *noncaching* pipelines, and use appropriate expires times in
the readers, very important
for fast pages because browsers honour the expires time
2) we also read binaries from our repository: these obviously need to be
cached, but what if it are mp3 files
of 15 Mb a piece? Storing this in a normal store...so, I added a protocol,
cached-binary: which in our
setup uses a different store which is configured to have no memory part, only disk cache.

Then again, perhaps the thing above isn't something we can code

definitly

(except for changing some things regarding having multiple event registries),
but...perhaps I should wikify it for the advanced useage? It is though quite some stuff.

Sometimes people have complained to me that
1) cocoon caching is difficult
2) why nobody explained before how cachekeys work, the status generator cachekey overview,
how validities work, etc etc

But, I doubt if there are frameworks around where you get so much ingenious
caching for free,
where 95% of the users never have to know about it. And, indeed, when you want
to run sites
with 100.000 pages, you indeed need to know more about it. I do think that is normal.

same opinion here

I think it is brilliant of cocoon that we run sites of 100.000 pages with many
users and editors,
which never go down and run everything live with eventcache, and have response
times when cached of within
32 ms (and my latest setups (a skeleton generator with standard conf and sitemaps even go to 0-15 ms)).
I did not get this for free. It took me around 3 months to have everything configured/rebuild/added and understood correctly.
I am not sure about the best way to have it for free for everybody, without needing to understand it all
(or at least get proper info about it).

WDOT?

yes please, I would be

Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)


Grzegorz Kossakowski schrieb:
In short: I mean that super should work as fallback mechanism. I guess 
it does not work that way now. However, this would eliminate need for 
circular dependencies and give cleaner design.


What do you think?


Yes, this would indeed be better. The super block must not know of its 
concrete children, but be able to call polymorphic matchers - true OO. Then 
I can remove the cyclic dep.


Alex

BTW: When I started to use blocks and especially using the inheritance 
feature, I was surprised that I manually had to include the 
forward-**-to-super-block matcher at the end of the child sitemap


--
Alexander Klimetschek
http://www.mindquarry.com

Re: Parameters in request get lost when using servlet: protocol


On 4/4/07, Alexander Klimetschek [EMAIL PROTECTED]
wrote:


Sounds good. We had this discussion a few months ago, where Daniel
explained
the problems with the parameters:

http://thread.gmane.org/gmane.text.xml.cocoon.devel/68157

I'd like to mention that there are two things we are talking about (I was
mixing them up in my first post ;-):

1) the original HTTP request parameters
2) cocoon attributes that can be set by the caller

The first was solved by you easily since it is static and overriding works
as expected. But with setting attributes (eg. by an action in a sitemap),
the separation between global attributes (for any block) and local
attributes (only for the current block and maybe the one's called by him)
is
needed.

There is also the request-scoped bean mentioned, where some work has
happened in the last time (regarding cocoon Environment). But I don't know
if this is in a state that allows you to do new things or at least
implement
the 2nd point more easily.



Yes, I think a lot of things to meet the requirements in the discussion have
been done in trunk but the author (Daniel?) seems not have time to connect
all stuffs together. For example, there has been a call frame stack.
All I do is just having a quick-but-dirty implementation of the logic I
stated earlier.

Rice

Alex


Rice Yeh schrieb:
 Not only  request.getParameter(String name) has problem but
 request.getLocale() has problem too. So I decide to modify some methods
in
 BlockCallHttpServletRequest. My logic is as follows:

 For parameters:
  First ask the request in the current call frame. If a parameter is not
 found in the current request,  ask the request in the previous call
frame.

 For locale:
  Directly ask the request in previous call frame and eventually the
request
 in the first call frame, which is not an instance of
 BlockCallHttpServletRequest,   answer the question.

 With such logic, a parameter in current request can override the
previous
 one for the time in current call frame. Once leaving current call frame,
 the
 overriding effect disappear.

 I test it in my application. It works for me now. But do not know such
 logic
 applies to others' use cases.

 Rice


--
Alexander Klimetschek
http://www.mindquarry.com

RE: StoreJanitor


 
 I suggest that we don't register them at StoreJanitor by 
 default anymore but 
 make it configureable for users who rely on it in their custom Store 
 implementations/configurations.

+1

 
 AFAIU, StoreJanitor only runs if at least one store is 
 registered so we don't 
 have to remove it.
 
- fix EventRegistry
  

/snip

 
 I have to learn more about the EventRegistry in order to 
 comment on your 
 suggestions.

I will mail tonight or tomorrow morning all ins and outs, pros and cons (I know 
of at least) of the current
eventRegistry and my suggested (implemented) fix (though we have to discuss 
wether I can get it to work for EHCache and wether it needs to be 
diskpersistent between JVM restarts)

 
  4) you have a memory leak in some custom component (a 
 little vague yes :-) )
  etc
 
 hehe, if we can implement an algorithm that can provide such 
 analysis reliably, 
 why not ;-)

I think this is extremely hard. Not for the pipeline caches because they store 
the response in byte[], but for continuations, internal component maps (for 
example i18n resource bundles I think, compiled jx), memory stores which 
contain any complex non serializable objects, I think it is impossible to know 
the amount of memory. I test these things the most dumb possible way you can 
imagine: I crawl my site, and look in status page what happens. I have
many stores in my status page. I have a clear link for each seperate store, and 
I look at the memory which gets
freed when clearing one store. This gives me a heuristic measurement of how 
large my stores are and should be configured

 
 Are you suggesting some kind of online monitor? I think 
 having a seperate 
 component would be better than merging it into StoreJanitor. 
 This component 
 could also be made available as MBean.

See above, very complex I think...and if we fix the standard things that it is 
harder for users to 
get bugged by the StoreJanitor, and they want to take it to the next level, 
there are always things
like yourkit profiler. But, perhaps I am not ambitious enough now :-) 
 

 
 yes please, I would be interested in more comments too! Are 

more comments like in wiki or in the cocoon.xconf more comment for different 
configurations? 
I can try to write extended documentation on what IMO is best for 
configuration, and tricks to 
avoid the StoreJanitor mechanism

 Ard and I right that 
 we shouldn't register EHDefaultStore and MRUMemoryStore at 
 StoreJanitor anymore 
 by default and make it configureable instead?

In principle, you could see the StoreJanitor as a real last resort (but IMO, it 
will never actually help). 
The StoreJanitor might still run, and give proper warnings when low on memory. 
Configuring your stores correctly
(and making sure no binary files of many Mb's end up in it), and certainly 
having the maxdiskelements 
configured should do the trick! Not running the StoreJanitor when JVM is low, 
will result in a little faster OOM,
but in my opinion, it differs not much. I also think, the maxdiskelements 
should have a sensible default, which
should be less then indefinitely (something like 30.000-50.000 should cover I 
think almost everybodies apps)

 
  Ard
  

 
 the formatting is okay now, but it seems that your mails 
 still don't set the 
 in-reply-to header correctly.

Hmmm, I will start using Thunderbird on short notice (not yet today :-) )

 
 -- 
 Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 
 
 {Software Engineering, Open Source, Web Applications, Apache Cocoon}
 
 web(log): http://www.poetz.cc

[jira] Created: (COCOON-2037) New DynamicGroup widget

2007-04-04 Thread Daniele Madama (JIRA)

New DynamicGroup widget
---

 Key: COCOON-2037
 URL: https://issues.apache.org/jira/browse/COCOON-2037
 Project: Cocoon
  Issue Type: New Feature
  Components: Blocks: Forms
Affects Versions: 2.1.11-dev (Current SVN)
Reporter: Daniele Madama
 Fix For: 2.1.11-dev (Current SVN)


I created a new DynamicGroup widget, with it you can replace all the children 
of the group, so you can simply create a *dynamic form* without recreate the 
form each time. Usefull for a very huge form that need to show only some widget 
at time.
This approach is a little different with the CForms standard because every time 
that you replace the children of the dynamic-group you must do a 
bindLoad()/bindSave() if you need to preserve the data.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)

2007-04-04 Thread Grzegorz Kossakowski

Rice Yeh napisał(a):
 The idea directly applies to OO's inheritance definition. However,
 it might not be easy to implement because it is hard to define the
 looked-up resource does not exist in the extending servlet. Take
 flowscript as example, it is usually a javascript error when calling a
 method of a non-existent javascript object which exists in the super
 servlet but matched in the extending servlet's sitemap.

Either you extend block or not you should always be careful about matching 
patterns. I think it has nothing to do with servlet services if
you just create to generic matchers.
Now commenting you concern, I do not fully understand javascript error when 
calling a method of a non-existent javascript object. Can you
explain it a little bit?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

[jira] Updated: (COCOON-2037) New DynamicGroup widget

2007-04-04 Thread Daniele Madama (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniele Madama updated COCOON-2037:
---

Attachment: dynamicgroup_patch.txt

 New DynamicGroup widget
 ---

 Key: COCOON-2037
 URL: https://issues.apache.org/jira/browse/COCOON-2037
 Project: Cocoon
  Issue Type: New Feature
  Components: Blocks: Forms
Affects Versions: 2.1.11-dev (Current SVN)
Reporter: Daniele Madama
 Fix For: 2.1.11-dev (Current SVN)

 Attachments: dynamicgroup_patch.txt


 I created a new DynamicGroup widget, with it you can replace all the children 
 of the group, so you can simply create a *dynamic form* without recreate the 
 form each time. Usefull for a very huge form that need to show only some 
 widget at time.
 This approach is a little different with the CForms standard because every 
 time that you replace the children of the dynamic-group you must do a 
 bindLoad()/bindSave() if you need to preserve the data.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (COCOON-2037) New DynamicGroup widget

2007-04-04 Thread Grzegorz Kossakowski (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486655
 ] 

Grzegorz Kossakowski commented on COCOON-2037:
--

I would like to understand your use case. Why don't you use widget states for 
this: 
http://cocoon.zones.apache.org/daisy/cdocs-forms/g1/forms/concepts/733.html

 New DynamicGroup widget
 ---

 Key: COCOON-2037
 URL: https://issues.apache.org/jira/browse/COCOON-2037
 Project: Cocoon
  Issue Type: New Feature
  Components: Blocks: Forms
Affects Versions: 2.1.11-dev (Current SVN)
Reporter: Daniele Madama
 Fix For: 2.1.11-dev (Current SVN)

 Attachments: dynamicgroup_patch.txt


 I created a new DynamicGroup widget, with it you can replace all the children 
 of the group, so you can simply create a *dynamic form* without recreate the 
 form each time. Usefull for a very huge form that need to show only some 
 widget at time.
 This approach is a little different with the CForms standard because every 
 time that you replace the children of the dynamic-group you must do a 
 bindLoad()/bindSave() if you need to preserve the data.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)

2007-04-04 Thread Grzegorz Kossakowski

Alexander Klimetschek napisał(a):
 
 Yes, this would indeed be better. The super block must not know of its
 concrete children, but be able to call polymorphic matchers - true OO.
 Then I can remove the cyclic dep.
 
 Alex
 
 BTW: When I started to use blocks and especially using the inheritance
 feature, I was surprised that I manually had to include the
 forward-**-to-super-block matcher at the end of the child sitemap
 

I'll create issue for this one. Once again: would you like to implement it? If 
so, just put a message on list.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

[jira] Created: (COCOON-2038) Implement true Object Oriented approach for handling super calls

2007-04-04 Thread Grzegorz Kossakowski (JIRA)

Implement true Object Oriented approach for handling super calls


 Key: COCOON-2038
 URL: https://issues.apache.org/jira/browse/COCOON-2038
 Project: Cocoon
  Issue Type: Task
  Components: - Servlet service framework
Reporter: Grzegorz Kossakowski
 Fix For: 2.2-dev (Current SVN)


As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 
implementation of super calls should be changed to make it more OO-like.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (COCOON-2037) New DynamicGroup widget

2007-04-04 Thread Daniele Madama (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486663
 ] 

Daniele Madama commented on COCOON-2037:


We have a very huge entity, with hundreds of different fields, but we need to 
show only some of they each time, with this widget we can *split* the different 
view in each form snippet without load the full form on startup (many widget 
have some logic during the on-create phase and so on). Take a look at the 
patch, it has a sample that can explain the case better of my english ;).


 New DynamicGroup widget
 ---

 Key: COCOON-2037
 URL: https://issues.apache.org/jira/browse/COCOON-2037
 Project: Cocoon
  Issue Type: New Feature
  Components: Blocks: Forms
Affects Versions: 2.1.11-dev (Current SVN)
Reporter: Daniele Madama
 Fix For: 2.1.11-dev (Current SVN)

 Attachments: dynamicgroup_patch.txt


 I created a new DynamicGroup widget, with it you can replace all the children 
 of the group, so you can simply create a *dynamic form* without recreate the 
 form each time. Usefull for a very huge form that need to show only some 
 widget at time.
 This approach is a little different with the CForms standard because every 
 time that you replace the children of the dynamic-group you must do a 
 bindLoad()/bindSave() if you need to preserve the data.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Circular deps in servlet connections (was Re: Servlet Services + Shielding)


Grzegorz Kossakowski schrieb:

Alexander Klimetschek napisał(a):

Yes, this would indeed be better. The super block must not know of its
concrete children, but be able to call polymorphic matchers - true OO.
Then I can remove the cyclic dep.

Alex

BTW: When I started to use blocks and especially using the inheritance
feature, I was surprised that I manually had to include the
forward-**-to-super-block matcher at the end of the child sitemap



I'll create issue for this one. Once again: would you like to implement it? If 
so, just put a message on list.



I could easily create the patch for the warning message.

Regarding the other solution (automatically resolving the circular dep and 
thus allowing it): I would now agree to skip this. A bit of research showed 
that generic circular deps handling is difficult. There are solutions if one 
specifically knows the two objects (see [1] and [2]). But here we are in a 
piece of code that has to work generically.


Instead, it would be nice to get the real forwarding implemented soon - but 
I don't know yet where to tackle the servlet-services code to get this done.


Alex

[1] http://forum.springframework.net/archive/index.php/t-94.html

[2] http://forum.springframework.org/archive/index.php/t-10186.html

--
Alexander Klimetschek
http://www.mindquarry.com

Re: StoreJanitor


Ard Schrijvers wrote:

yes please, I would be interested in more comments too! Are 


more comments like in wiki or in the cocoon.xconf more comment for different configurations? 
I can try to write extended documentation on what IMO is best for configuration, and tricks to 
avoid the StoreJanitor mechanism


I'm interested in further comments by you too, but actually I meant that other 
people should comment on our plan to change the behaviour of StoreJanitor.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: StoreJanitor

2007-04-04 Thread Peter Hunsberger


On 4/4/07, Reinhard Poetz [EMAIL PROTECTED] wrote:

Ard Schrijvers wrote:

 yes please, I would be interested in more comments too! Are

 more comments like in wiki or in the cocoon.xconf more comment for different 
configurations?
 I can try to write extended documentation on what IMO is best for configuration, and 
tricks to
 avoid the StoreJanitor mechanism

I'm interested in further comments by you too, but actually I meant that other
people should comment on our plan to change the behaviour of StoreJanitor.


Personally, I wonder if you can't just get rid of it altogether?  Do
you think anyone really has dependencies on it and is going to want to
migrate those dependencies to 2.2?

--
Peter Hunsberger

RE: StoreJanitor


 On 4/4/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
  Ard Schrijvers wrote:
 
   yes please, I would be interested in more comments too! Are
  
   more comments like in wiki or in the cocoon.xconf more 
 comment for different configurations?
   I can try to write extended documentation on what IMO is 
 best for configuration, and tricks to
   avoid the StoreJanitor mechanism
 
  I'm interested in further comments by you too, but actually 
 I meant that other
  people should comment on our plan to change the behaviour 
 of StoreJanitor.
 
 Personally, I wonder if you can't just get rid of it altogether? 

Yes we can, but we have to make sure the default store configurations are such 
that 
the maxdiskelements is not set to indefinitely in combination of 
time2liveseconds and
time2idleseconds of 0, or eternal = true. This would mean, cache would always 
fill all 
available memory in the end. Proper configured defaults should make the 
StoreJanitor redundant.

Ard

 Do
 you think anyone really has dependencies on it and is going to want to
 migrate those dependencies to 2.2?
 
 -- 
 Peter Hunsberger

Re: StoreJanitor

2007-04-04 Thread Peter Hunsberger


On 4/4/07, Ard Schrijvers [EMAIL PROTECTED] wrote:


 On 4/4/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
  Ard Schrijvers wrote:
 
   yes please, I would be interested in more comments too! Are
  
   more comments like in wiki or in the cocoon.xconf more
 comment for different configurations?
   I can try to write extended documentation on what IMO is
 best for configuration, and tricks to
   avoid the StoreJanitor mechanism
 
  I'm interested in further comments by you too, but actually
 I meant that other
  people should comment on our plan to change the behaviour
 of StoreJanitor.

 Personally, I wonder if you can't just get rid of it altogether?

Yes we can, but we have to make sure the default store configurations are such 
that
the maxdiskelements is not set to indefinitely in combination of 
time2liveseconds and
time2idleseconds of 0, or eternal = true. This would mean, cache would always 
fill all
available memory in the end. Proper configured defaults should make the 
StoreJanitor
redundant.


+1 to geting rid of the thing completely  in that case

snip/

--
Peter Hunsberger

cocoon-spring-configurator in trunk not working?