RE: Re[2]: JSR-168 Comments & Dispatching to portlets
[Moving the thread to Jetspeed Dev]
> >My problem is that is seems impossible to do both of:
> > a) Have a Portal implemented on top of a standard Servlet
> Container
> > b) Run multiple Portlet Applications, preferrably in a
> standard Portlet
> >Container, preferrably -the same- container as the Portal is
> running in.
> >.. and be able to, in a standard way, to communicate between
> the portal
> >and the portlets.
>
I agree that one of the concerns of the JSR 168 is that it does not
describe any public standard API for the communication between
the servlet container and the portlet container.
It does not mean it's impossible, simply that portability between
servlet containers will be an implementation specific feature of
the portlet container and that you may have to write servlet-container
specific adapter code.
Note that there's another related area where the portlet container
will have to have servlet container specific code: the portlet
application deployment requires you to deploy a standard WAR and thus
use the servlet colntainer deployment capabilities. :/
On the whole, I don't think this lack of APIs is a real showstopper
and would rather see that as an opportunity for an OSS project like
Jetspeed to work on the multi-containers approach while vendors will
most likely try to focus on tying their servlet and portlet container.
>
> From what I understand of my discussion in this mailing
> list, Pluto does
> something in between : it adds within the portlet a proxy
> servlet that
> allows dispatching to the portlets. This way the system I
> have been using
> with cross-context dispatching could be adapted, but it's
> still not as
> efficient as having a portal/portlet full-blown API. Maybe
> this is the
> subject for a new JSR ? Or maybe in this project (Apache
> Jetspeed) we could
> develop what we need and then propose this as a reference
> implementation
> and submit it as a JSR (maybe that way things would move
> faster ?). Seeing
> how projects such as Xerces and Xalan got accepted throughout
> the whole
> commercial world it would seem like Apache is in a position
> to "impose"
> defacto standards.
>
Yes Pluto implements something like this. The key issue to solve
here is request dispatching: how does the portlet container retrieves
a portlet pointer while still fullfilling the JSR constraints (like
sharing session between the portlet and objects in its WAR (JSPs, etc...)
The porxy servlet is mainly a portlet container specific implementation
of this request dispatching, using the native servlet API calls and some
custom parameters.
I don't believe there's a major performance impact there.
>
> >One way of solving it is apparently using WSRP as the "glue"
> between the
> >portlet and portal.
>
> Yes but at what cost. Serializing all objects through XML and
> sending them
> through sockets that are being opened / closed all the time is very
> expensive in terms of performance.
>
Agreed, I don't think WSRP is the solution to this problem.
>
>
>
> > I would have loved a spec where the Portal was the
> Container, and had to
> >be able to host Portlets within it. This way, one could buy
> the Servlet
> >Container from Oracle, use JetSpeed as the Portal, and buy
> Portlets from
> >CompanyA, B and C, plugging them in / installing like nice little
> >applications in a normal OS.
>
That would however seriously duplicate concerns as the portal/portlet
container would have to deal with classloading, WAR handling, etc...
There is some sense to try to leverage these functions of the servlet
container (after all, how many times do you *really* want lo load
xerces.jar ? :)
The JSR 168 tries to guarantee that any compliant portlet will run on
any compliant container. It does not try to address portlet container
portability just like EJB does not address portability of EJB
container implementations (any luck porting JBoss to Websphere
recently ?)
> Ok, again I agree. Users of portals should be free to migrate
> from one
> system to another, without vendor lock-in. After all the J2EE
> specs exist
> as Sun puts it : "for vendors to compete on implementation,
> and agree on
> standards". This is a nice vision but reality is more like : "vendors
> always compete on anything, Jakarta standardises".
>
+1. SO we can try to standardize what's missing from the JSR... :)
> Now enough with my whining, I'll start a quick proposition
> here : this is
> what I would have loved to see in JSR-168 :
>
> 1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ?
> Basically be able to do something like this :
>
> Context context = getInitialContext();
> PortletRepository portletRepository = (PortletRepository)
> context.lookup("PortletRepository");
> // list of portlet example : ArrayList portletList =
> portletRepository.getPortletList();
> Portlet myPortlet = portletRepository.getPortlet("myPortlet"
Re: Re[2]: JSR-168 Comments & Dispatching to portlets
Hi Endre,
Well I'm happy to see I'm not the only one with this concern. I was
beginning to think that nobody had this problem except me :)
At 11:54 AM 7/29/2003 +0200, you wrote:
My problem is that is seems impossible to do both of:
a) Have a Portal implemented on top of a standard Servlet Container
b) Run multiple Portlet Applications, preferrably in a standard Portlet
Container, preferrably -the same- container as the Portal is running in.
.. and be able to, in a standard way, to communicate between the portal
and the portlets.
Yes b) is exactly my problem too. I thought a lot about it and it would be
possible to develop a "sub portlet container" within the portal, using a
custom built portlet container (but that would imply also have to develop a
sub-servlet container, with everything that includes such as classloaders,
deployment descriptor handling, dispatching, etc). This solution is
interesting because it guarantees complete control over the process and
*no* vendor lock-in, but it's a bit of a shame because you are no longer
using all the tools that are available for the top-level portlet container.
So in effect you'd have this :
Portlet / Servlet Container
---
Portal
---
Sub-Portlet / Servlet Container
This would be heavy but optimal in terms of performance. In a way this is
very close to how Jetspeed currently works, as Jetspeed is a Web
application in a servlet container, and defines it's own "sub" portlet
container. In my work, I've designed a portal that uses cross context
dispatching to dispatch to standard servlets, and although it works quite
well, it is not as flexible as the interfaces that the JSR 168 proposes.
This is why I was hoping (and unfortunately I got involved to late to be a
real part of the JSR process) that they would address this issue, as it
seemed critical to me.
From what I understand of my discussion in this mailing list, Pluto does
something in between : it adds within the portlet a proxy servlet that
allows dispatching to the portlets. This way the system I have been using
with cross-context dispatching could be adapted, but it's still not as
efficient as having a portal/portlet full-blown API. Maybe this is the
subject for a new JSR ? Or maybe in this project (Apache Jetspeed) we could
develop what we need and then propose this as a reference implementation
and submit it as a JSR (maybe that way things would move faster ?). Seeing
how projects such as Xerces and Xalan got accepted throughout the whole
commercial world it would seem like Apache is in a position to "impose"
defacto standards.
One way of solving it is apparently using WSRP as the "glue" between the
portlet and portal.
Yes but at what cost. Serializing all objects through XML and sending them
through sockets that are being opened / closed all the time is very
expensive in terms of performance.
To me, this seems some a kind of vendor lock-in scheme: you buy the
Servlet Engine from us, and wow, it also have a Portal in there,
effeciently doing proprietary communications with the Portlets. You are
suddenly (as it is already) locked to both the Servlet Engine -and- the
Portal (application).
My guess here is that it's indeed a very political issue. All the current
commercial portal vendors involved in JSR-168 could only agree on the most
common and minimal specifications, and they didn't want to have too much
standardized or they would loose their commercial edge. It might not be the
case, but as this process has been entirely closed (even for me, and I am
part of the JCP but only as community member !), I can only speculate as to
what went on in the expert group.
I would have loved a spec where the Portal was the Container, and had to
be able to host Portlets within it. This way, one could buy the Servlet
Container from Oracle, use JetSpeed as the Portal, and buy Portlets from
CompanyA, B and C, plugging them in / installing like nice little
applications in a normal OS.
Ok, again I agree. Users of portals should be free to migrate from one
system to another, without vendor lock-in. After all the J2EE specs exist
as Sun puts it : "for vendors to compete on implementation, and agree on
standards". This is a nice vision but reality is more like : "vendors
always compete on anything, Jakarta standardises".
Now enough with my whining, I'll start a quick proposition here : this is
what I would have loved to see in JSR-168 :
1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ?
Basically be able to do something like this :
Context context = getInitialContext();
PortletRepository portletRepository = (PortletRepository)
context.lookup("PortletRepository");
// list of portlet example : ArrayList portletList =
portletRepository.getPortletList();
Portlet myPortlet = portletRepository.getPortlet("myPortlet");
2. Direct dispat
Re: Re[2]: JSR-168 Comments
On Wed, 23 Jul 2003, Serge Huber wrote: | At 09:05 AM 7/23/2003 -0700, you wrote: | | >Tomcat and Resin have a cross-context invoker feature. | >See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html | | Yes I am aware of those, but it still doesn't solve the problem of | dispatching to a Portlet API portlet. The entry point for one of those | portlets is a class that complies to a certain interface. For a Servlet in | a different web application we can dispatch by doing something like this : | | ServletContext otherWebAppContext = | ServletContext.getContext(otherWebAppContextPath); | RequestDispatcher otherWebAppDispatcher = | otherWebAppContext.getRequestDispatcher(otherWebAppURI) | otherWebAppDispatcher.include(request, response); | | But there is no equivalent for portlets. How can I call the doView method | of a certain portlet ? You'd need a way to access the classloader of the | other context. From what I understand in the implementation that is being | proposed to the ASF there will be a JAR that integrates with Tomcat | (meaning it will not be deployed in a context class loader but in Tomcat's | classloader, providing access down to all sub class loaders) to provide | access to the portlets, but this is very container specific and will have | to be modified to run on any other application server. I so hugely "agree with your problems" here. The spec is -very- confusing on how to bind together the actual portal application (the one that draws the windows and handles the user comms) and the portlet container. It states very hard that it "only defineds the contract between the portlet and the container". But how interesting is that, if it is impossible to actually -make a PORTAL- using these Portlets? My problem is that is seems impossible to do both of: a) Have a Portal implemented on top of a standard Servlet Container b) Run multiple Portlet Applications, preferrably in a standard Portlet Container, preferrably -the same- container as the Portal is running in. .. and be able to, in a standard way, to communicate between the portal and the portlets. One way of solving it is apparently using WSRP as the "glue" between the portlet and portal. To me, this seems some a kind of vendor lock-in scheme: you buy the Servlet Engine from us, and wow, it also have a Portal in there, effeciently doing proprietary communications with the Portlets. You are suddenly (as it is already) locked to both the Servlet Engine -and- the Portal (application). I would have loved a spec where the Portal was the Container, and had to be able to host Portlets within it. This way, one could buy the Servlet Container from Oracle, use JetSpeed as the Portal, and buy Portlets from CompanyA, B and C, plugging them in / installing like nice little applications in a normal OS. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
On Friday, July 25, 2003, at 01:59 AM, Serge Huber wrote: At 05:25 PM 7/24/2003 -0400, you wrote: > As for a Jetspeed portal dispatching to a Weblogic container, that is > something that I don't think is covered by the spec. > The spec covers the contract between the portlet and the container. > You may want to look into the WSRP for that kind of interoperability. Oracle claims to be using WSRP for just that: http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/ articles/OV ERVIEW.WSRP.JSR168.HTML Yes indeed I agree WSRP is an interesting integration technology, but it does have a cost : performance. Doing remote HTTP connections with XML encoding / decoding will (probably) never be as efficient as a simple local method call. Yes I didn't want to say anything negative about the Oracle implementation, because for me the design is quite impressive. But I can't help thinking about the performance hit for all of the encoding and decoding of simple method calls. But I do think it would be interesting for Jetspeed 2 to be able to talk both WSRP and Portlet API (and maybe also it's current API for legacy portlets) in order to offer the maximum compatibility. We should start looking at WSRP and Charon now, and try to build it into the Jetspeed architecture as soon as possible. But thats a discussion best for the other list (jetspeed-dev) -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[2]: JSR-168 Comments
We have discussed UDDI, David brought it up on IRC, and I think it is a good idea. *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 5:26 PM > To: [EMAIL PROTECTED] > Subject: RE: Re[2]: JSR-168 Comments > > > > As for a Jetspeed portal dispatching to a Weblogic container, that is > > something that I don't think is covered by the spec. > > The spec covers the contract between the portlet and the container. > > You may want to look into the WSRP for that kind of interoperability. > > Oracle claims to be using WSRP for just that: > http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/articles/ > OV > ERVIEW.WSRP.JSR168.HTML > > I haven't looked at it very closely, but it seems to be a good approach. > I > could see a Jetspeed Portal server talking to multiple JSR-168 portlet > provider servers via WSRP. Toss in a UDDI directory to register local and > remote portlets and I think things start to get interesting. (Of course, a > full blown UDDI server is overkill for a local registry, but having > linkage > to a UDDI directory sounds like a good thing.) I could see people > standing > up little local portlet servers for nifty portlet apps - email, calendar, > currency conversion, Star Trek quotes, blog service, etc. > > - Jasen. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[2]: JSR-168 Comments
At 05:25 PM 7/24/2003 -0400, you wrote: > As for a Jetspeed portal dispatching to a Weblogic container, that is > something that I don't think is covered by the spec. > The spec covers the contract between the portlet and the container. > You may want to look into the WSRP for that kind of interoperability. Oracle claims to be using WSRP for just that: http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/articles/OV ERVIEW.WSRP.JSR168.HTML Yes indeed I agree WSRP is an interesting integration technology, but it does have a cost : performance. Doing remote HTTP connections with XML encoding / decoding will (probably) never be as efficient as a simple local method call. But I do think it would be interesting for Jetspeed 2 to be able to talk both WSRP and Portlet API (and maybe also it's current API for legacy portlets) in order to offer the maximum compatibility. Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[2]: JSR-168 Comments
> As for a Jetspeed portal dispatching to a Weblogic container, that is > something that I don't think is covered by the spec. > The spec covers the contract between the portlet and the container. > You may want to look into the WSRP for that kind of interoperability. Oracle claims to be using WSRP for just that: http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/articles/OV ERVIEW.WSRP.JSR168.HTML I haven't looked at it very closely, but it seems to be a good approach. I could see a Jetspeed Portal server talking to multiple JSR-168 portlet provider servers via WSRP. Toss in a UDDI directory to register local and remote portlets and I think things start to get interesting. (Of course, a full blown UDDI server is overkill for a local registry, but having linkage to a UDDI directory sounds like a good thing.) I could see people standing up little local portlet servers for nifty portlet apps - email, calendar, currency conversion, Star Trek quotes, blog service, etc. - Jasen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
On Thursday, July 24, 2003, at 08:31 AM, Serge Huber wrote: At 08:16 AM 7/24/2003 -0700, you wrote: Im sorry, but I don't follow your logic. The proxy servlet is a part of the portlet container implementation. You can still take your exact same Portlet Application and drop it in any other compliant container. From the portlet's point of view, it shouldn't matter how the container is implemented, as long as the portlet container is compliant. Ok I hadn't noticed the proxy servlet was part of the container's implementation (did I miss this in the spec ? could you point me to it ? thanks) Or is it only available in the Pluto implementation ? Its not a part of the spec. Its just one way to implement it. Since Jetspeed tries to run on more than one servlet container, this solution meets our needs. I agree that from the portlet's point of view it shouldn't matter, and that's the whole point of the current spec. What I was asking was how do we make Jetspeed portable to any Portlet API and Servlet API 2.3 compliant container ? How does Jetspeed dispatch to portlets deployed in a portal container (for exemple how does Jetspeed dispatch to a portlet deployed in WebLogic's portal container?). It seems to me the current spec doesn't cover this, but if it does I'm happy :) When you say "any Portlet API", besides the JSR 168, what other Portlet APIs do you have in mind? Jetspeed currently runs as a web application. We can deploy this web application to any Servlet 2.2 container. I hope that a Portlet API compliant Jetspeed will continue this approach, since I know of many Jetspeed users who do not run on Tomcat in production. As for a Jetspeed portal dispatching to a Weblogic container, that is something that I don't think is covered by the spec. The spec covers the contract between the portlet and the container. You may want to look into the WSRP for that kind of interoperability. Now I am not saying that this is the only way to implement a portlet container. I think the most common implementation will be to put it in the servlet container. We have considered moving the portlet container into Tomcat, but as you pointed out, it will couple Jetspeed to working with only Tomcat. That may be the direction we take in the future, or it may be another project based in Tomcat. This is all up to the Jetspeed community. Ok I think I understand. You've managed to find a portable way to provide an implementation of the Portlet API by including it in the web application itself. But unfortunately this is not specified by the JCP as far as I can tell and therefore will not be officially recognized by other portlet containers which is unfortunate. Jetspeed has always ran as a web application. I think we have to make some choices about the future Jetspeed model. Perhaps we should be more tightly coupled with Tomcat, and forget about portability of the portal code to other containers Or perhaps Tomcat should have a portlet container built-in. We have been discovering the need for a standard Java interface between portal and container. These decisions are up to all of us in the community here to decide Oh Pluto, well that's what Im talking about too. Why didn't you just say Pluto :), Pluto uses the same approach as I am describing above. You will soon have the opportunity to see what Im talking about. We were planning on opening up a new CVS on Monday, jakarta-jetspeed-2. However, we are still waiting to get the directories created on the CVS server at Apache. As soon as this happens, I'll let you know. Cool, can't wait to see, and help out if possible ! Well its very much under development . Your thoughts and contributions are always welcome Its never too late to get involved -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
At 08:16 AM 7/24/2003 -0700, you wrote: Im sorry, but I don't follow your logic. The proxy servlet is a part of the portlet container implementation. You can still take your exact same Portlet Application and drop it in any other compliant container. From the portlet's point of view, it shouldn't matter how the container is implemented, as long as the portlet container is compliant. Ok I hadn't noticed the proxy servlet was part of the container's implementation (did I miss this in the spec ? could you point me to it ? thanks) Or is it only available in the Pluto implementation ? I agree that from the portlet's point of view it shouldn't matter, and that's the whole point of the current spec. What I was asking was how do we make Jetspeed portable to any Portlet API and Servlet API 2.3 compliant container ? How does Jetspeed dispatch to portlets deployed in a portal container (for exemple how does Jetspeed dispatch to a portlet deployed in WebLogic's portal container?). It seems to me the current spec doesn't cover this, but if it does I'm happy :) Now I am not saying that this is the only way to implement a portlet container. I think the most common implementation will be to put it in the servlet container. We have considered moving the portlet container into Tomcat, but as you pointed out, it will couple Jetspeed to working with only Tomcat. That may be the direction we take in the future, or it may be another project based in Tomcat. This is all up to the Jetspeed community. Ok I think I understand. You've managed to find a portable way to provide an implementation of the Portlet API by including it in the web application itself. But unfortunately this is not specified by the JCP as far as I can tell and therefore will not be officially recognized by other portlet containers which is unfortunate. Oh Pluto, well that's what Im talking about too. Why didn't you just say Pluto :), Pluto uses the same approach as I am describing above. You will soon have the opportunity to see what Im talking about. We were planning on opening up a new CVS on Monday, jakarta-jetspeed-2. However, we are still waiting to get the directories created on the CVS server at Apache. As soon as this happens, I'll let you know. Cool, can't wait to see, and help out if possible ! Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
On Thursday, July 24, 2003, at 06:54 AM, Serge Huber wrote: Hi David, At 10:05 AM 7/23/2003 -0700, you wrote: Yes I am aware of those, but it still doesn't solve the problem of dispatching to a Portlet API portlet. The entry point for one of those portlets is a class that complies to a certain interface. For a Servlet in a different web application we can dispatch by doing something like this : ServletContext otherWebAppContext = ServletContext.getContext(otherWebAppContextPath); RequestDispatcher otherWebAppDispatcher = otherWebAppContext.getRequestDispatcher(otherWebAppURI) otherWebAppDispatcher.include(request, response); Well one solution is to use a proxy servlet as part of the container which must reside in the portlet application, this servlet is seeded into the WAR during deployment. I've seen one other solution, where there had to be one servlet for each portlet, but I prefer the first solution. With the first approach, the deploy program is specific to the portal implementation, but the Portlet Application WAR is still portable. Well the proxy servlet would work, but it kinda removes the need for the Portlet API in a way. If we can integrate with proxy servlets, why need a portlet API ? Im sorry, but I don't follow your logic. The proxy servlet is a part of the portlet container implementation. You can still take your exact same Portlet Application and drop it in any other compliant container. From the portlet's point of view, it shouldn't matter how the container is implemented, as long as the portlet container is compliant. Now I am not saying that this is the only way to implement a portlet container. I think the most common implementation will be to put it in the servlet container. We have considered moving the portlet container into Tomcat, but as you pointed out, it will couple Jetspeed to working with only Tomcat. That may be the direction we take in the future, or it may be another project based in Tomcat. This is all up to the Jetspeed community. But there is no equivalent for portlets. How can I call the doView method of a certain portlet ? You'd need a way to access the classloader of the other context. From what I understand in the implementation that is being proposed to the ASF there will be a JAR that integrates with Tomcat (meaning it will not be deployed in a context class loader but in Tomcat's classloader, providing access down to all sub class loaders) to provide access to the portlets, but this is very container specific and will have to be modified to run on any other application server. I haven't seen the solution proposed by the ASF. Where can I find out about that,? Well I'm talking about project Pluto. From what I understand it will work as a library that will integrate with the servlet container, and the only way to do that is to be in the containers class loader. (http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal) Oh Pluto, well that's what Im talking about too. Why didn't you just say Pluto :), Pluto uses the same approach as I am describing above. You will soon have the opportunity to see what Im talking about. We were planning on opening up a new CVS on Monday, jakarta-jetspeed-2. However, we are still waiting to get the directories created on the CVS server at Apache. As soon as this happens, I'll let you know. -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
Hi David, At 10:05 AM 7/23/2003 -0700, you wrote: Yes I am aware of those, but it still doesn't solve the problem of dispatching to a Portlet API portlet. The entry point for one of those portlets is a class that complies to a certain interface. For a Servlet in a different web application we can dispatch by doing something like this : ServletContext otherWebAppContext = ServletContext.getContext(otherWebAppContextPath); RequestDispatcher otherWebAppDispatcher = otherWebAppContext.getRequestDispatcher(otherWebAppURI) otherWebAppDispatcher.include(request, response); Well one solution is to use a proxy servlet as part of the container which must reside in the portlet application, this servlet is seeded into the WAR during deployment. I've seen one other solution, where there had to be one servlet for each portlet, but I prefer the first solution. With the first approach, the deploy program is specific to the portal implementation, but the Portlet Application WAR is still portable. Well the proxy servlet would work, but it kinda removes the need for the Portlet API in a way. If we can integrate with proxy servlets, why need a portlet API ? But there is no equivalent for portlets. How can I call the doView method of a certain portlet ? You'd need a way to access the classloader of the other context. From what I understand in the implementation that is being proposed to the ASF there will be a JAR that integrates with Tomcat (meaning it will not be deployed in a context class loader but in Tomcat's classloader, providing access down to all sub class loaders) to provide access to the portlets, but this is very container specific and will have to be modified to run on any other application server. I haven't seen the solution proposed by the ASF. Where can I find out about that,? Well I'm talking about project Pluto. From what I understand it will work as a library that will integrate with the servlet container, and the only way to do that is to be in the containers class loader. (http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal) Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
On Wednesday, July 23, 2003, at 09:30 AM, Serge Huber wrote: At 09:05 AM 7/23/2003 -0700, you wrote: Tomcat and Resin have a cross-context invoker feature. See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html Yes I am aware of those, but it still doesn't solve the problem of dispatching to a Portlet API portlet. The entry point for one of those portlets is a class that complies to a certain interface. For a Servlet in a different web application we can dispatch by doing something like this : ServletContext otherWebAppContext = ServletContext.getContext(otherWebAppContextPath); RequestDispatcher otherWebAppDispatcher = otherWebAppContext.getRequestDispatcher(otherWebAppURI) otherWebAppDispatcher.include(request, response); Well one solution is to use a proxy servlet as part of the container which must reside in the portlet application, this servlet is seeded into the WAR during deployment. I've seen one other solution, where there had to be one servlet for each portlet, but I prefer the first solution. With the first approach, the deploy program is specific to the portal implementation, but the Portlet Application WAR is still portable. But there is no equivalent for portlets. How can I call the doView method of a certain portlet ? You'd need a way to access the classloader of the other context. From what I understand in the implementation that is being proposed to the ASF there will be a JAR that integrates with Tomcat (meaning it will not be deployed in a context class loader but in Tomcat's classloader, providing access down to all sub class loaders) to provide access to the portlets, but this is very container specific and will have to be modified to run on any other application server. I haven't seen the solution proposed by the ASF. Where can I find out about that,? -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
At 09:05 AM 7/23/2003 -0700, you wrote: Tomcat and Resin have a cross-context invoker feature. See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html Yes I am aware of those, but it still doesn't solve the problem of dispatching to a Portlet API portlet. The entry point for one of those portlets is a class that complies to a certain interface. For a Servlet in a different web application we can dispatch by doing something like this : ServletContext otherWebAppContext = ServletContext.getContext(otherWebAppContextPath); RequestDispatcher otherWebAppDispatcher = otherWebAppContext.getRequestDispatcher(otherWebAppURI) otherWebAppDispatcher.include(request, response); But there is no equivalent for portlets. How can I call the doView method of a certain portlet ? You'd need a way to access the classloader of the other context. From what I understand in the implementation that is being proposed to the ASF there will be a JAR that integrates with Tomcat (meaning it will not be deployed in a context class loader but in Tomcat's classloader, providing access down to all sub class loaders) to provide access to the portlets, but this is very container specific and will have to be modified to run on any other application server. Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
On Wednesday, July 23, 2003, at 06:00 AM, Serge Huber wrote: What's interesting about that document is page 14 "What The Portlet Specification Does Not Address", notably : Portlet Aggregators, Pre-built Portlets and Administration and Portlet Deployment. One of the issues I see for Jetspeed 2, using the new Portlet API, is how to port Jetspeed to other application servers than Tomcat. From what I understand of the specification, nothing concerning the dispatching to portlets is standardized, meaning there is no standard way to "lookup a portlet" and then to call the render or action methods on that portlet. As portlets are special classes in a standard Web application, this means it will be left to every servlet container implementation to do this in it's own way. And most servlet containers protect web applications contexts from one another, meaning they are in different class loader, so there is no way that Jetspeed, being a web application itself, could access the class of another web application in another context and dispatch to it. Sure Jetspeed could include a complete servlet container, but that's kinda unfortunate since we usually want to let the application server do that. Another way to look at this problem is : how do we port Jetspeed to other platforms than Tomcat ? In Tomcat we can access the whole source code and add interceptors into the servlet lookup to dispatch to a portlet from Jetspeed. How would we do this on Orion, or Resin, or WebLogic, or WebSphere ? Tomcat and Resin have a cross-context invoker feature. See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html I don't know about the commercial products -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: JSR-168 Comments
What's interesting about that document is page 14 "What The Portlet Specification Does Not Address", notably : Portlet Aggregators, Pre-built Portlets and Administration and Portlet Deployment. One of the issues I see for Jetspeed 2, using the new Portlet API, is how to port Jetspeed to other application servers than Tomcat. From what I understand of the specification, nothing concerning the dispatching to portlets is standardized, meaning there is no standard way to "lookup a portlet" and then to call the render or action methods on that portlet. As portlets are special classes in a standard Web application, this means it will be left to every servlet container implementation to do this in it's own way. And most servlet containers protect web applications contexts from one another, meaning they are in different class loader, so there is no way that Jetspeed, being a web application itself, could access the class of another web application in another context and dispatch to it. Sure Jetspeed could include a complete servlet container, but that's kinda unfortunate since we usually want to let the application server do that. Another way to look at this problem is : how do we port Jetspeed to other platforms than Tomcat ? In Tomcat we can access the whole source code and add interceptors into the servlet lookup to dispatch to a portlet from Jetspeed. How would we do this on Orion, or Resin, or WebLogic, or WebSphere ? Regards, Serge Huber. At 11:06 AM 7/23/2003 +0700, you wrote: http://developers.sun.com/prodtech/portalserver/reference/techart/jsr168/pb_whitepaper.pdf Jetspeed 2.0 is JSP taglib for Portlet?? what do you think Regards, Frans Thamura <[EMAIL PROTECTED]> Intercitra Innovation Center +62 855 7888 699 We help you manage and control. -- Tertarik dengan Java Open Source Integration discussion?? bergabung ke JUG Indonesia mailing list, untuk subscribe email aja ke [EMAIL PROTECTED] Website: http://jug-indonesia.dev.java.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- --- -=[ serge.huber at jahia dot com ]= --- -- - Jahia : A collaborative source CMS and Portal Server www.jahia.org Community and product web site www.jahia.com Commercial services company - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: JSR-168 Comments
http://developers.sun.com/prodtech/portalserver/reference/techart/jsr168/pb_whitepaper.pdf Jetspeed 2.0 is JSP taglib for Portlet?? what do you think Regards, Frans Thamura <[EMAIL PROTECTED]> Intercitra Innovation Center +62 855 7888 699 We help you manage and control. -- Tertarik dengan Java Open Source Integration discussion?? bergabung ke JUG Indonesia mailing list, untuk subscribe email aja ke [EMAIL PROTECTED] Website: http://jug-indonesia.dev.java.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
