You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Scott T. Weaver" <sc...@binary-designs.net> on 2004/07/20 16:52:09 UTC

[J2] Evaluation of Spring Framework

As much of a Pico fan as I am, I still felt it important that we 
evaluate Spring Framework to see what all the noise was about, the 
Spring guys are getting a helluva lot of good press these days.  We 
initially decided against Spring in our initial framework evaluation 
because, at the time, you had to download all of Spring, including there 
web framework, to use it.  Spring has now separated the framework into 
nice, bite-size pieces, so you only take what you need.

 I spent Friday and Saturday learning Spring Framework and took the 
liberty of trying to get Jetspeed 2 to run on top of Spring.  By the end 
of the day yesterday (Monday) I had Jetspeed 2 running using the Spring 
Framework.  I would like to ask everyone to take a look at the Spring 
Framework documentation and look at the pooled-datasource-support.xml 
and jetspeed-spring.xml in WEB-INF/assembly and get their thoughts on a 
possible move to Spring as our primary light-weight container and to 
possibly deprecate the Pico engine and ComponentManager.

Here are some of the pluses I have found with Spring Framework:

1.  It has great documentation and a relatively small learning curve 
(obviously, because I was able to get J2 running on it 3 days!).
2.  It has a very active community, the user list gets a ton of traffic.
3.  Spring has a very full-featured, well-documented AoP api built right 
into the framework.  We could take advantage of this for security, 
caching, etc.
4.  Spring had a thread local factory implementation built-in with 
examples were as in Pico I had to right a component adapter to perform 
the same logic myself.
5.  As cool as Groovy is, IMOHO, the spring configuration is much more 
readable and far easier to maintain.
6.  Pico has a lot of "moving" dependencies that, from time to time, 
cause us build problems.  Spring is in release 1.0.2 and all its deps 
are also release versions.
7.  Seems more efficient from a start up standpoint.  Spring is about 
2/3 faster if you look at the TestEngine (Pico) at 9~seconds versus the 
TestSpringEngine at 3~ seconds.
8.  Spring has very nice support for adding properties straight into 
your configuration.
9.  Pico requires that you implement the lifecycle interface, 
Startable.  Spring allows you to define init and destroy methods in the 
config.
10. I is very easy to mix constructor based dep injection with property 
dep injection.

By default the build is using the original PicoEngine so as not to 
interfere with anyone's existing apps. 

Enabling SpringEngine:

Go into the web.xml uncomment the init-param that specifies the 
SpringEngine and comment out the one that is using the PicoEngine.  It's 
just that simple ;)

p.s.
I think it would be unfair to us (Jetspeed developers) to give all the 
credit to Spring for the ease of transition.  We all have done a 
tremendous job writing well-designed components that are portable and 
that demonstrate low-coupling along with high re-useability.  This just 
goes to reaffirm that Jetspeed 2 is moving in the right direction in 
terms of design and architecture. Kudos to us all ;)


Regards,

-- 
******************************************
*           Scott T. Weaver              *
*         <we...@apache.org>            *
*     <http://www.einnovation.com>       *
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by Raphaël Luta <ra...@apache.org>.
That's new :)

http://www.almaer.com/blog/archives/000246.html
https://geronimo.apache.org/modules/spring/

and a bunch of mails in spring development mailing lists.

Not sure if the integration is fully operational yet.

Scott T. Weaver wrote:
> I did not know that.  That is very cool!
> 
> Raphaël Luta wrote:
> 
>> David Sean Taylor wrote:
>>
>>> I've also been reviewing Spring, and Im impressed.
>>> I was also very happy to see how well our component design stood up 
>>> to swapping container technologies out.
>>> I would like to throw out a few issues to consider as a team:
>>>
>>> 1. Do we want to try to support 2 or more lightweight container 
>>> frameworks, or keep it simple and support only one?
>>>     Now that the groundwork is in place for swapping containers, I 
>>> think we should also review Apache Geronimo's GBeans
>>>
>>
>> As another plus for Spring, it's supported directly by Geronimo and 
>> thus you can deploy Spring container/components with Geronimo deploy 
>> tools.
>>
>> -- 
>> Raphael Luta - raphael@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
I did not know that.  That is very cool!

