Re: [RT] Escaping Sitemap Hell

2005-01-07 Thread Peter Hunsberger 
On Fri, 7 Jan 2005 17:38:35 -0600, Glen Ezkovich <[EMAIL PROTECTED]> wrote:
> 
> On Jan 7, 2005, at 1:43 PM, Peter Hunsberger wrote:
> 
> > On Fri, 07 Jan 2005 14:28:06 -0500, Stefano Mazzocchi
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> See? the problem is that you are partitioning the matching space with
> >> URL matchers... I strongly feel that most of the problems that Daniel
> >> (and you) are outlining will just go away if you used non-URL
> >> matchers.
> >
> > Although I agree that 90% of the problem seems to be a matcher issue
> > I've got to ask; what would the matchers be matching on if it's not a
> > URL?  I have a couple answers, but I'd like other opinions...
> >
> > It seems to me that Daniel might be coming at this from a mostly
> > application POV.  If so, for such cases, I think you can't _always_ be
> > quite as dogmatic about how a URL is structured; for many apps there's
> > little to no exectation of long term URI persistance/repeatability.
> 
> I don't see this. The application is the resource and it is the
> application that should have a unique identifier. If the application
> allows a user to perform multiple tasks you may want to consider each
> task a resource. 

An app may be 1000's of resources.  The issue is how to find a
rational way of getting 1000's of unique identifiers.

> The persistence of the URI in general is not that
> important from a users perspective since the URI identifies a resource
> that might be reachable from multiple URLs. What is important is that
> the URL that a user uses to reach an application persist and not change
> as long as users may use the application. 

Umm, wasn't that my point?

> We may not expect to see
> identical results each time we access http://weather.com/neworleans but
> we do expect to get the current weather forecast for New Orleans. If
> weather.com switched the URI/L to http://weather.com?city=neworleans,
> as a user I would be perturbed to say the least.

You're missing the point: weather is a published resource, it's not an
application.   Consider something like a Web hosted SFA app, something
where you need work flow. The hard point isn't getting to the app, the
hard part is partitioning the app.  You've got lots' of orthogonal
concerns (and I mean lots). URI, scheme (protocol), and request
parameters (among others) all give you ways of attacking various parts
of the problem, but when you start hosting 1000's of different app
spaces on the same machine the issue isn't as trivial as
scheme://host?couple-of-parms.  You've got to allow for variations on
authorizations, error handling, timeouts, resumed sessions, etc.

> As far as dogmatism and URL structure goes, you can always be dogmatic
> in the way you structure them. ;-)  The problem with dogmatism is that
> it does not always lead to the best solution for a given case. Then
> again sometimes it does.

And that's this issue Daniel's worried about: what's the best
solution.  (However, I'm not completely sure for what problem space.)

-- 
Peter Hunsberger

RE: [RT] Escaping Sitemap Hell

2005-01-07 Thread Conal Tuohy 
> Il giorno 06/gen/05, alle 01:54, Daniel Fagerstrom ha scritto:

> > * where repository:{1}.x.y.z exists ==> XYZPipeline
> >
> > We get the right pipeline by querying the repository instead of
> > encoding it in the URL. A further advantage is that the
> rule becomes
> > "listable" as the "where" clause in the match expresses
> what are the
> > allowed values for the wildcard.

Ugo Cei wrote:

> Unless I misinterpret what you mean, we already can do this:
>
> 
>
>  
>
> 
>
> function fun() {
>var entity = repo.query("select * from entities where id = " +
> cocoon.parameters.par + " and {x, y, z}");
>cocoon.sendPage("views/XYZPipeline", { entity : entity });
> }
>
> 
>
>   ...
> 
>
> Apart from the obviously contrived example, isn't the Flowscript just
> what we need to "get the right pipeline by querying the repository"?

I was struck by your example because right now we are revising our website
using the same technique you describe, with a single external pipeline
calling a flowscript. (BTW the revised website isn't public yet but should
be ready next month.) We're using a topic map as the metadata repository
(with TM4J). As in Daniel's example it completely decouples the external URL
space from the URLs of internal pipelines.

In the "external" sitemap, we just marshall a couple of parameters out of
the URL and request headers, and pass them to a flowscript. This is the
first time I've used flowscript, but it has been fairly easy to write and
it's worked pretty well.

The flowscript queries the topic map to find the topic to display, and the
appropriate internal pipeline to use. It also looks up other "scope" topics
which define different viewpoints of the other topics. They are such things
as different languages, and (since this is a digital library application) we
also have "simplified" and "scholarly" scopes. The flowscript traverses the
class-instance and superclass-subclass hierarchies between the topics
looking for a jxtemplate to use (in the appropriate scope). Finally it
passes the "content" topic and the "scope" topics (and a basic ontology of
other topics) to the specified jxtemplate pipeline.

> In my sitemaps, public pipelines contain almost only  and
>  (for static resources) elements. All "classical"
> generator-transformer-serializer pipelines go into an "internal-only"
> pipeline that can be called from flowscripts only.
>
> Admittedly, this is fine for webapps, and maybe not so much for
> publishing-oriented websites.

Yes I think for webapps you could do the mapping just in javascript, but for
publishing I think you really need a metadata repository of some sort. You
could use an xml document linkbase, as Daniel suggests, or a cms, or a topic
map or rdf store, or a sql db or any number of things.

Con

Bug? External redirect not working in 2.1.6

2005-01-07 Thread Mark Lundquist 
In the sitemap:


  http://foo.bar.com"/>


Result:

org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
java.io.IOException
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLP
ipeline(AbstractProcessingPipeline.java:537)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Abs
tractProcessingPipeline.java:468)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(Seri
alizeNode.java:120)
Caused by: java.io.IOException
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection
.java:602)
at
org.apache.excalibur.source.impl.URLSource.getInputStream(URLSource.java:252
)
at
org.apache.cocoon.components.source.SourceUtil.getInputSource(SourceUtil.jav
a:459)
at
org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:238)
at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.j
ava:399)
at
org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:264)
at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:117)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLP
ipeline(AbstractProcessingPipeline.java:530)
... 27 more
Caused by: java.net.UnknownHostException: foo.bar.com
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:153)
at java.net.Socket.connect(Socket.java:452)

Normally I would debug these... but my PowerBook fried itself, so I'm
reduced to trying to get by on my wife's Winblows Pee Cee, and it's not
worth it to try to get a real working environment put together here... it's
just Outlook and putty to my remote server until the lappy gets fixed...
:-(.

Anyway, I'll wait a bit, and if nobody tells me I have my head up my b*tt
I'll bugilla it.  The bug, that is -- not my head (or my b*tt!)

~ml

DO NOT REPLY [Bug 33004] - Cocoon consumes 100% of CPU and never releases it

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33004





--- Additional Comments From [EMAIL PROTECTED]  2005-01-08 01:01 ---
Java 1.4.2_06 + cocoon 2.1.6 should do a big diference:

Bug #31760 (already fixed in 2.1.6)

BTW, will be fine to use tomcat 4.1.31. See:
http://www.ip97.com/apache.org/jakarta/tomcat-4/v4.1.31/RELEASE-NOTES






-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33004] - Cocoon consumes 100% of CPU and never releases it

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33004





--- Additional Comments From [EMAIL PROTECTED]  2005-01-08 00:42 ---
Tomcat 4.1.30.

Sun JDK 1.4.2_04.

We're upgrading the JDK 1.4.2_06 to see if that makes a difference.

We have tried Cocoon 2.1.6 yet. It will take awhile to do the functional testing
of our application with 2.1.6, so we haven't moved yet.

-James

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [RT] Escaping Sitemap Hell

