Hi Thomas,
yes, i rather see that now, after clarifying things with Ingo in an
exchange of email. i had
mistakenly thought the suggestion put the portlet code in the web server
document
root as opposed keeping it under the jetspeed webapp. *shrug* my mistake.
only
the portlet_resources will be under the webserver document root. all is
good with
that!
ttfn
--ron. ;-)
___________________________________________________________________________
Make it your ambition to lead a quiet life, to mind your own business, and
to work with your
hands, just as we told you, so that your daily life may win the respect of
outsiders and so
that you will not be dependent on anybody.
1 Thessalonians 4:11-12
"Thomas F. Boehme" <[EMAIL PROTECTED]>@list.working-dogs.com> on
01/25/2001 05:21:33 AM
Please respond to "JetSpeed" <[EMAIL PROTECTED]>
Sent by: <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
cc:
Subject: Re: Portlet Deployment...
Ron,
I don't understand what your disagreement is about -- you are saying the
exact same thing as Ingo did...
Cheers,
Thomas
----- Original Message -----
From: "Ron Lynn" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Wednesday, January 24, 2001 18:11
Subject: Re: Portlet Deployment...
Ingo,
i certainly agree with you on not mixing the engine with the portlets.
however, there is a tacit
implication that by placing the portlets under the document root of the
webserver that portlet
could be run without the engine. this is certainly not the case. perhaps
another approach
would be to have a directory under the jetspeed web app. set aside for
portlets.
call it the portlets directory which could have further structure as deemed
needed. perhaps
each and every portlet would have it's own sub directory under the portlets
directory in
which the portlet developer could establish her own sub directory
structure... very much
like how web apps are organized under tomcat today. none the less, it
should be
considered that the sample portlets distributed, present a misleading
example of how
other portlets should be organized.
meanwhile, the development of PAR should firmly fix what structure portlet
developers
should conform to and help automate the installation of portlets.
thanks for the data!
ttfn
--ron. ;-)
___________________________________________________________________________
Make it your ambition to lead a quiet life, to mind your own business, and
to work with your
hands, just as we told you, so that your daily life may win the respect of
outsiders and so
that you will not be dependent on anybody.
1 Thessalonians 4:11-12
ingo schuster <[EMAIL PROTECTED]>@list.working-dogs.com> on 01/24/2001
08:30:09 AM
Please respond to "JetSpeed" <[EMAIL PROTECTED]>
Sent by: <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
cc:
Subject: Re: Portlet Deployment...
At 16:30 01/24/01, Ron Lynn wrote:
>WooHoo! i'm looking forward to the PAR proposal!
>
>Ingo, on portlet deployment...
>
>i've noticed that if i put portlets in a jar file in the WEB-INF/lib
>directory they
>automagically get set in the classpath and all i need do is then define
>them in the
>WEB-INF/conf/jetspeed-config.jcfg file to get them running. further more
>i've utilized
>the existing WEB-INF/xsl directory for any xsl resources and used the web
>servers
>document root for any other resources. is this a _bad_ idea? it seemed a
>bit
>distributed, but that's how the sample portlets were laid out whether by
>design or
>default.
Well, the considerations behind my proposal are the following:
Jetspeed is the portal engine, the "core system", portlets are just clients
this engine.
I think it makes sense to separate those two you shouldn't be able to
mess up
the engine with a malfunctioning portlet. That's why IMHO portlet jars
should have
their own directory (that comes behind jetspeed in the calsspath). You
wouldn't want
mix a servlet engine with servlets either.
With respect to portlet resources, I think
a) they shouln't be mixed with the portal engine resources as well, and if
you deinstall
a portlet, it should be easy to remove it's resources as well.
-> put them below "portlet_resources/"
b) you have to make sure that different portlets are not interfering with
each other. (E.g:
Different portlets might want to bring their own logo.gif and sore it in
a subirectory "images").
-> give every portlet it's own subdirectory below "portlet_resources".
Notice that the name of this subirectory has to be choosen by the
portal administrator at
install time as their could easily be two portlets with the same name.
This is a problem,
as the portlet developer won't know the path to the resources at
development time.
ingo.
>ttfn
>--ron. ;-)
>
>
___________________________________________________________________________
>Make it your ambition to lead a quiet life, to mind your own business, and
>to work with your
>hands, just as we told you, so that your daily life may win the respect of
>outsiders and so
>that you will not be dependent on anybody.
>1 Thessalonians 4:11-12
>
>
>"Thomas F. Boehme" <[EMAIL PROTECTED]>@list.working-dogs.com> on
>01/24/2001 04:13:57 AM
>
>Please respond to "JetSpeed" <[EMAIL PROTECTED]>
>
>Sent by: <[EMAIL PROTECTED]>
>
>
>To: "JetSpeed" <[EMAIL PROTECTED]>
>cc:
>Subject: Re: Portlet Deployment...
>
>
>
>A proposal for PARs should be out by next week. The magic is in the
>deployment descriptor...
>
>Cheers,
>Thomas B.
>
>----- Original Message -----
>From: "ingo schuster" <[EMAIL PROTECTED]>
>To: "JetSpeed" <[EMAIL PROTECTED]>
>Sent: Wednesday, January 24, 2001 11:50
>Subject: Re: Portlet Deployment...
>
>
>At 10:32 01/24/01, Kimpton,C (Chris) wrote:
> >Hi,
> >
> >I was wondering what the preferred way of deploying a portlet was.
> >
> >For example, if I was using Turbine, I would include the turbine jar in
>lib
> >directory under the WEB-INF structure.
> >
> >Is this kind of thing possible with jetspeed - or should it be used more
> >like tomcat, in that you tell it where to look for applications in its
> >server.xml file.
>
>You can't simply put a jar file somewhere and expect your portlet to run.
>What you need to do is:
>* Make the portlet's classfiles available in the classpath,
>* Make the portlet's resources (images, etc) accessible somewhere below
the
>webserver's dorument root, and
>* Register the portlet in the portlet registry
>(WEB-INF/con/jetspeed-config.jcfg).
>The portal needs to be restarted to read the changes in the portlet
>registry - that's nasty.
>
>I put portlet code in a directory below WEB-INF
>(ROOT/WEB-INF/portlets/MyPortlet.jar) and its resources in a directory
>right below the document root (ROOT/portlet_resources/MyPortley/*).
>
>Where we need to get to is to have an packaging/installation mechanism
like
>WARs (in our case PARs), that can be installed automatically and at
>run-time.
>But that's still to solve and implement.
>
>ingo.
>
> >Thanks for the help.
> >Chris
> >
> >
>
===========================================================================
>=====================
> >This electronic message (email) and any attachments to it are subject to
> >copyright and are sent for the personal attention of the addressee.
> >Although you may be the named recipient, it may become apparent that
this
> >email and its contents are not intended for you and an addressing error
> >has been made. This email may include information that is legally
> >privileged and exempt from disclosure. If you have received this email
in
> >error, please advise us immediately and delete this email and any
> >attachments from your computer system.Rabobank International is the
> >trading name of Coöperatieve Centrale Raiffeisen-Boerenleenbank B.A.
which
> >is incorporated in the Netherlands. Registered with the Registrar of
> >Companies for England & Wales No. BR002630 and regulated by the SFA for
> >the conduct of investment business in the UK.
> >
> >The presence of this footnote also confirms that this email has been
> >automatically checked by Rabobank International for the presence of
> >computer viruses prior to it being sent, however, no guarantee is given
or
> >implied that this email is virus free upon delivery.
> >
> >
> >
> >
> >--
> >--------------------------------------------------------------
> >To subscribe: [EMAIL PROTECTED]
> >To unsubscribe: [EMAIL PROTECTED]
> >Search: <http://www.mail-archive.com/[email protected]/>
> >List Help?: [EMAIL PROTECTED]
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/[email protected]/>
>List Help?: [EMAIL PROTECTED]
>
>
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/[email protected]/>
>List Help?: [EMAIL PROTECTED]
>
>
>
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/[email protected]/>
>List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