Raphaël Luta wrote:

> David Sean Taylor wrote:
>
>> I've also been reviewing Spring, and Im impressed.
>> I was also very happy to see how well our component design stood up 
>> to swapping container technologies out.
>> I would like to throw out a few issues to consider as a team:
>>
>> 1. Do we want to try to support 2 or more lightweight container 
>> frameworks, or keep it simple and support only one?
>>     Now that the groundwork is in place for swapping containers, I 
>> think we should also review Apache Geronimo's GBeans
>>
>
> As another plus for Spring, it's supported directly by Geronimo and 
> thus you can deploy Spring container/components with Geronimo deploy 
> tools.
>
> -- 
> Raphael Luta - raphael@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


-- 
******************************************
*           Scott T. Weaver              *
*         <we...@apache.org>            *
*     <http://www.einnovation.com>       *
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
> I've also been reviewing Spring, and Im impressed.
> I was also very happy to see how well our component design stood up to 
> swapping container technologies out.
> I would like to throw out a few issues to consider as a team:
> 
> 1. Do we want to try to support 2 or more lightweight container 
> frameworks, or keep it simple and support only one?
>     Now that the groundwork is in place for swapping containers, I think 
> we should also review Apache Geronimo's GBeans
> 

As another plus for Spring, it's supported directly by Geronimo and thus 
you can deploy Spring container/components with Geronimo deploy tools.

--
Raphael Luta - raphael@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
David Sean Taylor wrote:

> I've also been reviewing Spring, and Im impressed.
> I was also very happy to see how well our component design stood up to 
> swapping container technologies out.
> I would like to throw out a few issues to consider as a team:
>
> 1. Do we want to try to support 2 or more lightweight container 
> frameworks, or keep it simple and support only one?
>     Now that the groundwork is in place for swapping containers, I 
> think we should also review Apache Geronimo's GBeans

We should settle on one light-weight container as the default, just to 
keep things simple.  I still would like to keep PicoEngine around if 
SpringEngine becomes the chosen path, or vice versa, just as a proof of 
concept.  However, we would have to make it known that the actual 
assembly for the runner-up would not be maintained and if someone did 
decide to go with the runner up, they would be responsible for 
replicating the assembly themselves. 

What would be great is having sub-projects for each "non-official" 
container.  It would be each sub-projects responsibility to keep their 
respective assemblies in line with the primary one.

+1 on GBeans if they as robust as Spring/Pico is in terms of assembly.

>
> 2. Spring supports AoP, where some other containers do not. If we were 
> to go with Spring's AoP for interceptive security,  how would this 
> work in Pico or other containers?

Pico does have support via nanning for the AoP alliance apis as does 
Spring.  If you read the Spring AoP doc, they discuss how you can make 
portable advisors, pointcuts, etc.  The bad thing about Pico and nanning 
is that there is relatively no documentation on how to implement it.

All that being said I agree that if we do decide to use AoP, we keep it 
to minimum and use for what those situations where it makes sense like 
security, caching and possibly some assistance on logging throwables.

