You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Werner Punz <we...@gmx.at> on 2002/08/05 18:31:21 UTC

Action class loading

Hi:

I played around about 10 hours with the Hello World Velocity Portlet 
Action example and tried to move it into a custom package. And all I got 
was a Turbine exception that the class could not be found. After 
searching the mail archive I found out that numerous others had the same 
  problem, and there was no solution to be found in the list. I finally 
solved it and just wanted to leave a message on how to overcome this 
problem:

a) First problem, if you want to unpack the Jetspeed jars and use the 
unpacked classes, remove you war file after the installation so that the 
proper jars and directories are used.

b) There seems to be a weird mapping of the action classes. You have to 
do following steps:

add your own proprietary module root package into the 
TurbineResources.properties file:

module.packages=com.labor.jsportalappsfe.modules

for instance would be my own package

And now there is a weird behavior, I´m not sure this is a bug or not:

If you make your own portlet entry in the reg file and you use an action 
portlet following happens:

The parameter:
  <parameter name="action" value="portlets.HelloAct" hidden="false"/>

is mapped into actions.portlets.HelloAct

That basically means action is mapped into the subpackage actions 
(notice the s!!!!)


so basically the full path for this module is:
com.labor.jsportalappsfe.modules.actions.portlets.HelloAct

Turbine/Jetspeed however has the first part of the path predefined in 
its properties file and will look there for subpackages.

That basically sums it up, and I think that was the cause of the problem 
for me and for the other people with similar action mapping problems. I 
hope this helps


Werner

Labor_C





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


developing using jetspeed Was: Action class loading

Posted by Jan Grant <Ja...@bristol.ac.uk>.
On Mon, 5 Aug 2002, Werner Punz wrote:

> Hi:
>
> I played around about 10 hours with the Hello World Velocity Portlet
> Action example and tried to move it into a custom package. And all I got
> was a Turbine exception that the class could not be found. After
> searching the mail archive I found out that numerous others had the same
>   problem, and there was no solution to be found in the list. I finally
> solved it and just wanted to leave a message on how to overcome this
> problem:

I've noticed that lots of people seem to be doing development on top of
jetspeed, using a variety of methods. We've had some success using a
"brain-dead" mechanism that doesn't require particularly clever tricks,
but leaves our developers (spread around the country) with a consistent
build environment:

- we deploy _on top of_ a stock, unrolled jetspeed.war

- we write code into a bunch of source directories: src/core/ for core
  stuff, src/portlets/xxx/java, src/portlets/xxx/velocity and
  src/portlets/xxx/configuration for per-portlet jetspeed-specific stuff

- we manage dependency fetching, deployment, build, testing through a
  bunch of ant scripts that patch "hooks" for our stuff into a stock jetspeed.

What we're left with is a simple, logically partitioned structure for
writing code that doesn't require vendor imports of jetspeed, which is
useful, because most of our developers are CVS newbies.

If this sounds like it might be of any use I can tidy up the appropriate
Ant files and post them*; I've no idea if there's any "best practice"
for this sort of thing but many of the starting hurdles with JS development
have pretty straightforward answers, if you know where to look.

My time's a little limited so drop me a note if you're interested - I
won't bother to spend the time nuless there's a call for this kind of
thing.

jan

* they've grown somewhat organically, and they represent an ugly
bunch of hacks to get ant to do stuff it doesn't really want to, but
they work as a "black box" for the most part.

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
"My army boots contain everything not in them." - Russell's pair o' Docs.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>