[TEST] please ignore
Just a test to see if my messages arrive on the list.
[TEST] please ignore (2)
Just a test to see if my messages arrive on the list.
[TEST] please ignore (3)
Just a test to see if my messages arrive on the list.
Re: Javaflow - major memory issue
On Mar 28, 2008, at 04:29, Joerg Heinicke wrote: On 27.03.2008 10:33, Torsten Curdt wrote: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660view=markup The output I showed pointed to org.apache.cocoon.components.flow.java.Continuation which only seems to exist in Cocoon 2.1. Nothing unsets the context there. Hah - well spotted! Having a look into the code continuations are only handled by JavaInterpreter. There are two methods callFunction(..) and handleContinuation(..) calling Continuation.registerThread() and deregisterThread() in a finally block. From a brief look I have no idea if I can just unset the ContinuationContext there as well. You might know more about it. We should add a try/finally block in Continuation.suspend() that clears the context after a suspend. That should fix it. cheers -- Torsten
Code freeze is over
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Grzegorz Kossakowski wrote:
Therefore I propose:
1. Make a 1.0.0 of SSF as it's now so Cocoon users can consume it and we
will be able to release other artifacts in final version. (Remember: we
can't release Cocoon Core 2.2 final if we don't have final release of
SSF)
Ok. Then I will create the release artifacts for
cocoon-parent
cocoon-servlet-service-impl
cocoon-servlet-service-components
cocoon-configuration
cocoon-spring-configurator
this afternoon.
Please don't do any commits in the relevant parts of our repository.
Thanks!
- o -
The rest will follow as soon as COCOON-2179 is fixed, if time permits
this week otherwise in the first week of April.
Thanks to Grek who fixed COCOON-2179 more quickly than expected, I was able to
create all the other M2 release artifacts. This means that the code freeze is over.
Before I can call for a vote I have to create all the Non-Maven release
artifacts which will happen the next days.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Layered software designs
Reinhard Poetz schrieb: Carsten Ziegeler wrote: The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. Yes, this layered approach is what I'm aiming for. All the reactions in this thread make me think that everybody, who has commented on this mailing list so far (except Carsten), believes that we want to throw away good things that have profed to be useful in many situations. Rest assured, that's not the case. Carsten and I only want to break up this all-or-nothing situation that we (still) have now. What I want to see is a concise pipeline API that comes with only little overhead in terms of its learning curve and its dependencies on third-party software. Usually this means that we stick with standard APIs as much as possible - and I think this rule applies for our situation too. This means that the user of the API only needs to learn as little as possible. When he wants more, we offer additional modules that help him. Since he has a concrete need, the motiviation to learn something new is much higher than when he has to learn everything right from the beginning. If you want to learn how this whole concept *might* apply for a next generation Cocoon, have a look at Steven's and my Exploring Corona mail from last week (http://marc.info/?l=xml-cocoon-devm=120611990603725w=2). The idea of Corona is having a concise core that doesn't have any dependencies on a particular component container (Spring, OSGi, etc.), source resolving mechanisms or environment (http, java only, etc.) or even the type of the components (XML-SAX event stream, XML-Stax event stream, binary streams, etc.) that are linked together in a pipeline. A simple scenario could be: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? It's appealing to me also. However, I'm not sure I did get the layers correctly. I did see: Pipeline API: responsible for composing different components, introduces the notion of Producer/Consumer and first and last component Sitemap API: responsible for executing pipelines Spring: responsible for setting up layers and identifying implementations to wildcard functionality (not really a layer for itself?) URI API (had no better term at hand): responsible for interpreting protocol strings for resource access. Currently two implementations in dicussion: URL and SourceResolver Pipeline Components? really a layer or just implementations of Pipeline API Can we line out the intended or existing layers? I do feel this would help focussing the discussion. We then can have a track reflecting actual layers, a track exploring interaction among layers (e.g caching, configuration...), and a track pondering implementation aspects. Rainer
Re: Layered software designs
Reinhard Poetz schrieb: Dev at weitling wrote: But (maybe I have missed some mails) how do you want to make this Pipeline API? E.g. a SAX-based pipeline is something different than image data running through several filters. How do you want to prevent the use of a SAX-events generating component together with an image data transformer? What about something like it's used in clipboards: each component offers a list of importable and exportable formats? See http://marc.info/?l=xml-cocoon-devm=120611990603725w=2 Do the explanations that this mail answer your question? They answer a number of questions. Nevertheless, the question of connection type is still open. Ok, the answer given is it is up to the components to ensure compatibility. However, what does this mean practically? Will there be different Interfaces for different type of data to e processed. (SAX events will use SAX interfaces, image data will use others) Or will there be some tagging where a component be asked for a list of types it will be able to process? (An image resizer will state PNG JPEG and GIF as being acceptable inputs for consumer side and PNG the type being produced, or something along?) And compatibility will be assumed if a linked pair of producer and consumer share a common tag string? Thus answering the type question might effect back to the API definitions... Rainer
Re: Exploring Corona
Carsten Ziegeler wrote:
Intersting stuff - thanks Reinhard and Steven for starting this and
sharing it with us.
Finally I had time to have a *brief* look at it and I have some remarks :)
:-)
I think the pipeline api and sitemap api should be separate things. So
the invocation should rather be in the pipeline api as the base of
executing pipelines. We could than split this into two modules.
good idea
I'm not sure if actions belong to the pipeline api; i think they are
rather sitemap specific. All they do wrt to the pipeline is to change
the invocation perhaps. So this could also be done before starting the
pipeline and get the action stuff out of the pipeline api.
Since I wasn't sure if we need actions in the sitemap language at all, we just
made them work. Maybe we can merge them with the controller integration which
hasn't been thought through either.
The classes should be put into different packages: we should separate
between the pure api, helper classes and implementations. This makes it
easier to use the stuff in an osgi environment.
ok. Steven and I will work on Corona next week again so that the code reflects
the layered design that we have discussed recently. When doing this we will
also improve the package structure to make it becomes cleaner in general (and
more OSGi friendly in particular).
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Exploring Corona
Reinhard Poetz wrote: ok. Steven and I will work on Corona next week again so that the code reflects the layered design that we have discussed recently. When doing this we will also improve the package structure to make it becomes cleaner in general (and more OSGi friendly in particular). Great :) I'll hold my breath till then (and try to get some ideas about the url and caching stuff) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Layered software designs
Rainer Pruy wrote:
Reinhard Poetz schrieb:
The idea of Corona is having a concise core that doesn't have any
dependencies on a particular component container (Spring, OSGi, etc.),
source resolving mechanisms or environment (http, java only, etc.) or even
the type of the components (XML-SAX event stream, XML-Stax event stream,
binary streams, etc.) that are linked together in a pipeline.
A simple scenario could be:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here
you are:
Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine +
Spring XML-SAX componnents
This layered approach makes Cocoon easily embeddable in any Java
application and Cocoon's learning curve becomes more gradual.
Is such a situation only appealing to Carsten, Steven and me?
It's appealing to me also.
However, I'm not sure I did get the layers correctly.
Note: All my answers are related to Corona. Here we go:
I did see:
Pipeline API: responsible for composing different components, introduces the
notion of Producer/Consumer and first and last component
the pipeline api will be enough to execute pipelines too.
Sitemap API: responsible for executing pipelines
no, the sitemap is a builder that builds pipelines and is put on top of the
pipeline API.
Spring: responsible for setting up layers and identifying implementations to
wildcard functionality (not really a layer for itself?)
Corona has a SpringComponentProvider which is used by the sitemap to lookup its
components. Spring manages the components but is completly hidden behind the
ComponentProvider interface. This makes it very easy to use alternative
containers (e.g. OSGi).
URI API (had no better term at hand): responsible for interpreting protocol
strings for resource access. Currently two implementations in dicussion: URL
and SourceResolver
yes. And as Sylvain and you pointed out, we maybe don't even need the
Sourceresolver anymore.
Pipeline Components? really a layer or just implementations of Pipeline API
Steven came up with the idea of having components that belong to different
layers. The first type is useable in every environment. This could be a
SAX-based FileGenerator or a SAX-based XSLTTransformer. There is no need for any
ties to the ServletAPI. Then there might be a second group of components that
are based on e.g. the Stax-API.
A third group of components has relations to the ServletAPI in order to produce
useful results.
In short, the idea is that the pipeline API is completly independant from any
environments. It can only connect components that belong together.
Can we line out the intended or existing layers? I do feel this would help
focussing the discussion.
I hope that my explanations above are already helpful. Steven and I will work on
Corona next week again and we hope that we can show how this layered design
can be applied in code.
We then can have a track reflecting actual layers, a track exploring
interaction among layers (e.g caching, configuration...), and a track
pondering implementation aspects.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Layered software designs
Rainer Pruy wrote:
Hi, I was off the net for some time and while catching up this discussion I
also got the feeling of being somehow lost a bit in the different aspects of
the discussions
From what I see the starting point was
the (technical) question of how to get rid of a unwanted dependency.
From that it changed to the conceptual question of how to provide flexible
support for arbitrary URI strings.
(out-of-the-box support for standard protocols and an easy extensibility
for more complex needs)
If I did get it right, the main difference between the two approaches in
discussion (URL vs. SourceResolver) is support for caching.
It was noted (and I fully agree) that adding caching later on will require
support from the lower level. (e.g. caching a file will need info about
modification times. caching a resource accessed via http might need access to
the expires header for example. This is not a place for talking about cache
*implementations* or what kind of caching is suited for what layer, it is
just a question of what information will any kind of caching require from
lower levels and will the intended implementation provide such info).
The standard URL implementation does not provide related methods (for
accessing cache control data). On the other hand URL has the benefit of being
plain standard and familiar to a large community of developers.
This to answer the initial question of can we drop SourceResolver support,
we must answer the question Can URL be extended to support cachable
implementations of protocols? and if true Is it possible to override
standard (non-cachable) implementations of protocols with cachable ones?
If both question can be answered with YES, then it will be possible to
implement the uri interpreting layer using plain Java URL and to drop use of
source resolver.
Thanks for sharing your thoughts. I think we have to get our hands dirty now to
figure out all the details.
This will raise questions of semantic differences remaining. E.g. was the
default protocol implementation used for path values without protocol
different with different locations (e.g. per component implementation?)
Probably, it will then be necessary to add some glue code to keep semantics,
or point out differences for migration guidelines.
The question is also, *where* we will introduce this change (if we do it at
all). Corona doesn't impose any constraints in terms of backwards-compatibility,
whereas we can't drop important contracts in 2.2.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Layered software designs
Rainer Pruy wrote:
Reinhard Poetz schrieb:
Dev at weitling wrote:
But (maybe I have missed some mails) how do you want to make this
Pipeline API? E.g. a SAX-based pipeline is something different than image
data running through several filters. How do you want to prevent the use
of a SAX-events generating component together with an image data
transformer? What about something like it's used in clipboards: each
component offers a list of importable and exportable formats?
See http://marc.info/?l=xml-cocoon-devm=120611990603725w=2 Do the
explanations that this mail answer your question?
They answer a number of questions.
Nevertheless, the question of connection type is still open.
Ok, the answer given is it is up to the components to ensure compatibility.
However, what does this mean practically? Will there be different
Interfaces for different type of data to e processed. (SAX events will use
SAX interfaces, image data will use others)
yes, that's the idea (and IIRC it is already implemented this way Corona).
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Meeting in Amsterdam
Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be
there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to
have some discussions about Corona.
What about a meeting on Monday 2pm at the official Hackathon room? (Though I
don't know if this conflicts with other community events
Sling/Jackrabbit/Wicket/... Could people involved with these communities clearify?)
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Meeting in Amsterdam
Reinhard Poetz wrote: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. Me too :) I'll be there from monday 1pm until friday. What about a meeting on Monday 2pm at the official Hackathon room? (Though I don't know if this conflicts with other community events Sling/Jackrabbit/Wicket/... Could people involved with these communities clearify?) Jackrabbit is tuesday morning and I think wicket is tuesday afternoon. Monday afternoon is the portals meetup. As you'll be away tuesday afternoon, I would suggest monday afternoon. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
SVGSerializer for Batik 1.7
Hi, due to circumstances I had to create a SVGSerializer that works with Batik 1.7. You can find it in the Daisy codebase [0] - feel free to add it to Cocoon if you think it is functional enough. [0] http://svn.cocoondev.org/viewsvn/trunk/daisy/applications/daisywiki/frontend/src/java/org/outerj/daisy/frontend/components/batik/ * AbstractDOMSerializer is based on AbstractDOMTransformer. * SVGSerializer is based on the old SVGSerializer There is an extra DOM-to-SAX round because I could not figure out how to use Batik's SAXDocumentFactory as a ContentHandler (It does not look like it was meant to be used as a ContentHandler even though it implements the ContentHandler interface) Note that I only needed it to generate PNG's so much remains untested Regards, Karel
Re: Exploring Corona
Carsten Ziegeler schrieb: Reinhard Poetz wrote: ok. Steven and I will work on Corona next week again so that the code reflects the layered design that we have discussed recently. When doing this we will also improve the package structure to make it becomes cleaner in general (and more OSGi friendly in particular). Great :) I'll hold my breath till then (and try to get some ideas about the url and caching stuff) How about: URL url = new URL(some url); UrlConnection connection = url.openConnection(); connection.getLastModified(); Not sure it this really works in all cases, but appears to be quite suitable and easily extensible. Carsten
Re: Exploring Corona
Steven Dolg wrote: How about: URL url = new URL(some url); UrlConnection connection = url.openConnection(); connection.getLastModified(); Not sure it this really works in all cases, but appears to be quite suitable and easily extensible. Yes, this works for many cases, but not for cases like where you have an expiry date etc. What do you mean by easily extensible? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Meeting in Amsterdam
On Mar 28, 2008, at 11:04, Reinhard Poetz wrote: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. Will someone actually bring Corona? :-D I will be around! ...speaking of which. I still need a place to stay :) Anyone willing to share a room for Sunday and Monday? ...or at least Monday? cheers -- Torsten
Re: Meeting in Amsterdam
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Is there anybody who is going to attend the ApacheCon in Amsterdam?
I'll be there at the two Hackathon days (Mon full day, Tue till 3pm)
and would love to have some discussions about Corona.
Me too :) I'll be there from monday 1pm until friday.
What about a meeting on Monday 2pm at the official Hackathon room?
(Though I don't know if this conflicts with other community events
Sling/Jackrabbit/Wicket/... Could people involved with these
communities clearify?)
Jackrabbit is tuesday morning and I think wicket is tuesday afternoon.
Monday afternoon is the portals meetup.
As you'll be away tuesday afternoon, I would suggest monday afternoon.
Carsten, what time do you prefer?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Exploring Corona
Carsten Ziegeler schrieb: Steven Dolg wrote: How about: URL url = new URL(some url); UrlConnection connection = url.openConnection(); connection.getLastModified(); Not sure it this really works in all cases, but appears to be quite suitable and easily extensible. Yes, this works for many cases, but not for cases like where you have an expiry date etc. What do you mean by easily extensible? url.openConnection() actually returns a subclass of URLConnection depending on the protocol of the URL. So own protocol implementations can return own subclasses that implement this (and other methods) accordingly. And - at least theoretically - provide additional methods for handling specific stuff, e.g. expiration dates. Carsten
Re: Meeting in Amsterdam
Reinhard Poetz wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. Me too :) I'll be there from monday 1pm until friday. What about a meeting on Monday 2pm at the official Hackathon room? (Though I don't know if this conflicts with other community events Sling/Jackrabbit/Wicket/... Could people involved with these communities clearify?) Jackrabbit is tuesday morning and I think wicket is tuesday afternoon. Monday afternoon is the portals meetup. As you'll be away tuesday afternoon, I would suggest monday afternoon. Carsten, what time do you prefer? 2pm or 3pm. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Meeting in Amsterdam
On Fri, Mar 28, 2008 at 11:39 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: ... Carsten, what time do you prefer?... Note this great (swiss made) tool to arrange meetings: http://doodle.ch -Bertrand
Re: Meeting in Amsterdam
Bertrand Delacretaz wrote:
On Fri, Mar 28, 2008 at 11:39 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
... Carsten, what time do you prefer?...
Note this great (swiss made) tool to arrange meetings: http://doodle.ch
... and I was thinking that Switzerland only stands for knives and cheese :-D
Seriously, everybody who wants to attend, please add yourself to this list:
http://doodle.ch/m5uuc89vidvtqmes
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Meeting in Amsterdam
Bertrand Delacretaz wrote:
how about having
dinner together somewhere on Monday night?
great. Count me in!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Meeting in Amsterdam
Hi, On Fri, Mar 28, 2008 at 11:04 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: ...Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. I'll be around but attending Sally's media training on Monday afternoon, and taking part in the JCR meetup [1] on Tuesday. So don't worry about me, but I'd be happy to talk about Corona (and maybe have some Corona with you guys as well ;-) - how about having dinner together somewhere on Monday night? -Bertrand [1] http://wiki.apache.org/jackrabbit/JcrMeetupApril2008
Re: Meeting in Amsterdam
On Mar 28, 2008, at 11:57, Reinhard Poetz wrote: Bertrand Delacretaz wrote: how about having dinner together somewhere on Monday night? great. Count me in! ...keep in mind there is also the BarCamp on Monday night. cheers -- Torsten
Re: Exploring Corona
Consider this: URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); This simple pipeline has these potentially cacheable components; xyz.xml, xyz.xslt, the result of the XSLT transformation, and the final result of the pipeline. As it relates to the pipeline I don't see how the URL.getLastModified() really helps as it could apply to any of these items, two of which aren't even URLs. Ralph Steven Dolg wrote: Carsten Ziegeler schrieb: Steven Dolg wrote: How about: URL url = new URL(some url); UrlConnection connection = url.openConnection(); connection.getLastModified(); Not sure it this really works in all cases, but appears to be quite suitable and easily extensible. Yes, this works for many cases, but not for cases like where you have an expiry date etc. What do you mean by easily extensible? url.openConnection() actually returns a subclass of URLConnection depending on the protocol of the URL. So own protocol implementations can return own subclasses that implement this (and other methods) accordingly. And - at least theoretically - provide additional methods for handling specific stuff, e.g. expiration dates. Carsten
Re: Exploring Corona
Ralph Goers wrote: Consider this: URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); This simple pipeline has these potentially cacheable components; xyz.xml, xyz.xslt, the result of the XSLT transformation, and the final result of the pipeline. As it relates to the pipeline I don't see how the URL.getLastModified() really helps as it could apply to any of these items, two of which aren't even URLs. Hmm, I think this isn't different to what we have today with sources. Today: FileGenerator, XSLTTransformer use a source as input For caching: this source provides a validity object URLs: FileGenerator, XSLTTransformer use a url as input For caching: this url provides a last modified date XMLSerializer in both cases returns a fake (or always valid) validity object/last modified. Now, as I responded to Steven, last modified covers most use cases but not all of the use cases the validity object can handle. This is where we have to think about a good way to have the same. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Exploring Corona
It is essential to keep the different layers straight here. The example is somewhere at the level of the pipeline api or probably sitemap api implementation.. Here caching is a question of the implementation of the components. It actually will depend on different implementations of generators, transformers or serializers (cache-enabled or not). URL cache support is an issue for implementing the cache support within a component. e.g. the FileGenerator might use .getLastModified() or alike methods for determining cache control info for its own cacheability... Also the transformer might use such information for determining whether the script used is still valid. Thus, it is not really surprising that the example will not really benefit from cache parameter info methods provided from URL implementations - it's a different layer. However, e.g. when trying to decide whether the cached result of the FileGenerator() *component* is still valid, it will come handy to have information on whether the file did change in between. Rainer Ralph Goers schrieb: Consider this: URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); This simple pipeline has these potentially cacheable components; xyz.xml, xyz.xslt, the result of the XSLT transformation, and the final result of the pipeline. As it relates to the pipeline I don't see how the URL.getLastModified() really helps as it could apply to any of these items, two of which aren't even URLs. Ralph Steven Dolg wrote: Carsten Ziegeler schrieb: Steven Dolg wrote: How about: URL url = new URL(some url); UrlConnection connection = url.openConnection(); connection.getLastModified(); Not sure it this really works in all cases, but appears to be quite suitable and easily extensible. Yes, this works for many cases, but not for cases like where you have an expiry date etc. What do you mean by easily extensible? url.openConnection() actually returns a subclass of URLConnection depending on the protocol of the URL. So own protocol implementations can return own subclasses that implement this (and other methods) accordingly. And - at least theoretically - provide additional methods for handling specific stuff, e.g. expiration dates. Carsten
Re: Exploring Corona
Carsten Ziegeler schrieb: Ralph Goers wrote: Consider this: URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); This simple pipeline has these potentially cacheable components; xyz.xml, xyz.xslt, the result of the XSLT transformation, and the final result of the pipeline. As it relates to the pipeline I don't see how the URL.getLastModified() really helps as it could apply to any of these items, two of which aren't even URLs. Hmm, I think this isn't different to what we have today with sources. Today: FileGenerator, XSLTTransformer use a source as input For caching: this source provides a validity object URLs: FileGenerator, XSLTTransformer use a url as input For caching: this url provides a last modified date XMLSerializer in both cases returns a fake (or always valid) validity object/last modified. Thanks for responding ;-) This is exactly the way I implemented the simple caching approach for Corona. Patch from me is still due (I know, shame on me) - work load is currently quite high... Now, as I responded to Steven, last modified covers most use cases but not all of the use cases the validity object can handle. This is where we have to think about a good way to have the same. Carsten
[jira] Created: (COCOON-2186) Suggest list .. initial value not being displayed
Suggest list .. initial value not being displayed -- Key: COCOON-2186 URL: https://issues.apache.org/jira/browse/COCOON-2186 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.11 Reporter: imran pariyani Priority: Minor For the forms field of type suggest with a suggestion list the initial value is not being displayed ... this dint happen for version 2.1.10 .. but when i upgraded to version 2.1.11 it no longer sets the initial value .. this bug is also present for the sample http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/do-suggest.flow Initial value of the widget is 16, the widget must show Bruno Dumon. fd:datatype base=integer/ fd:initial-value16/fd:initial-value fd:suggestion-list type=javascript after debugging i found out that the widgets value is being set but it isnt passed on to DOJO as initial value when the DOJO widget is created .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2187) Sitemap parameters get lost in JX templates
Sitemap parameters get lost in JX templates
---
Key: COCOON-2187
URL: https://issues.apache.org/jira/browse/COCOON-2187
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Reporter: Reinhard Poetz
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2187) Sitemap parameters get lost in JX templates when used in jx:import
[
https://issues.apache.org/jira/browse/COCOON-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz updated COCOON-2187:
---
Description:
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty. That only
happens when the parameter is used within a jx:import expression.
was:
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty.
Summary: Sitemap parameters get lost in JX templates when used in
jx:import (was: Sitemap parameters get lost in JX templates)
Sitemap parameters get lost in JX templates when used in jx:import
--
Key: COCOON-2187
URL: https://issues.apache.org/jira/browse/COCOON-2187
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Reporter: Reinhard Poetz
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty. That only
happens when the parameter is used within a jx:import expression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2187) Sitemap parameters get lost in JX templates when used in jx:import
[
https://issues.apache.org/jira/browse/COCOON-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583088#action_12583088
]
Grzegorz Kossakowski commented on COCOON-2187:
--
Interesting problem. Reinhard, any chance to have a IT or sample block
exhibiting this problem? This should greatly reduce my response time to this
bug report. :-)
Sitemap parameters get lost in JX templates when used in jx:import
--
Key: COCOON-2187
URL: https://issues.apache.org/jira/browse/COCOON-2187
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Reporter: Reinhard Poetz
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty. That only
happens when the parameter is used within a jx:import expression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-2187) Sitemap parameters get lost in JX templates when used in jx:import
[
https://issues.apache.org/jira/browse/COCOON-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583088#action_12583088
]
grek edited comment on COCOON-2187 at 3/28/08 9:38 AM:
---
Interesting problem. Reinhard, any chance to have a IT or sample block
exhibiting this problem? This should greatly reduce my response time to this
bug report. :-)
Actually, the test-case for cocoon-template-impl would be the best. We have
planty of them already so it should be quite easy to provide one testing this
problem.
was (Author: grek):
Interesting problem. Reinhard, any chance to have a IT or sample block
exhibiting this problem? This should greatly reduce my response time to this
bug report. :-)
Sitemap parameters get lost in JX templates when used in jx:import
--
Key: COCOON-2187
URL: https://issues.apache.org/jira/browse/COCOON-2187
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Reporter: Reinhard Poetz
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty. That only
happens when the parameter is used within a jx:import expression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2187) Sitemap parameters get lost in JX templates when used in jx:import
[
https://issues.apache.org/jira/browse/COCOON-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583090#action_12583090
]
Reinhard Poetz commented on COCOON-2187:
My first guess is that this only occurs when a sub-request (in this case
invoked by the jx:import statement) is being executed. Therefore I've added an
integration test to cocoon-webapp and cocoon-template-sample.
Sitemap parameters get lost in JX templates when used in jx:import
--
Key: COCOON-2187
URL: https://issues.apache.org/jira/browse/COCOON-2187
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Reporter: Reinhard Poetz
This template doesn't work with trunk:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
p1
jx:import uri=servlet:/it/${cocoon.parameters.doc}/
/p1
p2${cocoon.parameters.doc}/p2
/page
The second time when the 'doc' parameter is read, it is empty. That only
happens when the parameter is used within a jx:import expression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Disabling JavaPrimitiveWrap in flowscript
Hi I'd like to disable JavaPrimitiveWrap globally in Cocoon flowscripts. JavaPrimitiveWrap is a Rhino feature that, when disabled, will return strings and numbers from Java calls as native Javascript types, instead of wrapped Java objects. One can disable it on a (flowscript-)thread by thread basis by calling: org .mozilla .javascript .Context .getCurrentContext().getWrapFactory().setJavaPrimitiveWrap(false); but I'd like to disable it globally for all threads, continuations, etc. Any hint will be welcome. Tobia
[RT] Do we need URL/Source in SSF?
Hi guys, The discussion initiated by rather *technical* question about JNet integration with SSF turned into heated discussion on whether standard URL API is capable enough to replace Excalibur's Source/SourceFactory interfaces. Actually, it was Rainer Pruy who gave a nice summary[1] of discussed aspects up to now. Even though, it's real fun to see interesting solutions like one proposed by Sylvain[2] I'm still rather interested in that particular COCOON-2176[3] problem at the moment as it blocks any out of Cocoon world SSF usage. --- o0o --- Right from the beginning of my playings with JNet and URL replacement for SourceResolver I had constant feeling that something is stinky about the approach I taken. That's been reflected in bunch of dirty hacks in first, prototype implementation of JNet integration. I've taken a closer look at our current Source interface usage pattern. Obviously, started with blockcontext source that I'm mostly interested in at the moment and seen something like this in BlockContextSourceFactory: String blockContext = (String) blockContexts.get(blockName); [...] // construct the path relative the block context String resolvedPath = blockContext + path; [...] resolver = (SourceResolver) this.serviceManager.lookup(SourceResolver.ROLE); return resolver.resolveURI(resolvedPath); Some comments explaining what's happening here. If you try to resolve blockcontext:/myBlock/path it will obtain blockContext from Map of contexts. This map contains base URLs for corresponding blocks. Current implementation allows file: and jar: protocols. As you see, BlockContextSourceFactory returns Source implementations of protocols that have _nothing_ to do with BlockContextSource. Let's have a look at how resolved source is used (in ServletFactoryBean): source = resolver.resolveURI(contextPath); contextPath = source.getURI(); Where contextPath contains blockcontext:/myBlock/path at the beginning of processing. It's clear now, that ServletFactoryBean is interested only in String representation of base URL (Source) and nothing else. Don't you think that is little bit weird that following instructions: contextPath = blockcontext:/myBlock/path; source = resolver.resolveURI(contextPath); contextPath = source.getURI(); Will result with file://.../myBlock/path stored in contextPath instead of original blockcontext:/myBlock/path? I think that contract of URL/SourceFactory should be to to act as identity transform when above code is being executed. I mean, returned URL/Source instance should always be implementing the protocol we asked for. Do you agree? --- o0o --- My conclusion is that SSF exploits semantics of Source/SourceFactory interfaces for resolving *expressions*. My view on blockcontext:/myBlock/path is that we deal with an expression that should be resolved to real URL with real protocol implementation available. Having said all of this I would like to propose treating strings in contextPath attribute as expressions and using cocoon-expression-language-api module for resolving them. Then cocoon-servlet-service-components could provide implementation of blockcontext expression language that would use blockContext Map for resolving expressions to real base URLs. This way we can get rid of dependency on CocoonSourceResolver and Excalibur in one go. Moreover, it means that SSF won't mess with URL/Source handling anymore which was my intention right from the beginning. I think such functionality is far from SSF scope and should be implemented elsewhere, probably as a Spring AOP's /around advice/ so you could get more fine-grained control in which servlets you want to have extended URL support. WDYT? [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/77432 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/77352 [3] https://issues.apache.org/jira/browse/COCOON-2176 -- Grzegorz Kossakowski
Re: [RT] Do we need URL/Source in SSF?
Hi, I have a guts feeling that Spring's Resource and ResourcePatternResolver have similar functions as Source and SourceResolver, hence we could just depend on Spring's Resource to achieve the same functionality in SSF. Regards, Rice On Sat, Mar 29, 2008 at 5:48 AM, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Hi guys, The discussion initiated by rather *technical* question about JNet integration with SSF turned into heated discussion on whether standard URL API is capable enough to replace Excalibur's Source/SourceFactory interfaces. Actually, it was Rainer Pruy who gave a nice summary[1] of discussed aspects up to now. Even though, it's real fun to see interesting solutions like one proposed by Sylvain[2] I'm still rather interested in that particular COCOON-2176[3] problem at the moment as it blocks any out of Cocoon world SSF usage. --- o0o --- Right from the beginning of my playings with JNet and URL replacement for SourceResolver I had constant feeling that something is stinky about the approach I taken. That's been reflected in bunch of dirty hacks in first, prototype implementation of JNet integration. I've taken a closer look at our current Source interface usage pattern. Obviously, started with blockcontext source that I'm mostly interested in at the moment and seen something like this in BlockContextSourceFactory: String blockContext = (String) blockContexts.get(blockName); [...] // construct the path relative the block context String resolvedPath = blockContext + path; [...] resolver = (SourceResolver) this.serviceManager.lookup( SourceResolver.ROLE); return resolver.resolveURI(resolvedPath); Some comments explaining what's happening here. If you try to resolve blockcontext:/myBlock/path it will obtain blockContext from Map of contexts. This map contains base URLs for corresponding blocks. Current implementation allows file: and jar: protocols. As you see, BlockContextSourceFactory returns Source implementations of protocols that have _nothing_ to do with BlockContextSource. Let's have a look at how resolved source is used (in ServletFactoryBean): source = resolver.resolveURI(contextPath); contextPath = source.getURI(); Where contextPath contains blockcontext:/myBlock/path at the beginning of processing. It's clear now, that ServletFactoryBean is interested only in String representation of base URL (Source) and nothing else. Don't you think that is little bit weird that following instructions: contextPath = blockcontext:/myBlock/path; source = resolver.resolveURI(contextPath); contextPath = source.getURI(); Will result with file://.../myBlock/path stored in contextPath instead of original blockcontext:/myBlock/path? I think that contract of URL/SourceFactory should be to to act as identity transform when above code is being executed. I mean, returned URL/Source instance should always be implementing the protocol we asked for. Do you agree? --- o0o --- My conclusion is that SSF exploits semantics of Source/SourceFactory interfaces for resolving *expressions*. My view on blockcontext:/myBlock/path is that we deal with an expression that should be resolved to real URL with real protocol implementation available. Having said all of this I would like to propose treating strings in contextPath attribute as expressions and using cocoon-expression-language-api module for resolving them. Then cocoon-servlet-service-components could provide implementation of blockcontext expression language that would use blockContext Map for resolving expressions to real base URLs. This way we can get rid of dependency on CocoonSourceResolver and Excalibur in one go. Moreover, it means that SSF won't mess with URL/Source handling anymore which was my intention right from the beginning. I think such functionality is far from SSF scope and should be implemented elsewhere, probably as a Spring AOP's /around advice/ so you could get more fine-grained control in which servlets you want to have extended URL support. WDYT? [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/77432 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/77352 [3] https://issues.apache.org/jira/browse/COCOON-2176 -- Grzegorz Kossakowski