>
>     Lets learn and remember from this last lesson, and keep in mind 
> that we may want to swap out Spring for something better in the 
> future, and lets try to keep the couplings to a mimimal
>
> On Jul 20, 2004, at 7:52 AM, Scott T. Weaver wrote:
>
>> As much of a Pico fan as I am, I still felt it important that we 
>> evaluate Spring Framework to see what all the noise was about, the 
>> Spring guys are getting a helluva lot of good press these days.  We 
>> initially decided against Spring in our initial framework evaluation 
>> because, at the time, you had to download all of Spring, including 
>> there web framework, to use it.  Spring has now separated the 
>> framework into nice, bite-size pieces, so you only take what you need.
>>
>> I spent Friday and Saturday learning Spring Framework and took the 
>> liberty of trying to get Jetspeed 2 to run on top of Spring.  By the 
>> end of the day yesterday (Monday) I had Jetspeed 2 running using the 
>> Spring Framework.  I would like to ask everyone to take a look at the 
>> Spring Framework documentation and look at the 
>> pooled-datasource-support.xml and jetspeed-spring.xml in 
>> WEB-INF/assembly and get their thoughts on a possible move to Spring 
>> as our primary light-weight container and to possibly deprecate the 
>> Pico engine and ComponentManager.
>>
>> Here are some of the pluses I have found with Spring Framework:
>>
>> 1.  It has great documentation and a relatively small learning curve 
>> (obviously, because I was able to get J2 running on it 3 days!).
>> 2.  It has a very active community, the user list gets a ton of traffic.
>> 3.  Spring has a very full-featured, well-documented AoP api built 
>> right into the framework.  We could take advantage of this for 
>> security, caching, etc.
>> 4.  Spring had a thread local factory implementation built-in with 
>> examples were as in Pico I had to right a component adapter to 
>> perform the same logic myself.
>> 5.  As cool as Groovy is, IMOHO, the spring configuration is much 
>> more readable and far easier to maintain.
>> 6.  Pico has a lot of "moving" dependencies that, from time to time, 
>> cause us build problems.  Spring is in release 1.0.2 and all its deps 
>> are also release versions.
>> 7.  Seems more efficient from a start up standpoint.  Spring is about 
>> 2/3 faster if you look at the TestEngine (Pico) at 9~seconds versus 
>> the TestSpringEngine at 3~ seconds.
>> 8.  Spring has very nice support for adding properties straight into 
>> your configuration.
>> 9.  Pico requires that you implement the lifecycle interface, 
>> Startable.  Spring allows you to define init and destroy methods in 
>> the config.
>> 10. I is very easy to mix constructor based dep injection with 
>> property dep injection.
>>
>> By default the build is using the original PicoEngine so as not to 
>> interfere with anyone's existing apps.
>> Enabling SpringEngine:
>>
>> Go into the web.xml uncomment the init-param that specifies the 
>> SpringEngine and comment out the one that is using the PicoEngine.  
>> It's just that simple ;)
>>
>> p.s.
>> I think it would be unfair to us (Jetspeed developers) to give all 
>> the credit to Spring for the ease of transition.  We all have done a 
>> tremendous job writing well-designed components that are portable and 
>> that demonstrate low-coupling along with high re-useability.  This 
>> just goes to reaffirm that Jetspeed 2 is moving in the right 
>> direction in terms of design and architecture. Kudos to us all ;)
>>
>>
>> Regards,
>>
>> -- 
>> ******************************************
>> *           Scott T. Weaver              *
>> *         <we...@apache.org>            *
>> *     <http://www.einnovation.com>       *
>> * -------------------------------------- *
>> *   Apache Jetspeed Enterprise Portal    *
>> *     Apache Pluto Portlet Container     *
>> *                                        *
>> * OpenEditPro, Website Content Mangement *
>> *     <http://www.openeditpro.com>       *
>> ******************************************
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>
> -- 
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office]   +01 707 773-4646
> [mobile] +01 707 529 9194
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


-- 
******************************************
*           Scott T. Weaver              *
*         <we...@apache.org>            *
*     <http://www.einnovation.com>       *
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by David Sean Taylor <da...@bluesunrise.com>.
I've also been reviewing Spring, and Im impressed.
I was also very happy to see how well our component design stood up to 
swapping container technologies out.
I would like to throw out a few issues to consider as a team:

1. Do we want to try to support 2 or more lightweight container 
frameworks, or keep it simple and support only one?
     Now that the groundwork is in place for swapping containers, I 
think we should also review Apache Geronimo's GBeans

2. Spring supports AoP, where some other containers do not. If we were 
to go with Spring's AoP for interceptive security,  how would this work 
in Pico or other containers?

     Lets learn and remember from this last lesson, and keep in mind 
that we may want to swap out Spring for something better in the future, 
and lets try to keep the couplings to a mimimal

On Jul 20, 2004, at 7:52 AM, Scott T. Weaver wrote:

