Marcel Dullaart wrote:
Hi,
I ran into the same problem, same setup, JBoss 4.0.1 either with or without sp1, both show the same error as you experienced. To work around it for the time being, you can disable the call to $jetspeed.getTitle($myPE, $myF) in jetspeed/WEB-ING/decorations/portlet/html/tigris/decorator.vm
This prevents a title being displayed though.
This *might* (should) be solved with the refactoring_branch because one of its biggest changes is the way a PA classloader is determined and used.
I can't say anything about the chance of getting it running on JBoss though as I haven't tried it (nor with the HEAD branch for that matter).
It would be great if you have some time to try it out!
Ate
Marcel
On Tue, 8 Mar 2005 10:16:30 -0500, Doug Schnelzer <[EMAIL PROTECTED]> wrote:
I'm getting the following error running the latest Jetspeed2 from CVS under JBoss 4.0.1sp1 in the second and subsequent portlets in the portal. The first portlet and the portal display fine.
The error int the portlet window is: VelocityViewServlet : Error processing the template Invocation of method 'getTitle' in class org.apache.jetspeed.velocity.JetspeedPowerTool threw exception class java.lang.IllegalStateException : No classloader has been defined for portlet application 2 java.lang.IllegalStateException: No classloader has been defined for portlet application 2
Do you think this issue is related to this thread and the refactoring that Ate is doing? If so, any recommendations on a workaround in JBoss or do I just need to sit tight and wait till JS2-210 is committed?
Thanks for the help, - Doug
On Tue, 01 Mar 2005 14:29:30 -0800, David Sean Taylor <[EMAIL PROTECTED]> wrote:
Peter Meier wrote:
I noticed that the classloader that is stored in PortletDefinition under portletClassLoader is *not* the classloader that is actually used (or has been used) to load the portlet class itself. Instead, there is a classloader stored that has been taken from a map that has been previously created. Although in this case the URL classloader is pointing to the right class path, it could cause ClassCastExceptions if it used to create classes instead of the classloader from the portlet class.
My question is what was the initial intention of having a classloader map, when it is not used for portlet class loading itself? Is there any objection if the code in JetspeedPortletFactory is altered thus that it *always* stores the actual classloader of the portlet in portletClassLoader of Portletdefinition as the name suggests?
Ate's upcoming commit will fix that
http://issues.apache.org/jira/browse/JS2-210
By doing the latter, I also avoid classloader issues in JBoss.
Regards, Peter
Architect, TEC Wellington, New Zealand email: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
