Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Upayavira wrote:
Vadim Gritsenko wrote:
(don't forget command line, portlet, or any other 3rd party
environments too)
Yes, and I've not seen how it can be otherwise (i understand that
it's possible to use current osgi http service for an R&D process,
i'm mostly talking about production deployments).
The OSGi HttpService is an API, there are several implementations of
the service, one is based on Jetty. Have you found any limitations in
the OSGi HttpService API that makes it unsutable for production
environments?
Deployment environments I worked with so far include WebSphere,
WebLogic, and Tomcat. As long as these environments supported, I'm Ok.
If not, sooner or later I'll have to make sure that they are.
You start a framework, you start a servlet container bundle, then
you start your servlet bundle, all within the OSGi framework.
Replace 'you' with 'program', name this program CocoonOSGiServlet,
and we have something working. No need for servlet & servlet
container bundle, though. CocoonOSGiServlet will create Environment,
and pass it on to the TreeProcessor as usual,
Will it? This is not the way we have implemented it.
I was not implying it's currently done this way.
Vadim, I and others have spent a huge effort in the current design
and implementation. All important design questions and decisions have
been documented at the mail list and been approved explicitly by some
people and by lazy consensus by the rest of you. I think it is time
that you do your homework
I tried.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112177131522853
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112227711007436
<quote>
smooth migration path: you could simply use your old
applications as they are for 2.1.x without using bundles/blocks
and they would simply still work (with all the disadvantages of
course)
</quote>
and I wholeheartedly agree with the above.
<snip/>
This is open source you are not geting what you require, you get what
you implement.
:-)
Yes, I agree that an embeding servlet might be good for marketing and
that it obviously seem to be central in the way you build things. But
subtilities in servlet containers is not my area of speciality so I'm
not able to take care of that area. If you find it important, you and
others that find it important have to take care of it.
I'm sorry I lack time atm to join you or follow all discussions, but
if I to use Cocoon 2.2, I will have to implement the above - so yes,
it will be eventually taken care of.
Seconded. We will *all* need to run Cocoon as a servlet in whatever J2EE
server our customers require us to run it on (for example, we recently
were asked to deploy on an SAP app server). Saying that we can't deploy
on an app server because it's not available as an OSGi HttpService will
just make people throw away Cocoon, and us with it.
So although I clearly admit that using the OSGi HttpService is easier to
run Cocoon as a set of bundles, we shouldn't forget that we also need to
run Cocoon in a war file.
Yes, and, just to make it clear, no-one, including Daniel, suggested
that we wouldn't do so, only that doing it within the framework is easier.
And this requires to run the OSGi framework within a webapp classloader.
I understand this may prevent the use of the URL service, and we have to
find out if there are other issues as well. This discussion clearly
belongs to felix-dev.
Yup. When someone steps forward to solve that problem, that is the place
they should go.
Regards, Upayavira
- Re: [RT] Blocks that modify web.xml Upayavira
-