> As much of a Pico fan as I am, I still felt it important that we 
> evaluate Spring Framework to see what all the noise was about, the 
> Spring guys are getting a helluva lot of good press these days.  We 
> initially decided against Spring in our initial framework evaluation 
> because, at the time, you had to download all of Spring, including 
> there web framework, to use it.  Spring has now separated the 
> framework into nice, bite-size pieces, so you only take what you need.
>
> I spent Friday and Saturday learning Spring Framework and took the 
> liberty of trying to get Jetspeed 2 to run on top of Spring.  By the 
> end of the day yesterday (Monday) I had Jetspeed 2 running using the 
> Spring Framework.  I would like to ask everyone to take a look at the 
> Spring Framework documentation and look at the 
> pooled-datasource-support.xml and jetspeed-spring.xml in 
> WEB-INF/assembly and get their thoughts on a possible move to Spring 
> as our primary light-weight container and to possibly deprecate the 
> Pico engine and ComponentManager.
>
> Here are some of the pluses I have found with Spring Framework:
>
> 1.  It has great documentation and a relatively small learning curve 
> (obviously, because I was able to get J2 running on it 3 days!).
> 2.  It has a very active community, the user list gets a ton of 
> traffic.
> 3.  Spring has a very full-featured, well-documented AoP api built 
> right into the framework.  We could take advantage of this for 
> security, caching, etc.
> 4.  Spring had a thread local factory implementation built-in with 
> examples were as in Pico I had to right a component adapter to perform 
> the same logic myself.
> 5.  As cool as Groovy is, IMOHO, the spring configuration is much more 
> readable and far easier to maintain.
> 6.  Pico has a lot of "moving" dependencies that, from time to time, 
> cause us build problems.  Spring is in release 1.0.2 and all its deps 
> are also release versions.
> 7.  Seems more efficient from a start up standpoint.  Spring is about 
> 2/3 faster if you look at the TestEngine (Pico) at 9~seconds versus 
> the TestSpringEngine at 3~ seconds.
> 8.  Spring has very nice support for adding properties straight into 
> your configuration.
> 9.  Pico requires that you implement the lifecycle interface, 
> Startable.  Spring allows you to define init and destroy methods in 
> the config.
> 10. I is very easy to mix constructor based dep injection with 
> property dep injection.
>
> By default the build is using the original PicoEngine so as not to 
> interfere with anyone's existing apps.
> Enabling SpringEngine:
>
> Go into the web.xml uncomment the init-param that specifies the 
> SpringEngine and comment out the one that is using the PicoEngine.  
> It's just that simple ;)
>
> p.s.
> I think it would be unfair to us (Jetspeed developers) to give all the 
> credit to Spring for the ease of transition.  We all have done a 
> tremendous job writing well-designed components that are portable and 
> that demonstrate low-coupling along with high re-useability.  This 
> just goes to reaffirm that Jetspeed 2 is moving in the right direction 
> in terms of design and architecture. Kudos to us all ;)
>
>
> Regards,
>
> -- 
> ******************************************
> *           Scott T. Weaver              *
> *         <we...@apache.org>            *
> *     <http://www.einnovation.com>       *
> * -------------------------------------- *
> *   Apache Jetspeed Enterprise Portal    *
> *     Apache Pluto Portlet Container     *
> *                                        *
> * OpenEditPro, Website Content Mangement *
> *     <http://www.openeditpro.com>       *
> ******************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>

--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office]   +01 707 773-4646
[mobile] +01 707 529 9194



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by Christophe Lombart <ch...@sword-technologies.com>.
Same idea for the Persistence store. What about Hibernate instead of OJB ?
Who already test that ? I'm just wondering because I'm expecting some 
differencies specially with the query methods.


Christophe



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
It's fixed now.  I forgot to set PreferencesProvider's init-method in 
the jetspeed-spring.xml.  The start() method simply calls 
PreferencesImpl.class, which causes the ClassLoader to pre-load the class.

Ate Douma wrote:

