You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2007/05/16 12:13:06 UTC
DispatcherServlet
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi gang
I've had discussions with Felix (which is sitting next to me) about the issue that the mount path in
each block is carved in stone in the SitemapServlet bean definition (I suppose it is not
overwritable by Springs PropertyOverwrite mechanism we use as it is an attribute of our own servlet
Spring extension thingy).
Consider you have a third party block that can display stuff by itself and states to be mounted on
path "this-is-IBMs-best-ever". Would you like to have such a part in your URLs?
To me it seems we need a way to have a deployer person be able to overwrite such URL path parts.
Next comes, while Felix is converting the samples to use servlet-services, that outside a request to
the DisplatcherServlet (outside a block context) there is no such information available to where a
block is mounted to.
After having a look into the DispatcherServlet I would propose to refactor the logic in the
createMountableServletsMap method into a Spring bean so that for example the cocoon-webapp can
access it and produce a listing page of all samples it has found in the work/blocks directory
with the correct links to them.
WDYT?
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
iD8DBQFGStkyLNdJvZjjVZARAudxAJ9RBVeQjgerhfQzFsp5I6aVj91DggCgmKCP
r1nK/LJmt5rgd+oSK7a0PSE=
=Qdhe
-----END PGP SIGNATURE-----
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Giacomo Pati skrev:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Reinhard Poetz wrote:
>
>> Giacomo Pati wrote:
>>
>>> I've had discussions with Felix (which is sitting next to me) about
>>> the issue that the mount path in
>>> each block is carved in stone in the SitemapServlet bean definition (I
>>> suppose it is not
>>> overwritable by Springs PropertyOverwrite mechanism we use as it is an
>>> attribute of our own servlet
>>> Spring extension thingy).
>>>
>> You can override it by
>>
>> [block-servlet-bean-id]/contextPath
>>
>> See the output of the rcl goal
>> (./target/rcl/webapp/WEB-INF/cocoon/spring/rcl.properties) of the Cocoon
>> Maven plugin which already makes use of this configuration feature.
>>
>
> Ok, I wasn't aware that not only properties but even attributes of custom Spring extensions are
> overwritable.
>
In general they are not. The custom Spring extensions introduces a
preprocessing step where you can transform any custom XML format to an
ordinary bean configuration object. IIRC I tried to design the custom
format in such away that the corresponding properties would have the
intuitively expected property paths.
/Daniel
Re: DispatcherServlet
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> I've had discussions with Felix (which is sitting next to me) about
>> the issue that the mount path in
>> each block is carved in stone in the SitemapServlet bean definition (I
>> suppose it is not
>> overwritable by Springs PropertyOverwrite mechanism we use as it is an
>> attribute of our own servlet
>> Spring extension thingy).
>
> You can override it by
>
> [block-servlet-bean-id]/contextPath
>
> See the output of the rcl goal
> (./target/rcl/webapp/WEB-INF/cocoon/spring/rcl.properties) of the Cocoon
> Maven plugin which already makes use of this configuration feature.
Ok, I wasn't aware that not only properties but even attributes of custom Spring extensions are
overwritable.
But still the question about whether the mount path information should be made available outside the
blockcontext for i.e. the cocoon-webapp module.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
iD8DBQFGSuVBLNdJvZjjVZARAkcTAKCxmteUi2tgtllKBjcn+c+coRdZBgCeIlzl
mQizweLhemYpKQlCpuoTXQE=
=MT5E
-----END PGP SIGNATURE-----
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> I've had discussions with Felix (which is sitting next to me) about the issue that the mount path in
> each block is carved in stone in the SitemapServlet bean definition (I suppose it is not
> overwritable by Springs PropertyOverwrite mechanism we use as it is an attribute of our own servlet
> Spring extension thingy).
You can override it by
[block-servlet-bean-id]/contextPath
See the output of the rcl goal
(./target/rcl/webapp/WEB-INF/cocoon/spring/rcl.properties) of the Cocoon Maven
plugin which already makes use of this configuration feature.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Giacomo Pati schrieb:
> To me it seems we need a way to have a deployer person be able to overwrite such URL path parts.
You can override any spring bean parameters in a properties file, located in
some META-INF/cocoon/spring/*.properties:
my.package.foobar-servlet/mountPath=/new-mount-path
This can also be used to have the sources available in dev mode. Just put
the file in META-INF/cocoon/spring/dev/*.properties, so it will only be
loaded in dev mode, when you want sitemap and resources reloading:
my.package.foobar-servlet/contextPath=file:../package-block/src/main/resources/COB-INF/
In this case you specify the path relative from your webapp project, where
you run mvn jetty:run and which is on one level with all it's blocks, eg.
package-block.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> Now, I don't want to spoil the contest here, but I would be great if we
> could choose a real url syntax which is parsable by the java.net.URL
> class. It is a) good to have valid urls and b) a long time ago we had
> the idea of just using plain java.net.url implementations instead of the
> source resolver bean (and actually I'm currently working on this), so
> all sources which are now available through the source resolver will be
> available using the plain java api.
> So, I think its worth considering this now :)
Syntax proposed by Reinhard conforms URI specification. I know that URI is a superset of URL that has quite loose structure so almost every
syntax that makes sense is a valid URI.
I think that you have a valid point but how we can express current URIs by using URLs? Any neat ideas? In order to propose something on my
own I must read URL spec. to know where are boundaries.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>>> Some suggestions
>>>
>>> servlet:byId:com.mycompany.block1.servlet:/...
>>> servlet:!com.mycompany.block1.servlet:/...
>>> servlet:~com.mycompany.block1.servlet:/...
>>> servlet:@com.mycompany.block1.servlet:/...
>>>
>>> My favorite is the last one.
>>
>> I really like last one. I would agree to have such a syntax.
>>
> Now, I don't want to spoil the contest here, but I would be great if we
> could choose a real url syntax which is parsable by the java.net.URL
> class. It is a) good to have valid urls and b) a long time ago we had
> the idea of just using plain java.net.url implementations instead of the
> source resolver bean (and actually I'm currently working on this), so
> all sources which are now available through the source resolver will be
> available using the plain java api.
Being able to use java.net.URL would be awesome!
> So, I think its worth considering this now :)
Absolutely, but AFAICS the above URI:s actually are valid. According to
http://java.sun.com/j2se/1.4.2/docs/api/java/net/URL.html the URL syntax
is defined by RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt). And for
opaque URI:s (i.e. if scheme-specific part does not begin with a slash,
http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html#isOpaque())
there are very few restrictions on the scheme specific part.
URL:s of the form block:foo:/bar worked fine with java.net.URL in the
Cocoon OSGi prototype.
/Daniel
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>>
>> what's wrong with e.g. servlet:@com.mycompany.block1.servlet:/...?
> It's valid - but it looks strange to me; I would expect a user name
> after the '@'.
valid point ... then it seems that we have to continue the contest :-)
>
>> AFAIU, we have to register our own protocols. For that purpose we have
>> to call
>> http://javadoc.developintelligence.com/java/net/URL.html#setURLStreamHandlerFactory(java.net.URLStreamHandlerFactory)
>> and according to the javadocs it can only be called once per JVM. Is
>> it a good idea to rely on having to be the first?
> :)
>
> Yes, this is what the docs say - but there are solutions which work even
> if you're not first, e.g. equinox is doing this. So it's technically
> possible and it makes using custom protocols even easier.
I thought that there was some solution but wasn't sure whether we could use if
for our own purpose.
> I don't say that we should switch from source resolver to url and change
> everything we have; I just want to point out, that we should keep this
> in mind when creating urls.
ok.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Reinhard Poetz wrote:
>>
>> what's wrong with e.g. servlet:@com.mycompany.block1.servlet:/...?
> It's valid - but it looks strange to me; I would expect a user name
> after the '@'.
Agree. If we look at the details of RFC 2396, '@' only has a specific
meaning for hierarchal URI:s and then if they are on the form
scheme://userinfo@hostport/abs_path. So the above syntax would not be
"wrong", still I agree with that it creates the wrong associations.
/Daniel
Re: DispatcherServlet
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> what's wrong with e.g. servlet:@com.mycompany.block1.servlet:/...?
It's valid - but it looks strange to me; I would expect a user name
after the '@'.
> AFAIU, we have to register our own protocols. For that purpose we have
> to call
> http://javadoc.developintelligence.com/java/net/URL.html#setURLStreamHandlerFactory(java.net.URLStreamHandlerFactory)
> and according to the javadocs it can only be called once per JVM. Is it
> a good idea to rely on having to be the first?
:)
Yes, this is what the docs say - but there are solutions which work even
if you're not first, e.g. equinox is doing this. So it's technically
possible and it makes using custom protocols even easier.
I don't say that we should switch from source resolver to url and change
everything we have; I just want to point out, that we should keep this
in mind when creating urls.
Carsten
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>>> Some suggestions
>>>
>>> servlet:byId:com.mycompany.block1.servlet:/...
>>> servlet:!com.mycompany.block1.servlet:/...
>>> servlet:~com.mycompany.block1.servlet:/...
>>> servlet:@com.mycompany.block1.servlet:/...
>>>
>>> My favorite is the last one.
>>
>> I really like last one. I would agree to have such a syntax.
>>
> Now, I don't want to spoil the contest here, but I would be great if we
> could choose a real url syntax which is parsable by the java.net.URL
> class. It is a) good to have valid urls
what's wrong with e.g. servlet:@com.mycompany.block1.servlet:/...?
> and b) a long time ago we had
> the idea of just using plain java.net.url implementations instead of the
> source resolver bean (and actually I'm currently working on this), so
> all sources which are now available through the source resolver will be
> available using the plain java api.
> So, I think its worth considering this now :)
AFAIU, we have to register our own protocols. For that purpose we have to call
http://javadoc.developintelligence.com/java/net/URL.html#setURLStreamHandlerFactory(java.net.URLStreamHandlerFactory)
and according to the javadocs it can only be called once per JVM. Is it a good
idea to rely on having to be the first?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Some suggestions
>>
>> servlet:byId:com.mycompany.block1.servlet:/...
>> servlet:!com.mycompany.block1.servlet:/...
>> servlet:~com.mycompany.block1.servlet:/...
>> servlet:@com.mycompany.block1.servlet:/...
>>
>> My favorite is the last one.
>
> I really like last one. I would agree to have such a syntax.
>
Now, I don't want to spoil the contest here, but I would be great if we
could choose a real url syntax which is parsable by the java.net.URL
class. It is a) good to have valid urls and b) a long time ago we had
the idea of just using plain java.net.url implementations instead of the
source resolver bean (and actually I'm currently working on this), so
all sources which are now available through the source resolver will be
available using the plain java api.
So, I think its worth considering this now :)
Carsten
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Some suggestions
>
> servlet:byId:com.mycompany.block1.servlet:/...
> servlet:!com.mycompany.block1.servlet:/...
> servlet:~com.mycompany.block1.servlet:/...
> servlet:@com.mycompany.block1.servlet:/...
>
> My favorite is the last one.
I really like last one. I would agree to have such a syntax.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>> Don't like having a bean id where you would expect to have a
>> servername. I think the servlet:!com.mycompany.block1.servlet:/...
>> would be OK. It has a correct syntax, at least I don't have any
>> associations to the '!' and it looks quite "technical" which is good
>> as it mainly is available for internal use.
>
> +1
I'm also fine with exclamation mark. Does it mean we have reached an agreement on this? :-)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Grzegorz Kossakowski skrev:
>> So we could have:
>>
>> servlet:connection_name:/path
>> for relative URLs and
>>
>> servlet://bean_ID:/path
>> for absolute URLs
>
> Don't like having a bean id where you would expect to have a servername.
> I think the servlet:!com.mycompany.block1.servlet:/... would be OK. It
> has a correct syntax, at least I don't have any associations to the '!'
> and it looks quite "technical" which is good as it mainly is available
> for internal use.
+1
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Ralph Goers pisze:
>> What am I missing? All of these syntaxes look invalid to me. Why
>> isn't the syntax of the normal form
>>
>> protocol://[servername[:port]]/path
>>
>> From the discussions it isn't obvious to me if the block name should
>> be the server name or part of the path.
Opaque URI:s (see description earlier in the thread) doesn't have any
standardized structure after the scheme part, so syntactically the
servlet protocol is OK. As you can see in the implementation of the
ServletConnection#parseBlockURI(URI uri)
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/ServletConnection.java,
it actually make good use of the java.net.URI class for URI parsing.
> It could be a server name if we are referencing blocks (servlets) by
> their bean's IDs. One of requirement for construct:
> protocol://[servername[:port]]/path
> is that it is an absolute path, globally unique. The problem is with
> servlets referenced by their local aliases (connection names). As far as
> I understand RFC 1808[1] this is a proper URL:
> protocol:connection_name:/path is a proper URL?
>
> So we could have:
>
> servlet:connection_name:/path
> for relative URLs and
>
> servlet://bean_ID:/path
> for absolute URLs
Don't like having a bean id where you would expect to have a servername.
I think the servlet:!com.mycompany.block1.servlet:/... would be OK. It
has a correct syntax, at least I don't have any associations to the '!'
and it looks quite "technical" which is good as it mainly is available
for internal use.
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Ralph Goers pisze:
> What am I missing? All of these syntaxes look invalid to me. Why isn't
> the syntax of the normal form
>
> protocol://[servername[:port]]/path
>
> From the discussions it isn't obvious to me if the block name should be
> the server name or part of the path.
It could be a server name if we are referencing blocks (servlets) by their bean's IDs. One of requirement for construct:
protocol://[servername[:port]]/path
is that it is an absolute path, globally unique. The problem is with servlets referenced by their local aliases (connection names). As far
as I understand RFC 1808[1] this is a proper URL:
protocol:connection_name:/path is a proper URL?
So we could have:
servlet:connection_name:/path
for relative URLs and
servlet://bean_ID:/path
for absolute URLs
WDYT?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Ralph Goers <Ra...@dslextreme.com>.
What am I missing? All of these syntaxes look invalid to me. Why isn't
the syntax of the normal form
protocol://[servername[:port]]/path
From the discussions it isn't obvious to me if the block name should be
the server name or part of the path.
Ralph
Alexander Klimetschek wrote:
> Hi guys,
>
> I have a hack for our local Cocoon release that integrates global bean
> ids into the servlet protocol. It's not perfect and that's why I
> didn't provide a patch yet for
> https://issues.apache.org/jira/browse/COCOON-2044 (and because I have
> so much to do for our upcoming release).
>
> But I have some practical experience with that, so I can help in the
> discussion:
>
> Reinhard Poetz schrieb:
> > servlet:byId:com.mycompany.block1.servlet:/...
> > servlet:!com.mycompany.block1.servlet:/...
> > servlet:~com.mycompany.block1.servlet:/...
> > servlet:@com.mycompany.block1.servlet:/...
> >
> > My favorite is the last one.
>
> 1) the @ will make the URL invalid (it's reservered for
> username:password@server.com in the URL pattern)
>
> 2) I simply put the global bean id instead of the shorthand - in
> ServletServiceContext:getNamedContext() I simply look for the
> shorthand first and if that fails I do a lookup in the beanfactory
> assuming it is the global bean id, eg.:
>
> servlet:com.something.my-block:/path
>
> 3) IMPORTANT: one very important thing to note is that the servlet
> protocol is caller-dependent: servlet:SUPER: has a special meaning,
> ie. two calls to servlet:SUPER: from to different blocks are not
> identical - thus you have to add a marker for those calls. My pattern
> is to add "__super" after the global bean id, eg.:
>
> servlet:com.something.my-block__super:/path
>
> 4) I simply make the URLs absolute in the ServletSource() constructor
> and set the systemId of the source to the absolute path. Because any
> include/import mechanism (like in XSLT) will use source.getURI() to
> resolve the relative filename, it is important that this is fully
> resolvable by the servlet source implementation - 2) and 3) (but here
> I don't tell any new stuff ;-)
>
> 5) Different story, but also regarding globally unique keys:
> Environment.getURIPrefix() must be set to have the filename-part of
> the cache keys globally unique (it is empty in the current
> implementation, don't know when it was introduced and for what; but it
> is very useful, since it will be used for cache keys) - I simply use
> the mount path for the uri prefix, this makes the cache keys readable,
> because they look like the real URLs the browser sees.
>
> Alex
>
>
Re: DispatcherServlet
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Hi guys,
I have a hack for our local Cocoon release that integrates global bean ids
into the servlet protocol. It's not perfect and that's why I didn't provide
a patch yet for https://issues.apache.org/jira/browse/COCOON-2044 (and
because I have so much to do for our upcoming release).
But I have some practical experience with that, so I can help in the discussion:
Reinhard Poetz schrieb:
> servlet:byId:com.mycompany.block1.servlet:/...
> servlet:!com.mycompany.block1.servlet:/...
> servlet:~com.mycompany.block1.servlet:/...
> servlet:@com.mycompany.block1.servlet:/...
>
> My favorite is the last one.
1) the @ will make the URL invalid (it's reservered for
username:password@server.com in the URL pattern)
2) I simply put the global bean id instead of the shorthand - in
ServletServiceContext:getNamedContext() I simply look for the shorthand
first and if that fails I do a lookup in the beanfactory assuming it is the
global bean id, eg.:
servlet:com.something.my-block:/path
3) IMPORTANT: one very important thing to note is that the servlet protocol
is caller-dependent: servlet:SUPER: has a special meaning, ie. two calls to
servlet:SUPER: from to different blocks are not identical - thus you have to
add a marker for those calls. My pattern is to add "__super" after the
global bean id, eg.:
servlet:com.something.my-block__super:/path
4) I simply make the URLs absolute in the ServletSource() constructor and
set the systemId of the source to the absolute path. Because any
include/import mechanism (like in XSLT) will use source.getURI() to resolve
the relative filename, it is important that this is fully resolvable by the
servlet source implementation - 2) and 3) (but here I don't tell any new
stuff ;-)
5) Different story, but also regarding globally unique keys:
Environment.getURIPrefix() must be set to have the filename-part of the
cache keys globally unique (it is empty in the current implementation, don't
know when it was introduced and for what; but it is very useful, since it
will be used for cache keys) - I simply use the mount path for the uri
prefix, this makes the cache keys readable, because they look like the real
URLs the browser sees.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> A syntax that distinguishes the two cases is a must. Having a special
> protocol (like the servlets: one) is one possibility, but maybe we could
> find some sub syntax for the servlet: protocol.
Some suggestions
servlet:byId:com.mycompany.block1.servlet:/...
servlet:!com.mycompany.block1.servlet:/...
servlet:~com.mycompany.block1.servlet:/...
servlet:@com.mycompany.block1.servlet:/...
My favorite is the last one.
Comments/other ideas?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
...
>> I think we make the servlet: protocol unnecessarily complicated if we
>> try to overload it with webapp global interpretations as well.
>
> But we need to do that way. If Source returns globally unique URI it
> means that is must handle it. That's why we must implement block id
> handling in the servlet: source.
>
>> And as I asked before, how does the URI parser given e.g.
>> "servlet:foo/bar" know is "foo" is a servlet service local id or a
>> Spring bean id?
>
> It should try both options or we could could introduce some syntax that
> makes it easy to distinguish these two cases.
Trying both options is asking for hard to find bugs. Remember, we have
no control whatsoever of how users are going to chose bean ids and
servlet service connection names. The only thing we can be certain about
is that subtle clashes will happen and complicate life for our users.
A syntax that distinguishes the two cases is a must. Having a special
protocol (like the servlets: one) is one possibility, but maybe we could
find some sub syntax for the servlet: protocol.
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Daniel Fagerstrom pisze:
>>
>> What about omitting "/" part while asking for list of servlet bean ids?
>> It seems even more logical to me because the syntax will be:
>> servlet:[<bean id or connection name>:]/<rest of the path>
>> [] - means that it's optional part
>
> Doesn't seem that logical to me. For all other schemes directory URIs
> ends with a "/". It will confuse people to have another convention in
> this particular case. Furthermore it would not comply with
> http://tools.ietf.org/html/rfc3986.
You are right, it was a weak attempt.
> Thinking further on it. The URIs of current servlet protocol are only
> valid within the scope of a specific servlet service, outside it it
> lacks meaning. The URIs of the proposed servlets: protocol has a unique
> meaning in the scope of the whole webapp. URIs with webapp scope is
> needed both for the "global list" use case as well as for the "global
> id" use case that you and Alexander have discussed.
>
> I think we make the servlet: protocol unnecessarily complicated if we
> try to overload it with webapp global interpretations as well.
But we need to do that way. If Source returns globally unique URI it means that is must handle it. That's why we must implement block id
handling in the servlet: source.
> And as I asked before, how does the URI parser given e.g.
> "servlet:foo/bar" know is "foo" is a servlet service local id or a
> Spring bean id?
It should try both options or we could could introduce some syntax that makes it easy to distinguish these two cases.
> Of course I'm very happy with all your coding. But if you would like to
> write RTs, don't let your ideas about your English abilities limit you.
> The fastest way to improve your ability to write good RTs, is to
> actually write RTs ;) As long as the ideas interest people, they will
> try to understand and give you feedback.
I will remember what you said but for now finishing already started things should have highest priority.
> Servlets already are available for anyone coding Java, as they are
> ordinary Spring beans. So we have not any protection of them anyway.
>
> For most blocks it is much preferable to use the current servlet service
> wiring style as it clearly declares dependencies, and make it possible
> for a user to compose and replace servlet services as they want.
>
> But there are important use cases for run time discovery of servlet
> services as well. The current use case with a samples main page is one
> example. I mean you want it to work both for a normal build and an
> -Dallblocks build.
I see, thanks for clarification.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> That works for your use case, but not for the original one that creates
> a page with links to all samples.
Thanks for your explanations!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz skrev:
>>> Daniel Fagerstrom wrote:
>> ...
>>>> But there are important use cases for run time discovery of servlet
>>>> services as well.
>>>
>>> definitly. For the use cases that *I* have, a generator will be good
>>> enough - I don't think that I need a source for them:
>>>
>>> <map:generate type="servlets" src="data/myconfig.xml"/>
>>>
>>> This could return something like this:
>>>
>>> <servlets>
>>> <service-A>
>>> <config>...</config>
>>> </service->
>>> <service-B>
>>> <config>...</config>
>>> </service-B>
>>> </servlets>
>>>
>>> What are the usecases for implementing a servlets: protocol at all?
>>> (Maybe I'm overlooking something important here ...)
>>
>> In the above output from your generator, you need to reference the
>> actual resources of the listed servlet services. And to be able to do
>> that you need an URI.
>
> The URI is data/myconfig.xml, resolved against all available servlet
> services.
What I mean is that for the original use case where we needed a list of
links to block samples. What URIs are we going to list for the block
samples?
Being more concrete. With your servlets generator we would have
something like:
<map:generate type="servlets" src="xsample.xml"/>
in the cocoon-webapp sitemap. And it would return something like
<servlets>
<cocoon-ajax-sample-service>
<group name="Ajax">
<sample name="Ajax Block" href="ajax/">
Ajax block examples. This block is also used by <a
href="forms/">Cocoon Forms</a>.
</sample>
</group>
</cocoon-ajax-sample-service>
...
</servlets>
What about the /servlets/cocoon-ajax-sample-service/group/@href, what
protocol is that going to use?
>> And right now we have not any protocol that is suitable for that.
>
> AFAIU we only have to create ServletConnection objects. Currently the
> constructor expects the connection name as parameter but it shouldn't be
> difficult to create those objects by implementing a second constructor
> that uses the bean id or a bean reference.
That works for your use case, but not for the original one that creates
a page with links to all samples.
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Reinhard Poetz wrote:
>
> I also think that I understand know, why you'd need URIs containing the
> bean id because source.getChildren() returns a collection of sources and
> each of this sources has a getURI() method that has to be able to
> uniquly identify a child source.
Yes, that's the issue.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> The getChildren() method of
> the created source will return all child sources that return true on
> childSource().exists().
Forget this statement. After reading it again, I see that it is non-sense :-)
The getChildren() method of the source will return all child sources and it's
the concern of the user to call childSource().exists().
I also think that I understand know, why you'd need URIs containing the bean id
because source.getChildren() returns a collection of sources and each of this
sources has a getURI() method that has to be able to uniquly identify a child
source.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Daniel Fagerstrom wrote:
>>> Reinhard Poetz skrev:
>>> ...
>>>
>>> In the above output from your generator, you need to reference the
>>> actual resources of the listed servlet services. And to be able to do
>>> that you need an URI.
>>
>> The URI is data/myconfig.xml, resolved against all available servlet
>> services.
>>
>>> And right now we have not any protocol that is suitable for that.
>>
>> AFAIU we only have to create ServletConnection objects. Currently the
>> constructor expects the connection name as parameter but it shouldn't
>> be difficult to create those objects by implementing a second
>> constructor that uses the bean id or a bean reference.
>>
>>> For the use case we are discussing, the assumption is that the caller
>>> of the servlets generator is not connected to all the servlet
>>> services. Thus we cannot use the servlet: protocol that by design
>>> assumes an explicit named connection.
>>>
>>> So we need a protocol that allows (webapp) global servlet service
>>> URIs anyway. And then we could as well make it listable as a source
>>> is usable in more contexts than a generator.
>>
>> ok. What I still don't understand is, why we want to make the bean id
>> being part of this URI at all? Or do I misinterpret your discussion
>> with Grek here?
>
> I guess that main reason is that we need unique URIs.
>
>> Isn't having an URI
>>
>> servlets:/data/myconfig.xml
>>
>> good enough to configure a listable source? The getChildren() method
>> of the created source will return all child sources that return true
>> on childSource().exists().
>
> What would "servlets:" source return if getInputStream() was called for
> "servlets:/data/myconfig.xml" URI?
probably an exception, like the FileSource which is also a TraversableSource or
an aggregated view.
>> I don't see the need to lookup not configured servlet services by
>> their name. The only use case I can think of is optional servlet
>> services. To solve it, I'd rather introduce an "optional" parameter
>> for servlet service configurations. However, I'm not convinced that we
>> need this feature at all if we can resolve servlets:/data/myconfig.xml
>> URIs which would return servlet service sources that are unknow in the
>> context of the current servlet service.
>
> I can't parse the above. What does mean "to lookup not configured
> servlet services by their name"? How they can be not configured?
I mean a servlet service that is not configured as an entry of
servlet:connections of the servlet service bean definition.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz skrev:
>> ...
>>
>> In the above output from your generator, you need to reference the
>> actual resources of the listed servlet services. And to be able to do
>> that you need an URI.
>
> The URI is data/myconfig.xml, resolved against all available servlet
> services.
>
>> And right now we have not any protocol that is suitable for that.
>
> AFAIU we only have to create ServletConnection objects. Currently the
> constructor expects the connection name as parameter but it shouldn't be
> difficult to create those objects by implementing a second constructor
> that uses the bean id or a bean reference.
>
>> For the use case we are discussing, the assumption is that the caller
>> of the servlets generator is not connected to all the servlet
>> services. Thus we cannot use the servlet: protocol that by design
>> assumes an explicit named connection.
>>
>> So we need a protocol that allows (webapp) global servlet service URIs
>> anyway. And then we could as well make it listable as a source is
>> usable in more contexts than a generator.
>
> ok. What I still don't understand is, why we want to make the bean id
> being part of this URI at all? Or do I misinterpret your discussion with
> Grek here?
I guess that main reason is that we need unique URIs.
> Isn't having an URI
>
> servlets:/data/myconfig.xml
>
> good enough to configure a listable source? The getChildren() method of
> the created source will return all child sources that return true on
> childSource().exists().
What would "servlets:" source return if getInputStream() was called for "servlets:/data/myconfig.xml" URI?
> I don't see the need to lookup not configured servlet services by their
> name. The only use case I can think of is optional servlet services. To
> solve it, I'd rather introduce an "optional" parameter for servlet
> service configurations. However, I'm not convinced that we need this
> feature at all if we can resolve servlets:/data/myconfig.xml URIs which
> would return servlet service sources that are unknow in the context of
> the current servlet service.
I can't parse the above. What does mean "to lookup not configured servlet services by their name"? How they can be not configured?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz skrev:
>> Daniel Fagerstrom wrote:
> ...
>>> But there are important use cases for run time discovery of servlet
>>> services as well.
>>
>> definitly. For the use cases that *I* have, a generator will be good
>> enough - I don't think that I need a source for them:
>>
>> <map:generate type="servlets" src="data/myconfig.xml"/>
>>
>> This could return something like this:
>>
>> <servlets>
>> <service-A>
>> <config>...</config>
>> </service->
>> <service-B>
>> <config>...</config>
>> </service-B>
>> </servlets>
>>
>> What are the usecases for implementing a servlets: protocol at all?
>> (Maybe I'm overlooking something important here ...)
>
> In the above output from your generator, you need to reference the
> actual resources of the listed servlet services. And to be able to do
> that you need an URI.
The URI is data/myconfig.xml, resolved against all available servlet services.
> And right now we have not any protocol that is suitable for that.
AFAIU we only have to create ServletConnection objects. Currently the
constructor expects the connection name as parameter but it shouldn't be
difficult to create those objects by implementing a second constructor that uses
the bean id or a bean reference.
> For the use case we are discussing, the assumption is that the caller of
> the servlets generator is not connected to all the servlet services.
> Thus we cannot use the servlet: protocol that by design assumes an
> explicit named connection.
>
> So we need a protocol that allows (webapp) global servlet service URIs
> anyway. And then we could as well make it listable as a source is usable
> in more contexts than a generator.
ok. What I still don't understand is, why we want to make the bean id being part
of this URI at all? Or do I misinterpret your discussion with Grek here?
Isn't having an URI
servlets:/data/myconfig.xml
good enough to configure a listable source? The getChildren() method of the
created source will return all child sources that return true on
childSource().exists().
I don't see the need to lookup not configured servlet services by their name.
The only use case I can think of is optional servlet services. To solve it, I'd
rather introduce an "optional" parameter for servlet service configurations.
However, I'm not convinced that we need this feature at all if we can resolve
servlets:/data/myconfig.xml URIs which would return servlet service sources that
are unknow in the context of the current servlet service.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> I think it's time to support Reinhard :-)
> I agree with his opinion that servlets: source is not needed at the
> moment and generator will be sufficient.
It wasn't a general statement but rather, that *I* don't have the use case right
now. This doesn't mean that they don't exist.
As Daniel said, a source could be used in more contexts than a generator, e.g.
you could use it from within your Java code to access all servlets.
But I agree with you that the implementation of a generator is much simpler ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Reinhard Poetz skrev:
...
>> For the use case we are discussing, the assumption is that the caller
>> of the servlets generator is not connected to all the servlet
>> services. Thus we cannot use the servlet: protocol that by design
>> assumes an explicit named connection.
>
> But we already agreed to implement referencing by block id in servlet:
> source, right?
No, we are still in the phase of finding a good design.
>> So we need a protocol that allows (webapp) global servlet service URIs
>> anyway. And then we could as well make it listable as a source is
>> usable in more contexts than a generator.
>
> I think it's time to support Reinhard :-)
> I agree with his opinion that servlets: source is not needed at the
> moment and generator will be sufficient. I didn't like servlets: source
> from the beginning and that was the reason why I wanted to integrate
> it's planned functionality with servlet: source.
>
> Having a source that is listable only for one URL (servlets:/) is
> awkward idea IMO.
I can agree about that it isn't the neatest design I have seen. But from
an API POV, there is nothing strange with it. A listable Source returns
a list of Sources, there is no restrictions on that the listed Sources
should be of the same type or listable.
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Reinhard Poetz skrev:
>> definitly. For the use cases that *I* have, a generator will be good
>> enough - I don't think that I need a source for them:
>>
>> <map:generate type="servlets" src="data/myconfig.xml"/>
>>
>> This could return something like this:
>>
>> <servlets>
>> <service-A>
>> <config>...</config>
>> </service->
>> <service-B>
>> <config>...</config>
>> </service-B>
>> </servlets>
>>
>> What are the usecases for implementing a servlets: protocol at all?
>> (Maybe I'm overlooking something important here ...)
>
> In the above output from your generator, you need to reference the
> actual resources of the listed servlet services. And to be able to do
> that you need an URI. And right now we have not any protocol that is
> suitable for that.
>
> For the use case we are discussing, the assumption is that the caller of
> the servlets generator is not connected to all the servlet services.
> Thus we cannot use the servlet: protocol that by design assumes an
> explicit named connection.
But we already agreed to implement referencing by block id in servlet: source, right?
> So we need a protocol that allows (webapp) global servlet service URIs
> anyway. And then we could as well make it listable as a source is usable
> in more contexts than a generator.
I think it's time to support Reinhard :-)
I agree with his opinion that servlets: source is not needed at the moment and generator will be sufficient. I didn't like servlets: source
from the beginning and that was the reason why I wanted to integrate it's planned functionality with servlet: source.
Having a source that is listable only for one URL (servlets:/) is awkward idea IMO.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
...
>> But there are important use cases for run time discovery of servlet
>> services as well.
>
> definitly. For the use cases that *I* have, a generator will be good
> enough - I don't think that I need a source for them:
>
> <map:generate type="servlets" src="data/myconfig.xml"/>
>
> This could return something like this:
>
> <servlets>
> <service-A>
> <config>...</config>
> </service->
> <service-B>
> <config>...</config>
> </service-B>
> </servlets>
>
> What are the usecases for implementing a servlets: protocol at all?
> (Maybe I'm overlooking something important here ...)
In the above output from your generator, you need to reference the
actual resources of the listed servlet services. And to be able to do
that you need an URI. And right now we have not any protocol that is
suitable for that.
For the use case we are discussing, the assumption is that the caller of
the servlets generator is not connected to all the servlet services.
Thus we cannot use the servlet: protocol that by design assumes an
explicit named connection.
So we need a protocol that allows (webapp) global servlet service URIs
anyway. And then we could as well make it listable as a source is usable
in more contexts than a generator.
/Daniel
Re: DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> I think we make the servlet: protocol unnecessarily complicated if we
> try to overload it with webapp global interpretations as well.
agreed
> And as I asked before, how does the URI parser given e.g.
> "servlet:foo/bar" know is "foo" is a servlet service local id or a
> Spring bean id?
no chance to distinguish between them, IMO.
<snip/>
> But there are important use cases for run time discovery of servlet
> services as well.
definitly. For the use cases that *I* have, a generator will be good enough - I
don't think that I need a source for them:
<map:generate type="servlets" src="data/myconfig.xml"/>
This could return something like this:
<servlets>
<service-A>
<config>...</config>
</service->
<service-B>
<config>...</config>
</service-B>
</servlets>
What are the usecases for implementing a servlets: protocol at all? (Maybe I'm
overlooking something important here ...)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>> Daniel Fagerstrom pisze:
>>>
>>> I wonder why we really need new source in this case at all.
>>> Possibility to reference bean by bean id instead of connection name
>>> was already discussed: https://issues.apache.org/jira/browse/COCOON-2044
>>> Why do we need to invent new source?
>>
>> The important part is that "servlets:/" is listable and give a listing
>> of all servlet services. The above thing is because the listed servlet
>> services must have own URIs to be usable. If that could be done by
>> extending the ordinary servlet: protocol I'm fine with that as well.
>> But extending the servlet: protocol has the problem that you use the
>> same URI part for two distinct uses, both for servlet service relative
>> names and for some kind of global naming scheme like bean id. There is
>> some small risk that they are going to collide.
>
> What about omitting "/" part while asking for list of servlet bean ids?
> It seems even more logical to me because the syntax will be:
> servlet:[<bean id or connection name>:]/<rest of the path>
> [] - means that it's optional part
Doesn't seem that logical to me. For all other schemes directory URIs
ends with a "/". It will confuse people to have another convention in
this particular case. Furthermore it would not comply with
http://tools.ietf.org/html/rfc3986.
Thinking further on it. The URIs of current servlet protocol are only
valid within the scope of a specific servlet service, outside it it
lacks meaning. The URIs of the proposed servlets: protocol has a unique
meaning in the scope of the whole webapp. URIs with webapp scope is
needed both for the "global list" use case as well as for the "global
id" use case that you and Alexander have discussed.
I think we make the servlet: protocol unnecessarily complicated if we
try to overload it with webapp global interpretations as well.
And as I asked before, how does the URI parser given e.g.
"servlet:foo/bar" know is "foo" is a servlet service local id or a
Spring bean id?
>>> Do you mean that servlet will be able to construct it's connection at
>>> runtime or it will be able to reference resources from servlets that
>>> it is not connected to?
>>>
>>> Does second option fits to our design of servlet-service-fw?
>>
>> I'm not able to parse the above paragraphs at all. Could you please be
>> a little bit more verbose, so that I can understand what all the uses
>> of "servlet" and "it" refers to ;)
>
> Hehe ;-)
> My English sometimes really limits me and that's the reason why I don't
> write [RT] e-mails even though I have some ideas. It's not that bad in
> the end because I have to focus on the work instead of depicting a
> glowing vision of the future ;-)
Of course I'm very happy with all your coding. But if you would like to
write RTs, don't let your ideas about your English abilities limit you.
The fastest way to improve your ability to write good RTs, is to
actually write RTs ;) As long as the ideas interest people, they will
try to understand and give you feedback.
> Returning back to the topic:
> Let's assume we have servlet A that get list of the other servlet beans'
> ids and want to know if it has some samples. So servlet A must make list
> of calls:
> servlet:B's-id:/some_file
> servlet:B'C-id:/some_file
> ...
>
> But none of these servlets are registered as connections of servlet A so
> I would like to know if we are going to make it possible to request
> resources from servlets that another servlet is not connected to?
Servlets already are available for anyone coding Java, as they are
ordinary Spring beans. So we have not any protection of them anyway.
For most blocks it is much preferable to use the current servlet service
wiring style as it clearly declares dependencies, and make it possible
for a user to compose and replace servlet services as they want.
But there are important use cases for run time discovery of servlet
services as well. The current use case with a samples main page is one
example. I mean you want it to work both for a normal build and an
-Dallblocks build.
Also servlet service discovery could be really useful for tooling
webapps, e.g. block configuration webapps.
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Daniel Fagerstrom pisze:
>>
>> I wonder why we really need new source in this case at all.
>> Possibility to reference bean by bean id instead of connection name
>> was already discussed: https://issues.apache.org/jira/browse/COCOON-2044
>> Why do we need to invent new source?
>
> The important part is that "servlets:/" is listable and give a listing
> of all servlet services. The above thing is because the listed servlet
> services must have own URIs to be usable. If that could be done by
> extending the ordinary servlet: protocol I'm fine with that as well. But
> extending the servlet: protocol has the problem that you use the same
> URI part for two distinct uses, both for servlet service relative names
> and for some kind of global naming scheme like bean id. There is some
> small risk that they are going to collide.
What about omitting "/" part while asking for list of servlet bean ids?
It seems even more logical to me because the syntax will be:
servlet:[<bean id or connection name>:]/<rest of the path>
[] - means that it's optional part
>>
>> Do you mean that servlet will be able to construct it's connection at
>> runtime or it will be able to reference resources from servlets that
>> it is not connected to?
>>
>> Does second option fits to our design of servlet-service-fw?
>
> I'm not able to parse the above paragraphs at all. Could you please be a
> little bit more verbose, so that I can understand what all the uses of
> "servlet" and "it" refers to ;)
Hehe ;-)
My English sometimes really limits me and that's the reason why I don't write [RT] e-mails even though I have some ideas. It's not that bad
in the end because I have to focus on the work instead of depicting a glowing vision of the future ;-)
Returning back to the topic:
Let's assume we have servlet A that get list of the other servlet beans' ids and want to know if it has some samples. So servlet A must make
list of calls:
servlet:B's-id:/some_file
servlet:B'C-id:/some_file
...
But none of these servlets are registered as connections of servlet A so I would like to know if we are going to make it possible to request
resources from servlets that another servlet is not connected to?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>> Daniel Fagerstrom pisze:
>>>
>>> So would it be possible to access resources via servlets: source (by
>>> using internally a servlet: source) or not?
>>
>> I think that should be possible. URIs could look like:
>>
>> servlets:/<bean id>/<internal path>
>
> I wonder why we really need new source in this case at all. Possibility
> to reference bean by bean id instead of connection name was already
> discussed: https://issues.apache.org/jira/browse/COCOON-2044
> Why do we need to invent new source?
The important part is that "servlets:/" is listable and give a listing
of all servlet services. The above thing is because the listed servlet
services must have own URIs to be usable. If that could be done by
extending the ordinary servlet: protocol I'm fine with that as well. But
extending the servlet: protocol has the problem that you use the same
URI part for two distinct uses, both for servlet service relative names
and for some kind of global naming scheme like bean id. There is some
small risk that they are going to collide.
>>>
>>> After having a list of servlets we would have to find out which one
>>> contain samples. I guess that it's good idea to ask every servlet for
>>> certain resource (e.g. samples.xsamples file).
>>
>> Yes.
>>
>>> But how we do this not being connected to all these servlets?
>>
>> As Giacomo suggested it could be done by making the list from
>> o.a.c.servletservice.DispatcherServlet#createMountableServletsMap
>> available in a Spring bean. Another possibility would be to let the
>> blocks source depend on a bean map
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/BeanMap.java
>> that collects all beans that implement Servlet.
>
> Do you mean that servlet will be able to construct it's connection at
> runtime or it will be able to reference resources from servlets that it
> is not connected to?
>
> Does second option fits to our design of servlet-service-fw?
I'm not able to parse the above paragraphs at all. Could you please be a
little bit more verbose, so that I can understand what all the uses of
"servlet" and "it" refers to ;)
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Daniel Fagerstrom pisze:
>>
>> So would it be possible to access resources via servlets: source (by
>> using internally a servlet: source) or not?
>
> I think that should be possible. URIs could look like:
>
> servlets:/<bean id>/<internal path>
I wonder why we really need new source in this case at all. Possibility to reference bean by bean id instead of connection name was already
discussed: https://issues.apache.org/jira/browse/COCOON-2044
Why do we need to invent new source?
>>
>> After having a list of servlets we would have to find out which one
>> contain samples. I guess that it's good idea to ask every servlet for
>> certain resource (e.g. samples.xsamples file).
>
> Yes.
>
>> But how we do this not being connected to all these servlets?
>
> As Giacomo suggested it could be done by making the list from
> o.a.c.servletservice.DispatcherServlet#createMountableServletsMap
> available in a Spring bean. Another possibility would be to let the
> blocks source depend on a bean map
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/BeanMap.java
> that collects all beans that implement Servlet.
Do you mean that servlet will be able to construct it's connection at runtime or it will be able to reference resources from servlets that
it is not connected to?
Does second option fits to our design of servlet-service-fw?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> A Spring bean with directory info seem like a good idea. For
>> increasing the usability I would suggest to implement a new source as
>> well "servlets:" e.g. This source should be a listable source so that
>> you can use it with e.g. the directory generator. The source would of
>> course only be listable at the root level the listed sources would of
>> course be ordinary servlet: sources.
>
> So would it be possible to access resources via servlets: source (by
> using internally a servlet: source) or not?
I think that should be possible. URIs could look like:
servlets:/<bean id>/<internal path>
>> So in
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/blocks/sitemap.xmap
>> we could use:
>>
>> <map:generate type="xpathtraversable" src="servlets:/">
>>
>> instead of the current construction. I started to work on something
>> like that half a year ago but never finished it.
>
> After having a list of servlets we would have to find out which one
> contain samples. I guess that it's good idea to ask every servlet for
> certain resource (e.g. samples.xsamples file).
Yes.
> But how we do this not
> being connected to all these servlets?
As Giacomo suggested it could be done by making the list from
o.a.c.servletservice.DispatcherServlet#createMountableServletsMap
available in a Spring bean. Another possibility would be to let the
blocks source depend on a bean map
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/BeanMap.java
that collects all beans that implement Servlet.
/Daniel
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>
>> IIRC that is the case for the xpathstraversable generator. So it
>> wouldn't work with a servlets: protocol as I conceive it.
>>
>> Maybe we could have some extension to the directory generator so that
>> it only lists directories that contain a specified URI (like e.g.
>> list.xsamples) that could be implemented with the exists method in the
>> Servlet interface, which for the servlet service source in turn could
>> make a HEAD call and see if the response is 200 OK.
>
> We are back to HEAD call?
Maybe ;) In practice it would be a GET as we don't do anything about
HEAD in the samples sitemaps.
Another possibility would be to be able to filter servlets (beans) on
the value of some bean property in the bean map (which would be needed
to be extended for this). That would be similar to the way you do in
OSGi where you can use a subset of the LDAP filter language to chose
services based on their type and their properties.
> I think that we don't have to touch xpathtraversable generator. If we
> have list of servlets, what about generating list of XInclude
> instructions and applying XInclude transformer. This way we could
> collect list of servlet being a sample because other would just respond
> with 404 which could be filtered out.
Sure.
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> IIRC that is the case for the xpathstraversable generator. So it
> wouldn't work with a servlets: protocol as I conceive it.
>
> Maybe we could have some extension to the directory generator so that it
> only lists directories that contain a specified URI (like e.g.
> list.xsamples) that could be implemented with the exists method in the
> Servlet interface, which for the servlet service source in turn could
> make a HEAD call and see if the response is 200 OK.
We are back to HEAD call?
I think that we don't have to touch xpathtraversable generator. If we have list of servlets, what about generating list of XInclude
instructions and applying XInclude transformer. This way we could collect list of servlet being a sample because other would just respond
with 404 which could be filtered out.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Giacomo Pati pisze:
...
>> No, no. That's not the point. The cocoon-webapp already has a way to
>> find those .xsample files. I
>> didn't wanted to construct such an additional thing
>
> How it collects these files? By listing directories, right?
IIRC that is the case for the xpathstraversable generator. So it
wouldn't work with a servlets: protocol as I conceive it.
Maybe we could have some extension to the directory generator so that it
only lists directories that contain a specified URI (like e.g.
list.xsamples) that could be implemented with the exists method in the
Servlet interface, which for the servlet service source in turn could
make a HEAD call and see if the response is 200 OK.
> If so I
> don't think it's good solution because this functionality depends on
> where blocks are unpacked which is IMHO bad practise. Basically, one of
> the purposes to use "servlet:" source is to avoid dependency on exact
> directory structure that is only block's internal concern.
Even more, the servlet: protocol isn't supposed to now anything about
directory structures. Everything is supposed to be handled through the
servlet API.
/Daniel
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>>> A Spring bean with directory info seem like a good idea. For
>>> increasing the usability I would suggest to implement a new source as
>>> well "servlets:" e.g. This source should be a listable source so that
>>> you can use it with e.g. the directory generator. The source would of
>>> course only be listable at the root level the listed sources would of
>>> course be ordinary servlet: sources.
>> So would it be possible to access resources via servlets: source (by
>> using internally a servlet: source) or not?
>
> I don't get you here.
I was asking if "servlets:" source will be only used to list servlets or it will be fully functional source. It's more question to Daniel to
clarify his original description of "servlets:" source :-)
>> After having a list of servlets we would have to find out which one
>> contain samples. I guess that it's good idea to ask every servlet for
>> certain resource (e.g. samples.xsamples file). But how we do this not
>> being connected to all these servlets?
>
> No, no. That's not the point. The cocoon-webapp already has a way to find those .xsample files. I
> didn't wanted to construct such an additional thing
How it collects these files? By listing directories, right? If so I don't think it's good solution because this functionality depends on
where blocks are unpacked which is IMHO bad practise. Basically, one of the purposes to use "servlet:" source is to avoid dependency on
exact directory structure that is only block's internal concern.
I also wonder why we can't have cocoon-webapp's servlet registered in DispatcherServlet?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Daniel Fagerstrom pisze:
>> A Spring bean with directory info seem like a good idea. For
>> increasing the usability I would suggest to implement a new source as
>> well "servlets:" e.g. This source should be a listable source so that
>> you can use it with e.g. the directory generator. The source would of
>> course only be listable at the root level the listed sources would of
>> course be ordinary servlet: sources.
>
> So would it be possible to access resources via servlets: source (by
> using internally a servlet: source) or not?
I don't get you here.
>
>> So in
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/blocks/sitemap.xmap
>> we could use:
>>
>> <map:generate type="xpathtraversable" src="servlets:/">
>>
>> instead of the current construction. I started to work on something
>> like that half a year ago but never finished it.
>
> After having a list of servlets we would have to find out which one
> contain samples. I guess that it's good idea to ask every servlet for
> certain resource (e.g. samples.xsamples file). But how we do this not
> being connected to all these servlets?
No, no. That's not the point. The cocoon-webapp already has a way to find those .xsample files. I
didn't wanted to construct such an additional thing
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
iD8DBQFGSvwRLNdJvZjjVZARAtGbAJ43Xftua+25L0MR3fCf4Sahqlx0NQCdGVoM
dPbMQNtpMF5VecgOdYrgir8=
=aN5U
-----END PGP SIGNATURE-----
Re: DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> A Spring bean with directory info seem like a good idea. For increasing
> the usability I would suggest to implement a new source as well
> "servlets:" e.g. This source should be a listable source so that you can
> use it with e.g. the directory generator. The source would of course
> only be listable at the root level the listed sources would of course be
> ordinary servlet: sources.
So would it be possible to access resources via servlets: source (by using internally a servlet: source) or not?
> So in
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/blocks/sitemap.xmap
> we could use:
>
> <map:generate type="xpathtraversable" src="servlets:/">
>
> instead of the current construction. I started to work on something like
> that half a year ago but never finished it.
After having a list of servlets we would have to find out which one contain samples. I guess that it's good idea to ask every servlet for
certain resource (e.g. samples.xsamples file). But how we do this not being connected to all these servlets?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Giacomo Pati skrev:
...
Reinhard answered the first part.
> Next comes, while Felix is converting the samples to use servlet-services, that outside a request to
> the DisplatcherServlet (outside a block context) there is no such information available to where a
> block is mounted to.
>
I agree that such information need to be available.
> After having a look into the DispatcherServlet I would propose to refactor the logic in the
> createMountableServletsMap method into a Spring bean so that for example the cocoon-webapp can
> access it and produce a listing page of all samples it has found in the work/blocks directory
> with the correct links to them.
>
> WDYT?
>
A Spring bean with directory info seem like a good idea. For increasing
the usability I would suggest to implement a new source as well
"servlets:" e.g. This source should be a listable source so that you can
use it with e.g. the directory generator. The source would of course
only be listable at the root level the listed sources would of course be
ordinary servlet: sources.
So in
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/blocks/sitemap.xmap
we could use:
<map:generate type="xpathtraversable" src="servlets:/">
instead of the current construction. I started to work on something like
that half a year ago but never finished it.
/Daniel