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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:/...
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,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Once again
Giacomo Pati wrote:
Grzegorz Kossakowski wrote:
Giacomo Pati pisze:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The DispatcherServlet and Services combo is driving me totally crazy.
If the DisplatcherServlet is mounted
Giacomo Pati pisze:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Once again
Giacomo Pati wrote:
Grzegorz Kossakowski wrote:
Sure, compile cocoon, start the cocoon-webapp and point to
http://localhost:/blocks-test/cocoon-ajax-sample/ check the source of that
page and you'll see
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The DispatcherServlet and Services combo is driving me totally crazy.
If the DisplatcherServlet is mounted on something other than the root context
the pathes delivered
by the servlet input module are _wrong_!
I tried alot and I have absolutely
Giacomo Pati pisze:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The DispatcherServlet and Services combo is driving me totally crazy.
If the DisplatcherServlet is mounted on something other than the root context
the pathes delivered
by the servlet input module are _wrong_!
Can you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grzegorz Kossakowski wrote:
Giacomo Pati pisze:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The DispatcherServlet and Services combo is driving me totally crazy.
If the DisplatcherServlet is mounted on something other than the root
context
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:
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
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
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.
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
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
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
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
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
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:
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
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
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
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
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
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
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
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.
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
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
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
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
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
-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
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
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
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
-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
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
we can't have cocoon-webapp's servlet registered in
DispatcherServlet?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
Grek,
I've had some time today and found the reason why the rcl doesn't work
for you. You are using cocoon-servlet-service-impl-1.0.0-M1 and not
the latest version from SVN that I had to fix in order to get Spring
context objects
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
Grek,
I've had some time today and found the reason why the rcl doesn't work
for you. You are using cocoon-servlet-service-impl-1.0.0-M1 and not
the latest version from SVN that I had to fix in order to get
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Another cause might be that I had to comment the rcl modules in
trunk/tools/pom.xml in order not to break the build for everybody. In
the case that you haven't changed this yourself for you own build, you
won't get new artifacts
Reinhard Poetz napisał(a):
Grek,
I've had some time today and found the reason why the rcl doesn't work
for you. You are using cocoon-servlet-service-impl-1.0.0-M1 and not the
latest version from SVN that I had to fix in order to get Spring context
objects reloaded.
While Carsten and I
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Gosh, I have bad news :(
It does not work for me, when I change something in the class I see this
printed on console:
2007-03-14 13:34:32.657:/:INFO: Closing Spring root
WebApplicationContext
2007-03-14 13:34:32.658:/:INFO: Loading Spring
Reinhard Poetz napisał(a):
Another cause might be that I had to comment the rcl modules in
trunk/tools/pom.xml in order not to break the build for everybody. In
the case that you haven't changed this yourself for you own build, you
won't get new artifacts installed.
If I have some time this
Reinhard Poetz skrev:
After more than two days of debugging, many thanks go to Torsten and
Carsten who helped me to track down the problem, I found out, why the
reloading classloader plugin doesn't propertly reload the Spring
application context:
The problem is that the DispatcherServlet
is that the DispatcherServlet contains a map of all
mountable servlet services. This map is initialized in the init()
method of the servlet and will never be reloaded. These servlets have
a reference to the first Spring app context and every reset remains
without effect.
Use OSGi ;)
hehe
Reinhard Poetz napisał(a):
There is a startup time stamp in the Spring application context
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/context/ApplicationContext.html#getStartupDate()
maybe you can use that.
The simplest solution that I could think of is adding
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
There is a startup time stamp in the Spring application context
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/context/ApplicationContext.html#getStartupDate()
maybe you can use that.
The simplest solution that
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
You can develop your C22 application (incl. Java sources!) without any
restarts. The problem till yesterday was that the reload of the Spring
application context didn't work. Although the classes where reloaded
in the classloader
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
I'm not up-to-date with RCL stuff so I'm going to ask little ignorant
question. What exactly have you fixed and how it makes development
easier?
You can develop your C22 application (incl. Java sources!)
Grzegorz Kossakowski wrote:
Reinhard Poetz napisaÅ(a):
Grzegorz Kossakowski wrote:
Reinhard Poetz napisaÅ(a):
I'm not up-to-date with RCL stuff so I'm going to ask little ignorant
question. What exactly have you fixed and how it makes development
easier?
You can develop your C22
After more than two days of debugging, many thanks go to Torsten and Carsten who
helped me to track down the problem, I found out, why the reloading classloader
plugin doesn't propertly reload the Spring application context:
The problem is that the DispatcherServlet contains a map of all
65 matches
Mail list logo
