Grzegorz Kossakowski wrote:
Hello,
Thanks Reinhard for sharing your work. I have taken a quick look at the
code and fixed some bugs in order to get some basics working.
However I failed to fix BlockContextSource implementation that should
obtain blockContexts map from ServletContext.
The
Reinhard Poetz wrote:
At the ApacheCon Carsten, Grek and I had the chance to talk about the JNet
integration and to find a solution that (hopefully) works.
* First we all believe that it is not a good idea to consider the
blockcontext:/
URLs as expressions that are resolved to file: URLs
Hello,
Thanks Reinhard for sharing your work. I have taken a quick look at the code and fixed some bugs in
order to get some basics working.
However I failed to fix BlockContextSource implementation that should obtain blockContexts map from
ServletContext. I attach changes that reflects my
On Apr 8, 2008, at 7:54 AM, Reinhard Poetz wrote:
At the ApacheCon Carsten, Grek and I had the chance to talk about
the JNet
integration and to find a solution that (hopefully) works.
* First we all believe that it is not a good idea to consider the
blockcontext:/
URLs as expressions
At the ApacheCon Carsten, Grek and I had the chance to talk about the JNet
integration and to find a solution that (hopefully) works.
* First we all believe that it is not a good idea to consider the blockcontext:/
URLs as expressions that are resolved to file: URLs. We want to make them
Grzegorz Kossakowski wrote:
Hello,
I've played with JNet for a while trying to integrate it with SSF and run
into many troubles.
First of all, I'm not sure if I understand whole concept correctly. Do I
understand correctly that JNet provides SourceURLStreamHandlerFactory class
that acts just
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Hello,
I've played with JNet for a while trying to integrate it with SSF and run
into many troubles.
First of all, I'm not sure if I understand whole concept correctly. Do I
understand correctly that JNet provides SourceURLStreamHandlerFactory
On Apr 3, 2008, at 2:58 PM, Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Why do we have to replace the blockcontext: protocol at all?
Take a look at its current source code. There is no such a thing
like blockcontext: protocol implementation at the moment.
In my [RT] mail I explained
Grzegorz Kossakowski wrote:
Why do we have to replace the blockcontext: protocol at all?
Take a look at its current source code. There is no such a thing like
blockcontext: protocol implementation at the moment.
Therefore I'm asking ...
In my [RT] mail I explained how we could possibly to
Joerg Heinicke wrote:
CachingFileGenerator was something Reinhard came up with - I only
explained why I considered this as starting point for a mess which you
disagreed with.
But I will turn around the questions :) What caching do you need? The
ultra complex caching we currently have which
To be honest, I don't care about caching or how complex it
is. It has
to work and it does it nicely in Cocoon. If your name isn't
Ard ( ;-)
:-)
) you usually don't need to know more details. And that's
what it is
as Vadim pointed out: implementation details.
My name is not
Joerg Heinicke wrote:
On 25.03.2008 10:53, Reinhard Poetz wrote:
Once again, my goal is that if you use e.g. Corona in its simplest
form, I don't want to make everybody and his dog depend on
JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL
object is enough for simple use
It seems that this topic is even more interesting than the environment
abstraction threads we had a while back :)
Ok, first of all, the sourceresolver is a very cool component and I
really like it (and it was also me who started this component years ago
:) ). As the java api lacks such kind
On 26.03.2008 03:34, Reinhard Poetz wrote:
I never had the need to implement a Source and for the mentioned
simple cases I wonder where you have to cope with them at all? Cocoon
used to be a framework for non-Java developers ... even if we
introduce a pipeline API as in the examples in this
Joerg Heinicke wrote:
On 26.03.2008 03:34, Reinhard Poetz wrote:
I never had the need to implement a Source and for the mentioned
simple cases I wonder where you have to cope with them at all? Cocoon
used to be a framework for non-Java developers ... even if we
introduce a pipeline API as in
Carsten Ziegeler wrote:
Hmm, I don't think so. Imagine a pipeline java api just taking a uri
for the sources used in the pipeline. That's simple and easy.
Now, you can use the source resolver on top of that, resolve your
sources and you get a uri from your source that you can put into the
On 26.03.2008 08:04, Carsten Ziegeler wrote:
What's the advantage of giving our components the responsibility to
deal with strings that represent sources?
Isn't that what components are there for? Encapsulating commonly used
functionality? Why should I extract that to the pipeline *instance*
Ralph Goers wrote:
Carsten Ziegeler wrote:
Hmm, I don't think so. Imagine a pipeline java api just taking a uri
for the sources used in the pipeline. That's simple and easy.
Now, you can use the source resolver on top of that, resolve your
sources and you get a uri from your source that
Joerg Heinicke wrote:
I'm not sure if we are talking about the same. If I take Reinhard's
sample [1]
URL baseUrl = new URL(file:///C:/temp/);
Pipeline pipeline = new NonCachingPipeline();
pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml));
pipeline.addComponent(new
Carsten Ziegeler wrote:
It seems that this topic is even more interesting than the environment
abstraction threads we had a while back :)
Ok, first of all, the sourceresolver is a very cool component and I
really like it (and it was also me who started this component years
ago :) ). As the
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
That's why I wonder where a pipeline writer gets into uri resolving
at all? Why does he have to care about URLs or Sources? That's the
component developer's concern.
The pipeline writer needs to know how uri resolving works.
Still: Why?
He
On Wed, Mar 26, 2008 at 4:46 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote:
snip/
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.
We've ended up layering our own
Carsten Ziegeler schrieb:
The pipeline writer needs to know how uri resolving works. He needs to
know what input values are allowed, what relative values mean etc.
But I will turn around the questions :) What caching do you need? The
ultra complex caching we currently have which can cache
On Mar 26, 2008, at 11:09 AM, Steven Dolg wrote:
Carsten Ziegeler schrieb:
The pipeline writer needs to know how uri resolving works. He needs
to know what input values are allowed, what relative values mean etc.
But I will turn around the questions :) What caching do you need?
The ultra
Vadim Gritsenko schrieb:
On Mar 26, 2008, at 11:09 AM, Steven Dolg wrote:
Carsten Ziegeler schrieb:
The pipeline writer needs to know how uri resolving works. He needs
to know what input values are allowed, what relative values mean etc.
But I will turn around the questions :) What
On Mar 26, 2008, at 12:01 PM, Steven Dolg wrote:
Vadim Gritsenko schrieb:
On Mar 26, 2008, at 11:09 AM, Steven Dolg wrote:
Carsten Ziegeler schrieb:
The pipeline writer needs to know how uri resolving works. He
needs to know what input values are allowed, what relative values
mean etc.
On 26.03.2008 09:08, Carsten Ziegeler wrote:
and want to add caching to it and therefore have to switch from URL to
Source and from FileGenerator to CachingFileGenerator - sorry, but
that's a mess since this means pretty much rewriting the application
for adding caching. Why is this page so
into implementation of my original idea of
providing default
SourceResolver for SSF internal needs so we can release SSF 1.1.0 ASAP. I'll
wait with JNet
integration until someone (Carsten?) else chimes in and explains how everything
should be glued.
Abstract description explaining what are _real_ benefits
wait with JNet integration until someone (Carsten?) else
chimes in and explains how everything should be glued.
I don't understand this. From a quick glance at your code I see that there we
are able to set the servlet context in the SSF without depending on Excalibur
sourceresolve or Excalibur
On Mar 25, 2008, at 3:10 AM, Carsten Ziegeler wrote:
The abstraction we introduced with all these sub interfaces from
source looked great in the beginning, but today I'm not sure that
you really need this. Traversing over http urls is not working for
instance; if you want to traverse of
wait with JNet integration until someone (Carsten?) else
chimes in and explains how everything should be glued.
I don't understand this. From a quick glance at your code I see that
there we are able to set the servlet context in the SSF without
depending on Excalibur sourceresolve
ASAP. I'll wait with JNet integration until someone (Carsten?)
else chimes in and explains how everything should be glued.
I don't understand this. From a quick glance at your code I see that there
we are able to set the servlet context in the SSF without depending on
Excalibur sourceresolve
Reinhard Poetz wrote:
Once again, my goal is that if you use e.g. Corona in its simplest form,
I don't want to make everybody and his dog depend on
JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL
object is enough for simple use cases of a pipeline API.
Yes, I
Carsten Ziegeler pisze:
Reinhard Poetz wrote:
Once again, my goal is that if you use e.g. Corona in its simplest
form, I don't want to make everybody and his dog depend on
JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL
object is enough for simple use cases of a
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Reinhard Poetz wrote:
Once again, my goal is that if you use e.g. Corona in its simplest form,
I don't want to make everybody and his dog depend on
JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL
object is enough for
Reinhard Poetz wrote:
What about the developer? He could assemble pipelines this way:
URL baseUrl = new URL(file:///C:/temp/);
Pipeline pipeline = new NonCachingPipeline();
pipeline.addComponent(new FileGenerator(baseUrl, xyz.xml);
pipeline.addComponent(new XSLTTransformer(baseUrl, xyz.xslt);
Reinhard Poetz pisze:
Reinhard Poetz wrote:
What about the developer? He could assemble pipelines this way:
URL baseUrl = new URL(file:///C:/temp/);
Pipeline pipeline = new NonCachingPipeline();
pipeline.addComponent(new FileGenerator(baseUrl, xyz.xml);
pipeline.addComponent(new
Reinhard Poetz wrote:
Reinhard Poetz wrote:
What about the developer? He could assemble pipelines this way:
URL baseUrl = new URL(file:///C:/temp/);
Pipeline pipeline = new NonCachingPipeline();
pipeline.addComponent(new FileGenerator(baseUrl, xyz.xml);
pipeline.addComponent(new
I had to create a class at work for handling some files. I started with
an input stream. What I needed, though, required caching and being able
to check whether the file was still valid. In this case I soon realized
that I would have to reinvent the Excalibur Source interface since I had
to
I think you are out of your mind. (Not seriously).
I have to tell you, Cocoon without caching pipelines would suck so bad
with performance problems you would give it the boot in very short
order. Even without Cocoon, as soon as you start doing anything
serious caching will become necessary.
Ralph Goers wrote:
I think you are out of your mind. (Not seriously).
I have to tell you, Cocoon without caching pipelines would suck so bad
with performance problems you would give it the boot in very short
order. Even without Cocoon, as soon as you start doing anything
serious caching will
On 25.03.2008 10:53, Reinhard Poetz wrote:
Once again, my goal is that if you use e.g. Corona in its simplest form,
I don't want to make everybody and his dog depend on
JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL
object is enough for simple use cases of a pipeline
needs so we can release SSF 1.1.0 ASAP. I'll
wait with JNet
integration until someone (Carsten?) else chimes in and explains how everything
should be glued.
Abstract description explaining what are _real_ benefits of integrating JNet
into SSF and Cocoon
(Corona?) in general would be good. I really
Hello,
I've played with JNet for a while trying to integrate it with SSF and run into
many troubles.
First of all, I'm not sure if I understand whole concept correctly. Do I
understand correctly that
JNet provides SourceURLStreamHandlerFactory class that acts just like a bridge
supporting
Grzegorz Kossakowski wrote:
Hello,
I've played with JNet for a while trying to integrate it with SSF and run
into many troubles.
First of all, I'm not sure if I understand whole concept correctly. Do I
understand correctly that JNet provides SourceURLStreamHandlerFactory class
that acts just
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Hello,
I've played with JNet for a while trying to integrate it with SSF and run
into many troubles.
First of all, I'm not sure if I understand whole concept correctly. Do I
understand correctly that JNet provides
46 matches
Mail list logo
