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 Joachim Müller <jo...@wemove.com> on 2006/01/31 13:01:14 UTC
extending jetspeed with new services
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?)
Thanks for any reply.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: extending jetspeed with new services
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
Re: extending jetspeed with new services
Posted by Aaron Evans <aa...@yahoo.ca>.
Joachim Müller <joachim <at> wemove.com> writes:
>
> Hi Frank,
>
> Thanks for your reply. This sounds quite complicated to me. There must
> be an easier way. The Jetspeed Admin application uses quite some
> PortalServices. I suspect that the following steps will be required
> (please comment):
>
> 1.) Define the API of the service in a separate project and put it into
> maven repo (for compiplation) and the tomcat/shared/lib (similar to the
> jetspeed-api). Thus I can refernce the Service in every application this
> api will be included.
>
> 2.) Define my service in the portlat.genapp portal container using the
> 'normal' spring config approach.
>
> Question:
>
> How can I add a component to the PortalServices (normally defined in
> jetspeed-services.xml) without copy and modify the jetspeed-services.xml
> from the jetspeed distribution.
>
> 3.) Define the service in the jetspeed-portlet.xml of the application.
>
> 4.) Reference the service like this:
>
> service = (MyService)context.getAttribute(<name of service component>);
>
> Do I have any errors in reasoning?
>
> Thanks for any comment.
>
> Joachim
As Frank points out, I think the main challenge is with the class loader.
Normally, if you instantiate an object within a servlet/portlet application,
it is not available to other servlet/portlet applications because they use
different class loaders.
What Frank is suggesting is to use a facility provided in tomcat where you can
configure objects that are instantiated and can be used globally, accross
applications.
I agree that this seems a little too complicated. I have not looked into it
too much, but somehow the j2-admin application is using services that are
configured within the main jetspeed application, so I would take a look at
the source in that application to figure out how they have done it.
I have been thinking about this problem myself lately as I would like to be
able to get a handle to the jetpseed User Management components from within
my custom portlet application. So if you find the solution, please post.
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: extending jetspeed with new services
Posted by David Sean Taylor <da...@bluesunrise.com>.
Joachim Müller wrote:
> Hi Frank,
>
> Thanks for your reply. This sounds quite complicated to me. There must
> be an easier way. The Jetspeed Admin application uses quite some
> PortalServices. I suspect that the following steps will be required
> (please comment):
>
> 1.) Define the API of the service in a separate project and put it into
> maven repo (for compiplation) and the tomcat/shared/lib (similar to the
> jetspeed-api). Thus I can refernce the Service in every application this
> api will be included.
yes, i thing this is a valid approach
if the service is generic enough, send us a patch and we will add it to
the jetspeed codebase
>
> 2.) Define my service in the portlat.genapp portal container using the
> 'normal' spring config approach.
>
> Question:
>
> How can I add a component to the PortalServices (normally defined in
> jetspeed-services.xml) without copy and modify the jetspeed-services.xml
> from the jetspeed distribution.
you can define your service in another xml file
unfortunately you're going to have to modify the map entry
>
>
> 3.) Define the service in the jetspeed-portlet.xml of the application.
>
> 4.) Reference the service like this:
>
> service = (MyService)context.getAttribute(<name of service component>);
>
There are examples of doing this in the j2-admin app
>
>
> Do I have any errors in reasoning?
>
> Thanks for any comment.
>
> Joachim
>
>
> Frank Villarreal wrote:
>
>>Hi Joachim,
>>
>>I'm not sure about J2-Final, but in the previous releases, the only way I
>>was able to accomplish this was by creating a Tomcat-specific-Resource (see
>>the Tomcat docs on how to do this) ... which consisted of a class that
>>"looked up" my Spring application context. I in turn created a Jetspeed
>>service (that referenced the resource) normally and made the appropriate
>>entries in the J2 assembly files. A major problem I ran into was where to
>>place my spring-application files ... due to class loader issues (Tomcat
>>5.30), I had to place my jars in {TOMCAT_HOME}/common/lib instead of the
>>"recommended" location of "shared/lib" ... which did not work as advertised.
>>This was the only way I could share a spring-context across all of my
>>portlet applications. I'm hoping to devise a better solution with a newer
>>version of Tomcat and J2-Final.
>>
>>- Frank
>>
>>
>>>-----Original Message-----
>>>From: Joachim Müller [mailto:joachim@wemove.com]
>>>Sent: Tuesday, January 31, 2006 06:01 AM
>>>To: Jetspeed Users List
>>>Subject: extending jetspeed with new services
>>>
>>>
>>>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?)
>>>
>>>
>>>Thanks for any reply.
>>>
>>>
>>>Joachim
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>For additional commands, e-mail: jetspeed-user-help@portals.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-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: extending jetspeed with new services
Posted by Joachim Müller <jo...@wemove.com>.
Hi Frank,
Thanks for your reply. This sounds quite complicated to me. There must
be an easier way. The Jetspeed Admin application uses quite some
PortalServices. I suspect that the following steps will be required
(please comment):
1.) Define the API of the service in a separate project and put it into
maven repo (for compiplation) and the tomcat/shared/lib (similar to the
jetspeed-api). Thus I can refernce the Service in every application this
api will be included.
2.) Define my service in the portlat.genapp portal container using the
'normal' spring config approach.
Question:
How can I add a component to the PortalServices (normally defined in
jetspeed-services.xml) without copy and modify the jetspeed-services.xml
from the jetspeed distribution.
3.) Define the service in the jetspeed-portlet.xml of the application.
4.) Reference the service like this:
service = (MyService)context.getAttribute(<name of service component>);
Do I have any errors in reasoning?
Thanks for any comment.
Joachim
Frank Villarreal wrote:
> Hi Joachim,
>
> I'm not sure about J2-Final, but in the previous releases, the only way I
> was able to accomplish this was by creating a Tomcat-specific-Resource (see
> the Tomcat docs on how to do this) ... which consisted of a class that
> "looked up" my Spring application context. I in turn created a Jetspeed
> service (that referenced the resource) normally and made the appropriate
> entries in the J2 assembly files. A major problem I ran into was where to
> place my spring-application files ... due to class loader issues (Tomcat
> 5.30), I had to place my jars in {TOMCAT_HOME}/common/lib instead of the
> "recommended" location of "shared/lib" ... which did not work as advertised.
> This was the only way I could share a spring-context across all of my
> portlet applications. I'm hoping to devise a better solution with a newer
> version of Tomcat and J2-Final.
>
> - Frank
>
>> -----Original Message-----
>> From: Joachim Müller [mailto:joachim@wemove.com]
>> Sent: Tuesday, January 31, 2006 06:01 AM
>> To: Jetspeed Users List
>> Subject: extending jetspeed with new services
>>
>>
>> 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?)
>>
>>
>> Thanks for any reply.
>>
>>
>> Joachim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
--
. frankfurt am main, 1°c, die gefühlte temperatur
liegt bei -3°c. zur zeit durchbrochene bewölkung in
366 m. die sichtweite reicht 8.0 km.
< joachim müller
joachim@wemove.com
t +49 69 759003 11
wemove digital solutions GmbH
www.wemove.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: extending jetspeed with new services
Posted by Frank Villarreal <f_...@tetco.com>.
Hi Joachim,
I'm not sure about J2-Final, but in the previous releases, the only way I
was able to accomplish this was by creating a Tomcat-specific-Resource (see
the Tomcat docs on how to do this) ... which consisted of a class that
"looked up" my Spring application context. I in turn created a Jetspeed
service (that referenced the resource) normally and made the appropriate
entries in the J2 assembly files. A major problem I ran into was where to
place my spring-application files ... due to class loader issues (Tomcat
5.30), I had to place my jars in {TOMCAT_HOME}/common/lib instead of the
"recommended" location of "shared/lib" ... which did not work as advertised.
This was the only way I could share a spring-context across all of my
portlet applications. I'm hoping to devise a better solution with a newer
version of Tomcat and J2-Final.
- Frank
> -----Original Message-----
> From: Joachim Müller [mailto:joachim@wemove.com]
> Sent: Tuesday, January 31, 2006 06:01 AM
> To: Jetspeed Users List
> Subject: extending jetspeed with new services
>
>
> 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?)
>
>
> Thanks for any reply.
>
>
> Joachim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org