You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Reinhard Poetz (JIRA)" <ji...@apache.org> on 2007/12/26 12:11:43 UTC
[jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Servlet:/ protocol: Support absolute URIs
-----------------------------------------
Key: COCOON-2154
URL: https://issues.apache.org/jira/browse/COCOON-2154
Project: Cocoon
Issue Type: New Feature
Components: - Servlet service framework
Reporter: Reinhard Poetz
Using the servlet-protocol you can only define relative URIs which means that those URIs are only valid if they are resolved in the context of a particular servlet-service because they refer to the defines connections.
If you need globally resolveable URIs, there needs to be a way to define globally unique servlet:/ URIs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> Thanks for the explanation, except I'm still not clear what a
> "connection name" is. See below for my 2 cents.
>
> Grzegorz Kossakowski wrote:
>> The only problem is that we have no way to check if given URI contains
>> connection name or servlet
>> ID. Therefore the idea to add special sign that would remove the
>> ambiguousness appeared. Current
>> proposal are:
>> a) add a plus sign after servlet ID (by Reinhard)
>> b) add a exclamation mark at the very beginning of the path (by Vadim)
>>
>> My personal preference is a plus sign but as Reinhard already pointed
>> out it does not matter that
>> much because we usually won't be using absolute URIs directly.
>>
> Yuck, yuck, yuck. (If you get the impression I don't like a or b you
> are on track).
>
> c) Use a different scheme to identify one vs the other.
In my perception this is strange too because it's more or less the same.
> d) Use a different pattern. i.e "conventional" urls look like
> http://authority/path where authority can be a variety of things such as
> "server[:port]", "user@server[:port]" and server can be a domain name or
> an ip address. In this case, you could do something like
> servlet://connection@local/path which, if I understood you correctly.
> could be abbreviated to servlet://connection/path. For servlet id you
> could use the same syntax with servlet://connection@servlet_id/path. Of
> course, since I don't really know what a connection is I have no idea if
> this makes sense, but it could certainly be abbreviated to
> servlet://@servlet_id/path. Or use servlet://[connection][:id]/path,
> although servlet://:Servlet_C/path still looks a little odd.
This doesn't solve the problem that we have to distinguish between a connection
name and a servlet name.
The servlet-service framework is based around the concept of servlets. In the
current implementation each servlet is configured using Spring as a bean. In
difference to the original servlet concept, servlet-service-fw servlets can have
connections to other servlets. This way inheritance and composition are implemented.
Now there are two situations: If you are in the context of a servlet and want to
use another servlet which is configured as connection, you can call it by this URI:
servlet:[connection-id]:[path]
e.g. servlet:some-connection:/foo/bar
However, there are also use cases that don't allow you to define all relations
to other servlets beforehand because you don't know them at the time of
development. If then there is a need for a servlet URI, you need to access that
servlet directly via its bean name:
servlet:[bean-name]:[path]
And that's the problem: Comparing both URIs you can't make a difference between
the relative and the absolute one. From here we've started our discussion about
+, ! and other signs.
> + and : characters in uri's just plain look strange, even if they are
> allowed, unless they are used in a similar fashion to existing schemes.
> Also, not having the // in the uri makes one wonder just what the token
> before the first slash is. Everybody knows that whatever follows the
> double slashes is not part of the path so it is less confusing.
Does anybody have a pointer to the discussion why double slashes are wrong in
our situation? (I remember some mail by Pier that explains why the double slash
in the Cocoon protocol is wrong but can't find it.)
>> -- o0o --
>>
>> Now it's the time to give some description of static connection list
>> problem. Currently one can
>> define list of connection of a given servlet statically in XML config.
>> If you compile a block there
>> is no chance to add new connections to other servlets. Now, imagine
>> situation that you have some
>> application making charts and you create separate block (and servlet)
>> for each datasource provider.
>> For example, you create block that extracts some data from database
>> and second one that extracts
>> some data from mailbox. If you want to pull this data, you need to
>> connect to these two blocks of
>> course so you add them to your local connection list.
>> Now you can compile your application and everything will be working
>> fine. But what if you want to
>> define another datasource for your charts, for example data from some
>> web service? Of course you
>> develop a new block that downloads and transforms interesting data but
>> you need a way to inform your
>> appliction that there is a third block. The most obvious way is to add
>> connection to the third block
>> but this involves recompilation of your application!
>>
>> The solution that I and Reinhard (and probably others) have in mind is
>> to let servlet use absolute
>> URIs so you don't need to define connections statically to other
>> block. There would be also some
>> discovery mechanism of available blocks, probably a generator, that
>> would return you a list of
>> blocks fulfilling particular needs. The list would contain servlet ID
>> of each servlet (block) so you
>> could reference them later on.
>>
>> I hope this helps you a little bit.
>>
> I still don't quite get this connection thing.
>
> What I don't get is why this can't just be servlet://service@block/path?
We would misuse the authority part of a URI for the purpose of defining the
service name.
> Or better yet, why shouldn't my application just reference a bean id and
> wire it to the block service in its Spring configuration (think Spring
> remoting)?
See above. In some cases you don't know all the references beforehand. It's
similar to the use cases for the bean map (Spring Configurator).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Ralph Goers <Ra...@dslextreme.com>.
Thanks for the explanation, except I'm still not clear what a
"connection name" is. See below for my 2 cents.
Grzegorz Kossakowski wrote:
> The only problem is that we have no way to check if given URI contains connection name or servlet
> ID. Therefore the idea to add special sign that would remove the ambiguousness appeared. Current
> proposal are:
> a) add a plus sign after servlet ID (by Reinhard)
> b) add a exclamation mark at the very beginning of the path (by Vadim)
>
> My personal preference is a plus sign but as Reinhard already pointed out it does not matter that
> much because we usually won't be using absolute URIs directly.
>
Yuck, yuck, yuck. (If you get the impression I don't like a or b you
are on track).
c) Use a different scheme to identify one vs the other.
d) Use a different pattern. i.e "conventional" urls look like
http://authority/path where authority can be a variety of things such as
"server[:port]", "user@server[:port]" and server can be a domain name or
an ip address. In this case, you could do something like
servlet://connection@local/path which, if I understood you correctly.
could be abbreviated to servlet://connection/path. For servlet id you
could use the same syntax with servlet://connection@servlet_id/path. Of
course, since I don't really know what a connection is I have no idea if
this makes sense, but it could certainly be abbreviated to
servlet://@servlet_id/path. Or use servlet://[connection][:id]/path,
although servlet://:Servlet_C/path still looks a little odd.
+ and : characters in uri's just plain look strange, even if they are
allowed, unless they are used in a similar fashion to existing schemes.
Also, not having the // in the uri makes one wonder just what the token
before the first slash is. Everybody knows that whatever follows the
double slashes is not part of the path so it is less confusing.
> -- o0o --
>
> Now it's the time to give some description of static connection list problem. Currently one can
> define list of connection of a given servlet statically in XML config. If you compile a block there
> is no chance to add new connections to other servlets. Now, imagine situation that you have some
> application making charts and you create separate block (and servlet) for each datasource provider.
> For example, you create block that extracts some data from database and second one that extracts
> some data from mailbox. If you want to pull this data, you need to connect to these two blocks of
> course so you add them to your local connection list.
> Now you can compile your application and everything will be working fine. But what if you want to
> define another datasource for your charts, for example data from some web service? Of course you
> develop a new block that downloads and transforms interesting data but you need a way to inform your
> appliction that there is a third block. The most obvious way is to add connection to the third block
> but this involves recompilation of your application!
>
> The solution that I and Reinhard (and probably others) have in mind is to let servlet use absolute
> URIs so you don't need to define connections statically to other block. There would be also some
> discovery mechanism of available blocks, probably a generator, that would return you a list of
> blocks fulfilling particular needs. The list would contain servlet ID of each servlet (block) so you
> could reference them later on.
>
> I hope this helps you a little bit.
>
I still don't quite get this connection thing.
What I don't get is why this can't just be servlet://service@block/path?
Or better yet, why shouldn't my application just reference a bean id and
wire it to the block service in its Spring configuration (think Spring
remoting)?
Please reply, even though I'll be on a plane in a few hours. I'm sure
I'll find time to look at email while I'm out of town.
Ralph
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke pisze:
>
> Could anybody please sum up what the actual problem is and what the
> proposals are to solve it? So far I only got that there is an issue with
> cache key which can be solved by absolutizing URIs. Now there is this
> relative vs. absolute URI thing. What for do we need the +? What's the
> scheme for relative URIs?
Yeah, sure. Little bit background on caching issue:
Currently ServletSource.getURI() method returns relative URIs that look like this:
servlet:[connection_name:]/path
Where connect_name is name of connection to another servlet that is defined locally in a given
servlet. If it's omitted then it means that URI references to the current servlet. The conclusion is
that URIs of that form are relative to the servlet they are resolved in. E.g. servlet A can connect
to servlet C with connection name "foo", and servlet B can connect to servlet D with connection name
"foo" as well. Then in servlet A URI:
servlet:foo:/path
point to completely different resource than the same URI in servlet B. We came to conclusion that
the best way to absolutize URIs is to replace connection name (that is local to the given servlet)
with servlet ID (more precisely, Spring bean ID) that is unique in whole application. Then if we
absolutize URI from example above being in servlet A it would look like:
servlet:servlet_C:/path
and in servlet B the same URI would look like:
servlet:servlet_D:/path
The only problem is that we have no way to check if given URI contains connection name or servlet
ID. Therefore the idea to add special sign that would remove the ambiguousness appeared. Current
proposal are:
a) add a plus sign after servlet ID (by Reinhard)
b) add a exclamation mark at the very beginning of the path (by Vadim)
My personal preference is a plus sign but as Reinhard already pointed out it does not matter that
much because we usually won't be using absolute URIs directly.
-- o0o --
Now it's the time to give some description of static connection list problem. Currently one can
define list of connection of a given servlet statically in XML config. If you compile a block there
is no chance to add new connections to other servlets. Now, imagine situation that you have some
application making charts and you create separate block (and servlet) for each datasource provider.
For example, you create block that extracts some data from database and second one that extracts
some data from mailbox. If you want to pull this data, you need to connect to these two blocks of
course so you add them to your local connection list.
Now you can compile your application and everything will be working fine. But what if you want to
define another datasource for your charts, for example data from some web service? Of course you
develop a new block that downloads and transforms interesting data but you need a way to inform your
appliction that there is a third block. The most obvious way is to add connection to the third block
but this involves recompilation of your application!
The solution that I and Reinhard (and probably others) have in mind is to let servlet use absolute
URIs so you don't need to define connections statically to other block. There would be also some
discovery mechanism of available blocks, probably a generator, that would return you a list of
blocks fulfilling particular needs. The list would contain servlet ID of each servlet (block) so you
could reference them later on.
I hope this helps you a little bit.
--
Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.12.2007 21:51 Uhr, Reinhard Poetz wrote:
>> How about
>>
>> servlet:com.mycompany.project.servlet.service:!/test/foo/bar
>
> Hmmm, I'm not perfectly happy with this solution either. In this case
> the path is enriched with information that actually belongs to the
> sub-protocol part of the URI.
>
> However, I guess that there is no really good solution in this case.
> Currently I slightly prefer the "+" variant, though that's no strong
> opinion.
Could anybody please sum up what the actual problem is and what the
proposals are to solve it? So far I only got that there is an issue with
cache key which can be solved by absolutizing URIs. Now there is this
relative vs. absolute URI thing. What for do we need the +? What's the
scheme for relative URIs?
Joerg
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> On Dec 26, 2007, at 4:01 PM, Grzegorz Kossakowski wrote:
>> Plus sign doesn't look naturally for me. Are there any other options?
>
> How about
>
> servlet:com.mycompany.project.servlet.service:!/test/foo/bar
Hmmm, I'm not perfectly happy with this solution either. In this case the path
is enriched with information that actually belongs to the sub-protocol part of
the URI.
However, I guess that there is no really good solution in this case. Currently I
slightly prefer the "+" variant, though that's no strong opinion.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Dec 26, 2007, at 4:01 PM, Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>> Hi Reinhard, isn't it a duplicate of
>>> https://issues.apache.org/jira/browse/COCOON-2044 ?
>>
>> Not really. If I read that issue correctly, it talks about making
>> cache
>> keys unique. I refer to absolute servlet:/ URIs, e.g.
>>
>> servlet:com.mycompany.project.servlet.service+:/test/foo/bar
> Plus sign doesn't look naturally for me. Are there any other options?
How about
servlet:com.mycompany.project.servlet.service:!/test/foo/bar
Vadim
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> ServletSource is only available if you use the ServletService Framework
>> together with Cocoon. So I think that ServletConnection should become
>> public API too.
>>
>> We could offer two types of ServletConnections:
>>
>> * RelativeServletConnection that works relative to the current servlet
>> context * AbsoluteServletConnection that expects the servlet service name
>> (= the name of the Spring bean)
>
> I was wondering why ServletConnection can't be clever enough to figure it out
> if it's passed a relative URI or absolute one? Why we need separate classes?
>
> It's not a big deal for me, just curious.
the reason was that I didn't like the code when it did both. But let's discuss
this when the code is committed.
>> Actually I've already implemented it this way ...
>>
>> WDYT?
>
> The biggest mystery for me is why I don't see commit messages mentioning this
> great stuff being checked in into our repository.
>
> Keeping this code in a secret is just not fair! ;-)
I have to test it more extensivly, but I plan to commit it soon.
>> For me fixing the cache key generation problem is only a positive side
>> effect of my current work. I need absolute servlet URIs for a special
>> generator (or maybe a source, don't know yet) whose output depends on the
>> available servlet services which makes it impossible to define them as
>> connections beforehand.
>>
>> Probably it's very similar to what you call "dynamic connections".
>
> Yep, I guess so. I was thinking about dynamic servlet discovery based on some
> conditions. For example, I would like to see a generator that lets me to list
> all servlet giving 200 response when they asked for resource
> "/org.grek.app.skin.provider". This way I could easily list all skins
> available for my new, shiny application. Is it something similar to your
> goals?
yes
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
> ServletSource is only available if you use the ServletService Framework
> together with Cocoon. So I think that ServletConnection should become
> public API too.
>
> We could offer two types of ServletConnections:
>
> * RelativeServletConnection that works relative to the current servlet
> context
> * AbsoluteServletConnection that expects the servlet service name (= the
> name of the Spring bean)
I was wondering why ServletConnection can't be clever enough to figure it out if it's passed a
relative URI or absolute one? Why we need separate classes?
It's not a big deal for me, just curious.
> Actually I've already implemented it this way ...
>
> WDYT?
The biggest mystery for me is why I don't see commit messages mentioning this great stuff being
checked in into our repository.
Keeping this code in a secret is just not fair! ;-)
> For me fixing the cache key generation problem is only a positive side
> effect of my current work. I need absolute servlet URIs for a special
> generator (or maybe a source, don't know yet) whose output depends on
> the available servlet services which makes it impossible to define them
> as connections beforehand.
>
> Probably it's very similar to what you call "dynamic connections".
Yep, I guess so. I was thinking about dynamic servlet discovery based on some conditions. For
example, I would like to see a generator that lets me to list all servlet giving 200 response when
they asked for resource "/org.grek.app.skin.provider". This way I could easily list all skins
available for my new, shiny application.
Is it something similar to your goals?
--
Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> I've rewritten the ServletConnection and it always expects now globally
>> absolute URIs. If a service-relative URI is being resolved, the
>> ServletSource can translate it into an absolute one.
>
> It looks like you implying that ServletConnection should never be used
> directly only ServletSource, instead. Am I guessing right?
ServletSource is only available if you use the ServletService Framework together
with Cocoon. So I think that ServletConnection should become public API too.
We could offer two types of ServletConnections:
* RelativeServletConnection that works relative to the current servlet context
* AbsoluteServletConnection that expects the servlet service name (= the
name of the Spring bean)
Actually I've already implemented it this way ...
WDYT?
>> This should fix the cache key generation problem too.
>
> Yep, I hope so.
>
>>> Plus sign doesn't look naturally for me. Are there any other options?
>> Citing RFC 2396:
>>
>> Scheme names consist of a sequence of characters beginning with a lower
>> case letter and followed by any combination of lower case letters, digits,
>> plus ("+"), period ("."), or hyphen ("-"). For resiliency, programs
>> interpreting URI should treat upper case letters as equivalent to lower
>> case in scheme names (e.g., allow "HTTP" as well as "http").
>>
>> scheme = alpha *( alpha | digit | "+" | "-" | "." )
>>
>>
>> But since I strongly discourage from using absolute URIs directly, I don't
>> consider it being a big issue.
>
> Aha, ok. I forgot that absolute URIs shouldn't be used directly in general.
> Then I'm fine with plus sign.
>
> It brings interesting question: if user is not supposed to use absolute URIs
> directly will their usage be limited only to making ServletSource conforming
> the API of Source interface thus generating proper cache keys? I was thinking
> about dynamic connections between servlets but I would like to hear your
> opinion.
For me fixing the cache key generation problem is only a positive side effect of
my current work. I need absolute servlet URIs for a special generator (or maybe
a source, don't know yet) whose output depends on the available servlet services
which makes it impossible to define them as connections beforehand.
Probably it's very similar to what you call "dynamic connections".
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
>
> I've rewritten the ServletConnection and it always expects now globally
> absolute URIs. If a service-relative URI is being resolved, the
> ServletSource can translate it into an absolute one.
It looks like you implying that ServletConnection should never be used directly only ServletSource,
instead. Am I guessing right?
> This should fix the cache key generation problem too.
Yep, I hope so.
>>
>> Plus sign doesn't look naturally for me. Are there any other options?
>
> Citing RFC 2396:
>
> Scheme names consist of a sequence of characters beginning with a
> lower case letter and followed by any combination of lower case
> letters, digits, plus ("+"), period ("."), or hyphen ("-"). For
> resiliency, programs interpreting URI should treat upper case letters
> as equivalent to lower case in scheme names (e.g., allow "HTTP" as
> well as "http").
>
> scheme = alpha *( alpha | digit | "+" | "-" | "." )
>
>
> But since I strongly discourage from using absolute URIs directly, I don't
> consider it being a big issue.
Aha, ok. I forgot that absolute URIs shouldn't be used directly in general. Then I'm fine with plus
sign.
It brings interesting question: if user is not supposed to use absolute URIs directly will their
usage be limited only to making ServletSource conforming the API of Source interface thus generating
proper cache keys? I was thinking about dynamic connections between servlets but I would like to
hear your opinion.
--
Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>> Hi Reinhard, isn't it a duplicate of
>>> https://issues.apache.org/jira/browse/COCOON-2044 ?
>> Not really. If I read that issue correctly, it talks about making cache
>> keys unique. I refer to absolute servlet:/ URIs, e.g.
>>
>> servlet:com.mycompany.project.servlet.service+:/test/foo/bar
>
> In the discussion of COCOON-2044 it is mentioned that non-uniqueness of cache
> keys is caused by bad implementation of servlet service because it returns
> relative URIs instead of absolute ones when getURI() method is called. So in
> order to fix COCOON-2044 you just need essentially to implement support of
> absolute URI for servlet: protocol. That's why I see it as duplicate.
I've rewritten the ServletConnection and it always expects now globally absolute
URIs. If a service-relative URI is being resolved, the ServletSource can
translate it into an absolute one.
This should fix the cache key generation problem too.
>> Btw, after reading the URI spec and making some experiments with the URI
>> class of Java, I figured out that the originally proposed "!" at the
>> beginning of the sub schema is not allowed, however, appending a "+" is.
>> This is required in order to distinguish between relative and absolute
>> servlet:/ URIs.
>
> Plus sign doesn't look naturally for me. Are there any other options?
Citing RFC 2396:
Scheme names consist of a sequence of characters beginning with a
lower case letter and followed by any combination of lower case
letters, digits, plus ("+"), period ("."), or hyphen ("-"). For
resiliency, programs interpreting URI should treat upper case letters
as equivalent to lower case in scheme names (e.g., allow "HTTP" as
well as "http").
scheme = alpha *( alpha | digit | "+" | "-" | "." )
But since I strongly discourage from using absolute URIs directly, I don't
consider it being a big issue.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
>> Hi Reinhard, isn't it a duplicate of
>> https://issues.apache.org/jira/browse/COCOON-2044 ?
>
> Not really. If I read that issue correctly, it talks about making cache
> keys unique. I refer to absolute servlet:/ URIs, e.g.
>
> servlet:com.mycompany.project.servlet.service+:/test/foo/bar
In the discussion of COCOON-2044 it is mentioned that non-uniqueness of cache keys is caused by bad
implementation of servlet service because it returns relative URIs instead of absolute ones when
getURI() method is called.
So in order to fix COCOON-2044 you just need essentially to implement support of absolute URI for
servlet: protocol. That's why I see it as duplicate.
> Btw, after reading the URI spec and making some experiments with the URI
> class of Java, I figured out that the originally proposed "!" at the
> beginning of the sub schema is not allowed, however, appending a "+" is.
> This is required in order to distinguish between relative and absolute
> servlet:/ URIs.
Plus sign doesn't look naturally for me. Are there any other options?
--
Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz (JIRA) pisze:
>> Servlet:/ protocol: Support absolute URIs
>> -----------------------------------------
>>
>> Key: COCOON-2154 URL: https://issues.apache.org/jira/browse/COCOON-2154
>> Project: Cocoon Issue Type: New Feature Components: - Servlet service
>> framework Reporter: Reinhard Poetz
>>
>>
>> Using the servlet-protocol you can only define relative URIs which means
>> that those URIs are only valid if they are resolved in the context of a
>> particular servlet-service because they refer to the defines connections.
>>
>> If you need globally resolveable URIs, there needs to be a way to define
>> globally unique servlet:/ URIs.
>
> Hi Reinhard, isn't it a duplicate of
> https://issues.apache.org/jira/browse/COCOON-2044 ?
Not really. If I read that issue correctly, it talks about making cache keys
unique. I refer to absolute servlet:/ URIs, e.g.
servlet:com.mycompany.project.servlet.service+:/test/foo/bar
Btw, after reading the URI spec and making some experiments with the URI class
of Java, I figured out that the originally proposed "!" at the beginning of the
sub schema is not allowed, however, appending a "+" is. This is required in
order to distinguish between relative and absolute servlet:/ URIs.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz (JIRA) pisze:
> Servlet:/ protocol: Support absolute URIs -----------------------------------------
>
> Key: COCOON-2154 URL: https://issues.apache.org/jira/browse/COCOON-2154 Project: Cocoon Issue
> Type: New Feature Components: - Servlet service framework Reporter: Reinhard Poetz
>
>
> Using the servlet-protocol you can only define relative URIs which means that those URIs are only
> valid if they are resolved in the context of a particular servlet-service because they refer to
> the defines connections.
>
> If you need globally resolveable URIs, there needs to be a way to define globally unique
> servlet:/ URIs.
Hi Reinhard, isn't it a duplicate of https://issues.apache.org/jira/browse/COCOON-2044 ?
--
Grzegorz
[jira] Assigned: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by "Reinhard Poetz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Reinhard Poetz reassigned COCOON-2154:
--------------------------------------
Assignee: Reinhard Poetz
> Servlet:/ protocol: Support absolute URIs
> -----------------------------------------
>
> Key: COCOON-2154
> URL: https://issues.apache.org/jira/browse/COCOON-2154
> Project: Cocoon
> Issue Type: New Feature
> Components: - Servlet service framework
> Reporter: Reinhard Poetz
> Assignee: Reinhard Poetz
>
> Using the servlet-protocol you can only define relative URIs which means that those URIs are only valid if they are resolved in the context of a particular servlet-service because they refer to the defines connections.
> If you need globally resolveable URIs, there needs to be a way to define globally unique servlet:/ URIs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2154) Servlet:/ protocol: Support absolute
URIs
Posted by "Reinhard Poetz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Reinhard Poetz closed COCOON-2154.
----------------------------------
Resolution: Fixed
Fix version (Component): Parent values: Servlet Service Framework(10247).
> Servlet:/ protocol: Support absolute URIs
> -----------------------------------------
>
> Key: COCOON-2154
> URL: https://issues.apache.org/jira/browse/COCOON-2154
> Project: Cocoon
> Issue Type: New Feature
> Components: - Servlet service framework
> Reporter: Reinhard Poetz
> Assignee: Reinhard Poetz
>
> Using the servlet-protocol you can only define relative URIs which means that those URIs are only valid if they are resolved in the context of a particular servlet-service because they refer to the defines connections.
> If you need globally resolveable URIs, there needs to be a way to define globally unique servlet:/ URIs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.