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 still
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
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
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
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
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
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
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]
_