> Great job Scott and David!
>
> As we are using Spring within our own portlets you can guess I'm +1 on 
> using Spring!
>
> But, I'm having problems running J2 again after initial deployment 
> using Spring. If I stop Tomcat and start again I'm presented with the 
> following stack trace (in jetspeed.log):
>
> 2004-07-20 18:44:57,171 [WORKER_5] DEBUG 
> org.apache.jetspeed.container.JetspeedContainerServlet - Rendering: 
> Portlet Class = org.apache.jetspeed.demo.simple.PickANumberServlet
> 2004-07-20 18:44:57,187 [WORKER_5] ERROR 
> org.apache.jetspeed.container.JetspeedContainerServlet - Error 
> rendering portlet "PickANumberPortlet": java.lang.InternalError: Can't 
> instantiate Preferences factory java.lang.ClassNotFoundException: 
> org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl
> java.lang.InternalError: Can't instantiate Preferences factory 
> java.lang.ClassNotFoundException: 
> org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl
>     at java.util.prefs.Preferences.<clinit>(Preferences.java:218)
>     at 
> org.apache.jetspeed.components.portletentity.PortletEntityImpl.getPreferenceSet(PortletEntityImpl.java:153) 
>
>     at 
> org.apache.pluto.core.impl.PortletPreferencesImpl.<init>(PortletPreferencesImpl.java:72) 
>
>     at 
> org.apache.pluto.factory.impl.PortletPreferencesFactoryImpl.getPortletPreferences(PortletPreferencesFactoryImpl.java:39) 
>
>     at 
> org.apache.pluto.factory.PortletObjectAccess.getPortletPreferences(PortletObjectAccess.java:116) 
>
>     at 
> org.apache.pluto.core.impl.RenderRequestImpl.getPreferences(RenderRequestImpl.java:74) 
>
>     at 
> org.apache.jetspeed.demo.simple.PickANumberServlet.getHighRange(PickANumberServlet.java:247) 
>
>     at 
> org.apache.jetspeed.demo.simple.PickANumberServlet.doView(PickANumberServlet.java:137) 
>
>     at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>     at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>     at 
> org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:214) 
>
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:498) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:208) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:122) 
>
>     at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103) 
>
>     at 
> org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88) 
>
>     at 
> org.apache.jetspeed.aggregator.impl.RenderingJob.run(RenderingJob.java:109) 
>
>     at org.apache.jetspeed.aggregator.impl.Worker.run(Worker.java:142)
>
> Followed by the following exception:
>
> 2004-07-20 18:45:00,093 [http8080-Processor3] DEBUG 
> org.apache.jetspeed.container.JetspeedContainerServlet - Rendering: 
> Portlet Class = org.apache.jetspeed.portlets.layout.MultiColumnPortlet
> 2004-07-20 18:45:00,093 [http8080-Processor3] ERROR 
> org.apache.jetspeed.container.JetspeedContainerServlet - Error 
> rendering portlet "VelocityTwoColumns": java.lang.NoClassDefFoundError
> java.lang.NoClassDefFoundError
>     at 
> org.apache.jetspeed.components.portletentity.PortletEntityImpl.getPreferenceSet(PortletEntityImpl.java:153) 
>
>     at 
> org.apache.pluto.core.impl.PortletPreferencesImpl.<init>(PortletPreferencesImpl.java:72) 
>
>     at 
> org.apache.pluto.factory.impl.PortletPreferencesFactoryImpl.getPortletPreferences(PortletPreferencesFactoryImpl.java:39) 
>
>     at 
> org.apache.pluto.factory.PortletObjectAccess.getPortletPreferences(PortletObjectAccess.java:116) 
>
>     at 
> org.apache.pluto.core.impl.RenderRequestImpl.getPreferences(RenderRequestImpl.java:74) 
>
>     at 
> org.apache.jetspeed.portlets.layout.LayoutPortlet.doView(LayoutPortlet.java:72) 
>
>     at 
> org.apache.jetspeed.portlets.layout.MultiColumnPortlet.doView(MultiColumnPortlet.java:82) 
>
>     at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>     at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>     at 
> org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:214) 
>
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:498) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:208) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:122) 
>
>     at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103) 
>
>     at 
> org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88) 
>
>     at 
> org.apache.jetspeed.aggregator.impl.PortletRendererImpl.renderNow(PortletRendererImpl.java:95) 
>
>     at 
> org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.build(PageAggregatorImpl.java:222) 
>
>     at 
> org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:47) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:107) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:76) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.profiler.impl.ProfilerValveImpl.invoke(ProfilerValveImpl.java:57) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.security.impl.SecurityValveImpl.invoke(SecurityValveImpl.java:89) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.capabilities.impl.CapabilityValveImpl.invoke(CapabilityValveImpl.java:138) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.localization.impl.LocalizationValveImpl.invoke(LocalizationValveImpl.java:64) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:237) 
>
>     at 
> org.apache.jetspeed.engine.AbstractEngine.service(AbstractEngine.java:279) 
>
>     at 
> org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:214) 
>
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) 
>
>     at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) 
>
>     at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:492) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422) 
>
>     at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>
>     at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:199)
>     at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828) 
>
>     at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:700) 
>
>     at 
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:584) 
>
>     at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) 
>
>     at java.lang.Thread.run(Thread.java:534)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