2005-01-07 Thread Glen Ezkovich 
On Jan 7, 2005, at 1:43 PM, Peter Hunsberger wrote:
On Fri, 07 Jan 2005 14:28:06 -0500, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
See? the problem is that you are partitioning the matching space with
URL matchers... I strongly feel that most of the problems that Daniel
(and you) are outlining will just go away if you used non-URL 
matchers.
Although I agree that 90% of the problem seems to be a matcher issue
I've got to ask; what would the matchers be matching on if it's not a
URL?  I have a couple answers, but I'd like other opinions...
It seems to me that Daniel might be coming at this from a mostly
application POV.  If so, for such cases, I think you can't _always_ be
quite as dogmatic about how a URL is structured; for many apps there's
little to no exectation of long term URI persistance/repeatability.
I don't see this. The application is the resource and it is the 
application that should have a unique identifier. If the application 
allows a user to perform multiple tasks you may want to consider each 
task a resource. The persistence of the URI in general is not that 
important from a users perspective since the URI identifies a resource 
that might be reachable from multiple URLs. What is important is that 
the URL that a user uses to reach an application persist and not change 
as long as users may use the application. We may not expect to see 
identical results each time we access http://weather.com/neworleans but 
we do expect to get the current weather forecast for New Orleans. If 
weather.com switched the URI/L to http://weather.com?city=neworleans, 
as a user I would be perturbed to say the least.

As far as dogmatism and URL structure goes, you can always be dogmatic 
in the way you structure them. ;-)  The problem with dogmatism is that 
it does not always lead to the best solution for a given case. Then 
again sometimes it does.


Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

DO NOT REPLY [Bug 33004] - Cocoon consumes 100% of CPU and never releases it

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33004





--- Additional Comments From [EMAIL PROTECTED]  2005-01-08 00:10 ---
Please provide more info:

tomcat and JVM version.

have you tried cocoon 2.1.6?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33003] - "context:" psuedo protocol no longer available in TraxTransformer

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33003


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |critical
   Priority|P2  |P1




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33004] - Cocoon consumes 100% of CPU and never releases it

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33004


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33004] New: - Cocoon consumes 100% of CPU and never releases it

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33004

   Summary: Cocoon consumes 100% of CPU and never releases it
   Product: Cocoon 2
   Version: 2.1.5
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: general components
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


This problem recently cropped up when we put a flowscript/jxtemplate application
into production. The problem appears to be load related and we haven't been able
reproduce it in test conditions yet due to lack of resources (time and 
hardware).

After running normally for a time (the amount varies and appears to decrease as
the load increases) the Tomcat process running Cocoon pegs the CPU at 100%.
After stopping Apache HTTP to route users around the server the CPU never calms
back down.

>From comparing thread dumps of normal operation with the runaway condition it
looks like the problem is related to XSL transformer somehow. Here's a snip from
a thread dump during the runaway condition:

---
"TP-Processor1" daemon prio=5 tid=0x37056b80 nid=0x7c0 runnable 
[3927e000..3927fdb0]
 at java.util.Vector.indexOf(Vector.java:362)
 - waiting to lock <0x182fc440> (a java.util.Vector)
 at 
org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.endPrefixMapping(SAX2DTM.java:1794)
 at
org.apache.xalan.transformer.TransformerHandlerImpl.endPrefixMapping(TransformerHandlerImpl.java:455)
 at
org.apache.cocoon.xml.AbstractXMLPipe.endPrefixMapping(AbstractXMLPipe.java:77)
 at
org.apache.cocoon.components.EnvironmentChanger.endPrefixMapping(EnvironmentStack.java:117)
 at
org.apache.cocoon.xml.AbstractXMLPipe.endPrefixMapping(AbstractXMLPipe.java:77)
 at
org.apache.cocoon.components.EnvironmentChanger.endPrefixMapping(EnvironmentStack.java:117)
 at
org.apache.xml.serializer.NamespaceMappings.popNamespaces(NamespaceMappings.java:247)
 at
org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:270)
 at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:119)
 at
org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:395)
 at
org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:177)
 at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2336)
 at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:682)
 at
org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemForEach.java:420)
 at org.apache.xalan.templates.ElemForEach.execute(ElemForEach.java:259)
 at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2336)
 at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:682)
 at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2336)
 at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:682)
 at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2336)
 at
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2202)
 at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1276)
 - locked <0x182fba98> (a org.apache.xml.serializer.ToXMLSAXHandler)
 at 
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3383)
-

Does anyone have any idea what could be causing the runaway CPU consumption? Is
this something anyone else has encountered, or is it most likely something
unique to our application?

-James

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33003] New: - "context:" psuedo protocol no longer available in TraxTransformer

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33003

   Summary: "context:" psuedo protocol no longer available in
TraxTransformer
   Product: Cocoon 2
   Version: 2.1.6
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


http://marc.theaimsgroup.com/?t=11049697654&r=1&w=2

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [BUG?] JavaFlow and getComponent

2005-01-07 Thread Torsten Curdt 
What problems do you have?

I have compiled the trunk with the javaflow block. But when I tried to 
execute the flow, I got the following exception:
Cocoon trunk uses javaflow with the compiling classloader.
Do you have your source files under build/webapp/WEB-INF/src?
I saw the classes in WEB-INF but they're not included in the build. Just 
the source AbstractContinuation.java is included but not compiled. Is 
this right?
build/webapp/WEB-INF/src$ find -name *.java
./org/apache/cocoon/forms/flow/java/FormInstance.java
./org/apache/cocoon/samples/flow/java/CalculatorFlow.java
./org/apache/cocoon/samples/flow/java/PersistenceFlow.java
./org/apache/cocoon/samples/flow/java/FormFlow.java
./org/apache/cocoon/components/flow/java/AbstractContinuable.java
The compilation happens in memory.
Don't expect to see any .class files.
cheers
--
Torsten

Re: [BUG?] JavaFlow and getComponent

2005-01-07 Thread Stephan Coboos 
Torsten Curdt wrote:
JavaFlow doesn't work in trunk at all, because the class 
AbstractContinuation doesn't exist either in 
cocoon-javaflow.block.jar nor in src. There are just these few 
classes in org\apache\cocoon\components\flow\java:
CocoonContinuationContext.class
JavaInterpreter.class
VarMap.class
VarMapHandler.class

Things are pretty different
...but I am pretty sure it's working ;-)

What problems do you have?
I have compiled the trunk with the javaflow block. But when I tried to 
execute the flow, I got the following exception:

2005-01-07 13:59:46 StandardWrapperValve[Cocoon]: Servlet.service() for 
servlet Cocoon threw exception
java.lang.NoClassDefFoundError: 
org/apache/cocoon/components/flow/java/AbstractContinuable
   at java.lang.ClassLoader.defineClass0(Native Method)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
   at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
   at 
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1634)
   at 
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:860)
   at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1307)
   at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1189)
   at 
org.apache.jci.ResourceStoreClassLoader.loadClass(ResourceStoreClassLoader.java:56)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:235)

I saw the classes in WEB-INF but they're not included in the build. Just 
the source AbstractContinuation.java is included but not compiled. Is 
this right?

--
Regards
Stephan

Re: [RT] Escaping Sitemap Hell

2005-01-07 Thread Peter Hunsberger 
On Fri, 07 Jan 2005 14:28:06 -0500, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:



> >
> > Forrest is doing it for docs... someone else can do it for apps :-)
> 
> See? the problem is that you are partitioning the matching space with
> URL matchers... I strongly feel that most of the problems that Daniel
> (and you) are outlining will just go away if you used non-URL matchers.

Although I agree that 90% of the problem seems to be a matcher issue
I've got to ask; what would the matchers be matching on if it's not a
URL?  I have a couple answers, but I'd like other opinions...

It seems to me that Daniel might be coming at this from a mostly
application POV.  If so, for such cases, I think you can't _always_ be
quite as dogmatic about how a URL is structured; for many apps there's
little to no exectation of long term URI persistance/repeatability.

-- 
Peter Hunsberger  

