Christopher,

What is in the Jetspeed log file when the abstract entry is define in
local-portlets.xreg?

Paul Spencer

Christopher Abraham wrote:
> 
> I'm not moving an entry from portlets.xreg to local-portlets.xreg.
> I'm adding a new abstract portlet that looks something like this:
> 
>     <portlet-entry name="JSPnav" hidden="false" type="abstract"
> application="false">
> 
> <classname>com.MyCompaniesPackage.jetspeed.portal.portlets.JspPortletNav</cl
> assname>
>     </portlet-entry>
> 
> If I add this to Portlets.xreg, bounce tomcat, and then add the following to
> local-portlets, everything works beautifully:
> 
>    <portlet-entry name="New Portal User" hidden="false" type="ref"
>         parent="JSPnav" application="false">
>         <meta-info>
>             <title>New Portal User</title>
>             <description>Portal User Manager</description>
>         </meta-info>
>         <parameter name="templateNav" value="New Portal User"
> hidden="false"/>
>         <parameter name="template"
>             value="/jsp/modules/admin/UserPortalAdmin/user_portal_setup.jsp"
> hidden="false"/>
>         <media-type ref="html"/>
>     </portlet-entry>
> 
> ...But if I try to put the abstract portlet entry into local-portlets, even
> if I bounce, Jetspeed doesn't seem to see it at all.
> 
> Anyone have some more insight on how this works???
> 
> -----Original Message-----
> From: Paul Spencer [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 1:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: local-*.xreg handled how?
> 
> Christopher,
> If the entry work in portlets.xreg, then it should work in
> local-portlet.xreg.  You may need to shutdown jetspeed when you move the
> entry from portlets.xreg to local-portlet.xreg.
> 
> Are their any error in jetspeed.log?
> 
> Paul Spencer
> 
> Christopher Abraham wrote:
> >
> > Ok. So why do I not seem to be able to add an entry to local-portlets for
> an
> > abstract class pointing at a variation of
> > org.apache.jetspeed.portal.portlets.JSPPortlet (my flavor is called
> > JSPPortletNav), update the actual portlet so it's parent is the new
> abstract
> > portlet, and then have the actual portlet reload with it's parent being
> > JSPPortletNav?
> > I'm putting tomcat\CLASSES on the classpath and dropping the virgin (new)
> > class into the appropriate path/package.
> > This works if I edit Portlets.xreg, but not when I edit
> local-portlets.xreg.
> >
> > -----Original Message-----
> > From: Paul Spencer [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 21, 2001 12:18 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: local-*.xreg handled how?
> >
> > Christopher,
> > In general a copy of local-portlet.xreg is maintained in memory.
> > Jetspeed periodically checks to see if the file has been updated (note
> > the timestamp in Windows has a 1 minute granularity).  At shutdown
> > local-portlet.xreg is written from memory.  If a change has been made to
> > the file and Jetspeed has not updated it's in memory copy, then the
> > changes will be overwritten.
> >
> > You can search the mailing list for addition information.
> > http://www.mail-archive.com
> >
> > Paul Spencer
> >
> > Christopher Abraham wrote:
> > >
> > > This regards jetspeed 1.3.a2 running in Tomcat 3.23 environment:
> > >
> > > I thought I understood how local-portlets.xreg and the like relate to
> > > portlets.xreg, etc.
> > > But now I'm not sure. I was under the impression that local*.xreg files
> > were
> > > one-way feeds that allowed the insertion of new registry items into
> *.xreg
> > > files without the need for a "bounce".
> > >
> > > Can anyone explain how jetspeed handles these files?
> > >
> > > In particular, I don't understand when or why local-portlets.xreg gets
> > > overwritten during runtime, and I don't seem to be able to add abstract
> > > portlets to local-portlets.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to