-- 
******************************************
*           Scott T. Weaver              *
*         <we...@apache.org>            *
*     <http://www.einnovation.com>       *
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jul 20, 2004, at 9:50 AM, Ate Douma wrote:

> Great job Scott and David!
>

Spring integration was all Scott's hard work
My job was to shout at him, tell him he's crazy, and occasionally smash 
my keyboard ;-)

--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office]   +01 707 773-4646
[mobile] +01 707 529 9194



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
I am also.  Give me a minute and I'll get it straightend out.

Ate Douma wrote:

> Great job Scott and David!
>
> As we are using Spring within our own portlets you can guess I'm +1 on 
> using Spring!
>
> But, I'm having problems running J2 again after initial deployment 
> using Spring. If I stop Tomcat and start again I'm presented with the 
> following stack trace (in jetspeed.log):
>
> 2004-07-20 18:44:57,171 [WORKER_5] DEBUG 
> org.apache.jetspeed.container.JetspeedContainerServlet - Rendering: 
> Portlet Class = org.apache.jetspeed.demo.simple.PickANumberServlet
> 2004-07-20 18:44:57,187 [WORKER_5] ERROR 
> org.apache.jetspeed.container.JetspeedContainerServlet - Error 
> rendering portlet "PickANumberPortlet": java.lang.InternalError: Can't 
> instantiate Preferences factory java.lang.ClassNotFoundException: 
> org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl
> java.lang.InternalError: Can't instantiate Preferences factory 
> java.lang.ClassNotFoundException: 
> org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl
>     at java.util.prefs.Preferences.<clinit>(Preferences.java:218)
>     at 
> org.apache.jetspeed.components.portletentity.PortletEntityImpl.getPreferenceSet(PortletEntityImpl.java:153) 
>
>     at 
> org.apache.pluto.core.impl.PortletPreferencesImpl.<init>(PortletPreferencesImpl.java:72) 
>
>     at 
> org.apache.pluto.factory.impl.PortletPreferencesFactoryImpl.getPortletPreferences(PortletPreferencesFactoryImpl.java:39) 
>
>     at 
> org.apache.pluto.factory.PortletObjectAccess.getPortletPreferences(PortletObjectAccess.java:116) 
>
>     at 
> org.apache.pluto.core.impl.RenderRequestImpl.getPreferences(RenderRequestImpl.java:74) 
>
>     at 
> org.apache.jetspeed.demo.simple.PickANumberServlet.getHighRange(PickANumberServlet.java:247) 
>
>     at 
> org.apache.jetspeed.demo.simple.PickANumberServlet.doView(PickANumberServlet.java:137) 
>
>     at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>     at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>     at 
> org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:214) 
>
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:498) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:208) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:122) 
>
>     at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103) 
>
>     at 
> org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88) 
>
>     at 
> org.apache.jetspeed.aggregator.impl.RenderingJob.run(RenderingJob.java:109) 
>
>     at org.apache.jetspeed.aggregator.impl.Worker.run(Worker.java:142)
>
> Followed by the following exception:
>
> 2004-07-20 18:45:00,093 [http8080-Processor3] DEBUG 
> org.apache.jetspeed.container.JetspeedContainerServlet - Rendering: 
> Portlet Class = org.apache.jetspeed.portlets.layout.MultiColumnPortlet
> 2004-07-20 18:45:00,093 [http8080-Processor3] ERROR 
> org.apache.jetspeed.container.JetspeedContainerServlet - Error 
> rendering portlet "VelocityTwoColumns": java.lang.NoClassDefFoundError
> java.lang.NoClassDefFoundError
>     at 
> org.apache.jetspeed.components.portletentity.PortletEntityImpl.getPreferenceSet(PortletEntityImpl.java:153) 
>
>     at 
> org.apache.pluto.core.impl.PortletPreferencesImpl.<init>(PortletPreferencesImpl.java:72) 
>
>     at 
> org.apache.pluto.factory.impl.PortletPreferencesFactoryImpl.getPortletPreferences(PortletPreferencesFactoryImpl.java:39) 
>
>     at 
> org.apache.pluto.factory.PortletObjectAccess.getPortletPreferences(PortletObjectAccess.java:116) 
>
>     at 
> org.apache.pluto.core.impl.RenderRequestImpl.getPreferences(RenderRequestImpl.java:74) 
>
>     at 
> org.apache.jetspeed.portlets.layout.LayoutPortlet.doView(LayoutPortlet.java:72) 
>
>     at 
> org.apache.jetspeed.portlets.layout.MultiColumnPortlet.doView(MultiColumnPortlet.java:82) 
>
>     at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>     at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>     at 
> org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:214) 
>
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575) 
>
>     at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:498) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:208) 
>
>     at 
> org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:122) 
>
>     at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103) 
>
>     at 
> org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88) 
>
>     at 
> org.apache.jetspeed.aggregator.impl.PortletRendererImpl.renderNow(PortletRendererImpl.java:95) 
>
>     at 
> org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.build(PageAggregatorImpl.java:222) 
>
>     at 
> org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:47) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:107) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:76) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.profiler.impl.ProfilerValveImpl.invoke(ProfilerValveImpl.java:57) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.security.impl.SecurityValveImpl.invoke(SecurityValveImpl.java:89) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.capabilities.impl.CapabilityValveImpl.invoke(CapabilityValveImpl.java:138) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.localization.impl.LocalizationValveImpl.invoke(LocalizationValveImpl.java:64) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255) 
>
>     at 
> org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:237) 
>
>     at 
> org.apache.jetspeed.engine.AbstractEngine.service(AbstractEngine.java:279) 
>
>     at 
> org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:214) 
>
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) 
>
>     at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) 
>
>     at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:492) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422) 
>
>     at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>
>     at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) 
>
>     at 
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 
>
>     at 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 
>
>     at 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at 
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:199)
>     at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828) 
>
>     at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:700) 
>
>     at 
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:584) 
>
>     at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) 
>
>     at java.lang.Thread.run(Thread.java:534)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


