[Ds-java-dev] session on carbon usage

[Sanjaya Karunasena]

I am bit concerned about us trying interfere too much with the JSP translation 
process and the servlet engine.

Phases of a JSP
==========
A JSP goes through two phases, a translation phase and a request phase. During 
the translation phase the JSP is translated to create a servlet class which 
is the JSP page implementation class. This is instantiated at request time to 
handles requests and creates responses. Eventhough the translation phase is a 
dependency for the request phase the spec doesn't specify at which point this 
translation could occur. Therefore the container may take a JSP through the 
translation phase way before a request is initiated for that page. For 
example, Jasper has a separate thread which check JSPs and goes and compiles 
them on a periodic event. Since this is not covered in the spec the different 
implementations must be doing various things to have better performance.

JSP specification
http://java.sun.com/products/jsp/reference/api/index.html

Servlet specification
http://java.sun.com/products/servlet/download.html

This means to handle JSP compilation in our own way, we need to disable any of 
these fancy stuff, a JSP engine could do under the cover outside of the spec 
since the spec simply has stated an order of event.

URL Pattern Limitations
===============
As per the specification, a web.xml can contain only two types of URL 
patterns.

File extension => *.do, *.action, etc
Directory pattern => /foo/bar/*

This is all you can do. Now to handle JSP compilation in our own way we need 
to get all *.jsp requests coming in to our servlet and obviously we don't 
need all these jsp request coming in to our servlet. But the only usable 
patter here is the directory pattern. That means all the requests which 
originate under that pattern, which include images, js files, css files, etc 
will get landed in the target servlet. Since a JSP can have all that, this 
problem is guaranteed.

Second complexity here is handling <jsp:forward>. The spec doesn't say this 
should trigger a http redirect at the server side. If required the servlet 
engine can internally forward the http request object to the target servlet 
(or the JSP).

Class cast problem with different class loaders
=============================

The biggest problem is when all the components are not OSGI aware due to 
different class loaders we are unable pass java object between these 
different classes. Now due to previous reasons, it is difficult for us to 
make the servlet container OSGI aware in a consistent manner. So when you get 
an object which constructed by the servlet container (e.g. an object 
constructed via a html form) for us to do some thing usefull, we should be 
able to call a backend API with that. Eventhough the backend component is 
OSGI aware the servlet container is not, and therefore they are having two 
different class loaders. Its simply through a class cast exception at this 
point. Now, Saminda is trying to find a way around for this....

Thoughts, ideas? .....

I see few solutions until the servlet containers provide better support for 
OSGI...

1. No versioning support for UIs
2. If we have UI bits which potentially requires versioning, we use AJAX 
stuff.
3. Complete AJAX based UIs


/Sanjaya


On Monday 03 March 2008, Sanjiva Weerawarana wrote:
> Notes from today's meeting:
>
> - It turns out that OSGI's bundle class loading stuff doesn't quite work
> within a WAR file. That is, if you use JSPs and the JSPs need to load
> classes (e.g., useBean) then those classes have to be in the webapp class
> loader, which would eliminate the ability to have two versions of a given
> bundle etc..
>
> - That was because we were trying to load JSPs by copying them into the
> war file directly (out of the bundles that is). That was necessary because
> there's no JSP compiler integration for arbitrary servlet containers
> available via Felix.
>
> - We discussed an approach where we introduce a dispatcher servlet (which
> is Felix-aware) to route requests into a bundle and then a further
> dispatch within the bundle to the proper servlet. We'd then compile all
> JSPs into servlets before deploying and voila it should all work. Saminda
> will do some experimentation and see.
>
> - But that causes a development issue- editing one line in a JSP and
> deploying would take multiple minutes. Not acceptable.
>
> - We discussed a "development maven profile" (whatever that means) to
> build a different war which doesn't support multiple versions of bundles
> etc. which would have the simple ability to edit a JSP in place. Someone
> was going to work on this; not sure who.
>
> - We also discussed a way to re-use current UI code without rewriting them
> so that we can ship something fast rather than waiting for months.
>
> - I should note that there appears to be increasing appreciation for the
> simplicity and elegance of just doing straight AJAX UIs w/o any
> middle-tier at all. OSGI for managing different versions of different
> components is fine but the UI bit of it a bit of a pain. However, I think
> once we sort out how to reuse the current UI work (which IMO is easy) then
> we'll have the flexibility to have the current architecture (all AJAX all
> the way) to all server-side JSPs to everything in the middle without
> trouble.
>
> Sanjiva.
>
> Glen Daniels wrote:
> > I'll try to make it if I can either stay up that late or take a nap
> > beforehand. :)  Have you guys already set up a dialin?
> >
> > --Glen
> >
> > Sanjiva Weerawarana wrote:
> >> +1 .. I have a call for a bit before that but I should be able to come
> >> soon after.
> >>
> >> Sanjiva.
> >>
> >> Afkham Azeez wrote:
> >>> Shall we have this on Monday, starting at 11AM?
> >>>
> >>> Azeez
> >>>
> >>> Sumedha Rubasinghe wrote:
> >>>> folks,
> >>>> Shall we have a session on Carbon usage tomorrow?
> >>>>
> >>>> Lets try to use Carbon for a hypothetical solution & cover commons
> >>>> scenarios/patterns required by future applications. Covering,
> >>>>
> >>>> 1. Service Deployment
> >>>> 2. Module Deployment
> >>>> 3. UI
> >>>>
> >>>> With this level of knowledge, we can kick off UI design &
> >>>> development for DS solution.
> >>>>
> >>>> Currently work on DS core & eclipse plugin are being carried out
> >>>> using existing environment(WSAS) & we need to start moving towards a
> >>>> Carbon based environment to minimize future integration problems.
> >>>>
> >>>> /sumedha
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Ds-java-dev mailing list
> >>>> Ds-java-dev at wso2.org
> >>>> http://wso2.org/cgi-bin/mailman/listinfo/ds-java-dev
> >>>
> >>> _______________________________________________
> >>> Ds-java-dev mailing list
> >>> Ds-java-dev at wso2.org
> >>> http://wso2.org/cgi-bin/mailman/listinfo/ds-java-dev