portal question - custom classloaders

[Filip Defoort <fi...@cirquedigital.com>]

Hi,

I'm working with the cocoon portal, and I'm starting cocoon via a custom 
classloader
( <classloader class="..." /> in cocoon.xconf ) to make a number of 
dynamically
assembled classes and a back-end service available to cocoon. So far so 
good,
all works. My app starts; cocoon starts after that, and the portal works.

The problem I have is that I need to make my portlets (JSR-168 based; 
implementation
in classes loaded by my custom classloader) available to the cocoon portal.

I've put them in cocoon/WEB-INF/portlet.xml, but nothing happens. It 
seems that
I also need to put them as separate servlets in cocoon/WEB-INF/web.xml, 
but if
I do that, they're using the regular classloader, which doesn't have the 
implementation
and I'm getting NPE's (and looking at the sources, it's on the class 
resolution).

I've tried to have the classloader that starts the cocoon webapp be 
swapped out
by my custom classloader, but that seems to create all kinds of 
conflicts when starting
cocoon.

Anybody any ideas on how to accomplish this ?

Many thanks in advance,
- Filip


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: portal question - custom classloaders

[Filip Defoort <fi...@cirquedigital.com>]

Hi Carsten,

Carsten Ziegeler wrote:
> Filip Defoort wrote:
>   
>>     
> I guess it's not easy to do :) Now, putting your jsr-168 based portals
> into the cocoon webapp is a proprietary way and not standard conform.
> Usually, you should put your portlets into an own webapp (which has an
> own classloader). So perhaps this might help you.
>   
Yes, that's what I've done so far. I'm just trying to access the login 
information
from inside of my portlets so I can look up the access rights and so on..
> In the case, that you need/want to run those portlets in the cocoon
> webapp, you could try to create a wrapper for the portlet servlets. The
> Cocoon portal uses Pluto and Pluto requires a servlet for the deployed
> portlets; so you could write a wrapper for this servlet which gets the
> classloader from Cocoon and uses this classloader. You could share the
> classloader between the portlets by putting it into the servlet context.
> I'm not sure if this really works, but it sounds doable.
>   
I'll give this a try - will let you know if it works...

Thanks a lot for the hint,
- Filip
> HTH
> Carsten
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: portal question - custom classloaders

[Carsten Ziegeler <cz...@apache.org>]

Filip Defoort wrote:
> Hi,
> 
> I'm working with the cocoon portal, and I'm starting cocoon via a custom 
> classloader
> ( <classloader class="..." /> in cocoon.xconf ) to make a number of 
> dynamically
> assembled classes and a back-end service available to cocoon. So far so 
> good,
> all works. My app starts; cocoon starts after that, and the portal works.
> 
> The problem I have is that I need to make my portlets (JSR-168 based; 
> implementation
> in classes loaded by my custom classloader) available to the cocoon portal.
> 
> I've put them in cocoon/WEB-INF/portlet.xml, but nothing happens. It 
> seems that
> I also need to put them as separate servlets in cocoon/WEB-INF/web.xml, 
> but if
> I do that, they're using the regular classloader, which doesn't have the 
> implementation
> and I'm getting NPE's (and looking at the sources, it's on the class 
> resolution).
> 
> I've tried to have the classloader that starts the cocoon webapp be 
> swapped out
> by my custom classloader, but that seems to create all kinds of 
> conflicts when starting
> cocoon.
> 
> Anybody any ideas on how to accomplish this ?
> 
I guess it's not easy to do :) Now, putting your jsr-168 based portals
into the cocoon webapp is a proprietary way and not standard conform.
Usually, you should put your portlets into an own webapp (which has an
own classloader). So perhaps this might help you.

In the case, that you need/want to run those portlets in the cocoon
webapp, you could try to create a wrapper for the portlet servlets. The
Cocoon portal uses Pluto and Pluto requires a servlet for the deployed
portlets; so you could write a wrapper for this servlet which gets the
classloader from Cocoon and uses this classloader. You could share the
classloader between the portlets by putting it into the servlet context.
I'm not sure if this really works, but it sounds doable.

HTH
Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org