-- 
******************************************
*           Scott T. Weaver              *
*         <we...@apache.org>            *
*     <http://www.einnovation.com>       *
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: [J2] Evaluation of Spring Framework

Posted by Ate Douma <at...@douma.nu>.
Great job Scott and David!

As we are using Spring within our own portlets you can guess I'm +1 on using Spring!

But, I'm having problems running J2 again after initial deployment using Spring. 
If I stop Tomcat and start again I'm presented with the following stack trace 
(in jetspeed.log):

2004-07-20 18:44:57,171 [WORKER_5] DEBUG 
org.apache.jetspeed.container.JetspeedContainerServlet - Rendering: Portlet 
Class = org.apache.jetspeed.demo.simple.PickANumberServlet
2004-07-20 18:44:57,187 [WORKER_5] ERROR 
org.apache.jetspeed.container.JetspeedContainerServlet - Error rendering portlet 
"PickANumberPortlet": java.lang.InternalError: Can't instantiate Preferences 
factory java.lang.ClassNotFoundException: 
org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl
java.lang.InternalError: Can't instantiate Preferences factory 
java.lang.ClassNotFoundException: 
org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl
	at java.util.prefs.Preferences.<clinit>(Preferences.java:218)
	at 
org.apache.jetspeed.components.portletentity.PortletEntityImpl.getPreferenceSet(PortletEntityImpl.java:153)
	at 
