Re: WO Deployment [was:A WebObjects article on Appleinsider]
Re: WO Deployment [was:A WebObjects article on Appleinsider]
- Subject: Re: WO Deployment [was:A WebObjects article on Appleinsider]
- From: Lachlan Deck <email@hidden>
- Date: Fri, 10 Jul 2009 11:06:06 +1000
On 10/07/2009, at 8:24 AM, Andrew Lindesay wrote:
There 2 issues to fix: one is trivial the session id key is
"sessionid" and not "wosid" 5.4 and later support changing that key.
If you grab "LEWOAJPContext" from LEWOStuff, you will see that I
stick the route (to get back to the instance) and session id into
the URLs using the standard ";jsessionid=" technique. I guess if
WOContext did this instead when it finds itself being fed from
"mod_balancer" then it would be all that were required.
The other issue is dynamic reconfiguration. Adding an instance
require editing the apache config file and restarting apache. We
need to add to the mod_proxybalancer a mechanism to dynamically
load the configuration, this is not a major endeavor and I am
looking for a volunteer… We should contribute this code back to the
apache foundation so we don not have to maintain it ourself. I
would be happy to work with whoever volunteer.
It was actually my intention to look into this a couple of years
ago, but guessed that I would wait and see if Apple were going to do
anything with deployment going forward first. I'd be quite keen to
take a look, but it may take a little while to fit around chargeable
work. I think such a deployment-refresh would be really good for
the platform.
I like the idea of moving to a servlet container bundle. I am not
sure what would be required for this to work.
I don't of course have access to the WO source code, but I _guess_
that in broad terms, I would scrap most of the scaffolding that must
exist in WO before "dispatchRequest(..)" gets hit and just hook
"dispatchRequest()" directly up to the interfaces on
"javax.servlet.http.HttpServlet" such as "goGet", "doPost" etc...
I'm sure it is much the same stuff that is going on in the JSP/
Servlet framework. There was, somewhere in the 5.4 API, a situation
where the instance number was being exposed as public and this needs
to be removed as it will make no sense under servlet or balancer
deploy -- this is quite an important point. Next, the HTTP server
that exists inside WO should be removed and so it only communicates
through the servlet API.
WOA's would then be built into 'war' or 'servlet directories' to be
unpacked into a servlet container – Jetty, Tomcat,
WebSphere...etc... In order to produce framework jars, I have
extended the standard ant "Jar" task with some specific WebObjects
material to build WebObjects framework jars. The same sort of
approach could be taken for building WOA 'wars' -- extend the 'War'
task. I'm not sure about Maven (sorry Henrique and Lachlan!).
No worries. I'm already building all my frameworks as jars using
standard maven 'jar' packaging. The woproject woframework packaging
does this also (and supplies the Info.plist and wo-jar packaging
layout with a tiny bit less config).
war packaging is well supported (and quite standard in maven).
Henrique knows more about wars. I've not really ventured down that
path (yet). But certainly if WO was easy to work with in servlet mode
that'd be great ... mvn jetty:run would do the trick :)
I know Jetty is pretty easy to work with, but to make things easier,
a "tiny little servletish container" (TLSC) (thanks Mike) could be
written which would wrap the WebObjects servlet and feed it with
requests through the standard servlet API's. I know Jetty is really
easy to use, but this TLSC would be just there to run the one
servlet rather than a bunch of servlets so it would retain the
spirit of one instance = one process and the dead simple
configuration that WebObjects has now. It would essentially also
mean that there is a high level of continuity with what most of us
are doing now as well.
I have attached a drawing to try to illustrate what I mean.
(Mike)
do you get into weird issues with servlet.jar dependencies here?
if this was in WO core, for instance, presumably JavaWebObjects.jar
would have to have a servlet.jar dependency ... to run it in dev w/
directconnect you'd have to have that servlet.jar in your project,
but to deploy it into a servlet container, you'd want that to be
gone or the container yells at you. do you run into this problem
or am i just making that out to be more difficult than it is?
I _think_ they get around this by the servlet-container having it's
own class loader so that the servlet API is not actually in the
servlet itself. At build time, yes it would need to be external. I
don't have this problem because I no longer build as servlet!
(Chuck)
What are the advantages of moving to a servlet container bundle?
As far as I can see;
* new developers already know what a servlet is and it surprisingly
doesn't scare them
* managers making decisions already know what a servlet is and it
surprisingly doesn't scare them
* we loose any discrepancies between regular and servlet development/
deployment
* build process is probably simplified and can probably extend
existing tools so Apple/we don't need to maintain/document so much
stuff
* by creating the "tiny little servletish container" we can get the
topology and simplicity that we get now
* because it's what most people are doing and we can "fit in and
stand out" rather than "not fit in and stand out"
* gives us more control and options around our deployments
cheers.
___
Andrew Lindesay
www.lindesay.co.nz
<WODeploymentTopologyIdeas.graffle.pdf>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden