You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2004/08/26 16:36:43 UTC
Portal - PortletDefinitionRegistryImpl question
I posted this last week and just want to make sure I'm not doing anything
wrong, as I plan to submit a patch as soon as I verify that it works
correctly (I'm not getting a NullPointerException at startup at least).
I am trying to modify the pluto support so that it will work in a war
file. In looking at PortletDefinitionRegistryImpl I see that it is
looking at every webapp deployed in this server and calling castor to
convert the portlet.xml and web.xml to objects for every webapp that has a
portlet.xml. Why would it be doing that? That would seem like a
violation of security or at least bad manners. Of course, it is also
impossible to do in an environment where war files are used.
Ralph
RE: Portal - PortletDefinitionRegistryImpl question
Posted by Ralph Goers <Ra...@dslextreme.com>.
At 8/26/2004 11:29 PM, you wrote:
>At 8/26/2004 11:19 PM, you wrote:
>
>>A JSR-168 portlet (or a set of them) is a complete webapp plus
>>a configuration file! Pluto and therefore Cocoon uses the
>>easiest way to handle this by using the servlet engine to
>>deploy those portlet webapps - I don't know how other
>>portal engines do it.
>
>Yes. But I was under the impression that the portlet.xml file would exist
>within the Cocoon webapp along with all the portlets.
Well darn. I just reread the deployment chapter and now I see what I was
missing. This makes it very hard for a standard servlet to be a portal
unless it is also integrated with the servlet container.
RE: Portal - PortletDefinitionRegistryImpl question
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> >However, the best solution would be a deployment functionality
> >for JSR-168 in Cocoon.
>
> Do you have any suggestions on how this could be
> accomplished? I'd be
> happy to implement it, but using the services available to
> servlets I'm not
> sure how to do that. In fact, because our war is packaged in
> an ear I
> can't even find out the context path during initialization.
>
No, I don't have any clue right now - the only suggestion I have
is to look at other portal implementations and see how they
managed this.
Carsten
RE: Portal - PortletDefinitionRegistryImpl question
Posted by Ralph Goers <Ra...@dslextreme.com>.
At 8/26/2004 11:19 PM, you wrote:
>A JSR-168 portlet (or a set of them) is a complete webapp plus
>a configuration file! Pluto and therefore Cocoon uses the
>easiest way to handle this by using the servlet engine to
>deploy those portlet webapps - I don't know how other
>portal engines do it.
Yes. But I was under the impression that the portlet.xml file would exist
within the Cocoon webapp along with all the portlets.
> >
> > Also, how does that actually work? How does the portlet run
> > if it needs jars from the other webapp? Wouldn't you get a
> > ClassNotFoundException?
>You don't need classes etc. If a portlet is used the request
>is forwarded to the portlet webapp.
>
>So, currently only looking in the Cocoon war would break
>the JSR-168 feature.
>If you don't need JSR-168 portlets, you can use a different
>portal manager and turn off the support.
I'm not sure why that would break anything. My reading of the spec led me
to believe that a Portal is a single webapp with all portlets deployed
within it. In this case, all the portlets would have to exist within the
war. I absolutely need the support, but I was planning on packaging all
the available portlets inside the war.
>However, the best solution would be a deployment functionality
>for JSR-168 in Cocoon.
Do you have any suggestions on how this could be accomplished? I'd be
happy to implement it, but using the services available to servlets I'm not
sure how to do that. In fact, because our war is packaged in an ear I
can't even find out the context path during initialization.
>Carsten
RE: Portal - PortletDefinitionRegistryImpl question
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>
> In my patch I have it only scanning the current war file. I
> don't know of any way to even get access to other webapps
> from inside a war. Then again, I'm not sure why I'd want to
> get to portlets from some other webapp.
A JSR-168 portlet (or a set of them) is a complete webapp plus
a configuration file! Pluto and therefore Cocoon uses the
easiest way to handle this by using the servlet engine to
deploy those portlet webapps - I don't know how other
portal engines do it.
>
> Also, how does that actually work? How does the portlet run
> if it needs jars from the other webapp? Wouldn't you get a
> ClassNotFoundException?
You don't need classes etc. If a portlet is used the request
is forwarded to the portlet webapp.
So, currently only looking in the Cocoon war would break
the JSR-168 feature.
If you don't need JSR-168 portlets, you can use a different
portal manager and turn off the support.
However, the best solution would be a deployment functionality
for JSR-168 in Cocoon.
Carsten
RE: Portal - PortletDefinitionRegistryImpl question
Posted by Ralph Goers <Ra...@dslextreme.com>.
At 8/26/2004 10:54 PM, you wrote:
>This is the way, Pluto works, so it just has been "copied" to
>Cocoon. Somehow, the Cocoon portal has to know which JSR-168
>portlets are available and this search mechanism tries
>to look through all mounted webapps and extracts the portlet
>information (if available).
>Now, a nicer solution would be if we have a deployment tool
>where you drop your portlet war file into, the portlets
>are registered and Cocoon does not need to scan all webapps
>
>Carsten
In my patch I have it only scanning the current war file. I don't know of
any way to even get access to other webapps from inside a war. Then again,
I'm not sure why I'd want to get to portlets from some other webapp.
Also, how does that actually work? How does the portlet run if it needs
jars from the other webapp? Wouldn't you get a ClassNotFoundException?
Ralph
RE: Portal - PortletDefinitionRegistryImpl question
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> I posted this last week and just want to make sure I'm not
> doing anything wrong, as I plan to submit a patch as soon as
> I verify that it works correctly (I'm not getting a
> NullPointerException at startup at least).
>
> I am trying to modify the pluto support so that it will work
> in a war file. In looking at PortletDefinitionRegistryImpl I
> see that it is looking at every webapp deployed in this
> server and calling castor to convert the portlet.xml and
> web.xml to objects for every webapp that has a portlet.xml.
> Why would it be doing that? That would seem like a violation
> of security or at least bad manners. Of course, it is also
> impossible to do in an environment where war files are used.
>
This is the way, Pluto works, so it just has been "copied" to
Cocoon. Somehow, the Cocoon portal has to know which JSR-168
portlets are available and this search mechanism tries
to look through all mounted webapps and extracts the portlet
information (if available).
Now, a nicer solution would be if we have a deployment tool
where you drop your portlet war file into, the portlets
are registered and Cocoon does not need to scan all webapps
Carsten