(Won't be able to respond untili Wed.)

Re: [RT] Escaping Sitemap Hell

2005-01-07 Thread Stefano Mazzocchi 
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
...
A real map for the site should be tree structured like the linkmap in 
forrest. Take a look at the example in [1], (I don't suggest using 
the "free form" XML, something stricter is required). Such a tree 
model will also help in planning the URI space as it gives a good 
overview of it.

Forrest and cocoon serve different purposes.
While I totally welcome the fact that Forrest has such "linkmaps", I 
don't think they are general-enough concepts to drive the entire 
framework. They are fine as specific cases, especially appealing for a 
website generation facility like forrest, but as a general concept is 
too weak.

While I agree with your reply, I think that I understand what problem 
Daniel thinks he sees.

 A sitemap is not the _map_ of a _site_.
That's why we made site.xml.
But saying that this should drive processing is IMHO not correct. In 
fact, it's the opposite. We made the site.xml stuff in a different file 
so that it would *not* interfere with processing.
Right. I see that.
...
Choosing Production Pipeline

...
Now instead of having the rule:
*.x.y.z ==> XYZPipeline
we have
* where repository:{1} have properites {x, y, z} ==> XYZPipeline
or
* where repository:{1}.x.y.z exists ==> XYZPipeline

Oh, a rule system for sitemap!
h, interesting... know what? the above smells a *lot* like you are 
querying RDF. h...

At Forrest, we have done a similar thing, and are still in the process 
of finishing it. IT states something like this:

 "Forrest processing should not be tied to URLs."
IOW, Forrest should not process a file differently just because it's in 
a particular directory, but using other characteristics, like mime-type, 
DTD, schema, etc. For us, an URL is a partitioning decision of the 
content creator, not of the application creator.

Many sites fail to do this, and URL matching has become the easiest way 
of partitioning Cocoon's processing, although not the best.

You can make your own matcher... and here is where we should 
concentrate, by defining new blueprints that don't use the URL as a 
matching system.

Forrest is doing it for docs... someone else can do it for apps :-)
See? the problem is that you are partitioning the matching space with 
URL matchers... I strongly feel that most of the problems that Daniel 
(and you) are outlining will just go away if you used non-URL matchers.

--
Stefano.

Re: svn commit: r124480 - in cocoon/branches/BRANCH_2_1_X: . src/blocks/portal/java/org/apache/cocoon/portal/components/modules/input src/blocks/portal/samples/skins/basic src/blocks/portal/samples/skins/basic/images src/blocks/portal/samples/skins/common src/blocks/portal/samples/skins/common/images

2005-01-07 Thread Joerg Heinicke 
On 07.01.2005 12:42, [EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Fri Jan  7 03:42:22 2005
New Revision: 124480
URL: http://svn.apache.org/viewcvs?view=rev&rev=124480
Log:
Fix paths
Added:
   cocoon/branches/BRANCH_2_1_X/org.apache.ojb.log
   
cocoon/branches/BRANCH_2_1_X/src/blocks/portal/samples/skins/basic/images/thumb.jpg
  - copied unchanged from r124479, 
cocoon/branches/BRANCH_2_1_X/src/blocks/portal/samples/skins/basic/thumb.jpg
   
cocoon/branches/BRANCH_2_1_X/src/blocks/portal/samples/skins/common/images/thumb.jpg
   (contents, props changed)
Removed:
   cocoon/branches/BRANCH_2_1_X/src/blocks/portal/samples/skins/basic/thumb.jpg
   cocoon/branches/BRANCH_2_1_X/src/blocks/portal/samples/skins/common/thumb.jpg
Modified:
   
cocoon/branches/BRANCH_2_1_X/src/blocks/portal/java/org/apache/cocoon/portal/components/modules/input/SkinModule.java
Where all the files added by intent? Especially org.apache.ojb.log.
Joerg

Re: ANN: [portal] New CachingPortletAdapter

2005-01-07 Thread Carsten Ziegeler 
DURDINA Michal wrote:
Sorry for just a quick response.
JSR168 - portlet specification really defines something like "expiration cache", which when set to -1 should provide caching of portlet content. 

But as I see it:
 * according to spec, implementation of caching is optional for portlet 
container
 * content would be cached also with translated links (conflict with 
DefaultEventConverter - that generates links only with one request validity)
 * portal samples already contains -1 but 
caching is not working (try to output current time in TestPortlet - it will always refresh)
 * yet must investigate pluto distribution wheter caching is supported by pluto 
container at all
If the caching as outlined in the spec is not working in Cocoon, we have 
to first fix this to be jsr 168 compliant. So, let's wait for the results.

Carsten

RE: ANN: [portal] New CachingPortletAdapter

2005-01-07 Thread DURDINA Michal 
Sorry for just a quick response.

JSR168 - portlet specification really defines something like "expiration 
cache", which when set to -1 should provide caching of portlet content. 

But as I see it:
 * according to spec, implementation of caching is optional for portlet 
container
 * content would be cached also with translated links (conflict with 
DefaultEventConverter - that generates links only with one request validity)
 * portal samples already contains -1 but 
caching is not working (try to output current time in TestPortlet - it will 
always refresh)
 * yet must investigate pluto distribution wheter caching is supported by pluto 
container at all

Michal

> -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 07, 2005 1:14 PM
> To: dev@cocoon.apache.org
> Subject: Re: ANN: [portal] New CachingPortletAdapter
> 
> 
> Hi,
> 
> the portlet standard already supports caching; each portlet can be 
> configured to be cached and the portlet container (in our case pluto)
> should cache the content.
> So I think our portal already does the caching. Or do I 
> oversee something?
> 
> Carsten
> 
> DURDINA Michal wrote:
> > Hi,
> > after some days of coding I finished the implementation of 
> CachingPortletAdapter ! With CachingPortletAdapter you can 
> have JSR168 portlets that behave (almost) exactly as they 
> were every opened in single web browsers. This means that 
> only one portlet that triggered the action is regenerated at 
> the time. Content of other portlets are returned from cache. 
> Porlet content caching was also possible using non-caching 
> PortletAdapter, but developers needed to implement caching 
> behaviour inside their portlets. Moreover changing portlet 
> window state (maximize/minimize/normalize) can be now 
> optionally handled just by portal without calling the 
> portlet. This code is already in our application and is 
> already tested.
> > 
> > CachingPortletAdapter works on these principles:
> >  * portlet hyperlinks are cached with contents
> >  * links for window icons have different validity category 
> mode that links located in content
> >  * fullscreen state stored on session
> > 
> > Some extensions to existing implementation was required:
> >  * added links validity categories to EventConverter 
> (request, half-session, session, permanent)
> >  * new CopletLinkingEventConverter that implements 
> half-session links validity
> >  * new PortletInstanceEvent implemented by 
> PortletURLProviderImpl to distinguish that portlet events are 
> NOT targeted to CachingURICopletAdapter (caused conflict)
> >  * storing EntryLayout (fullscreen) to PortalService 
> attribute (session) instead of temporaryAttribute (request)
> >  * refactoring of caching methods to new CopletCache class
> >  * refactoring of portlet content loading to 
> loadPortletContent method
> >  * all changes are backwards compatible
> > 
> > CachingPortletAdapter in hierarchy of coplet adapters:
> > AbstractCopletAdapter
> > PortletAdapter  URICopletAdapter
> > CachingPortletAdapter   CachingURICopletAdapter
> > ApplicationCopletAdapter
> > 
> > The code is submitted in bugzilla:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=32991
> > 
> > The code contains modified samples that demonstrate new 
> portlet caching ability. It has been tested with 
> cocoon-2.1.6. Please take a look at it and possibly apply it 
> to BRANCH_2_1_X and thereafter to trunk.
> > 
> > Thank you,
> > Michal
> > 
> > 
> >>-Original Message-
> >>From: Ralph Goers [mailto:[EMAIL PROTECTED]
> >>Sent: Wednesday, December 08, 2004 4:50 PM
> >>To: dev@cocoon.apache.org
> >>Subject: RE: [portal] Need for CachingPortletAdapter
> >>
> >>
> >>Michal,
> >>
> >>Unfortunately, I have a lot on my plate right now. I'm going 
> >>to have to do
> >>some research to look into your proposals below and so I 
> >>won't be able to
> >>give you my opinion for a few days. But I don't want you to 
> think I am
> >>ignoring this.
> >>
> >>Ralph
> >>
> >>
> >>ÏURDINA Michal said:
> >>
> >>>Hi,
> >>>I got finally into PageLabels that are implemented in 
> >>
> >>portal block in
> >>
> >>>cocoon 2.1.6 and documented at
> >>>http://wiki.apache.org/cocoon/PortalPageLabels.
> >>>
> >>>Ralf Goers wrote on
> >>>
> >>
> >>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=11019115492
> 5434&w=2:
> >>
> >Main issue I see in implementing CachingPortletAdapter is
> 
> "link translation".
> 
> >1.) links that are sent to browser are valid only for the
> 
> next request
> 
> >2.) translated links are part of generated content
> >3.) portlet content cannot be cached since its links will
> 
> not be valid after next request
> 
> >
> If you use PageLabels the above is not true.  Events are 
> >>
> >>valid until
> >>
> they are regenerated on the next request to that page label.
> >>>
> >>>It i

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Carsten Ziegeler 
Stefano Mazzocchi wrote:
Carsten, too early. Now that avalon is closed, nobody is going to modify 
those classes in a non-compatible way.
That's true.
There is *less* to worry about now than in the past.
>
>
> Let's try to act rationally people, if ain't broken, don't try to fix it.
>
I'm not worrying about avalon (or excalibur) and their future. Once we 
had the agreement to move away from marker interfaces to POJOs - one 
remaining piece for this is in fact logging. But it's true that we don't 
have to do it today, we have time. Personally I like to introduce an 
alternative very early in time and have a long migration phase. But I 
have no problem with leaving things as they are.
So let's drop this topic and finish the virtual sitemap components. Someone?

Carsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Stefano Mazzocchi 
Carsten Ziegeler wrote:
Torsten Curdt wrote:
Is there any technical reason to switch from the Avalon Logger
abstraction?

No.

Well ...then that's no good reason to me.
Rather I would also import the few classes
into out repository (like we did with ECM)
than doing the switch.
We can't import the classes in this case as these are interfaces. For 
ECM we could provide our own implementation, but - for now - we are 
still using the interfaces of the avalon framework. We agreed to move 
away someday from these interfaces - and part of this logging discussion 
is exactly about this: moving away from the avalon interfaces.
Carsten, too early. Now that avalon is closed, nobody is going to modify 
those classes in a non-compatible way.

There is *less* to worry about now than in the past.
Let's try to act rationally people, if ain't broken, don't try to fix it.
--
Stefano.

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Stefano Mazzocchi 
Nicola Ken Barozzi wrote:
Torsten Curdt wrote:
If you prefer commons logging over it, please write a technical 
motivation about it.

As I already said: I don't see the point of this parameter stuff.

Then don't use the parameter stuff.
IMO this only leads to mixing of concepts. 

What concepts? Remember that python and Java 1.5 have this capability, 
because it's useful... are they both so wrong?

Some people will
use the "{}" some won't. To be honest I would not feel very happy
with UGLI since IMHO this interface is only half-backed. Sorry.

Half baked because it has "the parameter stuff"?
Remember that log4j uses that interface. Is log4j also half-baked?
...and I don't see point of getting rid of the Avalon Logger
dependency and introducing the UGLI dependency instead. Only
because we want to get rid of Avalon?

Yes.
Is there any technical reason to switch from the Avalon Logger
abstraction?

No.
People, enough bike shedding already.
Nicola, UGLI is a nice attempt and an improvement over existing stuff, 
but Torsten is right: without Java 1.5/python/C unlimited parameter 
passing style, it's clearly a hack.

Carsten understimated the amount of establishment (rational or 
irrational) on top of the existing logging environments.

I say we move on to move important things.
--
Stefano.

DO NOT REPLY [Bug 32994] - [PATCH] Portal samples: missing CachingURICopletAdapter example

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32994





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 15:59 ---
Created an attachment (id=13927)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13927&action=view)
RELEASE_2_1_6_cachinggallerysample.diff


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32994] New: - [PATCH] Portal samples: missing CachingURICopletAdapter example

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32994

   Summary: [PATCH] Portal samples: missing CachingURICopletAdapter
example
   Product: Cocoon 2
   Version: 2.1.6
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P5
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Using CachingURICopletAdapter has a small trap: hyperlinks in coplet content 
must not be cached translated. Link Translation must be performed for every 
request in portal sitemap instead of coplet sitemap. This is not obvious from 
provided portal samples. There have been mails on users-list that required help 
about this behaviour.

This patch contains modified Gallery example that demonstrates use of 
CachingURICopletAdpater and comments link translation trap.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Ralph Goers 
Carsten Ziegeler wrote:
Hmm, we have discussed this topic very lengthy and to summarize
it, we don't want to have dependencies for the core which
translates to: we don't want the core to depend on avalon.
On the technical side this means: moving from marker interfaces to POJOs.
With ECM++ ..eh..our own container, we are free to do what we want and 
we can provide a smooth migration path.
Ok, so copy the interfaces from Avalon and name then o.a.c.whatever.
Ralph

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Carsten Ziegeler 
Torsten Curdt wrote:
They would no longer be the "avalon interfaces"
..or is the ECM++ still avalon?
What was the reason again to move exchange the
abstraction layer? ...not talking about the
implementation.
Sorry, guys this discussion getting a bit absurd to me.
Hmm, we have discussed this topic very lengthy and to summarize
it, we don't want to have dependencies for the core which
translates to: we don't want the core to depend on avalon.
On the technical side this means: moving from marker interfaces to POJOs.
With ECM++ ..eh..our own container, we are free to do what we want and 
we can provide a smooth migration path.

Carsten

Re: [BUG?] JavaFlow and getComponent

2005-01-07 Thread Torsten Curdt 
JavaFlow doesn't work in trunk at all, because the class 
AbstractContinuation doesn't exist either in cocoon-javaflow.block.jar 
nor in src. There are just these few classes in 
org\apache\cocoon\components\flow\java:
CocoonContinuationContext.class
JavaInterpreter.class
VarMap.class
VarMapHandler.class

Things are pretty different
...but I am pretty sure it's working ;-)
What problems do you have?
cheers
--
Torsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Torsten Curdt 
Is there any technical reason to switch from the Avalon Logger
abstraction?
No.
Well ...then that's no good reason to me.
Rather I would also import the few classes
into out repository (like we did with ECM)
than doing the switch.
We can't import the classes in this case as these are interfaces. For 
> ECM we could provide our own implementation, but - for now - we are
> still using the interfaces of the avalon framework.
...well interfaces then - whatever.
We agreed to move 
away someday from these interfaces - and part of this logging discussion 
is exactly about this: moving away from the avalon interfaces.
They would no longer be the "avalon interfaces"
..or is the ECM++ still avalon?
What was the reason again to move exchange the
abstraction layer? ...not talking about the
implementation.
Sorry, guys this discussion getting a bit absurd to me.
--
Torsten

Re: [BUG?] JavaFlow and getComponent

2005-01-07 Thread Torsten Curdt 
JavaFlow doesn't work in trunk at all, because the class 
AbstractContinuation doesn't exist either in cocoon-javaflow.block.jar 
nor in src. There are just these few classes in 
org\apache\cocoon\components\flow\java:
CocoonContinuationContext.class
JavaInterpreter.class
VarMap.class
VarMapHandler.class
Things are pretty different
...but I am pretty sure it's working ;-)
Some classes moved either into the javaflow jar or are going
to be compiled at runtime and therefor are in the source
repository under WEB-INF.
cheers
--
Torsten

Re: [BUG?] JavaFlow and getComponent

2005-01-07 Thread Stephan Coboos 

