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
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 c
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 at
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:
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
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 explaine
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
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 li
> > 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
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
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 sl
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.
B
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 caching
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 c
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 pa
On Wed, Mar 26, 2008 at 4:46 AM, Carsten Ziegeler <[EMAIL PROTECTED]> 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.
>
We've ended up layering our own cach
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 n
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 ja
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 XSLTTra
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 you
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*
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
p
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
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 th
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 of
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 c
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 API.
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 wil
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
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 cac
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 XSLTTransfo
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
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
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 si
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
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 understan
F 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.
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
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.
>
> I don't understand thi
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 file
eResolver 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.
I don't understand this. From a quick glance at your code I see that there we
are able to set the
I'm going to invest my energy 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 de
I'm going to invest my energy 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 descript
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 SourceURLStr
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 li
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 lega
46 matches
Mail list logo