Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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]", "[EMAIL PROTECTED]:port]" and server can be a domain name or an ip address. In this case, you could do something like servlet://[EMAIL PROTECTED]/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://[EMAIL PROTECTED]/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
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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]", "[EMAIL PROTECTED]:port]" and server can be a domain name or an ip address. In this case, you could do something like servlet://[EMAIL PROTECTED]/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://[EMAIL PROTECTED]/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://[EMAIL PROTECTED]/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
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
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
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ö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: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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
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ö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: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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ö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: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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
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
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ö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: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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
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ö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: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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] 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.