org.apache.pluto.core.impl.PortletPreferencesImpl.<init>(PortletPreferencesImpl.java:72)
	at 
org.apache.pluto.factory.impl.PortletPreferencesFactoryImpl.getPortletPreferences(PortletPreferencesFactoryImpl.java:39)
	at 
org.apache.pluto.factory.PortletObjectAccess.getPortletPreferences(PortletObjectAccess.java:116)
	at 
org.apache.pluto.core.impl.RenderRequestImpl.getPreferences(RenderRequestImpl.java:74)
	at 
org.apache.jetspeed.demo.simple.PickANumberServlet.getHighRange(PickANumberServlet.java:247)
	at 
org.apache.jetspeed.demo.simple.PickANumberServlet.doView(PickANumberServlet.java:137)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
	at 
org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:214)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
	at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575)
	at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:498)
	at 
org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:208)
	at 
org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:122)
	at 
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103)
	at 
org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88)
	at org.apache.jetspeed.aggregator.impl.RenderingJob.run(RenderingJob.java:109)
	at org.apache.jetspeed.aggregator.impl.Worker.run(Worker.java:142)

Followed by the following exception:

2004-07-20 18:45:00,093 [http8080-Processor3] DEBUG 
org.apache.jetspeed.container.JetspeedContainerServlet - Rendering: Portlet 
Class = org.apache.jetspeed.portlets.layout.MultiColumnPortlet
2004-07-20 18:45:00,093 [http8080-Processor3] ERROR 
org.apache.jetspeed.container.JetspeedContainerServlet - Error rendering portlet 
"VelocityTwoColumns": java.lang.NoClassDefFoundError
java.lang.NoClassDefFoundError
	at 
org.apache.jetspeed.components.portletentity.PortletEntityImpl.getPreferenceSet(PortletEntityImpl.java:153)
	at 
org.apache.pluto.core.impl.PortletPreferencesImpl.<init>(PortletPreferencesImpl.java:72)
	at 
org.apache.pluto.factory.impl.PortletPreferencesFactoryImpl.getPortletPreferences(PortletPreferencesFactoryImpl.java:39)
	at 
org.apache.pluto.factory.PortletObjectAccess.getPortletPreferences(PortletObjectAccess.java:116)
	at 
org.apache.pluto.core.impl.RenderRequestImpl.getPreferences(RenderRequestImpl.java:74)
	at org.apache.jetspeed.portlets.layout.LayoutPortlet.doView(LayoutPortlet.java:72)
	at 
org.apache.jetspeed.portlets.layout.MultiColumnPortlet.doView(MultiColumnPortlet.java:82)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
	at 
org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:214)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
	at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575)
	at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:498)
	at 
org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:208)
	at 
org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:122)
	at 
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103)
	at 
org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88)
	at 
org.apache.jetspeed.aggregator.impl.PortletRendererImpl.renderNow(PortletRendererImpl.java:95)
	at 
org.apache.jetspeed.aggregator.impl.PageAggregatorImpl.build(PageAggregatorImpl.java:222)
	at org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:47)
	at 
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255)
	at 
org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:107)
	at 
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255)
	at org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:76)
	at 
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255)
	at 
org.apache.jetspeed.profiler.impl.ProfilerValveImpl.invoke(ProfilerValveImpl.java:57)
	at 
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255)
	at 
org.apache.jetspeed.security.impl.SecurityValveImpl.invoke(SecurityValveImpl.java:89)
	at 
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255)
	at 
org.apache.jetspeed.capabilities.impl.CapabilityValveImpl.invoke(CapabilityValveImpl.java:138)
	at 
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255)
	at 
org.apache.jetspeed.localization.impl.LocalizationValveImpl.invoke(LocalizationValveImpl.java:64)
	at 
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:255)
	at org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:237)
	at org.apache.jetspeed.engine.AbstractEngine.service(AbstractEngine.java:279)
	at org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:214)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
	at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
	at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:492)
	at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
	at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
	at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163)
	at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
	at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:199)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
	at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:700)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:584)
	at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:534)


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org