It would also be great if you could
try cocoon-trunk and report back. 
Hi Torsten,
JavaFlow doesn't work in trunk at all, because the class 
AbstractContinuation doesn't exist either in cocoon-javaflow.block.jar 
nor in src. There are just these few classes in 
org\apache\cocoon\components\flow\java:
CocoonContinuationContext.class
JavaInterpreter.class
VarMap.class
VarMapHandler.class

--
Regards
Stephan

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Carsten Ziegeler 
Torsten Curdt wrote:
Is there any technical reason to switch from the Avalon Logger
abstraction?

No.

Well ...then that's no good reason to me.
Rather I would also import the few classes
into out repository (like we did with ECM)
than doing the switch.
We can't import the classes in this case as these are interfaces. For 
ECM we could provide our own implementation, but - for now - we are 
still using the interfaces of the avalon framework. We agreed to move 
away someday from these interfaces - and part of this logging discussion 
is exactly about this: moving away from the avalon interfaces.

Carsten

Re: ANN: [portal] New CachingPortletAdapter

2005-01-07 Thread Carsten Ziegeler 
Hi,
the portlet standard already supports caching; each portlet can be 
configured to be cached and the portlet container (in our case pluto)
should cache the content.
So I think our portal already does the caching. Or do I oversee something?

Carsten
DURDINA Michal wrote:
Hi,
after some days of coding I finished the implementation of 
CachingPortletAdapter ! With CachingPortletAdapter you can have JSR168 portlets 
that behave (almost) exactly as they were every opened in single web browsers. 
This means that only one portlet that triggered the action is regenerated at 
the time. Content of other portlets are returned from cache. Porlet content 
caching was also possible using non-caching PortletAdapter, but developers 
needed to implement caching behaviour inside their portlets. Moreover changing 
portlet window state (maximize/minimize/normalize) can be now optionally 
handled just by portal without calling the portlet. This code is already in our 
application and is already tested.
CachingPortletAdapter works on these principles:
 * portlet hyperlinks are cached with contents
 * links for window icons have different validity category mode that links 
located in content
 * fullscreen state stored on session
Some extensions to existing implementation was required:
 * added links validity categories to EventConverter (request, half-session, 
session, permanent)
 * new CopletLinkingEventConverter that implements half-session links validity
 * new PortletInstanceEvent implemented by PortletURLProviderImpl to 
distinguish that portlet events are NOT targeted to CachingURICopletAdapter 
(caused conflict)
 * storing EntryLayout (fullscreen) to PortalService attribute (session) 
instead of temporaryAttribute (request)
 * refactoring of caching methods to new CopletCache class
 * refactoring of portlet content loading to loadPortletContent method
 * all changes are backwards compatible
CachingPortletAdapter in hierarchy of coplet adapters:
AbstractCopletAdapter
PortletAdapter  URICopletAdapter
CachingPortletAdapter   CachingURICopletAdapter
ApplicationCopletAdapter
The code is submitted in bugzilla:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32991
The code contains modified samples that demonstrate new portlet caching 
ability. It has been tested with cocoon-2.1.6. Please take a look at it and 
possibly apply it to BRANCH_2_1_X and thereafter to trunk.
Thank you,
Michal

-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 08, 2004 4:50 PM
To: dev@cocoon.apache.org
Subject: RE: [portal] Need for CachingPortletAdapter
Michal,
Unfortunately, I have a lot on my plate right now. I'm going 
to have to do
some research to look into your proposals below and so I 
won't be able to
give you my opinion for a few days. But I don't want you to think I am
ignoring this.

Ralph
ÏURDINA Michal said:
Hi,
I got finally into PageLabels that are implemented in 
portal block in
cocoon 2.1.6 and documented at
http://wiki.apache.org/cocoon/PortalPageLabels.
Ralf Goers wrote on
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110191154925434&w=2:
Main issue I see in implementing CachingPortletAdapter is
"link translation".
1.) links that are sent to browser are valid only for the
next request
2.) translated links are part of generated content
3.) portlet content cannot be cached since its links will
not be valid after next request

If you use PageLabels the above is not true.  Events are 
valid until
they are regenerated on the next request to that page label.
It is not exactly so. Lifecycle of links when using 
PageLabels is very
simmilar to that in the original DefaultEventConverter. They are
genereated and stored to ENCODE hashmap in the coplet 
generation phase and
live until the portal tab page is generated again. Links 
are preserved
ONLY when switching form one tagged page to another tagged page.
Therefore I refine my statements of issues for implementing
CachingPortletAdapter (using PageLabels):
1.) links that are sent to browser are valid only for the 
next request
(unless the tagged page is switched)
2.) translated links are part of generated content
3.) portlet content cannot be cached since its links will 
not be valid
after next request to the same tagged page
I have CachingPortletAdapter finished, but I must solve the 
problem with
links to make it working.
I see these possibilities:
A.) invert the responsibility and let the coplets to 
maintain lifecycle of
their events/links
- coplet will add the event to store (EventConverter) on content
generation
- coplet will remember its own list of its events
- coplet will remove its remembered old events from the store when
regenerating or removing (logout)
- EventConverter will not remove events
B.) enhance PageLabelEventConverter and add name of coplet 
instance to key
for events store
- currently only page tab name is used for pageLabel parameter i.e.
port

Re: fb:insert-bean & class hierarchies

2005-01-07 Thread Torsten Curdt 
Gianugo Rabellino wrote:
Pardon me if this has been discussed already... I did some quick
search and was unable to find anything relevant.
We are currently being severely bitten by a limitation in the Java
reflection API that hits on fb:insert-bean.
Huh? ...you mean not providing the methods of
the base classes?
If class B extends A, and
you have a method in your binding base such as
void addA(A a)
you cannot bind it using a B instance since Java will complain about
not finding a
void addA(B b)
method.
I am not sure how the insert-bean works but is
due to the inheritance or the overloading?
Maybe have a look at the ReflectionUtils (cocoon repo).
cheers
--
Torsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Gianugo Rabellino 
On Fri, 07 Jan 2005 12:26:12 +0100, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> >> IMO this only leads to mixing of concepts.
> >
> >
> > What concepts? Remember that python and Java 1.5 have this capability,
> > because it's useful... are they both so wrong?
> 
> No ...it *is* useful!! ...a variable amount
> of parameters!

Bah, I don't like varargs that much, it's just syntax sugar adding
opacity in exchange for a few keystrokes. The compiler is changing
varargs into arrays, and the receiving method needs to be written
against an array anyway, so why bother?

> >> Some people will
> >> use the "{}" some won't. To be honest I would not feel very happy
> >> with UGLI since IMHO this interface is only half-backed. Sorry.
> >
> >
> > Half baked because it has "the parameter stuff"?
> 
> Either make it use the 1.5 stuff (and make
> 1.5 a requirement) or leave it out ...but
> this mixture is what I call half baked.
> 
> > Remember that log4j uses that interface. Is log4j also half-baked?

Not quite, but still this shaky interface adds up to the list of Log4J
poorly engineered stuff that makes me wish for an interface to isolate
myself from it (even though I do reckon that we have to suppport it
given how pervasive it has become). UGLI looks like the less worst
alternative, so I can digest it. But getting to like that... well,
that's entirely another issue.

Ciao,
-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Torsten Curdt 
IMO this only leads to mixing of concepts. 

What concepts? Remember that python and Java 1.5 have this capability, 
because it's useful... are they both so wrong?
No ...it *is* useful!! ...a variable amount
of parameters!
Some people will
use the "{}" some won't. To be honest I would not feel very happy
with UGLI since IMHO this interface is only half-backed. Sorry.

Half baked because it has "the parameter stuff"?
Either make it use the 1.5 stuff (and make
1.5 a requirement) or leave it out ...but
this mixture is what I call half baked.
Remember that log4j uses that interface. Is log4j also half-baked?
Also with the parameters? ...wasn't aware
of that ...but my opinion would still apply.
...and I don't see point of getting rid of the Avalon Logger
dependency and introducing the UGLI dependency instead. Only
because we want to get rid of Avalon?
Yes.
Is there any technical reason to switch from the Avalon Logger
abstraction?
No.
Well ...then that's no good reason to me.
Rather I would also import the few classes
into out repository (like we did with ECM)
than doing the switch.
cheers
--
Torsten

