Vadim Gritsenko wrote:
Upayavira wrote:
Vadim Gritsenko wrote:
Well, we have briefly talked about the fact that we need to support
both scenarios. We need to be able to run the Cocoon servlet within
an OSGi framework, and this will probably be the default option, and
we also
I can not imagine who or in what environment will ever run this, and
why.
You're saying that, as far as you're concerned, Cocoon should _just_
be a servlet, and OSGi should be embedded and invisible?
(don't forget command line, portlet, or any other 3rd party environments
too)
Oh, I didn't. I started to mention them, then stopped.
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).
Me too. The OSGi container is, in my (limited) impression, capable of
handling production deployments. However, it will not, in itself,
satisfy those that need to deploy within an servlet container.
Well, that's not the way that OSGi works.
:-)
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, which can have mounts for different
blocks - if blocks are used at all.
Well, the exact details would need to be worked out. We've talked about
this already. There are potential issues, e.g. to do with URLHandlers,
but these are issues that are specific to OSGi, not just Cocoon, and
would best be handled on felix-dev, for example.
Remember, it is always easier to do small steps than one huge leap into
unknown :)
Well, actually, the OSGi framework way is a smaller step. It pretty much
works now. The servlet container approach requires more consideration
and work.
need to support running an OSGi framework within a servlet (and a
Cocoon servlet within that OSGi framework), for those that _must_
run Cocoon in a servlet container, such as JBoss, etc.
This seems to me like the option used by most Cocoon users. IMHO, for
an average Cocoon user it should not even matter whether you buried
OSGi somewhere inside Cocoon or not.
This may be the way used my most Cocoon users at the moment, yes.
However, many Cocoon users just want to start Cocoon, they're not
fussed about a servlet container, that's just a complication. For
those, the OSGi approach will work.
It might go well while you are developing an app... As long as you can
keep said app isolated from other pieces you have to be integrated with
(which is usually not the case).
Well, usually is in my case, but likely not in many.
For the more aware, and perhaps constrained (e.g. by corporate
requirements for a specific servlet container), will require the
ability to run within a container.
Include here hosted apps: as long as there is no abundance of "OSGi
hosting", you will have to bundle your app as a war.
Yup.
Include here integration with existing apps: as long as you have
investments into j2ee or some other technology not available under OSGi,
you will prefer using Cocoon as a servlet.
Which is why I've been talking about both - I've always seen that we
need both approaches, just that the OSGi framework is the easiest to
implement.
Forcing OSGi will limit applicability of Cocoon in many (imho, almost
all) environments.
Yup.
To do it the other way brings up some issues that will need to be
resolved. We will need to write a servlet that will defer requests to
the OSGi framework.
Exactly my point. I never questioned this.
Good!
Upayavira, who's looking forward to meeting Vadim again!
