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 David Sean Taylor <da...@bluesunrise.com> on 2006/02/01 00:49:13 UTC

Re: extending jetspeed with new services

Joachim Müller wrote:
> Hi all.
> 
> I want to extend the jetspeed portal with new spring configured
> services, similar the JetspeedPortletServices.
> 
> Using a portal.genapp.miminal codebase and several portal applications
> that deploy into this portal container:
> 
> How can I define new services that are known to the portal applications
> via the standard way of accessing the services
> 
> service = (MyService)context.getAttribute(<name of service component>);
> 
> without changing the jetspeed codebase (i.e. jetspeed-api)? Is there a
> easy way that the developers already have had in mind?
> 
> (Defining the services in the portal container is not the problem, but
> how can I access them in the portal applications?)

Is there a reason why you cannot put the service in the portal's 
WEB-INF/lib directory and then make it avalialbe to ALL portlet 
applications as a jetspeed service?

What I usually do is structure my custom build like this:

/custom-project
     /applications
         /custom-app1
         /custom-app2
    /services
        /custom-service-1


custom-service-1.jar is built and dropped into the portal's WEB-INF/lib 
directory.

If a service is specific to one application, arguably it should not be a 
  jetspeed service. Many portlet apps have their own Spring version 
built into the webapp (like Spring MVC portlet apps for instance). So 
you can manage your own Spring components inside your app.



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