ANN: [portal] New CachingPortletAdapter

2005-01-07 Thread DURDINA Michal 
Hi,
after some days of coding I finished the implementation of 
CachingPortletAdapter ! With CachingPortletAdapter you can have JSR168 portlets 
that behave (almost) exactly as they were every opened in single web browsers. 
This means that only one portlet that triggered the action is regenerated at 
the time. Content of other portlets are returned from cache. Porlet content 
caching was also possible using non-caching PortletAdapter, but developers 
needed to implement caching behaviour inside their portlets. Moreover changing 
portlet window state (maximize/minimize/normalize) can be now optionally 
handled just by portal without calling the portlet. This code is already in our 
application and is already tested.

CachingPortletAdapter works on these principles:
 * portlet hyperlinks are cached with contents
 * links for window icons have different validity category mode that links 
located in content
 * fullscreen state stored on session

Some extensions to existing implementation was required:
 * added links validity categories to EventConverter (request, half-session, 
session, permanent)
 * new CopletLinkingEventConverter that implements half-session links validity
 * new PortletInstanceEvent implemented by PortletURLProviderImpl to 
distinguish that portlet events are NOT targeted to CachingURICopletAdapter 
(caused conflict)
 * storing EntryLayout (fullscreen) to PortalService attribute (session) 
instead of temporaryAttribute (request)
 * refactoring of caching methods to new CopletCache class
 * refactoring of portlet content loading to loadPortletContent method
 * all changes are backwards compatible

CachingPortletAdapter in hierarchy of coplet adapters:
AbstractCopletAdapter
PortletAdapter  URICopletAdapter
CachingPortletAdapter   CachingURICopletAdapter
ApplicationCopletAdapter

The code is submitted in bugzilla:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32991

The code contains modified samples that demonstrate new portlet caching 
ability. It has been tested with cocoon-2.1.6. Please take a look at it and 
possibly apply it to BRANCH_2_1_X and thereafter to trunk.

Thank you,
Michal

> -Original Message-
> From: Ralph Goers [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 08, 2004 4:50 PM
> To: dev@cocoon.apache.org
> Subject: RE: [portal] Need for CachingPortletAdapter
> 
> 
> Michal,
> 
> Unfortunately, I have a lot on my plate right now. I'm going 
> to have to do
> some research to look into your proposals below and so I 
> won't be able to
> give you my opinion for a few days. But I don't want you to think I am
> ignoring this.
> 
> Ralph
> 
> 
> ÏURDINA Michal said:
> > Hi,
> > I got finally into PageLabels that are implemented in 
> portal block in
> > cocoon 2.1.6 and documented at
> > http://wiki.apache.org/cocoon/PortalPageLabels.
> >
> > Ralf Goers wrote on
> > 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110191154925434&w=2:
> >> >Main issue I see in implementing CachingPortletAdapter is
> >> "link translation".
> >> > 1.) links that are sent to browser are valid only for the
> >> next request
> >> > 2.) translated links are part of generated content
> >> > 3.) portlet content cannot be cached since its links will
> >> not be valid after next request
> >> >
> >> >
> >> If you use PageLabels the above is not true.  Events are 
> valid until
> >> they are regenerated on the next request to that page label.
> >
> > It is not exactly so. Lifecycle of links when using 
> PageLabels is very
> > simmilar to that in the original DefaultEventConverter. They are
> > genereated and stored to ENCODE hashmap in the coplet 
> generation phase and
> > live until the portal tab page is generated again. Links 
> are preserved
> > ONLY when switching form one tagged page to another tagged page.
> >
> > Therefore I refine my statements of issues for implementing
> > CachingPortletAdapter (using PageLabels):
> > 1.) links that are sent to browser are valid only for the 
> next request
> > (unless the tagged page is switched)
> > 2.) translated links are part of generated content
> > 3.) portlet content cannot be cached since its links will 
> not be valid
> > after next request to the same tagged page
> >
> > I have CachingPortletAdapter finished, but I must solve the 
> problem with
> > links to make it working.
> >
> > I see these possibilities:
> > A.) invert the responsibility and let the coplets to 
> maintain lifecycle of
> > their events/links
> >
> >  - coplet will add the event to store (EventConverter) on content
> > generation
> >  - coplet will remember its own list of its events
> >  - coplet will remove its remembered old events from the store when
> > regenerating or removing (logout)
> >  - EventConverter will not remove events
> >
> > B.) enhance PageLabelEventConverter and add name of coplet 
> instance to key
> > for events store
> >
> >  - currently only page tab name is used for

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Nicola Ken Barozzi 
Torsten Curdt wrote:
If you prefer commons logging over it, please write a technical 
motivation about it.
As I already said: I don't see the point of this parameter stuff.
Then don't use the parameter stuff.
IMO this only leads to mixing of concepts. 
What concepts? Remember that python and Java 1.5 have this capability, 
because it's useful... are they both so wrong?

Some people will
use the "{}" some won't. To be honest I would not feel very happy
with UGLI since IMHO this interface is only half-backed. Sorry.
Half baked because it has "the parameter stuff"?
Remember that log4j uses that interface. Is log4j also half-baked?
...and I don't see point of getting rid of the Avalon Logger
dependency and introducing the UGLI dependency instead. Only
because we want to get rid of Avalon?
Yes.
Is there any technical reason to switch from the Avalon Logger
abstraction?
No.
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

DO NOT REPLY [Bug 32991] - New CachingPortletAdapter

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32991





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 12:08 ---
Created an attachment (id=13923)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13923&action=view)
RELEASE_2_1_6.patch_14.diff


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32783] - [PATCH] Portlet ActionResponse.setWindowState() not working

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32783


[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||32991
  nThis||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32991] New: - New CachingPortletAdapter

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32991

   Summary: New CachingPortletAdapter
   Product: Cocoon 2
   Version: 2.1.6
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]
 BugsThisDependsOn: 32166,32783


This patch contains implementation of CachingPortletAdapter. 
CachingPortletAdapter provides caching ability for JSR168 portlets.

CachingPortletAdapter works on these principles:
 * portlet hyperlinks are cached with contents
 * links for window icons have different validity category mode that links 
located in content
 * fullscreen state stored on session

Some extensions to existing implementation was required:
 * added links validity categories to EventConverter (request, half-session, 
session, permanent)
 * new CopletLinkingEventConverter that implements half-session links validity
 * new PortletInstanceEvent implemented by PortletURLProviderImpl to 
distinguish that portlet events are NOT targeted to CachingURICopletAdapter 
(caused conflict)
 * storing EntryLayout (fullscreen) to PortalService attribute (session) 
instead of temporaryAttribute (request)
 * refactoring of caching methods to new CopletCache class
 * refactoring of portlet content loading to loadPortletContent method
 * all changes are backwards compatible

CachingPortletAdapter in hierarchy of coplet adapters:
AbstractCopletAdapter
PortletAdapter  URICopletAdapter
CachingPortletAdapter   CachingURICopletAdapter
ApplicationCopletAdapter


The code contains modified samples that demonstrate new portlet caching 
ability. It has been tested with cocoon-2.1.6. Please take a look at it and 
possibly apply it to BRANCH_2_1_X and thereafter to trunk.

Thank you,
Michal

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32166] - [PATCH] PortletWindowAspect: hiding portlet mode icons and new feature "force-sizable"

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32166


[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||32991
  nThis||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

fb:insert-bean & class hierarchies

2005-01-07 Thread Gianugo Rabellino 
Pardon me if this has been discussed already... I did some quick
search and was unable to find anything relevant.

We are currently being severely bitten by a limitation in the Java
reflection API that hits on fb:insert-bean. If class B extends A, and
you have a method in your binding base such as

void addA(A a)

you cannot bind it using a B instance since Java will complain about
not finding a

void addA(B b)

method.

Now, apart from this being quite silly from the reflection POV, is
there anything we're missing of is that a confirmed limitation? And,
if, so, would anyone here be interested in a fix? I can see three
solutions for that:

1. brute force approach: try to call the method with every possible
superclass of the parameter giving an error;

2. lookup: get all the methods, grab the one that needs to be called,
find out which is the correct superclass to use;

3. insert a "cast" semantic to the binding instruction and then cast
(using a Proxy?) to the correct implementation the class is expecting.

Of course the 4th solution still applies:

4. I'm a moron and I'm overlooking how this has been discussed at
lenght and solved long ago.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Torsten Curdt 
If you prefer commons logging over it, please write a technical 
motivation about it.
As I already said: I don't see the point of this parameter stuff.
IMO this only leads to mixing of concepts. Some people will
use the "{}" some won't. To be honest I would not feel very happy
with UGLI since IMHO this interface is only half-backed. Sorry.
...and I don't see point of getting rid of the Avalon Logger
dependency and introducing the UGLI dependency instead. Only
because we want to get rid of Avalon?
Is there any technical reason to switch from the Avalon Logger
abstraction?
cheers
--
Torsten

Re: [RT] Pre- and Postfunctions in FlowScript?

2005-01-07 Thread Leszek Gawron 
Jens Maukisch wrote:
Hi,
I recently thought about if it would be useful to
have pre- and postfunctions in FlowScript which are
excecuted before and after a normal flow-function.
The reason was that we needed some components in
every flow-function and it was not so nice to get
and release the components in each functions.
Something like this:
flow.js:
var comp1;
var comp2;
function preFunc() {
  comp1 = cocoon.getComponent("comp1");
  comp2 = cocoon.getComponent("comp2");
}
function myFlowFunction1() {
  comp1.doSomething();
  comp2.doSomething();
}
function myFlowFunction2() {
  comp1.doIt();
  comp2.soIt();
}
function postFunc() {
  cocoon.releaseComponent(comp1);
  cocoon.releaseComponent(comp2);
}
sitemap:

  


  

This would call:
preFunc();
myFlowFunction();
postFunc();
I was wondering if it would be safe to use the 'global' vars
comp1 and comp2 e.g. if a user has tow parallel requests
(race conditions?)?
This is just a basic thought and I'm not sure if it causes
more problems than it solves. :-) 

There is a cocoon block with intercepted flowscript that was supposed to 
do a functionality similar to what you describe. I am not aware of 
current state of this block though.

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: [RT] Escaping Sitemap Hell

2005-01-07 Thread Nicola Ken Barozzi 
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
...
A real map for the site should be tree structured like the linkmap in 
forrest. Take a look at the example in [1], (I don't suggest using the 
"free form" XML, something stricter is required). Such a tree model 
will also help in planning the URI space as it gives a good overview 
of it.
Forrest and cocoon serve different purposes.
While I totally welcome the fact that Forrest has such "linkmaps", I 
don't think they are general-enough concepts to drive the entire 
framework. They are fine as specific cases, especially appealing for a 
website generation facility like forrest, but as a general concept is 
too weak.
While I agree with your reply, I think that I understand what problem 
Daniel thinks he sees.

 A sitemap is not the _map_ of a _site_.
That's why we made site.xml.
But saying that this should drive processing is IMHO not correct. In 
fact, it's the opposite. We made the site.xml stuff in a different file 
so that it would *not* interfere with processing.

...
Choosing Production Pipeline

...
Now instead of having the rule:
*.x.y.z ==> XYZPipeline
we have
* where repository:{1} have properites {x, y, z} ==> XYZPipeline
or
* where repository:{1}.x.y.z exists ==> XYZPipeline

Oh, a rule system for sitemap!
h, interesting... know what? the above smells a *lot* like you are 
querying RDF. h...
At Forrest, we have done a similar thing, and are still in the process 
of finishing it. IT states something like this:

 "Forrest processing should not be tied to URLs."
IOW, Forrest should not process a file differently just because it's in 
a particular directory, but using other characteristics, like mime-type, 
DTD, schema, etc. For us, an URL is a partitioning decision of the 
content creator, not of the application creator.

Many sites fail to do this, and URL matching has become the easiest way 
of partitioning Cocoon's processing, although not the best.

You can make your own matcher... and here is where we should 
concentrate, by defining new blueprints that don't use the URL as a 
matching system.

Forrest is doing it for docs... someone else can do it for apps :-)
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

[RT] Pre- and Postfunctions in FlowScript?

2005-01-07 Thread Jens Maukisch 
Hi,

I recently thought about if it would be useful to
have pre- and postfunctions in FlowScript which are
excecuted before and after a normal flow-function.

The reason was that we needed some components in
every flow-function and it was not so nice to get
and release the components in each functions.

Something like this:

flow.js:

var comp1;
var comp2;

function preFunc() {
  comp1 = cocoon.getComponent("comp1");
  comp2 = cocoon.getComponent("comp2");
}

function myFlowFunction1() {
  comp1.doSomething();
  comp2.doSomething();
}

function myFlowFunction2() {
  comp1.doIt();
  comp2.soIt();
}

function postFunc() {
  cocoon.releaseComponent(comp1);
  cocoon.releaseComponent(comp2);
}

sitemap:

  


  


This would call:
preFunc();
myFlowFunction();
postFunc();

I was wondering if it would be safe to use the 'global' vars
comp1 and comp2 e.g. if a user has tow parallel requests
(race conditions?)?

This is just a basic thought and I'm not sure if it causes
more problems than it solves. :-) 

WDYT?


Freundliche Grüße / With kind regards
Jens Maukisch
-- 
S&N AG
Competence Center Open Source
Klingenderstr. 5 
D 33100 Paderborn

DO NOT REPLY [Bug 32986] - [PATCH] Missing ContextAttributeInputModule

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32986


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|P1  |P3




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32987] - [PATCH] Small fix that throws meaningful configuration exception on input module not found before NPE is thrown few lines lower in the code.

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32987


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|P1  |P3




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

[Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

2005-01-07 Thread Nicola Ken Barozzi 
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
How about leaving everything as is and just change the default logger 
to be log4j instead of logkit?

Hm, yeah, why not :( It seems that everyone is using different logging 
approaches, so a consensus is impossible. Sigh.
Wait, not all is lost.
Let's restart with the points I think we agree upon.
1: we want to get rid of Avalon dependency
-> get rid of logkit
2: there seems to be a general like of log4j as an implementation
-> use log4j as a standard implementation
3: we want a logging abstraction, not be tied to a concrete impl
-> use commons logging or UGLI
These points have brought us to almost say yes to Commons Logging + 
Log4j as predefined implementation.

Then I came up with proposing UGLI as an alternative abstraction, as it 
has the *same* advantages of commons logging without the configuration 
nightmare drawbacks, has some extra niceties, and is supported by log4j, 
which is the implementation that we tend to prefer.

Now, it seems to me that nobody is against UGLI instead of commons 
logging for a logging abstraction, as all things against UGLI have 
nothing to do with the comparison with commons logging but just about 
the extra features it has, which seem not so important.

Now, I propose that we use UGLI as a logging abstraction and log4j as 
the predefined logging package.

Here is the UGLI logging interface [1].
If you prefer commons logging over it, please write a technical 
motivation about it.

"
package org.apache.ugli;
public interface ULogger {
  public boolean isDebugEnabled();
  public void debug(Object msg);
  public void debug(Object parameterizedMsg, Object param1);
  public void debug(String parameterizedMsg, Object param1,
 Object param2);
  public void debug(Object msg, Throwable t);
  public boolean isInfoEnabled();
  public void info(Object msg);
  public void info(Object parameterizedMsg, Object param1);
  public void info(String parameterizedMsg, Object param1,
Object param2);
  public void info(Object msg, Throwable t);
  public boolean isWarnEnabled();
  public void warn(Object msg);
  public void warn(Object parameterizedMsg, Object param1);
  public void warn(String parameterizedMsg, Object param1,
Object param2);
  public void warn(Object msg, Throwable t);
  public boolean isErrorEnabled();
  public void error(Object msg);
  public void error(Object parameterizedMsg, Object param1);
  public void error(String parameterizedMsg, Object param1,
 Object param2);
  public void error(Object msg, Throwable t);
}
"
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/ULogger.java?rev=1.2&view=markup
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Cocoon-2.1.X Tests Failure 01/07/05

2005-01-07 Thread Vadim Gritsenko 
Automated Cocoon Unit tests failed!

Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20050107.log

Last messages from the log file:
==
  [foreach] reader-mime-type.xml:39: Starting 
http://localhost:1///samples/test/reader-mime-type/test20.html
  [foreach] reader-mime-type.xml:41: Running test [Header: Content-type = 
text/html ... done (1ms)
  [foreach] reader-mime-type.xml:39: Finished 
http://localhost:1///samples/test/reader-mime-type/test20.html (82ms)
  [foreach] reader-mime-type.xml:44: Starting 
http://localhost:1///samples/test/reader-mime-type/test20.html
  [foreach] reader-mime-type.xml:46: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:44: Finished 
http://localhost:1///samples/test/reader-mime-type/test20.html (77ms)
  [foreach] reader-mime-type.xml:50: Starting 
http://localhost:1///samples/test/reader-mime-type/test30.html
  [foreach] reader-mime-type.xml:52: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:50: Finished 
http://localhost:1///samples/test/reader-mime-type/test30.html (438ms)
  [foreach] reader-mime-type.xml:55: Starting 
http://localhost:1///samples/test/reader-mime-type/test30.html
  [foreach] reader-mime-type.xml:57: Running test [Header: Content-type = 
text/html ... done (1ms)
  [foreach] reader-mime-type.xml:55: Finished 
http://localhost:1///samples/test/reader-mime-type/test30.html (75ms)
  [foreach] reader-mime-type.xml:61: Starting 
http://localhost:1///samples/test/reader-mime-type/test40.html
  [foreach] reader-mime-type.xml:63: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:61: Finished 
http://localhost:1///samples/test/reader-mime-type/test40.html (31ms)
  [foreach] reader-mime-type.xml:66: Starting 
http://localhost:1///samples/test/reader-mime-type/test40.html
  [foreach] reader-mime-type.xml:68: Running test [Header: Content-type = 
text/html ... done (1ms)
  [foreach] reader-mime-type.xml:66: Finished 
http://localhost:1///samples/test/reader-mime-type/test40.html (27ms)
  [foreach] reader-mime-type.xml:72: Starting 
http://localhost:1///samples/test/reader-mime-type/test50.html
  [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = 
text/html  Failure: 
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:74:
  message doesn't match because header 'content-type' is not present
  [foreach] ... done (6ms)
  [foreach] reader-mime-type.xml:72: Finished 
http://localhost:1///samples/test/reader-mime-type/test50.html (43ms)
BUILD FAILED
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72:
 Task at 
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72:
  failed
Total time: 26 seconds

Last messages from the server console:
==
[EMAIL PROTECTED]: Startup sequence initiated from main() method
[EMAIL PROTECTED]: Loaded properties from 
[/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties]
[EMAIL PROTECTED]: Initiating startup sequence...
[EMAIL PROTECTED]: Server socket opened successfully in 10 ms.
[EMAIL PROTECTED]: Database [index=0, id=0, 
db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb,
 alias=] opened sucessfully in 1692 ms.
[EMAIL PROTECTED]: Startup sequence completed in 1754 ms.
[EMAIL PROTECTED]: 2005-01-07 01:28:11.505 HSQLDB server 1.7.3 is online
[EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL
[EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly
- The database 'db' root directory has been set to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind 
that if a war upgrade will take place the database will be lost.
- Database points to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db
- [main] '/db/system/SysSymbols' Set object system_SysConfig
- [main] '/db/system/SysConfig' Set document database.xml
- [main] '/db/system/SysSymbols' Set object meta_Metas
- [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig
- Database 'db' successfully opened
- Xindice server successfully started
parameter = @PARAMETER@  replaceme = replaceme-abc
parameter = @PARAMETER@  replaceme = replaceme-123
- VM shutting down with the disk store for cocoon-ehcache-1 still active. The 
disk store is persistent. Calling dispose...
- Database 'db' successfully closed
- Scheduler Cocoon_$_Fri_Jan_07_01:28:00_PST_2005 paused.
- Scheduler Cocoon_$_Fri_Jan_07_01:2

DO NOT REPLY [Bug 32988] - [PATCH] Portal - castor failes on parsing web.xml containing ejb-ref elements

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32988





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 10:33 ---
Created an attachment (id=13922)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13922&action=view)
RELEASE_2_1_6.patch_16.diff


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32988] New: - [PATCH] Portal - castor failes on parsing web.xml containing ejb-ref elements

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32988

   Summary: [PATCH] Portal - castor failes on parsing web.xml
containing ejb-ref elements
   Product: Cocoon 2
   Version: 2.1.6
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Some of web.xml elements having zero or many occurence (*) are mapped to single 
String field. As a result Castor is throwing ValidationException.

In our case the exception message was: ValidationException: "element "ejb-ref" 
occurs more than once."

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32987] - [PATCH] Small fix that throws meaningful configuration exception on input module not found before NPE is thrown few lines lower in the code.

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32987


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|blocks  |core




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32987] - [PATCH] Small fix that throws meaningful configuration exception on input module not found before NPE is thrown few lines lower in the code.

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32987





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 10:27 ---
Created an attachment (id=13921)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13921&action=view)
RELEASE_2_1_6.patch_15.diff


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32987] New: - [PATCH] Small fix that throws meaningful configuration exception on input module not found before NPE is thrown few lines lower in the code.

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32987

   Summary: [PATCH] Small fix that throws meaningful configuration
exception on input module not found before NPE is thrown
few lines lower in the code.
   Product: Cocoon 2
   Version: 2.1.6
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Small fix that throws meaningful configuration exception when input module is 
not found to prevent NPE that is thrown few lines lower in the code.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [BUG?] JavaFlow and getComponent

2005-01-07 Thread Stephan Coboos 
Torsten Curdt wrote:
What is "cocoon-trunk"?

That would be the one from svn :) Being a versioning system there
are different branches. Trunk is the main development branch.
 https://svn.apache.org/repos/asf/cocoon/trunk/
This might also help
 http://wiki.apache.org/cocoon/SubversionMigration
Thanks
--
Torsten

Ah, ok. The same as HEAD in CVS means?
Ok, I will try it in the next days if I'll find some time for it.
--
Stephan

DO NOT REPLY [Bug 32986] - [PATCH] Missing ContextAttributeInputModule

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32986





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 10:09 ---
Created an attachment (id=13920)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13920&action=view)
RELEASE_2_1_6.patch_13.diff


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32986] New: - [PATCH] Missing ContextAttributeInputModule

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32986

   Summary: [PATCH] Missing ContextAttributeInputModule
   Product: Cocoon 2
   Version: 2.1.6
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


This patch contains missing input module "context-attr" that encapsulates 
o.a.c.environment.Context#getAttribute(String).

I needed "context-attr" input module for the meta module chain of retrieving 
attribute across viarious scopes:

  
  
  
  
  
  


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32984] - [PATCH] Implementation of PortletRequest#getQueryString()

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32984





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 10:00 ---
Created an attachment (id=13919)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13919&action=view)
RELEASE_2_1_6.patch_12.diff


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32984] New: - [PATCH] Implementation of PortletRequest#getQueryString()

2005-01-07 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32984

   Summary: [PATCH] Implementation of
PortletRequest#getQueryString()
   Product: Cocoon 2
   Version: 2.1.6
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Uncompleted method PortletRequest#getQueryString() implemented.

New implementation is aggregating all portlet request parameters
and creates query string the same way as in they were from http request.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.