RE: tomcat 5.0.19, jetspeed 1.4, jdk 1.4.2, SAX problem again
Will, JDK 1.4.2 includes an old xml parser within the jdk. You have to override this by some mechanism. Easiest way is to put the correct parser in tomcats common/endorsed and restart tomcat. If that's not working then something new may be wrong but I doubt it. I don't have 5.0.19 so I can't really comment on it. Search both the jetspeed lists and bugzilla. You should find all the comments about this and how to solve it there. The issue has been around for quite a while. Gerry Reno --- Will Saxon <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 24, 2004 9:46 PM > > To: Jetspeed Users List > > Subject: Re: tomcat 5.0.19, jetspeed 1.4, jdk 1.4.2, SAX problem > again > > > > > > Will, > > Somehow an incorrect version of xml parser/transformer is > > being found > > in your classpath. I opened a bug on this with jetspeed and > > with sun a > > while back. After putting files into common/endorsed try > restarting > > your container. Also make sure that you don't have any xml > > parser/transformers in your jdk lib directories. > > Gerry, > > Does this include the jre rt.jar? Basically, I have a fresh > installation > of jdk-1.4.2, tomcat 5.0.19 and jetspeed 1.4 with nothing else. I > don't > know enough about how this all interoperates yet to determine where > else > the problem might be coming from. There appears to be plenty of xml > classes in the rt.jar file. > > Should I just move back to jdk 1.3.1? > > -Will > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0.19, jetspeed 1.4, jdk 1.4.2, SAX problem again
Will,
Somehow an incorrect version of xml parser/transformer is being found
in your classpath. I opened a bug on this with jetspeed and with sun a
while back. After putting files into common/endorsed try restarting
your container. Also make sure that you don't have any xml
parser/transformers in your jdk lib directories.
Gerry Reno
--- Will Saxon <[EMAIL PROTECTED]> wrote:
> I am running the above configuration on FreeBSD 5.2.1-RELEASE.
> FreeBSD installs
> Tomcat to /usr/local/jakarta-tomcat5.0, and jetspeed to
> /usr/local/jakarta-tomcat5.0/webapps/jetspeed.
>
> I have read through the archives and bugzilla to find solutions for
> the error:
>
> problem in SAX transform:
> org.apache.xml.utils.WrappedRuntimeException:
> The output format must have a
> '{http://xml.apache.org/xalan}content-handler' property!
>
> The workaround seems to be to copy at least xalan-2.3.1.jar from
> webapps/jetspeed/WEB-INF to common/endorsed. This does not work for
> me. I have copied
> other files over like xerces-2.0.2.jar, xml-apis.jar, etc. without
> success.
>
> I have also tried to get xalan-2.5.1 and -2.6.0 jar files into that
> directory, also
> without success.
>
> What is the next step in troubleshoot this problem?
>
> -Will
>
> _
> Will Saxon
> Systems Programmer - Network Services
> Department of Housing and Residence Education
> University of Florida
> Email: [EMAIL PROTECTED]
> Phone: (352) 392-2171 x10148
>
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New (sort of) Jetspeed-based site
Hi Stuart, I had taken a look at your site some time ago and it was ok. But, I just took a look at your new layout and it's terrific. Very nice. Good luck with it. Gerry Reno --- Stuart Belden <[EMAIL PROTECTED]> wrote: > Technically it's been up for around a year now, but we recently > rolled out our new layout (a vast improvement over the circa '97 > style that was there before) so it seems a fitting time to annouce > it. :) http://www.boone.org > > The majority of portlets are Staff only, but there are a couple > public portlets worth mentioning. All of the content is served > through a modified WebSurfPortlet, which works with our very basic > in-house CMS. Two other non-trivial portlets are the job search / > job application portlets (click employment link on left menu). They > are a simple example of linking from one portlet to another and using > multiple vm templates in one portlet. I'd be happy to answer > questions about our experience with Jetspeed so far if there's an > interest. > > There used to be a "we use jetspeed" survey portlet; does that still > exist somewhere? > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: panes and skins
Aurelien, Go ahead and use what you like from my templates. They work good for now with the current skinning until something new will be ready. rgds, Gerry --- Pernoud Aurelien <[EMAIL PROTECTED]> wrote: > > Well in fact the new skinning process was supposed to get rid of all > the property of a skin... > > That's why in skins.xreg metal skin should only have the > portlet-skin-class entry, nothing else. > > I'll keep your templates to see if I can reuse them the way I wanted > to :) > > Thx > Aurelien > > Gerry Reno a �crit : > > > Hi, > > I kinda figured that out after looking at the code for a minute. > I > > went ahead and changed jetspeed-tab.vm to add support for new skins > > and jetspeed.vm to be able to have just title image with a > > line-bordered content box. I don't have cvs so I'm attaching the > > whole new files. Maybe you could diff against the cvs and create > > patch for me. > > > > Also, here is the skins registry entry I used: > > > > > > > hidden="false"/> name="highlight-background-color" > > value="#00" hidden="false"/> > name="title-text-color" value="#00FF00" hidden="false"/> > > > hidden="false"/> name="highlight-title-style-class" > > value="TTitle" hidden="false"/> > name="title-style-class" value="TTitle" hidden="false"/> > > > hidden="false"/> > hidden="false"/> > hidden="false"/> > > > > In skins.css file TTitle was set same as PTitle. Added these to > > PContent: border-left:#FF solid 1px; > > border-right:#FF solid 1px; > > border-bottom:#FF solid 1px; > > > > and this to PTitle, TTitle: > > // width:100%; /* required for IE, else you get > > leftcorner-title gap */ > > > > > > HTH, > > Gerry Reno > > > > > > > > --- Pernoud Aurelien <[EMAIL PROTECTED]> wrote: > >> > >> 1.5-dev skins are not finished yet, I haven't had time to do all > the > >> panes stuff, only portlets :( > >> > >> I hope to be able to do it soon. > >> > >> Gerry Reno a �crit : > >> > >>> In a J1 1.5-dev portal, I have not been able to select Metal for > >>> skin in the panes. When I try to do this the pane title is > >>> displayed with no background color. No images appear. Is there > >>> some configuration setting that is needed to use this skin with > >>> panes? > >>> > >>> thx > >> > > > > > > = > > Gerry Reno > > mailto: grenoml at@ yahoo dot. com > > (if mail bounces please retry later - spam rapidly fills up > mailbox) > > > > __ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free web site building tool. Try it! > > http://webhosting.yahoo.com/ps/sb/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: panes and skins
Ok, yahoo is doing weird things with my attachments so I'm including
code inline.
Here is code for jetspeed-tab.vm:
##
#if (! $data.Customized )
#if ( ! $tabs )
#parse ("jetspeed.vm")
#else
##
## Tab Title Bar
##
#foreach ( $tab in $tabs )
#if ($tab.isSelected() )
#set ($bgcolor = $!{skin.HighlightBackgroundColor} )
#set ($color = $!{skin.HighlightTextColor} )
#set ($titleclass = $!{skin.HighlightTitleStyleClass} )
#else
#set ($bgcolor = $!{skin.TitleBackgroundColor} )
#set ($color = $!{skin.TitleTextColor} )
#set ($titleclass = $!{skin.TitleStyleClass} )
#end
#if (${bgcolor})
#if (${color})
#set ($titlestyle = "background-color: $bgcolor; color:
$color;" )
#else
#set ($titlestyle = "background-color: $bgcolor;" )
#end
#else
#if (${color})
#set ($titlestyle = "color: $color;" )
#else
#set ($titlestyle = "" )
#end
#end
#if (${skin.tab-skin-class})
#end
#if ($tab.Link && ($tab.isSelected() == false))
$tab.Title
#else
$tab.Title
#end
#foreach ( $action in $actions )
#end
#if (${skin.tab-skin-class})
#end
#end
#foreach ( $action in $actions )
#end
$portlet.getContent($data)
#end
#else
$portlet.getContent($data)
#end
##
Here is code for jetspeed.vm:
##
## --
## Set portlet style
## --
#if (${skin.TitleBackgroundColor})
#set ($portletStyle="border-color: ${skin.TitleBackgroundColor}")
#end
## --
## Set title style
## --
#if (${skin.TitleBackgroundColor})
#if (${skin.TitleTextColor})
#set ($titlestyle = "background-color: $skin.TitleBackgroundColor;
color: $skin.TitleTextColor;" )
#else
#set ($titlestyle = "background-color: $skin.TitleBackgroundColor;"
)
#end
#else
#if (${$skin.TitleTextColor})
#set ($titlestyle = "color: $skin.TitleTextColor;" )
#end
#end
## --
## Set content style
## --
#if (${skin.BackgroundColor})
#if (${skin.TextColor})
#set ($contentstyle = "background-color: $skin.BackgroundColor;
color: $skin.TextColor;" )
#else
#set ($contentstyle = "background-color: $skin.BackgroundColor;" )
#end
#else
#if (${$skin.TextColor})
#set ($contentstyle = "color: $skin.TextColor;" )
#end
#end
#if( ! $portlet.isClosed($data) )
##
## Here we set a global css for the portlet using div tag
##
##
## Portlet Title Bar
##
#set ($cspan = 2)
#if( $portlet_instance.isShowTitleBar() )
#if (${skin.PortletSkinClass})
#else
## There's an extra column created for the portlet icon
#if ($portlet_instance.Image && $portlet_instance.Image !=
"images/dot.gif")
#set ($cspan = 3)
#end
#end
$portlet_instance.Title
#foreach ( $action in $actions )
#end
#if (${skin.PortletSkinClass})
#end
#end
##
## Portlet Content
##
#if( ! $portlet.isMinimized($data) )
#if (${skin.PortletSkinClass} &&
$portlet_instance.isShowTitleBar())
#end
#if (${skin.no-content-skin}) #set ($cspan = $cspan + 2) #end
$!portlet.getContent($data)
#if (${skin.PortletSkinClass} &&
$portlet_instance.isShowTitleBar())
#end
#end
##
## Portlet Bottom
##
#if ($portlet_instance.isShowTitleBar() && ${skin.PortletSkinClass})
#end
#end
##
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> Hi,
> I kinda figured that out after looking at the code for a minute. I
> went ahead and changed jetspeed-tab.vm to add support for new skins
> and
> jetspeed.vm to be able to have just title image with a line-bordered
> content box. I don't have cvs so I'm attaching the whole new files.
> Maybe you could diff against the cvs and create patch for me.
>
> Also, here is the skins registry entry I used:
>
>
> hidden="false"/>
> hidden="false"/>
> hidden="false"/>
> hidden="false"/>
> hidden="false"/>
> hidden="false"/>
> hidden="false"/>
> hidden="false"/>
>
>
>
> In skins.css file TTitle was set same as PTitle. Added these to
> PContent:
> border-left:#FF so
RE: panes and skins
Hi, I kinda figured that out after looking at the code for a minute. I went ahead and changed jetspeed-tab.vm to add support for new skins and jetspeed.vm to be able to have just title image with a line-bordered content box. I don't have cvs so I'm attaching the whole new files. Maybe you could diff against the cvs and create patch for me. Also, here is the skins registry entry I used: In skins.css file TTitle was set same as PTitle. Added these to PContent: border-left:#FF solid 1px; border-right:#FF solid 1px; border-bottom:#FF solid 1px; and this to PTitle, TTitle: // width:100%; /* required for IE, else you get leftcorner-title gap */ HTH, Gerry Reno --- Pernoud Aurelien <[EMAIL PROTECTED]> wrote: > > 1.5-dev skins are not finished yet, I haven't had time to do all the > panes stuff, only portlets :( > > I hope to be able to do it soon. > > Gerry Reno a �crit : > > > In a J1 1.5-dev portal, I have not been able to select Metal for > skin > > in the panes. When I try to do this the pane title is displayed > with > > no background color. No images appear. Is there some > configuration > > setting that is needed to use this skin with panes? > > > > thx > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
panes and skins
In a J1 1.5-dev portal, I have not been able to select Metal for skin in the panes. When I try to do this the pane title is displayed with no background color. No images appear. Is there some configuration setting that is needed to use this skin with panes? thx = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: skin
The problem seems to be with the colspan setting in jetspeed.vm. If I set the flanking left and right content boxes and the bottom boxes to display:none, and colspan is left at 2 the content box does not display right. If I set the colspan to 4 then everything is ok but it messes up other portlets that have the surrounding images. It appears there needs to be a way to set the colspan dynamically to get the right effect. --- Gerry Reno <[EMAIL PROTECTED]> wrote: > The best I've been able to do is to get only the images on top and a > content box but the content box always has a little margin around it > even though I set margins, padding to 0px so it always looks as > though > the title bar is overhanging on both sides just a little. Anybody > know > how to do this? > > thx > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > I've been trying to have a skin that only has images on the top. I > > know that the skin mechanism is about 10 boxes and I've been > changing > > the skin css file but I haven't been able to get just the top > images > > and a content box. Is this possible to do by changing or adding > css > > entries? > > > > thx > > > > > > = > > Gerry Reno > > mailto: grenoml at@ yahoo dot. com > > (if mail bounces please retry later - spam rapidly fills up > mailbox) > > > > __ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free web site building tool. Try it! > > http://webhosting.yahoo.com/ps/sb/ > > > > > ----- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: skin
The best I've been able to do is to get only the images on top and a content box but the content box always has a little margin around it even though I set margins, padding to 0px so it always looks as though the title bar is overhanging on both sides just a little. Anybody know how to do this? thx --- Gerry Reno <[EMAIL PROTECTED]> wrote: > I've been trying to have a skin that only has images on the top. I > know that the skin mechanism is about 10 boxes and I've been changing > the skin css file but I haven't been able to get just the top images > and a content box. Is this possible to do by changing or adding css > entries? > > thx > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
skin
I've been trying to have a skin that only has images on the top. I know that the skin mechanism is about 10 boxes and I've been changing the skin css file but I haven't been able to get just the top images and a content box. Is this possible to do by changing or adding css entries? thx = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J1: URL - domain name - IP behavior
Since first posting this I've been in discussions with a webhoster after explaining to them the behavior that we were seeing with a Jetspeed portal. After some investigation it appears that this may not be a Jetspeed-1 problem after all but due to the way in which webhosts setup apache, rewriting and servlet containers especially in shared host environments. After working with the webhost for about a week we were finally able to get things configured to where any type of permissible access to the webapp would produce consistent and correct results for jetspeed portal sites. This included http://www.portalsite.com, http://portalsite.com, http://portalsite.domain.com, and http://domain.com/portalsite. All these mappings now keep the url consistent for all accesses. So now even active-x controls load from the same domain and don't encounter the cross-site scripting security violations that they were previously. So if you are having any of these types of issues that we had run into I would suggest that you contact your webhost and have them check how they have their apache and servlet container configurations and mappings setup for your portal sites. Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > One of the things that my users and I have found when accessing > jetspeed-1 portals is that they modify the accessing URL which can > provide for some strange results. For instance if I have a domain > named 'domain.com' and a user accesses the portal using > http://www.domain.com everything works fine. But if the user > accesses > the portal with http://domain.com they get access denied errors for > some of my activeX controls that I load because apparently jetspeed > is > changing some of the accesses to add the 'www' in front which makes > the > browser think that it's a cross-domain scripting access and the > browser > security refuses to load the controls. Secondarily, the same type of > thing applies when I try to access the portal site using the sites IP > address. Instead of all accesses showing up as > http://111.222.333.444/... they are converted back into the > http://www.domain.com/... name style. This doesn't cause the > cross-scripting security problem but what it does do is prevent me > from > setting up a www.domain.com locally in my own network for development > and testing and then using the real portal's IP to test the real > domain > once we push code up. I've done this for years when developing sites > with no problems except for jetspeed. When the IP style of accesses > is > converted back by jetspeed to the name style then when we test the > real > site by using it's IP address as jetspeed is converting the access to > name-style it ends up resolving the access to our internally mapped > test address which screws things up. I think jetspeed should > consistently use whatever form of URL access that the user used to > access the portal and maintain that form consistently throughout the > session. > > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
J1: URL - domain name - IP behavior
One of the things that my users and I have found when accessing jetspeed-1 portals is that they modify the accessing URL which can provide for some strange results. For instance if I have a domain named 'domain.com' and a user accesses the portal using http://www.domain.com everything works fine. But if the user accesses the portal with http://domain.com they get access denied errors for some of my activeX controls that I load because apparently jetspeed is changing some of the accesses to add the 'www' in front which makes the browser think that it's a cross-domain scripting access and the browser security refuses to load the controls. Secondarily, the same type of thing applies when I try to access the portal site using the sites IP address. Instead of all accesses showing up as http://111.222.333.444/... they are converted back into the http://www.domain.com/... name style. This doesn't cause the cross-scripting security problem but what it does do is prevent me from setting up a www.domain.com locally in my own network for development and testing and then using the real portal's IP to test the real domain once we push code up. I've done this for years when developing sites with no problems except for jetspeed. When the IP style of accesses is converted back by jetspeed to the name style then when we test the real site by using it's IP address as jetspeed is converting the access to name-style it ends up resolving the access to our internally mapped test address which screws things up. I think jetspeed should consistently use whatever form of URL access that the user used to access the portal and maintain that form consistently throughout the session. = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.5-dev weather portlet
Correction: When I attempt to customize the weather portlet it expands to max size but still displays the message, Please customize your weather location. --- Gerry Reno <[EMAIL PROTECTED]> wrote: > I migrated one of my older portals to 1.5-dev and everything is > working except for the weather portlet. It displays a message to > please customize but when I try to customize it complains you don't > have access to these portlets. I have manually gone in and reset the > security-ref setting to default, owner, admin. Nothing helps. I set > the same as every other portlet on the page and those I can access > without any problem but this weather portlet refuses to let me > customize it. I searched the list but no comments. I put in a stock > 1.5-dev portal and yes, there I can customize the weather portlet. > So > my question is, in the migrated portal why won't it let me customize > it > when I have its security set exactly the same as all the other > portlets > and they are all working fine? Is there some new class or properties > entry I need somewhere? > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jetspeed 1.5-dev weather portlet
I migrated one of my older portals to 1.5-dev and everything is working except for the weather portlet. It displays a message to please customize but when I try to customize it complains you don't have access to these portlets. I have manually gone in and reset the security-ref setting to default, owner, admin. Nothing helps. I set the same as every other portlet on the page and those I can access without any problem but this weather portlet refuses to let me customize it. I searched the list but no comments. I put in a stock 1.5-dev portal and yes, there I can customize the weather portlet. So my question is, in the migrated portal why won't it let me customize it when I have its security set exactly the same as all the other portlets and they are all working fine? Is there some new class or properties entry I need somewhere? ===== Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Velocity reference problem in navigation file
In one of my portals in top.vm I've added another velocity reference
to extract from a properties file. And when I try to use it, it works
just fine, but, the first reference to the logo file that was
originally there stops working. If I comment out my new code, the
original reference works fine again.
>From top.vm:
#if ($config.getString("topnav.logo.file"))
#set ($LogoFile = $config.getString("topnav.logo.file"))
#set ($LogoURI = $clink.setURI("$LogoFile").Absolute)
#else
#set ($LogoURI = $config.getString("topnav.logo.url"))
#end
## Added by GR
## Calculate the URI for the logo background image - optional
##
#if ($config.getString("topnav.logo.background.file"))
#set ($LogoBGFile = $config.getString("topnav.logo.background.file"))
#set ($LogoBGURI = $clink.setURI("$LogoBGFile").Absolute)
#else
#set ($LogoBGURI = $config.getString("topnav.logo.background.url"))
#end
-
When both references are present, the served page displays:
When only the original reference is present, the served page displays:
-
I do not understand Velocity that well (mostly use JSP/Struts) so is
there something else I need to do to make this work, or is this a bug?
This behavior is the same for 1.4-b4, 1.4, 1.5-dev
Gerry Reno
=
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Using eclipse cvs w/jetspeed
I would now like to upgrade some of my production jetspeed-1 portals to pick up the latest bug fixes. I'm trying to figure out how the CVS capabilities in eclipse can help me do this in the simplest manner possible. If I synchronize with the HEAD of course I can pull in all the latest jetspeed changes and I think merge any conflicts locally for the basic jetspeed. I should be able to then build, deploy and test the new version of our generated basic jetspeed war file. Great. But, is there some way that I can then pull one of the existing user production portals (war file) into eclipse (with all of the users changes) and use CVS to merge in the new changes from the newly generated jetspeed war? I'm thinking this is going to take some type of CVS export/import sequence. Is someone familiar enough with eclipse that could detail the procedures that I would need to use with eclipse CVS to perform this type synchronization for my production portals? thx, Gerry Reno ===== Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
--- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Thursday, November 20, 2003, at 02:00 PM, Gerry Reno wrote: > > > David, > > No, I did not have the demo app deployed. I deployed it into > 4.1.29 > > and guess what - Jetspeed-2 displayed with a login portlet! > Finally. > > You should get more than just the login portlet, scroll down... > > > I wish this dependency was documented in GETTING_STARTED. > > I tried the exact same sequence with 5.0.14 but no luck - still > > getting the double initialization error. > > What do you mean? > It is documented. See step #6 Well, right below it in 7 it shows How to undeploy the demo app which led me to believe that it was optional to begin with. > > It runs fine for me under Tomcat 5.0.9, except that of course the > Login > Portlet (dependent on Catalina) doesn't display, but the other > portlets > do > Maybe some one else can verify version 5.0.14 Yes, there is definitely something different about 5.0.14. Whoever tests this should start like I did with a completely fresh version of 5.0.14 and then build and deploy pluto and J2. > > If you are using 2 different servlet containers, of course you know > you > must change your properties before deploying and pam.deploying to the > > second container > Im sure you are aware of this, but just thought I'd mention it just > in > case Yes, I was changing the properties file in between each deployment. > > I plan to change the way the database works now, and use a data > source > to locate the database instead of a property > Good. > > > > Also, nothing happens when I click on HW_App in the TC manager. > Is > > there a different URL that I should use other than > > http://localhost:8080/HW_App ? Right now all I get is a Directory > > Listing page with no files listed. > > Thats expected. OK, not here yet. > > > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > Thanks for the help. Gerry Reno = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
David, No, I did not have the demo app deployed. I deployed it into 4.1.29 and guess what - Jetspeed-2 displayed with a login portlet! Finally. I wish this dependency was documented in GETTING_STARTED. I tried the exact same sequence with 5.0.14 but no luck - still getting the double initialization error. Also, nothing happens when I click on HW_App in the TC manager. Is there a different URL that I should use other than http://localhost:8080/HW_App ? Right now all I get is a Directory Listing page with no files listed. Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Thursday, November 20, 2003, at 01:04 PM, Gerry Reno wrote: > > > David, > > Ok, I retried this and did not remove the pluto jar from > shared/lib > > this time. > yes Pluto needs to be there > > > Jetspeed now initializes and I see a page with only the > > Jetspeed-2 logo on it but nothing else. The loge still shows > problems: > > > > INFO: Jetspeed Initialization complete, Ready to service requests. > > Nov 20, 2003 4:00:39 PM org.apache.jetspeed.engine.JetspeedServlet > init > > INFO: Jetspeed Initialization complete, Ready to service requests. > > Nov 20, 2003 4:00:40 PM org.apache.coyote.http11.Http11Protocol > start > > INFO: Starting Coyote HTTP/1.1 on port 8080 > > Nov 20, 2003 4:00:40 PM org.apache.jk.common.ChannelSocket init > > INFO: JK2: ajp13 listening on /0.0.0.0:8009 > > Nov 20, 2003 4:00:40 PM org.apache.jk.server.JkMain start > > INFO: Jk running ID=0 time=0/41 > > config=/usr/local/jakarta-tomcat-4.1.29/conf/jk2.properties > > Capability Valve Invoked > > *** Getting portlet from registry: LoginPortlet > > org.apache.jetspeed.exception.JetspeedException: Failed to load: > > LoginPortlet from registry > > at > > Your registry does not have a portlet entry named "LoginPortlet" > Did you run the "maven pam.deploy" goal? > The PSML is hard-coded right now, so it expects that the demo app > will > be deployed > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
Here are my build.properties:
catalina.home=/usr/local/jakarta-tomcat-4.1.29/
#catalina.home=/usr/local/jakarta-tomcat/
locale.default=en
maven.ant.generatebuild.file=generated_maven_build.xml
catalina.shared.lib=${catalina.home}/shared/lib/
deploy.war.dir=${catalina.home}/webapps/
deployment.db.alias=${catalina.home}/webapps/jetspeed/WEB-INF/db/hsql/Registry
Gerry Reno
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> Yes, if you'll read back through the thread you will see that we
> covered this.
>
> Gerry Reno
>
>
> --- David Le Strat <[EMAIL PROTECTED]> wrote:
> > Have you correctly set up the db.alias in your
> > user.home? See getting started step 2.
> >
> > Hope this helps.
> >
> > David.
> > --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > > David,
> > > Ok, I retried this and did not remove the pluto
> > > jar from shared/lib
> > > this time. Jetspeed now initializes and I see a
> > > page with only the
> > > Jetspeed-2 logo on it but nothing else. The loge
> > > still shows problems:
> > >
> > > INFO: Jetspeed Initialization complete, Ready to
> > > service requests.
> > > Nov 20, 2003 4:00:39 PM
> > > org.apache.jetspeed.engine.JetspeedServlet init
> > > INFO: Jetspeed Initialization complete, Ready to
> > > service requests.
> > > Nov 20, 2003 4:00:40 PM
> > > org.apache.coyote.http11.Http11Protocol start
> > > INFO: Starting Coyote HTTP/1.1 on port 8080
> > > Nov 20, 2003 4:00:40 PM
> > > org.apache.jk.common.ChannelSocket init
> > > INFO: JK2: ajp13 listening on /0.0.0.0:8009
> > > Nov 20, 2003 4:00:40 PM org.apache.jk.server.JkMain
> > > start
> > > INFO: Jk running ID=0 time=0/41
> > >
> > config=/usr/local/jakarta-tomcat-4.1.29/conf/jk2.properties
> > > Capability Valve Invoked
> > > *** Getting portlet from registry: LoginPortlet
> > > org.apache.jetspeed.exception.JetspeedException:
> > > Failed to load:
> > > LoginPortlet from registry
> > > at
> > >
> >
>
org.apache.jetspeed.aggregator.BasicAggregator.build(BasicAggregator.java:191)
> > > at
> > >
> >
>
org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:84)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.valve.impl.VerySimpleLayoutValveImpl.invoke(VerySimpleLayoutValveImpl.java:137)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:132)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.services.profiler.ProfilerValve.invoke(ProfilerValve.java:90)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:106)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.capability.CapabilityValveImpl.invoke(CapabilityValveImpl.java:141)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:275)
> > > at
> > >
> >
>
org.apache.jetspeed.engine.JetspeedEngine.service(JetspeedEngine.java:240)
> > > at
> > >
> >
>
org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:245)
> > > 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.doForward(ApplicationDispatcher.
Re: Jetspeed-2 install problems
Yes, if you'll read back through the thread you will see that we covered this. Gerry Reno --- David Le Strat <[EMAIL PROTECTED]> wrote: > Have you correctly set up the db.alias in your > user.home? See getting started step 2. > > Hope this helps. > > David. > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > David, > > Ok, I retried this and did not remove the pluto > > jar from shared/lib > > this time. Jetspeed now initializes and I see a > > page with only the > > Jetspeed-2 logo on it but nothing else. The loge > > still shows problems: > > > > INFO: Jetspeed Initialization complete, Ready to > > service requests. > > Nov 20, 2003 4:00:39 PM > > org.apache.jetspeed.engine.JetspeedServlet init > > INFO: Jetspeed Initialization complete, Ready to > > service requests. > > Nov 20, 2003 4:00:40 PM > > org.apache.coyote.http11.Http11Protocol start > > INFO: Starting Coyote HTTP/1.1 on port 8080 > > Nov 20, 2003 4:00:40 PM > > org.apache.jk.common.ChannelSocket init > > INFO: JK2: ajp13 listening on /0.0.0.0:8009 > > Nov 20, 2003 4:00:40 PM org.apache.jk.server.JkMain > > start > > INFO: Jk running ID=0 time=0/41 > > > config=/usr/local/jakarta-tomcat-4.1.29/conf/jk2.properties > > Capability Valve Invoked > > *** Getting portlet from registry: LoginPortlet > > org.apache.jetspeed.exception.JetspeedException: > > Failed to load: > > LoginPortlet from registry > > at > > > org.apache.jetspeed.aggregator.BasicAggregator.build(BasicAggregator.java:191) > > at > > > org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:84) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.pipeline.valve.impl.VerySimpleLayoutValveImpl.invoke(VerySimpleLayoutValveImpl.java:137) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:132) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.services.profiler.ProfilerValve.invoke(ProfilerValve.java:90) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:106) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.capability.CapabilityValveImpl.invoke(CapabilityValveImpl.java:141) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:275) > > at > > > org.apache.jetspeed.engine.JetspeedEngine.service(JetspeedEngine.java:240) > > at > > > org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:245) > > 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.doForward(ApplicationDispatcher.java:432) > > at > > > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356) > > at > > > org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:430) > > at > > > org.apache.jsp.index_jsp._jspService(index_jsp.java:42) > > at > > > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210) > > at > > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) > > at > > > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.catalina.core.ApplicationFilte
Re: Jetspeed-2 install problems
(AuthenticatorBase.java:494) 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:2417) 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:172) 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:193) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:781) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:549) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:589) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666) at java.lang.Thread.run(Thread.java:534) Caused by: org.apache.jetspeed.exception.JetspeedException: Failed to load: LoginPortlet from registry at org.apache.jetspeed.aggregator.BasicAggregator.build(BasicAggregator.java:191) at org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:84) ... 58 more Gerry Reno = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
ig=/usr/local/jakarta-tomcat-4.1.29/conf/jk2.properties Nov 20, 2003 3:47:15 PM org.apache.jetspeed.engine.JetspeedServlet init INFO: Jetspeed Starting Initialization... Nov 20, 2003 3:47:15 PM org.apache.jetspeed.engine.JetspeedServlet init INFO: Double initialization of Jetspeed was attempted! Nov 20, 2003 3:47:15 PM org.apache.jetspeed.engine.JetspeedServlet init INFO: Double initialization of Jetspeed was attempted! java.lang.NoClassDefFoundError: org/apache/pluto/services/ContainerService at org.apache.jetspeed.Jetspeed.createEngine(Jetspeed.java:96) at org.apache.jetspeed.engine.JetspeedServlet.init(JetspeedServlet.java:168) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3422) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3623) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:700) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:252) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1058) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1567) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:385) at org.apache.catalina.core.StandardHost.install(StandardHost.java:819) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:442) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:399) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:718) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:358) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196) at org.apache.catalina.core.StandardHost.start(StandardHost.java:754) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:363) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190) at org.apache.catalina.startup.Catalina.start(Catalina.java:512) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) -- end of logfile Gerry Reno = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Ge
Re: Jetspeed-2 install problems
David,
Running a grep through jakarta-jetspeed-2 I get this:
find . -exec grep -Hn unreleased {} \;
./commons/project.xml:18: 0.1-dev-unreleased
./docs/GETTING-STARTED.html:62:The pluto jar needs
to be named to pluto-0.1-dev-unreleased.jar
./portal/maven.xml:214:
./portal/target/test-reports/TEST-org.apache.jetspeed.cache.file.TestFileCache.xml:70:
> > pam.deploy" and start it up again
> > >
> > >
> > >
> >
> -
> > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > >
> >
> >
> > =
> > Gerry Reno
> > mailto: grenoml at@ yahoo dot. com
> > (if mail bounces please retry later - spam rapidly fills up
> mailbox)
> >
> > __
> > Do you Yahoo!?
> > Free Pop-Up Blocker - Get it now
> > http://companion.yahoo.com/
> >
> >
> -----
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
>
>
> =
> Gerry Reno
> mailto: grenoml at@ yahoo dot. com
> (if mail bounces please retry later - spam rapidly fills up mailbox)
>
> __
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
David,
After resync with HEAD, J2 maven allBuild produces error now:
BUILD FAILED
File.. file:/home/greno/projects/workspace/jakarta-jetspeed-2/
Element... maven:reactor
Line.. 72
Column 40
The build cannot continue because of the following unsatisfied
dependency:
pluto-0.1-dev-unreleased.jar (no download url specified)
Total time: 18 seconds
Finished at: Thu Nov 20 15:18:31 EST 2003
Gerry Reno
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
>
> --- David Sean Taylor <[EMAIL PROTECTED]> wrote:
> >
> > On Thursday, November 20, 2003, at 10:26 AM, Gerry Reno wrote:
> >
> > > From jakarta-pluto/build I typed:
> > > ./build.sh
> > >
> > You will need to CVS UPDATE both Jetspeed-2 and Pluto
> > I just checked in some changes, including the Jetspeed-2
> project.xml
> > referencing pluto-1.0.jar
> > After building Pluto, copy pluto-1.0.jar to
> > ${MAVEN_HOME}/repository/pluto-container/jars/
>
>
> I also copied it to my local maven repository
>
> Working on J2 rebuild now.
>
>
> > (Sorry but we should have Pluto mavenized soon...)
> > Then run "maven allBuild" and "cd portal, maven deploy, maven
> > pam.deploy" and start it up again
> >
> >
> >
> -----
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
>
>
> =
> Gerry Reno
> mailto: grenoml at@ yahoo dot. com
> (if mail bounces please retry later - spam rapidly fills up mailbox)
>
> __
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
--- David Sean Taylor <[EMAIL PROTECTED]> wrote:
>
> On Thursday, November 20, 2003, at 10:26 AM, Gerry Reno wrote:
>
> > From jakarta-pluto/build I typed:
> > ./build.sh
> >
> You will need to CVS UPDATE both Jetspeed-2 and Pluto
> I just checked in some changes, including the Jetspeed-2 project.xml
> referencing pluto-1.0.jar
> After building Pluto, copy pluto-1.0.jar to
> ${MAVEN_HOME}/repository/pluto-container/jars/
I also copied it to my local maven repository
Working on J2 rebuild now.
> (Sorry but we should have Pluto mavenized soon...)
> Then run "maven allBuild" and "cd portal, maven deploy, maven
> pam.deploy" and start it up again
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
From jakarta-pluto/build I typed: ./build.sh Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Thursday, November 20, 2003, at 09:47 AM, Gerry Reno wrote: > > > David, > > Ok, I went and resync'd with the pluto HEAD and rebuilt pluto. > It > > now builds a jar named "pluto-1.0.jar" instead of the name " > > pluto-0.1-dev-unreleased.jar". Is this going to be a problem? Do > I > > need to rename this jar? > > How did you build Pluto? > What did you type and from which directory? > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
David, Ok, I went and resync'd with the pluto HEAD and rebuilt pluto. It now builds a jar named "pluto-1.0.jar" instead of the name " pluto-0.1-dev-unreleased.jar". Is this going to be a problem? Do I need to rename this jar? Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Thursday, November 20, 2003, at 07:14 AM, Gerry Reno wrote: > > > David, > > I rebuilt everything this morning and redeployed to 4.1.29, then > > removed the pluto jar from shared/lib and started Tomcat. The log > > shows that jetspeed intitialized and then immediately shutdown. > > The container is not getting initialized. > It must be throwing a runtime exception thats not being caught, and > then causing the servlet to shut down > See JetspeedEngine.java, line 202, there is a comment about the > signature changing on PortletContainer.init > > This suspects me to believe that you don't have the latest Pluto jar > You will need to checkout the latest Pluto source, build it and copy > it > into Maven's repo, since I don't think Pluto has been mavenized yet > Then rebuild J2 and deploy it > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
ered bean org.apache.jetspeed:mbean=Registry 2003-11-20 10:08:40,046 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - Registered simple name Registry to qualified object name org.apache.jetspeed:mbean=Registry 2003-11-20 10:08:40,421 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - JetspeedJMX remote services sucessfuly started! 2003-11-20 10:08:40,421 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Finish Initializing service (late): JMXService 2003-11-20 10:08:40,422 [main] INFO org.apache.jetspeed.engine.JetspeedEngine - JMX services sucessfully started. 2003-11-20 10:08:40,422 [main] INFO org.apache.jetspeed.Jetspeed - JetspeedEngine scuccessfuly intialized. 2003-11-20 10:08:40,422 [main] INFO org.apache.jetspeed.Jetspeed - Jetspeed environment scuccessfuly intialized. 2003-11-20 10:08:42,201 [main] INFO org.apache.jetspeed.persistence.impl.AbstractOJBPersistencePlugin - DB Alias changed to /usr/local/jakarta-tomcat//webapps/jetspeed/WEB-INF/db/hsql/Registry for the jetspeed-deploy plugin. 2003-11-20 10:08:43,171 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down all services! 2003-11-20 10:08:43,171 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PageManager 2003-11-20 10:08:43,209 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PortletEntityService 2003-11-20 10:08:43,213 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: JMXService 2003-11-20 10:08:43,726 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - Unregistering MBean: Naming:type=rmiregistry 2003-11-20 10:08:43,726 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - MBean: Naming:type=rmiregistry was successfuly unregistered. 2003-11-20 10:08:43,726 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - Unregistering MBean: org.apache.jetspeed:mbean=Registry 2003-11-20 10:08:43,726 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - MBean: org.apache.jetspeed:mbean=Registry was successfuly unregistered. 2003-11-20 10:08:43,726 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - Unregistering MBean: Adaptor:protocol=JRMP 2003-11-20 10:08:43,726 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - MBean: Adaptor:protocol=JRMP was successfuly unregistered. 2003-11-20 10:08:43,727 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: Profiler 2003-11-20 10:08:43,752 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PsmlManager 2003-11-20 10:08:43,766 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: capability 2003-11-20 10:08:43,766 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PortletRegistry 2003-11-20 10:08:43,766 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PersistenceService 2003-11-20 10:08:43,766 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: IdGenerator 2003-11-20 10:08:43,767 [main] INFO org.apache.jetspeed.services.idgenerator.JetspeedIdGeneratorService - Shutdown for JetspeedIdGeneratorService called. idCounter = 65536 (1) 2003-11-20 10:08:43,767 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: Aggregator 2003-11-20 10:08:43,771 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: factory 2003-11-20 10:08:43,772 [main] INFO org.apache.jetspeed.services.factory.FactoryManagerServiceImpl - Shutdown for FactoryManagerService called 2003-11-20 10:08:43,772 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: InformationProviderService 2003-11-20 10:08:43,772 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: logadaptor 2003-11-20 10:08:43,772 [main] INFO org.apache.jetspeed.container.services.log.ContainerLogAdaptorServiceImpl - Shutdown for ContainerLogAdaptor called Gerry Reno = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:891) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756) at com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.loadClass(MBeanInstantiatorImpl.java:439) ... 40 more 2003-11-19 22:14:47,229 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - Unregistering MBean: Naming:type=rmiregistry 2003-11-19 22:14:47,229 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - MBean: Naming:type=rmiregistry was successfuly unregistered. 2003-11-19 22:14:47,229 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - Unregistering MBean: org.apache.jetspeed:mbean=Registry 2003-11-19 22:14:47,229 [main] INFO org.apache.jetspeed.services.jmx.JetspeedJMXService - MBean: org.apache.jetspeed:mbean=Registry was successfuly unregistered. 2003-11-19 23:00:30,275 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down all services! 2003-11-19 23:00:30,276 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PageManager 2003-11-19 23:00:30,441 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PortletEntityService 2003-11-19 23:00:30,461 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: JMXService 2003-11-19 23:00:30,461 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: Profiler 2003-11-19 23:00:30,569 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PsmlManager 2003-11-19 23:00:30,604 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: capability 2003-11-19 23:00:30,604 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PortletRegistry 2003-11-19 23:00:30,604 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: PersistenceService 2003-11-19 23:00:30,604 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: IdGenerator 2003-11-19 23:00:30,605 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: Aggregator 2003-11-19 23:00:30,614 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: factory 2003-11-19 23:00:30,616 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: InformationProviderService 2003-11-19 23:00:30,616 [main] INFO org.apache.jetspeed.cps.CommonPortletServices - Shutting down service: logadaptor Gerry Reno = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
They are only in Tomcat 4.1.29. I get this error when I move the server/lib jars away: Nov 19, 2003 11:01:01 PM org.apache.commons.digester.Digester startElement SEVERE: Begin event threw error java.lang.NoClassDefFoundError: javax/management/MBeanException at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610) at java.lang.Class.getConstructor0(Class.java:1922) at java.lang.Class.newInstance0(Class.java:278) at java.lang.Class.newInstance(Class.java:261) at org.apache.commons.digester.ObjectCreateRule.begin(ObjectCreateRule.java:253) and Tomcat dies. Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Wednesday, November 19, 2003, at 07:50 PM, Gerry Reno wrote: > > > I am also seeing these in server/lib: > > ./server/lib/mx4j-jmx.jar > > ./server/lib/mx4j.license > > > For Tomcat 5 or Catalina? > I don't have those files in my version of Tomcat 5, nor Catalina > try moving them away and restarting > My version of Tomcat 5 is 5.0.9 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
I am also seeing these in server/lib: ./server/lib/mx4j-jmx.jar ./server/lib/mx4j.license Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Yes, I see these mx4j jars in jetspeed/WEB-INF/lib: > mx4j-jmx-1.1.1.jar > mx4j-tools-1.1.1.jar > > Gerry Reno > > --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > > On Wednesday, November 19, 2003, at 07:33 PM, Gerry Reno wrote: > > > - Root Cause - > > > javax.management.ReflectionException: The MBean class could not > be > > > loaded by the context classloader > > > at > > > > > > com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.loadClass(MBeanInstantiat > > > > > orImpl.java:444) > > > at > > > > > > com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClass(MBeanInstantiat > > > > > orImpl.java:80) > > > at > > > > > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(Defau > > > > > ltMBeanServerInterceptor.java:286) > > > at > > > > > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(Defau > > > > > ltMBeanServerInterceptor.java:234) > > > at > > > > > > com.sun.jmx.mbeanserver.JmxMBeanServer.createMBean(JmxMBeanServer.java: > > > > > 362) > > > > > > > > > Gerry Reno > > Please try to send only the relevant information in the email for > > indexing. > > It appears to me that JMX is failing to init > > Make sure you have the 2 mx4j files in your deployed webapp's lib > dir > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
Yes, I see these mx4j jars in jetspeed/WEB-INF/lib: mx4j-jmx-1.1.1.jar mx4j-tools-1.1.1.jar Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Wednesday, November 19, 2003, at 07:33 PM, Gerry Reno wrote: > > - Root Cause - > > javax.management.ReflectionException: The MBean class could not be > > loaded by the context classloader > > at > > > com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.loadClass(MBeanInstantiat > > > orImpl.java:444) > > at > > > com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClass(MBeanInstantiat > > > orImpl.java:80) > > at > > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(Defau > > > ltMBeanServerInterceptor.java:286) > > at > > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(Defau > > > ltMBeanServerInterceptor.java:234) > > at > > > com.sun.jmx.mbeanserver.JmxMBeanServer.createMBean(JmxMBeanServer.java: > > > 362) > > > > > > Gerry Reno > Please try to send only the relevant information in the email for > indexing. > It appears to me that JMX is failing to init > Make sure you have the 2 mx4j files in your deployed webapp's lib dir > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
David, Yes, in 5.0.14 but not in 4.1.29. Here is webapps in 5.0.14: calendar jetspeed-1.4b4 jsp-examples portal.war tomcat-docs calendar.war jetspeed-1.4b4.war pluto ROOT HW_Appjetspeed.warpluto.xml servlets-examples jetspeed jetspeed.xmlportaltestsuite Here is webapps in 4.1.29: admin.xml jetspeed jetspeed.xml pluto ROOT webdav examples jetspeed.war manager.xml pluto.xml tomcat-docs Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Wednesday, November 19, 2003, at 07:25 PM, Gerry Reno wrote: > > > David, > > I do see two jetspeed initializations going on in the log. The > first > > at 2:29:29 and the second at 2:29:51. > > > Send us a listing of your webapps directory > Do you have 2 jetspeeds installed into the webapps directory? > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
David, And this I get out of the localhost log (different run - same problem): 2003-11-19 22:14:47 Servlet /jetspeed threw load() exception javax.servlet.ServletException: Jetspeed: init() failed at org.apache.jetspeed.engine.JetspeedServlet.init(JetspeedServlet.java:189) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1044) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:887) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3853) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4168) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:866) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:850) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:315) at org.apache.catalina.core.StandardHost.install(StandardHost.java:859) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:653) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1002) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:393) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133) at org.apache.catalina.core.StandardHost.start(StandardHost.java:816) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:518) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2343) at org.apache.catalina.startup.Catalina.start(Catalina.java:580) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:397) - Root Cause - javax.management.ReflectionException: The MBean class could not be loaded by the context classloader at com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.loadClass(MBeanInstantiatorImpl.java:444) at com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClass(MBeanInstantiatorImpl.java:80) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:286) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:234) at com.sun.jmx.mbeanserver.JmxMBeanServer.createMBean(JmxMBeanServer.java:362) Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > David, > I do see two jetspeed initializations going on in the log. The > first > at 2:29:29 and the second at 2:29:51. > > Here's the complete startup log from Tomcat 5.0.14: > > Nov 19, 2003 2:29:14 PM org.apache.coyote.http11.Http11Protocol init > INFO: Initializing Coyote HTTP/1.1 on port 8080 > Nov 19, 2003 2:29:14 PM org.apache.catalina.startup.Catalina load > INFO: Initialization processed in 2185 ms > Nov 19, 2003 2:29:14 PM org.apache.catalina.core.StandardService > start > INFO: Starting service Catalina > Nov 19, 2003 2:29:14 PM org.apache.catalina.core.StandardEngine start > INFO: Starting Servlet Engine: Apache Tomcat/5.0.14 > Nov 19, 2003 2:29:14 PM org.apache.catalina.core.StandardHost start > INFO: XML validation disabled > Nov 19, 2003 2:29:14 PM org.apache.catalina.core.StandardHost > getDeployer > INFO: Create Host deployer for direct deployment ( non-jmx ) > Nov 19, 2003 2:29:14 PM org.apache.catalina.core.StandardHostDeployer > install > INFO: Processing Context configuration file URL > file:/usr/local/jakarta-tomcat-5.0.14/conf/Catalina/localhost/manager.xml > Nov 19, 2003 2:29:15 PM org.apache.catalina.core.StandardHostDeployer > install > INFO: Processing Context configuration file URL > file:/usr/local/jakarta-tomcat-5.0.14/conf/Catalina/localhost/admin.xml > Nov 19, 2003 2:29:16 PM > org.apache.struts.util.PropertyMessageResources > > INFO: Initializing, config='org.apache.struts.util.LocalStrings', > returnNull=true > Nov 19, 2003 2:29:16 PM > org.apache.struts.util.PropertyMessageResources > > INFO: Initializing, > config='org.apache.struts.action.Ac
Re: Jetspeed-2 install problems
che.jetspeed.engine.JetspeedServlet init INFO: Jetspeed Starting Initialization... Nov 19, 2003 2:29:51 PM org.apache.jetspeed.engine.JetspeedServlet init INFO: Double initialization of Jetspeed was attempted! Nov 19, 2003 2:29:51 PM org.apache.jetspeed.engine.JetspeedServlet init INFO: Double initialization of Jetspeed was attempted! Nov 19, 2003 2:29:51 PM org.apache.jetspeed.request.RequestContextFactory getInstance SEVERE: RequestContextFactory: Failed to create a Class object for RequestContext: java.lang.NullPointerException: The engine is null, have you called createEgine() yet? java.lang.NullPointerException: The engine is null, have you called createEgine() yet? at org.apache.jetspeed.Jetspeed.getContext(Jetspeed.java:130) at org.apache.jetspeed.request.RequestContextFactory.getInstance(RequestContextFactory.java:101) at org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:243) Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > David, > I don't know where else to look. I started with completely new > versions of Tomcat and the J2 maven build went through without a > problem. I checked in the logs and right after the shutdown at the > very beginning of the startup is where the double initialization > error > occurs. Here's my environment: > > RedHat Linux 8.0 > Java 1.4.2 > Tomcat 4.1.29, 5.0.14 > > How can I force maven to ignore all the current jars and download > all > new jars? Maybe that would help. > > Gerry Reno > > > --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > > On Wednesday, November 19, 2003, at 11:41 AM, Gerry Reno wrote: > > > > > Tomcat 5.0.14: > > > I removed the following jars from shared/lib and restarted: > > > pluto-0.1-dev-unreleased.jar > > > portlet-api.jar > > > > > > Pluto no longer runs. Jetspeed still gets the following double > > > initialization error: > > > > > > INFO: Jetspeed Starting Initialization... > > > Nov 19, 2003 2:29:51 PM > org.apache.jetspeed.engine.JetspeedServlet > > init > > > INFO: Double initialization of Jetspeed was attempted! > > > Nov 19, 2003 2:29:51 PM > org.apache.jetspeed.engine.JetspeedServlet > > init > > > INFO: Double initialization of Jetspeed was attempted! > > > Nov 19, 2003 2:29:51 PM > > > org.apache.jetspeed.request.RequestContextFactory getInstance > > > SEVERE: RequestContextFactory: Failed to create a Class object > for > > > RequestContext: java.lang.NullPointerException: The engine is > null, > > > have you called createEgine() yet? > > > java.lang.NullPointerException: The engine is null, have you > called > > > createEgine() yet? > > > > Well I've been trying to reproduce this under Tomcat 5 and > Catalina. > > I'll be damned but it works for me without error :( > > Im not sure whats different in my environment here from yours > > suggest looking at the log files and seeing if anything is failing > up > > > > top > > > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: J2: maven goals
Hi Scott, Took a look at CVS. Should the wrote: > David, > > I have already made the changes and tested them here in my local > drop. Once we get a positive vote, I will move the two maven.xml > files up to the CVS. > > Regards, > ** > | Scott T Weaver | > | <[EMAIL PROTECTED]>| > | Apache Jetspeed Portal Project | > | Apache Pluto Portlet Container | > ** > > > -Original Message- > > From: David Sean Taylor [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 18, 2003 12:37 PM > > To: Jetspeed Users List > > Subject: Re: J2: maven goals > > > > > > On Tuesday, November 18, 2003, at 08:44 AM, Gerry Reno wrote: > > > > > The catalina:shared and catalina-base:shared goals currently > are a > > > dependency of allBuild. Shouldn't these really be a dependency > of the > > > 'deploy' goal? In fact, I noticed that when trying to switch > between > > > Tomcat versions and redeploy to the new version that jars were > missing > > > in shared/lib because there was no dependency goals of 'deploy' > to put > > > them there. > > > > > > Gerry Reno > > > > > yes agreed > > i'll propose the change on jetspeed-dev > > > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
David, I don't know where else to look. I started with completely new versions of Tomcat and the J2 maven build went through without a problem. I checked in the logs and right after the shutdown at the very beginning of the startup is where the double initialization error occurs. Here's my environment: RedHat Linux 8.0 Java 1.4.2 Tomcat 4.1.29, 5.0.14 How can I force maven to ignore all the current jars and download all new jars? Maybe that would help. Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Wednesday, November 19, 2003, at 11:41 AM, Gerry Reno wrote: > > > Tomcat 5.0.14: > > I removed the following jars from shared/lib and restarted: > > pluto-0.1-dev-unreleased.jar > > portlet-api.jar > > > > Pluto no longer runs. Jetspeed still gets the following double > > initialization error: > > > > INFO: Jetspeed Starting Initialization... > > Nov 19, 2003 2:29:51 PM org.apache.jetspeed.engine.JetspeedServlet > init > > INFO: Double initialization of Jetspeed was attempted! > > Nov 19, 2003 2:29:51 PM org.apache.jetspeed.engine.JetspeedServlet > init > > INFO: Double initialization of Jetspeed was attempted! > > Nov 19, 2003 2:29:51 PM > > org.apache.jetspeed.request.RequestContextFactory getInstance > > SEVERE: RequestContextFactory: Failed to create a Class object for > > RequestContext: java.lang.NullPointerException: The engine is null, > > have you called createEgine() yet? > > java.lang.NullPointerException: The engine is null, have you called > > createEgine() yet? > > Well I've been trying to reproduce this under Tomcat 5 and Catalina. > I'll be damned but it works for me without error :( > Im not sure whats different in my environment here from yours > suggest looking at the log files and seeing if anything is failing up > > top > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IFrame-Portlet with state?
--- Kai Grossjohann <[EMAIL PROTECTED]> wrote: > Gerry Reno <[EMAIL PROTECTED]> writes: > > > Within the iframe itself you could maintain a session as long as no > > one reloaded the page that contained the iframe. > > Yes. > > > The problem we have now is mainly with the portlet control icons > > causing page reloads that destroy the context of things like > > iframes. Within a limited set of webapps, you can attempt to > > maintain state through using cookies and other methods > > Well, like I said I was hoping the HTTP session should be enough. > The > webapp needs a single URL (servlet or JSP, or whatever) which is > capable of looking at the session and gleaning the current > application > state from there. Then, said servlet or JSP (or whatever) should > produce the right HTML. > > In fact, our webapp almost has this, but it invokes different URLs > (each URL one frameset) for different states. So we just need to > store the URL also in the session, and then make a JSP that > dispatches > to the different URLs, and then we're finished. > > Is this correct? Possibly. Without knowing a lot of details it would be difficult to offer an opinion on what you're trying to accomplish. Should be easy enough to try out little experiments and see what works for you. > > What are the "other methods" that could be used to maintain state? URL rewriting for instance. > > > but overall it would be best if all of this portlet control stuff > > were performed on the client and just a notification sent to the > > server to inform it of what the current portlet state is. That way > > there would not be any destruction of the state for things like > > iframe portlets and you wouldn't lose your place in your portlet > > ecommerce session, your mainframe remote logon session or your > place > > in your multimedia or video presentation. > > I'm afraid you lost me there. It seems you're saying it would be > best > for portlets not to be web-based. Heh, maybe you're right ;-) The comments were in regard to how jetspeed specifically is handling the control of its portlets. Things like maximize, minimize, print-friendly, etc. Gerry Reno > > Kai > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
Tomcat 5.0.14:
I removed the following jars from shared/lib and restarted:
pluto-0.1-dev-unreleased.jar
portlet-api.jar
Pluto no longer runs. Jetspeed still gets the following double
initialization error:
INFO: Jetspeed Starting Initialization...
Nov 19, 2003 2:29:51 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Double initialization of Jetspeed was attempted!
Nov 19, 2003 2:29:51 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Double initialization of Jetspeed was attempted!
Nov 19, 2003 2:29:51 PM
org.apache.jetspeed.request.RequestContextFactory getInstance
SEVERE: RequestContextFactory: Failed to create a Class object for
RequestContext: java.lang.NullPointerException: The engine is null,
have you called createEgine() yet?
java.lang.NullPointerException: The engine is null, have you called
createEgine() yet?
at org.apache.jetspeed.Jetspeed.getContext(Jetspeed.java:130)
at
org.apache.jetspeed.request.RequestContextFactory.getInstance(RequestContextFactory.java:101)
at
org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:243)
Tomcat 4.1.29:
I removed the following jars from shared/lib and restarted:
pluto-0.1-dev-unreleased.jar
Pluto no longer runs. Jetspeed displays a totally blank page. Log
shows:
Nov 19, 2003 2:37:04 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Jetspeed Starting Initialization...
Nov 19, 2003 2:37:04 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Double initialization of Jetspeed was attempted!
Nov 19, 2003 2:37:04 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Double initialization of Jetspeed was attempted!
Nov 19, 2003 2:37:04 PM
org.apache.jetspeed.request.RequestContextFactory getInstance
SEVERE: RequestContextFactory: Failed to create a Class object for
RequestContext: java.lang.NullPointerException: The engine is null,
have you called createEgine() yet?
java.lang.NullPointerException: The engine is null, have you called
createEgine() yet?
at org.apache.jetspeed.Jetspeed.getContext(Jetspeed.java:130)
at
org.apache.jetspeed.request.RequestContextFactory.getInstance(RequestContextFactory.java:101)
at
org.apache.jetspeed.engine.JetspeedServlet.doGet(JetspeedServlet.java:
Well, at least now I'm getting the same errors trying to start J2 in
both versions of Tomcat. Anything else I should try?
Gerry Reno
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> Here's the ${catalina.home}/shared/lib from my other TC 4.1.29
> installation:
> commons-configuration-1.0-dev.jar log4j-1.2.6.jar
> commons-lang-1.0.1.jar pluto-0.1-dev-unreleased.jar
> commons-logging-1.0.2.jar portlet-api-1.0.jar
> jetspeed-commons-2.0-a1-dev.jar
>
> Gerry Reno
>
> --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > David,
> > Here's ${catalina.home}/shared/lib:
> > commons-configuration-1.0-dev.jar log4j-1.2.6.jar
> > commons-lang-1.0.1.jar pluto-0.1-dev-unreleased.jar
> > commons-logging-1.0.2.jar portlet-api-1.0.jar
> > jetspeed-commons-2.0-a1-dev.jarportlet-api.jar
> >
> > Which jars are conflicting?
> >
> > Gerry Reno
> >
> > --- David Sean Taylor <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wednesday, November 19, 2003, at 11:02 AM, Gerry Reno wrote:
> > >
> > > > I have not been able to make any more progress getting J2 to
> > run.
> > > > Here are my ${user}/build.properties entries:
> > > >
> > > > #catalina.home=/usr/local/jakarta-tomcat-4.1.29/
> > > > catalina.home=/usr/local/jakarta-tomcat/
> > > > locale.default=en
> > > > maven.ant.generatebuild.file=generated_maven_build.xml
> > > > catalina.shared.lib=${catalina.home}/shared/lib/
> > > > deploy.war.dir=${catalina.home}/webapps/
> > > >
> > >
> >
>
deployment.db.alias=${catalina.home}/webapps/jetspeed/WEB-INF/db/hsql/
> > >
> > > > Registry
> > > >
> > > > Anything wrong with these?
> > > >
> > > no
> > > do you have pluto installed in the same shared area of tomcat?
> > >
> > >
> > >
> >
> -
> > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > >
> >
> >
> > =
> > Gerry Reno
> > mailto: grenoml at@ yahoo dot. com
> > (if mail bounces please retry later - spam rapidly fills up
> mailbox)
> >
> > __
> > Do you Yahoo!?
> > Protect your identity with Yahoo! Mail
Re: Jetspeed-2 install problems
Here's the ${catalina.home}/shared/lib from my other TC 4.1.29
installation:
commons-configuration-1.0-dev.jar log4j-1.2.6.jar
commons-lang-1.0.1.jar pluto-0.1-dev-unreleased.jar
commons-logging-1.0.2.jar portlet-api-1.0.jar
jetspeed-commons-2.0-a1-dev.jar
Gerry Reno
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> David,
> Here's ${catalina.home}/shared/lib:
> commons-configuration-1.0-dev.jar log4j-1.2.6.jar
> commons-lang-1.0.1.jar pluto-0.1-dev-unreleased.jar
> commons-logging-1.0.2.jar portlet-api-1.0.jar
> jetspeed-commons-2.0-a1-dev.jarportlet-api.jar
>
> Which jars are conflicting?
>
> Gerry Reno
>
> --- David Sean Taylor <[EMAIL PROTECTED]> wrote:
> >
> > On Wednesday, November 19, 2003, at 11:02 AM, Gerry Reno wrote:
> >
> > > I have not been able to make any more progress getting J2 to
> run.
> > > Here are my ${user}/build.properties entries:
> > >
> > > #catalina.home=/usr/local/jakarta-tomcat-4.1.29/
> > > catalina.home=/usr/local/jakarta-tomcat/
> > > locale.default=en
> > > maven.ant.generatebuild.file=generated_maven_build.xml
> > > catalina.shared.lib=${catalina.home}/shared/lib/
> > > deploy.war.dir=${catalina.home}/webapps/
> > >
> >
>
deployment.db.alias=${catalina.home}/webapps/jetspeed/WEB-INF/db/hsql/
> >
> > > Registry
> > >
> > > Anything wrong with these?
> > >
> > no
> > do you have pluto installed in the same shared area of tomcat?
> >
> >
> >
> -
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
>
>
> =
> Gerry Reno
> mailto: grenoml at@ yahoo dot. com
> (if mail bounces please retry later - spam rapidly fills up mailbox)
>
> __
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
David,
Here's ${catalina.home}/shared/lib:
commons-configuration-1.0-dev.jar log4j-1.2.6.jar
commons-lang-1.0.1.jar pluto-0.1-dev-unreleased.jar
commons-logging-1.0.2.jar portlet-api-1.0.jar
jetspeed-commons-2.0-a1-dev.jarportlet-api.jar
Which jars are conflicting?
Gerry Reno
--- David Sean Taylor <[EMAIL PROTECTED]> wrote:
>
> On Wednesday, November 19, 2003, at 11:02 AM, Gerry Reno wrote:
>
> > I have not been able to make any more progress getting J2 to run.
> > Here are my ${user}/build.properties entries:
> >
> > #catalina.home=/usr/local/jakarta-tomcat-4.1.29/
> > catalina.home=/usr/local/jakarta-tomcat/
> > locale.default=en
> > maven.ant.generatebuild.file=generated_maven_build.xml
> > catalina.shared.lib=${catalina.home}/shared/lib/
> > deploy.war.dir=${catalina.home}/webapps/
> >
>
deployment.db.alias=${catalina.home}/webapps/jetspeed/WEB-INF/db/hsql/
>
> > Registry
> >
> > Anything wrong with these?
> >
> no
> do you have pluto installed in the same shared area of tomcat?
>
>
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
I have not been able to make any more progress getting J2 to run.
Here are my ${user}/build.properties entries:
#catalina.home=/usr/local/jakarta-tomcat-4.1.29/
catalina.home=/usr/local/jakarta-tomcat/
locale.default=en
maven.ant.generatebuild.file=generated_maven_build.xml
catalina.shared.lib=${catalina.home}/shared/lib/
deploy.war.dir=${catalina.home}/webapps/
deployment.db.alias=${catalina.home}/webapps/jetspeed/WEB-INF/db/hsql/Registry
Anything wrong with these?
Gerry Reno
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> Correction. Pluto portal comes up but when you click on the Test
> link the Test portlet does not show. Log shows:
> DEBUG org.apache.pluto.invoker
> PortletContainerImpl.portletLoad(test_row_col1_p1) called.
> java.lang.NullPointerException
> at
>
org.apache.pluto.portalImpl.om.entity.impl.PortletEntityImpl.getPortletDefinition(PortletEntityImpl.java:120)
> at
>
org.apache.pluto.PortletContainerImpl.portletLoad(PortletContainerImpl.java:281)
> at
>
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.portletLoad(PortletContainerWrapperImpl.java:132)
> at
> org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl
> ...
>
> Gerry Reno
>
> --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > Ok, started off with a brand-spanking-new version of Tomcat
> 4.1.29,
> > deployed jetspeed-2 and pluto. Pluto works fine but I get the
> exact
> > same results for jetspeed-2 as before. Only get a logo and nothing
> > else. Log shows the same error, trying to get the LoginPortlet
> from
> > the registry. Clues anyone?
> >
> > Gerry Reno
> >
> >
> > --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > > After moving maven goals catalina:base-shared and
> catalina:shared
> > > from maven.xml to portal/maven.xml and shutdown, redeploy,
> > startup
> > > I
> > > finally got something with J2 under Tomcat 4.1.24 -- the logo!
> > > That's
> > > it, just the logo. No login, nothing else. Checking the log I
> see
> > > this error:
> > >
> > > Capability Valve Invoked
> > > *** Getting portlet from registry: LoginPortlet
> > > org.apache.jetspeed.exception.JetspeedException: Failed to load:
> > > LoginPortlet from registry
> > > at
> > >
> >
>
org.apache.jetspeed.aggregator.BasicAggregator.build(BasicAggregator.java:191)
> > > at
> > >
> >
>
org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:84)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.valve.impl.VerySimpleLayoutValveImpl.invoke(VerySimpleLayoutValveImpl.java:137)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:132)
> > > at
> > >
> >
>
org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293)
> > > at
> > >
> >
>
org.apache.jetspeed.services.profiler.ProfilerValve.invoke(ProfilerValve.java:90)
> > >
> > > Still investigating...
> > >
> > > Gerry Reno
> > >
> > >
> > >
> > > --- David Sean Taylor <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Tuesday, November 18, 2003, at 03:23 PM, Gerry Reno wrote:
> > > >
> > > > > Here are some of my observations trying to get JS2 running:
> > > > >
> > > > > I have two Tomcat installations:
> > > > > jakarta-tomcat-4.1.24
> > > > > jakarta-tomcat-5.0.14
> > > > >
> > > > > Pluto:
> > > > > Pluto gets the following error when trying to run under
> > Tomcat
> > > > > 4.1.24:
> > > > >
> > > >
> > > >
> > > > >
> > > > > Jetspeed-2:
> > > > > Jetspeed-2 builds without error under Maven and deploys ok
> > but
> > > > won't
> > > > > run under Tomcat 4.1.24 (probably because pluto won't run).
> > > > >
> > > > > Jetspeed-2 builds without error under Maven and deploys ok
> > but
> > > > won't
> > > > > run under Tomcat 5.0.14 due to a doubl
Re: HTML standard in Jetspeed ?
I thought I remembered seeing somewhere that it was html 3.2. Gerry Reno --- Stuart Belden <[EMAIL PROTECTED]> wrote: > It's by and large not standards compliant. A doctype isn't even > specified in default.vm. > > > >>> [EMAIL PROTECTED] 11/19/03 10:19AM >>> > Hi everybody, > do the HTML bits in Jetspeed (templates, existing portlets) adhere to > any > specification (HTML 4 ...) ? Or is it just hack-as-it-works html ? (I > do > believe in this, but wanted to ask) > I ask because I would be interested in making our portal > standard-compliant. > Thanks > Stefan > -- > Stefan Kuhn M. A. > Cologne University BioInformatics Center > (http://www.cubic.uni-koeln.de) > Zülpicher Str. 47, 50674 Cologne > Tel: +49(0)221-470-7428 Fax: +49 (0) 221-470-7786 > My public PGP key is available at http://pgp.mit.edu > > > - > 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] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.5 dev demo
Also, retried it in firebird on windows - it's working. Yesterday, I don't think I was giving it enough time to display the red bar. Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Gerald, Jun, > I'm assuming your speaking about the drag and drop customizer > working. I just downloaded firebird onto one of my linux boxes and > tried this again. Yes, it's working in firebird on rh9. I also > tried > on IE6 on windows and it is working there also. > > Gerry Reno > > --- Gerald Stampfel <[EMAIL PROTECTED]> wrote: > > Jun Yang schrieb: > > > > > I just tried it on IE 6.0, Firebird 0.7 and Mozilla 1.5. All > > worked. > > > > > > > I tried it too on IE6.0 and it worked for me. > > > > > > - > > Gerald Stampfel > > [EMAIL PROTECTED] > > > > > > > ----- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.5 dev demo
Gerald, Jun, I'm assuming your speaking about the drag and drop customizer working. I just downloaded firebird onto one of my linux boxes and tried this again. Yes, it's working in firebird on rh9. I also tried on IE6 on windows and it is working there also. Gerry Reno --- Gerald Stampfel <[EMAIL PROTECTED]> wrote: > Jun Yang schrieb: > > > I just tried it on IE 6.0, Firebird 0.7 and Mozilla 1.5. All > worked. > > > > I tried it too on IE6.0 and it worked for me. > > > - > Gerald Stampfel > [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
Correction. Pluto portal comes up but when you click on the Test link the Test portlet does not show. Log shows: DEBUG org.apache.pluto.invoker PortletContainerImpl.portletLoad(test_row_col1_p1) called. java.lang.NullPointerException at org.apache.pluto.portalImpl.om.entity.impl.PortletEntityImpl.getPortletDefinition(PortletEntityImpl.java:120) at org.apache.pluto.PortletContainerImpl.portletLoad(PortletContainerImpl.java:281) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.portletLoad(PortletContainerWrapperImpl.java:132) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl ... Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Ok, started off with a brand-spanking-new version of Tomcat 4.1.29, > deployed jetspeed-2 and pluto. Pluto works fine but I get the exact > same results for jetspeed-2 as before. Only get a logo and nothing > else. Log shows the same error, trying to get the LoginPortlet from > the registry. Clues anyone? > > Gerry Reno > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > After moving maven goals catalina:base-shared and catalina:shared > > from maven.xml to portal/maven.xml and shutdown, redeploy, > startup > > I > > finally got something with J2 under Tomcat 4.1.24 -- the logo! > > That's > > it, just the logo. No login, nothing else. Checking the log I see > > this error: > > > > Capability Valve Invoked > > *** Getting portlet from registry: LoginPortlet > > org.apache.jetspeed.exception.JetspeedException: Failed to load: > > LoginPortlet from registry > > at > > > org.apache.jetspeed.aggregator.BasicAggregator.build(BasicAggregator.java:191) > > at > > > org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:84) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.pipeline.valve.impl.VerySimpleLayoutValveImpl.invoke(VerySimpleLayoutValveImpl.java:137) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:132) > > at > > > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > > at > > > org.apache.jetspeed.services.profiler.ProfilerValve.invoke(ProfilerValve.java:90) > > > > Still investigating... > > > > Gerry Reno > > > > > > > > --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > > > > On Tuesday, November 18, 2003, at 03:23 PM, Gerry Reno wrote: > > > > > > > Here are some of my observations trying to get JS2 running: > > > > > > > > I have two Tomcat installations: > > > > jakarta-tomcat-4.1.24 > > > > jakarta-tomcat-5.0.14 > > > > > > > > Pluto: > > > > Pluto gets the following error when trying to run under > Tomcat > > > > 4.1.24: > > > > > > > > > > > > > > > > > > Jetspeed-2: > > > > Jetspeed-2 builds without error under Maven and deploys ok > but > > > won't > > > > run under Tomcat 4.1.24 (probably because pluto won't run). > > > > > > > > Jetspeed-2 builds without error under Maven and deploys ok > but > > > won't > > > > run under Tomcat 5.0.14 due to a double initialization error > (see > > > > below) which I have not been able to stop from happening. > > > > > > > J2 has a login portlet dependent on Tomcat 4 security. It fails > in > > > Tomcat 5 > > > Besides that J2, what little of it there is to see, runs fine on > > > Tomcat > > > 5 > > > > > > > > > > > All my other webapps of which I have about 30, many > jetspeed-1 > > > based, > > > > run fine under both versions of Tomcat. Insights would be > > welcome. > > > > > > > The simple Pluto portal environment has had conflicts with > > Jetspeed-2 > > > > > > in the Tomcat shared/lib directory. > > > Its been a while since I've toyed with the pluto portal, it may > > still > > > > > > be a problem. > > > Recommend cleaning out either Pluto or J2 from the shared/lib > > > directory > > > before using the other > > > > > &g
Re: Jetspeed-2 install problems
Ok, started off with a brand-spanking-new version of Tomcat 4.1.29, deployed jetspeed-2 and pluto. Pluto works fine but I get the exact same results for jetspeed-2 as before. Only get a logo and nothing else. Log shows the same error, trying to get the LoginPortlet from the registry. Clues anyone? Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > After moving maven goals catalina:base-shared and catalina:shared > from maven.xml to portal/maven.xml and shutdown, redeploy, startup > I > finally got something with J2 under Tomcat 4.1.24 -- the logo! > That's > it, just the logo. No login, nothing else. Checking the log I see > this error: > > Capability Valve Invoked > *** Getting portlet from registry: LoginPortlet > org.apache.jetspeed.exception.JetspeedException: Failed to load: > LoginPortlet from registry > at > org.apache.jetspeed.aggregator.BasicAggregator.build(BasicAggregator.java:191) > at > org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:84) > at > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > at > org.apache.jetspeed.pipeline.valve.impl.VerySimpleLayoutValveImpl.invoke(VerySimpleLayoutValveImpl.java:137) > at > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > at > org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:132) > at > org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) > at > org.apache.jetspeed.services.profiler.ProfilerValve.invoke(ProfilerValve.java:90) > > Still investigating... > > Gerry Reno > > > > --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > > On Tuesday, November 18, 2003, at 03:23 PM, Gerry Reno wrote: > > > > > Here are some of my observations trying to get JS2 running: > > > > > > I have two Tomcat installations: > > > jakarta-tomcat-4.1.24 > > > jakarta-tomcat-5.0.14 > > > > > > Pluto: > > > Pluto gets the following error when trying to run under Tomcat > > > 4.1.24: > > > > > > > > > > > > > Jetspeed-2: > > > Jetspeed-2 builds without error under Maven and deploys ok but > > won't > > > run under Tomcat 4.1.24 (probably because pluto won't run). > > > > > > Jetspeed-2 builds without error under Maven and deploys ok but > > won't > > > run under Tomcat 5.0.14 due to a double initialization error (see > > > below) which I have not been able to stop from happening. > > > > > J2 has a login portlet dependent on Tomcat 4 security. It fails in > > Tomcat 5 > > Besides that J2, what little of it there is to see, runs fine on > > Tomcat > > 5 > > > > > > > > All my other webapps of which I have about 30, many jetspeed-1 > > based, > > > run fine under both versions of Tomcat. Insights would be > welcome. > > > > > The simple Pluto portal environment has had conflicts with > Jetspeed-2 > > > > in the Tomcat shared/lib directory. > > Its been a while since I've toyed with the pluto portal, it may > still > > > > be a problem. > > Recommend cleaning out either Pluto or J2 from the shared/lib > > directory > > before using the other > > > > -- > > David Sean Taylor > > Bluesunrise Software > > [EMAIL PROTECTED] > > +01 707 773-4646 > > +01 707 529 9194 > > +44 (0)79 8538 6471 > > > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IFrame-Portlet with state?
Kai, Within the iframe itself you could maintain a session as long as no one reloaded the page that contained the iframe. The problem we have now is mainly with the portlet control icons causing page reloads that destroy the context of things like iframes. Within a limited set of webapps, you can attempt to maintain state through using cookies and other methods but overall it would be best if all of this portlet control stuff were performed on the client and just a notification sent to the server to inform it of what the current portlet state is. That way there would not be any destruction of the state for things like iframe portlets and you wouldn't lose your place in your portlet ecommerce session, your mainframe remote logon session or your place in your multimedia or video presentation. Gerry Reno --- Kai Grossjohann <[EMAIL PROTECTED]> wrote: > Gerry Reno <[EMAIL PROTECTED]> writes: > > > And what do you do when people have cookies turned off as many do? > > I hang my head in shame. > > I know that this is a problem. But maybe companies' intranet > applications can require a bit more from the web browsers than other > websites. > > If you write down what the user interface looks like that we have, > then you get a pretty good list of things not to do in web > applications. But what can I do? I try to argue as well as I can. > > For example, the belief prevails that a web application can find out > how wide in pixels is a certain string on the client: in the CSS file > you specify that you want to use the foo font in the bar size, and > then you can compute on the server side how wide is the string. > 'Nuff > said. > > > And how does a cookie help with an interactive remote logon session > to > > say a mainframe or to a multimedia presentation, etc., etc. > > If the logon session is represented by an object in the HTTP session > (in our case it is), and if you have access to the HTTP session, then > Bob's your uncle. No? > > Kai > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2 install problems
After moving maven goals catalina:base-shared and catalina:shared from maven.xml to portal/maven.xml and shutdown, redeploy, startup I finally got something with J2 under Tomcat 4.1.24 -- the logo! That's it, just the logo. No login, nothing else. Checking the log I see this error: Capability Valve Invoked *** Getting portlet from registry: LoginPortlet org.apache.jetspeed.exception.JetspeedException: Failed to load: LoginPortlet from registry at org.apache.jetspeed.aggregator.BasicAggregator.build(BasicAggregator.java:191) at org.apache.jetspeed.aggregator.AggregatorValve.invoke(AggregatorValve.java:84) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) at org.apache.jetspeed.pipeline.valve.impl.VerySimpleLayoutValveImpl.invoke(VerySimpleLayoutValveImpl.java:137) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) at org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:132) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:293) at org.apache.jetspeed.services.profiler.ProfilerValve.invoke(ProfilerValve.java:90) Still investigating... Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Tuesday, November 18, 2003, at 03:23 PM, Gerry Reno wrote: > > > Here are some of my observations trying to get JS2 running: > > > > I have two Tomcat installations: > > jakarta-tomcat-4.1.24 > > jakarta-tomcat-5.0.14 > > > > Pluto: > > Pluto gets the following error when trying to run under Tomcat > > 4.1.24: > > > > > > > > Jetspeed-2: > > Jetspeed-2 builds without error under Maven and deploys ok but > won't > > run under Tomcat 4.1.24 (probably because pluto won't run). > > > > Jetspeed-2 builds without error under Maven and deploys ok but > won't > > run under Tomcat 5.0.14 due to a double initialization error (see > > below) which I have not been able to stop from happening. > > > J2 has a login portlet dependent on Tomcat 4 security. It fails in > Tomcat 5 > Besides that J2, what little of it there is to see, runs fine on > Tomcat > 5 > > > > > All my other webapps of which I have about 30, many jetspeed-1 > based, > > run fine under both versions of Tomcat. Insights would be welcome. > > > The simple Pluto portal environment has had conflicts with Jetspeed-2 > > in the Tomcat shared/lib directory. > Its been a while since I've toyed with the pluto portal, it may still > > be a problem. > Recommend cleaning out either Pluto or J2 from the shared/lib > directory > before using the other > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > +01 707 773-4646 > +01 707 529 9194 > +44 (0)79 8538 6471 > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.5 dev demo
--- Jun Yang <[EMAIL PROTECTED]> wrote: > Gerry Reno wrote: > > > Ok, I like the drag and drop customizer although for me I would > drag > >and drop but the portlet would move right back to its original > >position. > > > Make sure you drag it over a "sink" while lights up in red when your > mouse cursor is over it. > > Jun Tried this is both Mozilla 1.2.1 on Linux and in Mozilla Firebird 0.7 on Windows and in both I can drag the portlet all over and nowhere does it light up red or anything and when I drop it anywhere it always returns to its original position. Gerry Reno > > > On the stock portlet, I would like to see a timestamp of > >some kind and something that could say something like "at > : > >quotes delayed XX minutes". > > > >Gerry Reno > > > >BTW, Mozilla Firebird rules. Best browser I've seen yet. > > > > > >--- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > > > >>On Tuesday, November 18, 2003, at 09:59 AM, Gerry Reno wrote: > >> > >> > >> > >>> Is there anything in particular that we should try out? I'm > >>> > >>> > >>going to > >> > >> > >>>take a look. > >>> > >>> > >>> > >>drag and drop customizer and delay rendering sample portlet "Delay > >>render Stock Portlet" > >> > >> > >> > >>- > >>To unsubscribe, e-mail: > [EMAIL PROTECTED] > >>For additional commands, e-mail: > >>[EMAIL PROTECTED] > >> > >> > >> > > > > > >= > >Gerry Reno > >mailto: grenoml at@ yahoo dot. com > >(if mail bounces please retry later - spam rapidly fills up mailbox) > > > >__ > >Do you Yahoo!? > >Protect your identity with Yahoo! Mail AddressGuard > >http://antispam.yahoo.com/whatsnewfree > > > >- > >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] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.5 dev demo
Like the parent and alphabet filtering. Gerry Reno --- Jeremy Ford <[EMAIL PROTECTED]> wrote: > Other recent additions include: > > 1) Ability to filter by parents when adding portlets to the psml > 2) Filtering support for the registry browsers. Currently, the > Portlet > Browser is the only one that uses it > 3) New alphabet navigation for the registry browsers as well as when > adding > portlets to the psml. > > Jeremy Ford > > -Original Message- > From: Gerry Reno [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 12:00 PM > To: Jetspeed Users List > Subject: Re: 1.5 dev demo > > Is there anything in particular that we should try out? I'm going > to > take a look. > > Gerry Reno > > --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > I installed a 1.5-dev demo at www.bluesunrise.com/jetspeed for you > > all > > to try out. > > To my disappointment, the drag and drop customizer doesn't work on > > Safari :-( > > And it crashes on IE 6 :-( > > Oh well > > > > if anyone had an account that they were actually using there, let > me > > know and I'll restore it. > > There were a few thousand accounts > > > > Please could you all refrain from changing the turbine and admin > > passwords? > > I don't know if you realize, but if you change the password, how > can > > others demo the system? > > > > I've noticed that "Create New Account" feature is no longer enabled > > as > > default. > > So if you change the two default account passwords, then it ruins > the > > > > demo for everyone else. > > > > > > -- > > David Sean Taylor > > Bluesunrise Software > > [EMAIL PROTECTED] > > +01 707 773-4646 > > +01 707 529 9194 > > +44 (0)79 8538 6471 > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > - > 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] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.5 dev demo
Ok, I like the drag and drop customizer although for me I would drag and drop but the portlet would move right back to its original position. On the stock portlet, I would like to see a timestamp of some kind and something that could say something like "at : quotes delayed XX minutes". Gerry Reno BTW, Mozilla Firebird rules. Best browser I've seen yet. --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Tuesday, November 18, 2003, at 09:59 AM, Gerry Reno wrote: > > > Is there anything in particular that we should try out? I'm > going to > > take a look. > > > drag and drop customizer and delay rendering sample portlet "Delay > render Stock Portlet" > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.5 dev demo
Is there anything in particular that we should try out? I'm going to take a look. Gerry Reno --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > I installed a 1.5-dev demo at www.bluesunrise.com/jetspeed for you > all > to try out. > To my disappointment, the drag and drop customizer doesn't work on > Safari :-( > And it crashes on IE 6 :-( > Oh well > > if anyone had an account that they were actually using there, let me > know and I'll restore it. > There were a few thousand accounts > > Please could you all refrain from changing the turbine and admin > passwords? > I don't know if you realize, but if you change the password, how can > others demo the system? > > I've noticed that "Create New Account" feature is no longer enabled > as > default. > So if you change the two default account passwords, then it ruins the > > demo for everyone else. > > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > +01 707 773-4646 > +01 707 529 9194 > +44 (0)79 8538 6471 > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
J2: maven goals
The catalina:shared and catalina-base:shared goals currently are a dependency of allBuild. Shouldn't these really be a dependency of the 'deploy' goal? In fact, I noticed that when trying to switch between Tomcat versions and redeploy to the new version that jars were missing in shared/lib because there was no dependency goals of 'deploy' to put them there. Gerry Reno = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed-2 install problems
Here are some of my observations trying to get JS2 running: I have two Tomcat installations: jakarta-tomcat-4.1.24 jakarta-tomcat-5.0.14 Pluto: Pluto gets the following error when trying to run under Tomcat 4.1.24: 2003-11-18 10:04:47 ServiceManager: An unidentified error occurred org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'portlet-app'. at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) at org.apache.pluto.portalImpl.xml.XmlParser.parsePortletXml(XmlParser.java:96) at org.apache.pluto.portalImpl.services.portletdefinitionregistry.PortletDefinitionRegistryServiceFileImpl.load(PortletDefinitionRegistryServiceFileImpl.java:211) at org.apache.pluto.portalImpl.services.portletdefinitionregistry.PortletDefinitionRegistryServiceFileImpl.load(PortletDefinitionRegistryServiceFileImpl.java:189) at org.apache.pluto.portalImpl.services.portletdefinitionregistry.PortletDefinitionRegistryServiceFileImpl.init(PortletDefinitionRegistryServiceFileImpl.java:165) at org.apache.pluto.portalImpl.services.ServiceManager.init(ServiceManager.java:250) ... javax.servlet.UnavailableException: Initialization of one or more services failed. at org.apache.pluto.portalImpl.Servlet.init(Servlet.java:111) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) 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.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:2415) 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:172) 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:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:534) Same pluto: Pluto installs and runs fine under Tomcat 5.0.14 Jetspeed-2: Jetspeed-2 builds without error under Maven and deploys ok but won't run under Tomcat 4.1.24 (probably because pluto won't run). Jetspeed-2 builds without error under Maven and deploys ok but won't run under Tomcat 5.0.14 due to a double initialization error (see below) which I have not been able to stop from happening. All my other webapps of which I have about 30, many jetspeed-1 based, run fine under both versions of Tomcat. Insights would be welcome. thx, Gerry Reno Env: RH Linux 8.0 java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Tomcats: 4.1.24, 5.0.14 --- Gerry Reno <[
Re: IFrame-Portlet with state?
Kai, And what do you do when people have cookies turned off as many do? And how does a cookie help with an interactive remote logon session to say a mainframe or to a multimedia presentation, etc., etc. Gerry Reno --- Kai Grossjohann <[EMAIL PROTECTED]> wrote: > In the past, I thought that interactive iframe-portlets don't make > sense because the portal always loads the same URL into the iframe, > whenever the user clicks outside the iframe. > > But preliminary experiments appear to show that it can sometimes > work: > if the stuff inside the iframe is a web application which keeps the > session via cookies, then the cookie will be retransmitted to the > inside of the iframe on page reload. > > So this appears to imply that the web app inside the iframe just > needs > to have a URL which is sure to regenerate the current state based on > the HTTP session, and then Bob's my uncle. > > Right? > > Thoughts? Comments? Ideas? > > Kai > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed-2 install problems
Ok, seems like I'm past the Zip error problem. Ran into the next
problem which is:
Nov 13, 2003 2:51:32 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Jetspeed Starting Initialization...
Nov 13, 2003 2:51:32 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Double initialization of Jetspeed was attempted!
Nov 13, 2003 2:51:32 PM org.apache.jetspeed.engine.JetspeedServlet init
INFO: Double initialization of Jetspeed was attempted!
javax.management.ReflectionException: The MBean class could not be
loaded by the context classloader
at
com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.loadClass(MBeanInstantiatorImpl.java:444)
at
com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClass(MBeanInstantiatorImpl.java:80)
What is this double initialization? How can I fix this?
(As a side note I can't get /pluto/portal to work now)
Gerry Reno
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> It appears that there is a copy of the bad jar here:
>
.../jakarta-jetspeed-2/portal/target/jetspeed/WEB-INF/lib/xalan-2.4.1.jar
> I'm removing it and we'll see what happens...
>
> --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > Ok, deleted the jar in the repository and maven then downloaded a
> new
> > jar (which is not corrupt) into the repository. So I thought
> > everything would be fine. But when I run maven allBuild it
> downloads
> > the new jar and reports BUILD SUCCESSFUL. I then cd portal and run
> > maven deploy and pam.deploy. I bring up Tomcat and try to access
> the
> > portal. No luck. Check the logs and I still see the Zip error. I
> > check .../jetspeed/WEB-INF/lib/xalan-2.4.1.jar and it is corrupt!
> It
> > is still the previous jar. Is maven caching this jar someplace? I
> > ran
> > maven clean to see if that might help and then rebuilt and deployed
> > again. Still get the zip error. The offending jar looks like
> this:
> > -rw-r--r--1 root root 296053 Nov 8 00:15
> > xalan-2.4.1.jar
> >
> > Gerry Reno
> >
> >
> > --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > > Scott,
> > > Sorry about that, I wasn't looking in dot directories - Yes, I
> do
> > > have a xalan-2.4.1.jar located in
> > > ${USER_HOME}/.maven/repository/xalan/jars and it too is corrupt.
> > It
> > > is
> > > dated Nov 8th 00:08. That must have been when maven loaded it in
> > > here
> > > the first time. Can I just delete this jar from the repository
> > area
> > > and then will maven go out and download another one?
> > >
> > > Gerry
> > >
> > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote:
> > > > Hi Gerry,
> > > >
> > > > > Where is maven sourcing this jar from? I don't have a
> > > > xalan-2.4.1.jar
> > > > > anywhere else on my system.
> > > >
> > > > If a jar is not on your system, maven will attempt to download
> it
> > > to
> > > > your local repository from the remote repository server, which
> > > > defaults to www.ibiblio.com/maven.
> > > >
> > > > The xalan jar, once downloaded, should be located in your
> > > > ${USER_HOME}/.maven/repository/xalan/jars.
> > > >
> > > > If you need a copy of xalan-2.4.1.jar, I would be more than
> happy
> > > > send you the one that I use which isn't corrupt. All you would
> > > have
> > > > to do then is drop it in the location specified above. Maven
> > will
> > > > not try to download a jar that already is present locally.
> > > >
> > > > Regards,
> > > > **
> > > > | Scott T Weaver |
> > > > | <[EMAIL PROTECTED]>|
> > > > | Apache Jetspeed Portal Project |
> > > > | Apache Pluto Portlet Container |
> > > > **
> > > >
> > > > > -Original Message-
> > > > > From: Gerry Reno [mailto:[EMAIL PROTECTED]
> > > > > Sent: Thursday, November 13, 2003 1:35 PM
> > > > > To: Jetspeed Users List
> > > > > Subject: Re: Jetspeed-2 install problems
> > > > >
> > > > >Ok, did another resync with the HEAD and then ran maven
> > > allBuild
> > > > > again. This time it says BUILD SUCESSFUL. Ran maven deploy
> > and
> > > > > pam.deploy. Both worked. But when I try to run /jetspeed
> I'm
&g
RE: Jetspeed-2 install problems
It appears that there is a copy of the bad jar here:
.../jakarta-jetspeed-2/portal/target/jetspeed/WEB-INF/lib/xalan-2.4.1.jar
I'm removing it and we'll see what happens...
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> Ok, deleted the jar in the repository and maven then downloaded a new
> jar (which is not corrupt) into the repository. So I thought
> everything would be fine. But when I run maven allBuild it downloads
> the new jar and reports BUILD SUCCESSFUL. I then cd portal and run
> maven deploy and pam.deploy. I bring up Tomcat and try to access the
> portal. No luck. Check the logs and I still see the Zip error. I
> check .../jetspeed/WEB-INF/lib/xalan-2.4.1.jar and it is corrupt! It
> is still the previous jar. Is maven caching this jar someplace? I
> ran
> maven clean to see if that might help and then rebuilt and deployed
> again. Still get the zip error. The offending jar looks like this:
> -rw-r--r--1 root root 296053 Nov 8 00:15
> xalan-2.4.1.jar
>
> Gerry Reno
>
>
> --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > Scott,
> > Sorry about that, I wasn't looking in dot directories - Yes, I do
> > have a xalan-2.4.1.jar located in
> > ${USER_HOME}/.maven/repository/xalan/jars and it too is corrupt.
> It
> > is
> > dated Nov 8th 00:08. That must have been when maven loaded it in
> > here
> > the first time. Can I just delete this jar from the repository
> area
> > and then will maven go out and download another one?
> >
> > Gerry
> >
> > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote:
> > > Hi Gerry,
> > >
> > > > Where is maven sourcing this jar from? I don't have a
> > > xalan-2.4.1.jar
> > > > anywhere else on my system.
> > >
> > > If a jar is not on your system, maven will attempt to download it
> > to
> > > your local repository from the remote repository server, which
> > > defaults to www.ibiblio.com/maven.
> > >
> > > The xalan jar, once downloaded, should be located in your
> > > ${USER_HOME}/.maven/repository/xalan/jars.
> > >
> > > If you need a copy of xalan-2.4.1.jar, I would be more than happy
> > > send you the one that I use which isn't corrupt. All you would
> > have
> > > to do then is drop it in the location specified above. Maven
> will
> > > not try to download a jar that already is present locally.
> > >
> > > Regards,
> > > **
> > > | Scott T Weaver |
> > > | <[EMAIL PROTECTED]>|
> > > | Apache Jetspeed Portal Project |
> > > | Apache Pluto Portlet Container |
> > > **
> > >
> > > > -Original Message-
> > > > From: Gerry Reno [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, November 13, 2003 1:35 PM
> > > > To: Jetspeed Users List
> > > > Subject: Re: Jetspeed-2 install problems
> > > >
> > > >Ok, did another resync with the HEAD and then ran maven
> > allBuild
> > > > again. This time it says BUILD SUCESSFUL. Ran maven deploy
> and
> > > > pam.deploy. Both worked. But when I try to run /jetspeed I'm
> > > still
> > > > getting the error about the zipfile:
> > > >
> > > > Nov 13, 2003 1:07:24 PM
> > > org.apache.catalina.core.StandardHostDeployer
> > > > install
> > > > INFO: Installing web application at context path /jetspeed from
> > URL
> > > > file:/usr/local/jakarta-tomcat/webapps/jetspeed
> > > > java.util.zip.ZipException: error in opening zip file
> > > > at java.util.zip.ZipFile.open(Native Method)
> > > > at java.util.zip.ZipFile.(ZipFile.java:112)
> > > > at java.util.jar.JarFile.(JarFile.java:127)
> > > > at java.util.jar.JarFile.(JarFile.java:92)
> > > >
> > > > I checked the xalan-2.4.1.jar in WEB-INF/lib and sure enough
> it's
> > > > corrupt again:
> > > >
> > > > Ran jar -tf xalan-2.4.1.jar and saw this:
> > > > ...
> > > > org/apache/xalan/templates/ElemParam.class
> > > > org/apache/xalan/templates/ElemPI.class
> > > > java.io.EOFException: Unexpected end of ZLIB input stream
> > > > at
> > > >
> > >
> >
> java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:21
RE: Jetspeed-2 install problems
Ok, deleted the jar in the repository and maven then downloaded a new
jar (which is not corrupt) into the repository. So I thought
everything would be fine. But when I run maven allBuild it downloads
the new jar and reports BUILD SUCCESSFUL. I then cd portal and run
maven deploy and pam.deploy. I bring up Tomcat and try to access the
portal. No luck. Check the logs and I still see the Zip error. I
check .../jetspeed/WEB-INF/lib/xalan-2.4.1.jar and it is corrupt! It
is still the previous jar. Is maven caching this jar someplace? I ran
maven clean to see if that might help and then rebuilt and deployed
again. Still get the zip error. The offending jar looks like this:
-rw-r--r--1 root root 296053 Nov 8 00:15 xalan-2.4.1.jar
Gerry Reno
--- Gerry Reno <[EMAIL PROTECTED]> wrote:
> Scott,
> Sorry about that, I wasn't looking in dot directories - Yes, I do
> have a xalan-2.4.1.jar located in
> ${USER_HOME}/.maven/repository/xalan/jars and it too is corrupt. It
> is
> dated Nov 8th 00:08. That must have been when maven loaded it in
> here
> the first time. Can I just delete this jar from the repository area
> and then will maven go out and download another one?
>
> Gerry
>
> --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote:
> > Hi Gerry,
> >
> > > Where is maven sourcing this jar from? I don't have a
> > xalan-2.4.1.jar
> > > anywhere else on my system.
> >
> > If a jar is not on your system, maven will attempt to download it
> to
> > your local repository from the remote repository server, which
> > defaults to www.ibiblio.com/maven.
> >
> > The xalan jar, once downloaded, should be located in your
> > ${USER_HOME}/.maven/repository/xalan/jars.
> >
> > If you need a copy of xalan-2.4.1.jar, I would be more than happy
> > send you the one that I use which isn't corrupt. All you would
> have
> > to do then is drop it in the location specified above. Maven will
> > not try to download a jar that already is present locally.
> >
> > Regards,
> > **
> > | Scott T Weaver |
> > | <[EMAIL PROTECTED]>|
> > | Apache Jetspeed Portal Project |
> > | Apache Pluto Portlet Container |
> > **
> >
> > > -Original Message-
> > > From: Gerry Reno [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, November 13, 2003 1:35 PM
> > > To: Jetspeed Users List
> > > Subject: Re: Jetspeed-2 install problems
> > >
> > >Ok, did another resync with the HEAD and then ran maven
> allBuild
> > > again. This time it says BUILD SUCESSFUL. Ran maven deploy and
> > > pam.deploy. Both worked. But when I try to run /jetspeed I'm
> > still
> > > getting the error about the zipfile:
> > >
> > > Nov 13, 2003 1:07:24 PM
> > org.apache.catalina.core.StandardHostDeployer
> > > install
> > > INFO: Installing web application at context path /jetspeed from
> URL
> > > file:/usr/local/jakarta-tomcat/webapps/jetspeed
> > > java.util.zip.ZipException: error in opening zip file
> > > at java.util.zip.ZipFile.open(Native Method)
> > > at java.util.zip.ZipFile.(ZipFile.java:112)
> > > at java.util.jar.JarFile.(JarFile.java:127)
> > > at java.util.jar.JarFile.(JarFile.java:92)
> > >
> > > I checked the xalan-2.4.1.jar in WEB-INF/lib and sure enough it's
> > > corrupt again:
> > >
> > > Ran jar -tf xalan-2.4.1.jar and saw this:
> > > ...
> > > org/apache/xalan/templates/ElemParam.class
> > > org/apache/xalan/templates/ElemPI.class
> > > java.io.EOFException: Unexpected end of ZLIB input stream
> > > at
> > >
> >
> java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215)
> > > at
> > >
> >
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> > > at
> > java.util.zip.ZipInputStream.read(ZipInputStream.java:139)
> > > at
> > > java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:91)
> > > at sun.tools.jar.Main.list(Main.java:744)
> > > at sun.tools.jar.Main.run(Main.java:192)
> > > at sun.tools.jar.Main.main(Main.java:904)
> > >
> > > Where is maven sourcing this jar from? I don't have a
> > xalan-2.4.1.jar
> > > anywhere else on my system.
> > >
> > > Gerry Reno
> > >
> > >
>
RE: Jetspeed-2 install problems
Scott,
Sorry about that, I wasn't looking in dot directories - Yes, I do
have a xalan-2.4.1.jar located in
${USER_HOME}/.maven/repository/xalan/jars and it too is corrupt. It is
dated Nov 8th 00:08. That must have been when maven loaded it in here
the first time. Can I just delete this jar from the repository area
and then will maven go out and download another one?
Gerry
--- "Weaver, Scott" <[EMAIL PROTECTED]> wrote:
> Hi Gerry,
>
> > Where is maven sourcing this jar from? I don't have a
> xalan-2.4.1.jar
> > anywhere else on my system.
>
> If a jar is not on your system, maven will attempt to download it to
> your local repository from the remote repository server, which
> defaults to www.ibiblio.com/maven.
>
> The xalan jar, once downloaded, should be located in your
> ${USER_HOME}/.maven/repository/xalan/jars.
>
> If you need a copy of xalan-2.4.1.jar, I would be more than happy
> send you the one that I use which isn't corrupt. All you would have
> to do then is drop it in the location specified above. Maven will
> not try to download a jar that already is present locally.
>
> Regards,
> **
> | Scott T Weaver |
> | <[EMAIL PROTECTED]>|
> | Apache Jetspeed Portal Project |
> | Apache Pluto Portlet Container |
> **
>
> > -Original Message-
> > From: Gerry Reno [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, November 13, 2003 1:35 PM
> > To: Jetspeed Users List
> > Subject: Re: Jetspeed-2 install problems
> >
> >Ok, did another resync with the HEAD and then ran maven allBuild
> > again. This time it says BUILD SUCESSFUL. Ran maven deploy and
> > pam.deploy. Both worked. But when I try to run /jetspeed I'm
> still
> > getting the error about the zipfile:
> >
> > Nov 13, 2003 1:07:24 PM
> org.apache.catalina.core.StandardHostDeployer
> > install
> > INFO: Installing web application at context path /jetspeed from URL
> > file:/usr/local/jakarta-tomcat/webapps/jetspeed
> > java.util.zip.ZipException: error in opening zip file
> > at java.util.zip.ZipFile.open(Native Method)
> > at java.util.zip.ZipFile.(ZipFile.java:112)
> > at java.util.jar.JarFile.(JarFile.java:127)
> > at java.util.jar.JarFile.(JarFile.java:92)
> >
> > I checked the xalan-2.4.1.jar in WEB-INF/lib and sure enough it's
> > corrupt again:
> >
> > Ran jar -tf xalan-2.4.1.jar and saw this:
> > ...
> > org/apache/xalan/templates/ElemParam.class
> > org/apache/xalan/templates/ElemPI.class
> > java.io.EOFException: Unexpected end of ZLIB input stream
> > at
> >
> java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215)
> > at
> >
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
> > at
> java.util.zip.ZipInputStream.read(ZipInputStream.java:139)
> > at
> > java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:91)
> > at sun.tools.jar.Main.list(Main.java:744)
> > at sun.tools.jar.Main.run(Main.java:192)
> > at sun.tools.jar.Main.main(Main.java:904)
> >
> > Where is maven sourcing this jar from? I don't have a
> xalan-2.4.1.jar
> > anywhere else on my system.
> >
> > Gerry Reno
> >
> >
> >
> >
> > --- Gerry Reno <[EMAIL PROTECTED]> wrote:
> > > That's exactly the document that I am following.
> > >
> > > I'll give it another try this afternoon.
> > >
> > > --- Roger Ruttimann <[EMAIL PROTECTED]> wrote:
> > > > Please follow all steps in the /doc/Getting-Started.htm
> document.
> > > > It seems that some of your dependencies are not correct.
> > > >
> > > > Roger
> > > >
> > > > -Original Message-
> > > > From: Gerry Reno <[EMAIL PROTECTED]>
> > > > Sent: Nov 12, 2003 7:55 PM
> > > > To: Jetspeed Users List <[EMAIL PROTECTED]>
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: Jetspeed-2 install problems
> > > >
> > > > I resynced with the HEAD and now when I run maven allBuild I'm
> > > seeing
> > > > other errors:
> > > >
> > > > BUILD FAILED
> > > > File..
> > > > file:/home/greno/projects/workspace/jakarta-jetspeed-2/portal/
> > > > Element... copy
> > > > Line.. 105
> > > > Column
Re: Jetspeed-2 install problems
Ok, did another resync with the HEAD and then ran maven allBuild again. This time it says BUILD SUCESSFUL. Ran maven deploy and pam.deploy. Both worked. But when I try to run /jetspeed I'm still getting the error about the zipfile: Nov 13, 2003 1:07:24 PM org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /jetspeed from URL file:/usr/local/jakarta-tomcat/webapps/jetspeed java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:112) at java.util.jar.JarFile.(JarFile.java:127) at java.util.jar.JarFile.(JarFile.java:92) I checked the xalan-2.4.1.jar in WEB-INF/lib and sure enough it's corrupt again: Ran jar -tf xalan-2.4.1.jar and saw this: ... org/apache/xalan/templates/ElemParam.class org/apache/xalan/templates/ElemPI.class java.io.EOFException: Unexpected end of ZLIB input stream at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134) at java.util.zip.ZipInputStream.read(ZipInputStream.java:139) at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:91) at sun.tools.jar.Main.list(Main.java:744) at sun.tools.jar.Main.run(Main.java:192) at sun.tools.jar.Main.main(Main.java:904) Where is maven sourcing this jar from? I don't have a xalan-2.4.1.jar anywhere else on my system. Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > That's exactly the document that I am following. > > I'll give it another try this afternoon. > > --- Roger Ruttimann <[EMAIL PROTECTED]> wrote: > > Please follow all steps in the /doc/Getting-Started.htm document. > > It seems that some of your dependencies are not correct. > > > > Roger > > > > -Original Message- > > From: Gerry Reno <[EMAIL PROTECTED]> > > Sent: Nov 12, 2003 7:55 PM > > To: Jetspeed Users List <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: Jetspeed-2 install problems > > > > I resynced with the HEAD and now when I run maven allBuild I'm > seeing > > other errors: > > > > BUILD FAILED > > File.. > > file:/home/greno/projects/workspace/jakarta-jetspeed-2/portal/ > > Element... copy > > Line.. 105 > > Column 97 > > Warning: Could not find file > > > /home/greno/projects/workspace/jakarta-jetspeed-2/portal/commons/target/jetspeed-commons-2.0-a1-dev.jar > > to copy. > > Total time: 3 seconds > > Finished at: Wed Nov 12 22:40:48 EST 2003 > > > > I looked under .../jakarta-jetspeed-2/portal and there isn't even a > > commons directory. > > There's a commons under .../jakarta-jetspeed-2. > > > > I'll try again tomorrow. > > > > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > > Hi Scott, > > > No, it's not. Do I need to manually copy it there? Where > should > > I > > > go to get the correct commons-configuration jar? Shouldn't Maven > > > have > > > taken care of this dependency? > > > > > > rgds, > > > Gerry > > > > > > > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > > > Is the commons-configuration jar in your > $TOMCAT_HOME/shared/lib > > > > directory? > > > > > > > > Regards, > > > > ** > > > > | Scott T Weaver | > > > > | <[EMAIL PROTECTED]>| > > > > | Apache Jetspeed Portal Project | > > > > | Apache Pluto Portlet Container | > > > > ** > > > > > > > > > > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Installed Pluto - runs fine. > > > > > Checked out Jetspeed-2 from CVS and built and deployed it > using > > > > maven > > > > > (maven allBuild deploy pam.deploy) but it will not start. > > > > > Maven said everything built successful with no errors. > > > > > > > > > > First startup error received was: > > > > > 2003-11-08 12:06:26 ContextConfig[/jetspeed] Exception > > processing > > > > JAR > > > > > at resource path /WEB-INF/lib/xalan-2.4.1.jar > > > > > javax.servlet.ServletException: Exception processing JAR at > > > > resource > > > > > path /WEB
Re: Jetspeed-2 install problems
That's exactly the document that I am following. I'll give it another try this afternoon. --- Roger Ruttimann <[EMAIL PROTECTED]> wrote: > Please follow all steps in the /doc/Getting-Started.htm document. > It seems that some of your dependencies are not correct. > > Roger > > -Original Message- > From: Gerry Reno <[EMAIL PROTECTED]> > Sent: Nov 12, 2003 7:55 PM > To: Jetspeed Users List <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: Jetspeed-2 install problems > > I resynced with the HEAD and now when I run maven allBuild I'm seeing > other errors: > > BUILD FAILED > File.. > file:/home/greno/projects/workspace/jakarta-jetspeed-2/portal/ > Element... copy > Line.. 105 > Column 97 > Warning: Could not find file > /home/greno/projects/workspace/jakarta-jetspeed-2/portal/commons/target/jetspeed-commons-2.0-a1-dev.jar > to copy. > Total time: 3 seconds > Finished at: Wed Nov 12 22:40:48 EST 2003 > > I looked under .../jakarta-jetspeed-2/portal and there isn't even a > commons directory. > There's a commons under .../jakarta-jetspeed-2. > > I'll try again tomorrow. > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > Hi Scott, > > No, it's not. Do I need to manually copy it there? Where should > I > > go to get the correct commons-configuration jar? Shouldn't Maven > > have > > taken care of this dependency? > > > > rgds, > > Gerry > > > > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > > Is the commons-configuration jar in your $TOMCAT_HOME/shared/lib > > > directory? > > > > > > Regards, > > > ** > > > | Scott T Weaver | > > > | <[EMAIL PROTECTED]>| > > > | Apache Jetspeed Portal Project | > > > | Apache Pluto Portlet Container | > > > ** > > > > > > > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > > > > > > > Installed Pluto - runs fine. > > > > Checked out Jetspeed-2 from CVS and built and deployed it using > > > maven > > > > (maven allBuild deploy pam.deploy) but it will not start. > > > > Maven said everything built successful with no errors. > > > > > > > > First startup error received was: > > > > 2003-11-08 12:06:26 ContextConfig[/jetspeed] Exception > processing > > > JAR > > > > at resource path /WEB-INF/lib/xalan-2.4.1.jar > > > > javax.servlet.ServletException: Exception processing JAR at > > > resource > > > > path /WEB-INF/lib/xalan-2.4.1.jar > > > > at > > > > > > > > > > org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) > > > > at > > > > > > > > > > org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) > > > > at > > > > > > > > > > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) > > > > at > > > > > > > > > > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) > > > > ... > > > > - Root Cause - > > > > java.util.zip.ZipException: error in opening zip file > > > > at java.util.zip.ZipFile.open(Native Method) > > > > at java.util.zip.ZipFile.(ZipFile.java:112) > > > > at java.util.jar.JarFile.(JarFile.java:127) > > > > at > > > > sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:51) > > > > at > > > > sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:178) > > > > > > > > The problem is that the xalan-2.4.1.jar in WEB-INF/lib is > > corrupt. > > > > When I try to list it from the command line (jar -tvf > > > > xalan-2.4.1.jar) > > > > it shows this error: > > > > > > > > ... > > > > 21920 Thu Oct 31 14:22:02 EST 2002 > > > > org/apache/xalan/templates/ElemNumber.class > > > >538 Thu Oct 31 14:22:04 EST 2002 > > > > org/apache/xalan/templates/ElemOtherwise.class > > > > 2808 Thu Oct 31 14:22:00 EST 2002 > > > > org/apache/xalan/templates/ElemParam.class > > > > 4026 Thu Oct 31 14:22:04 EST 2002 > > > > org/apache/xalan/templates/ElemPI.class >
Re: Jetspeed-2 install problems
I resynced with the HEAD and now when I run maven allBuild I'm seeing other errors: BUILD FAILED File.. file:/home/greno/projects/workspace/jakarta-jetspeed-2/portal/ Element... copy Line.. 105 Column 97 Warning: Could not find file /home/greno/projects/workspace/jakarta-jetspeed-2/portal/commons/target/jetspeed-commons-2.0-a1-dev.jar to copy. Total time: 3 seconds Finished at: Wed Nov 12 22:40:48 EST 2003 I looked under .../jakarta-jetspeed-2/portal and there isn't even a commons directory. There's a commons under .../jakarta-jetspeed-2. I'll try again tomorrow. --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Hi Scott, > No, it's not. Do I need to manually copy it there? Where should I > go to get the correct commons-configuration jar? Shouldn't Maven > have > taken care of this dependency? > > rgds, > Gerry > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > Is the commons-configuration jar in your $TOMCAT_HOME/shared/lib > > directory? > > > > Regards, > > ** > > | Scott T Weaver | > > | <[EMAIL PROTECTED]>| > > | Apache Jetspeed Portal Project | > > | Apache Pluto Portlet Container | > > ** > > > > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > > > > > Installed Pluto - runs fine. > > > Checked out Jetspeed-2 from CVS and built and deployed it using > > maven > > > (maven allBuild deploy pam.deploy) but it will not start. > > > Maven said everything built successful with no errors. > > > > > > First startup error received was: > > > 2003-11-08 12:06:26 ContextConfig[/jetspeed] Exception processing > > JAR > > > at resource path /WEB-INF/lib/xalan-2.4.1.jar > > > javax.servlet.ServletException: Exception processing JAR at > > resource > > > path /WEB-INF/lib/xalan-2.4.1.jar > > > at > > > > > > org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) > > > at > > > > > > org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) > > > at > > > > > > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) > > > at > > > > > > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) > > > ... > > > - Root Cause - > > > java.util.zip.ZipException: error in opening zip file > > > at java.util.zip.ZipFile.open(Native Method) > > > at java.util.zip.ZipFile.(ZipFile.java:112) > > > at java.util.jar.JarFile.(JarFile.java:127) > > > at > > > sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:51) > > > at > > > sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:178) > > > > > > The problem is that the xalan-2.4.1.jar in WEB-INF/lib is > corrupt. > > > When I try to list it from the command line (jar -tvf > > > xalan-2.4.1.jar) > > > it shows this error: > > > > > > ... > > > 21920 Thu Oct 31 14:22:02 EST 2002 > > > org/apache/xalan/templates/ElemNumber.class > > >538 Thu Oct 31 14:22:04 EST 2002 > > > org/apache/xalan/templates/ElemOtherwise.class > > > 2808 Thu Oct 31 14:22:00 EST 2002 > > > org/apache/xalan/templates/ElemParam.class > > > 4026 Thu Oct 31 14:22:04 EST 2002 > > > org/apache/xalan/templates/ElemPI.class > > > java.io.EOFException: Unexpected end of ZLIB input stream > > > at > > > > > > java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215) > > > at > > > > > > java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134) > > > at > > java.util.zip.ZipInputStream.read(ZipInputStream.java:139) > > > at > > > java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:91) > > > at sun.tools.jar.Main.list(Main.java:744) > > > at sun.tools.jar.Main.run(Main.java:192) > > > at sun.tools.jar.Main.main(Main.java:904) > > > > > > > > > So I removed xalan-2.4.1.jar from WEB-INF/lib (let it rely on > > > xalan-2.5.1.jar in TC/common/endorsed) > > > > > > > > > Retried startup; next error: > > > ... > > > 2003-11-08 12:21:53 pluto: Initializing PortletContainer... > > >
Re: Jetspeed-2 install problems
Hi Scott, No, it's not. Do I need to manually copy it there? Where should I go to get the correct commons-configuration jar? Shouldn't Maven have taken care of this dependency? rgds, Gerry --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Is the commons-configuration jar in your $TOMCAT_HOME/shared/lib > directory? > > Regards, > ** > | Scott T Weaver | > | <[EMAIL PROTECTED]>| > | Apache Jetspeed Portal Project | > | Apache Pluto Portlet Container | > ** > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > > > Installed Pluto - runs fine. > > Checked out Jetspeed-2 from CVS and built and deployed it using > maven > > (maven allBuild deploy pam.deploy) but it will not start. > > Maven said everything built successful with no errors. > > > > First startup error received was: > > 2003-11-08 12:06:26 ContextConfig[/jetspeed] Exception processing > JAR > > at resource path /WEB-INF/lib/xalan-2.4.1.jar > > javax.servlet.ServletException: Exception processing JAR at > resource > > path /WEB-INF/lib/xalan-2.4.1.jar > > at > > > org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) > > at > > > org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) > > at > > > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) > > at > > > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) > > ... > > - Root Cause - > > java.util.zip.ZipException: error in opening zip file > > at java.util.zip.ZipFile.open(Native Method) > > at java.util.zip.ZipFile.(ZipFile.java:112) > > at java.util.jar.JarFile.(JarFile.java:127) > > at > > sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:51) > > at > > sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:178) > > > > The problem is that the xalan-2.4.1.jar in WEB-INF/lib is corrupt. > > When I try to list it from the command line (jar -tvf > > xalan-2.4.1.jar) > > it shows this error: > > > > ... > > 21920 Thu Oct 31 14:22:02 EST 2002 > > org/apache/xalan/templates/ElemNumber.class > >538 Thu Oct 31 14:22:04 EST 2002 > > org/apache/xalan/templates/ElemOtherwise.class > > 2808 Thu Oct 31 14:22:00 EST 2002 > > org/apache/xalan/templates/ElemParam.class > > 4026 Thu Oct 31 14:22:04 EST 2002 > > org/apache/xalan/templates/ElemPI.class > > java.io.EOFException: Unexpected end of ZLIB input stream > > at > > > java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215) > > at > > > java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134) > > at > java.util.zip.ZipInputStream.read(ZipInputStream.java:139) > > at > > java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:91) > > at sun.tools.jar.Main.list(Main.java:744) > > at sun.tools.jar.Main.run(Main.java:192) > > at sun.tools.jar.Main.main(Main.java:904) > > > > > > So I removed xalan-2.4.1.jar from WEB-INF/lib (let it rely on > > xalan-2.5.1.jar in TC/common/endorsed) > > > > > > Retried startup; next error: > > ... > > 2003-11-08 12:21:53 pluto: Initializing PortletContainer... > > 2003-11-08 12:21:53 pluto: Ready to serve you. > > 2003-11-08 12:22:05 ApplicationDispatcher[/jetspeed]: Servlet > > jetspeed > > is currently unavailable > > 2003-11-08 12:49:31 SessionListener: contextDestroyed() > > 2003-11-08 12:49:31 ContextListener: contextDestroyed() > > 2003-11-08 12:49:31 SessionListener: contextDestroyed() > > 2003-11-08 12:49:31 ContextListener: contextDestroyed() > > 2003-11-08 12:49:32 -- INFO -- Shutting down service: > > ResourceService > > 2003-11-08 12:49:32 -- INFO -- Turbine: Done shutting down! > > 2003-11-08 12:53:54 Marking servlet jetspeed as unavailable > > 2003-11-08 12:53:54 Servlet /jetspeed threw load() exception > > javax.servlet.ServletException: Error instantiating servlet class > > org.apache.jetspeed.engine.JetspeedServlet > > at > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1011) > > at > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:887) > > at > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:38
Jetspeed-2 install problems
Installed Pluto - runs fine. Checked out Jetspeed-2 from CVS and built and deployed it using maven (maven allBuild deploy pam.deploy) but it will not start. First error received was: 2003-11-08 12:06:26 ContextConfig[/jetspeed] Exception processing JAR at resource path /WEB-INF/lib/xalan-2.4.1.jar javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/xalan-2.4.1.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) ... - Root Cause - java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:112) at java.util.jar.JarFile.(JarFile.java:127) at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:51) at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:178) So I removed xalan-2.4.1.jar from WEB-INF/lib (let it rely on xalan-2.5.1.jar in TC/common/endorsed) Retried startup; next error: ... 2003-11-08 12:21:53 pluto: Initializing PortletContainer... 2003-11-08 12:21:53 pluto: Ready to serve you. 2003-11-08 12:22:05 ApplicationDispatcher[/jetspeed]: Servlet jetspeed is currently unavailable 2003-11-08 12:49:31 SessionListener: contextDestroyed() 2003-11-08 12:49:31 ContextListener: contextDestroyed() 2003-11-08 12:49:31 SessionListener: contextDestroyed() 2003-11-08 12:49:31 ContextListener: contextDestroyed() 2003-11-08 12:49:32 -- INFO -- Shutting down service: ResourceService 2003-11-08 12:49:32 -- INFO -- Turbine: Done shutting down! 2003-11-08 12:53:54 Marking servlet jetspeed as unavailable 2003-11-08 12:53:54 Servlet /jetspeed threw load() exception javax.servlet.ServletException: Error instantiating servlet class org.apache.jetspeed.engine.JetspeedServlet at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1011) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:887) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3853) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 ... - Root Cause - java.lang.NoClassDefFoundError: org/apache/commons/configuration/Configuration at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610) at java.lang.Class.getConstructor0(Class.java:1922) at java.lang.Class.newInstance0(Class.java:278) at java.lang.Class.newInstance(Class.java:261) Maven said everything built successful with no errors. Have I missed a step somewhere in the build process? Env: Linux Redhat 8.0 Tomcat 5.0.14 = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jetspeed-2 install problems
Installed Pluto - runs fine. Checked out Jetspeed-2 from CVS and built and deployed it using maven (maven allBuild deploy pam.deploy) but it will not start. Maven said everything built successful with no errors. First startup error received was: 2003-11-08 12:06:26 ContextConfig[/jetspeed] Exception processing JAR at resource path /WEB-INF/lib/xalan-2.4.1.jar javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/xalan-2.4.1.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) ... - Root Cause - java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:112) at java.util.jar.JarFile.(JarFile.java:127) at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:51) at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:178) The problem is that the xalan-2.4.1.jar in WEB-INF/lib is corrupt. When I try to list it from the command line (jar -tvf xalan-2.4.1.jar) it shows this error: ... 21920 Thu Oct 31 14:22:02 EST 2002 org/apache/xalan/templates/ElemNumber.class 538 Thu Oct 31 14:22:04 EST 2002 org/apache/xalan/templates/ElemOtherwise.class 2808 Thu Oct 31 14:22:00 EST 2002 org/apache/xalan/templates/ElemParam.class 4026 Thu Oct 31 14:22:04 EST 2002 org/apache/xalan/templates/ElemPI.class java.io.EOFException: Unexpected end of ZLIB input stream at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134) at java.util.zip.ZipInputStream.read(ZipInputStream.java:139) at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:91) at sun.tools.jar.Main.list(Main.java:744) at sun.tools.jar.Main.run(Main.java:192) at sun.tools.jar.Main.main(Main.java:904) So I removed xalan-2.4.1.jar from WEB-INF/lib (let it rely on xalan-2.5.1.jar in TC/common/endorsed) Retried startup; next error: ... 2003-11-08 12:21:53 pluto: Initializing PortletContainer... 2003-11-08 12:21:53 pluto: Ready to serve you. 2003-11-08 12:22:05 ApplicationDispatcher[/jetspeed]: Servlet jetspeed is currently unavailable 2003-11-08 12:49:31 SessionListener: contextDestroyed() 2003-11-08 12:49:31 ContextListener: contextDestroyed() 2003-11-08 12:49:31 SessionListener: contextDestroyed() 2003-11-08 12:49:31 ContextListener: contextDestroyed() 2003-11-08 12:49:32 -- INFO -- Shutting down service: ResourceService 2003-11-08 12:49:32 -- INFO -- Turbine: Done shutting down! 2003-11-08 12:53:54 Marking servlet jetspeed as unavailable 2003-11-08 12:53:54 Servlet /jetspeed threw load() exception javax.servlet.ServletException: Error instantiating servlet class org.apache.jetspeed.engine.JetspeedServlet at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1011) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:887) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3853) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 ... - Root Cause - java.lang.NoClassDefFoundError: org/apache/commons/configuration/Configuration at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610) at java.lang.Class.getConstructor0(Class.java:1922) at java.lang.Class.newInstance0(Class.java:278) at java.lang.Class.newInstance(Class.java:261) Env: Linux Redhat 8.0 Tomcat 5.0.14 = Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
What are you guys talking about? I just went and accessed the iView site with Mozilla and Mozilla Firebird and went all over it without seeing any problems. I saw no display issues at all. Are you referring to the fact that they have it setup at fixed width that is a tad wider and that you have to pull you browser open a little? I mean come on. Or would you rather have them resizing your browser window for you. People hate that. The site displays just fine in Mozilla. Gerry Reno --- Gregory Joseph <[EMAIL PROTECTED]> wrote: > Raphaël Luta wrote: > >I just registered to check it out and, of course, it simply doesn't > >recognize my Mozilla Firebird as a supported client so I get a very > >ugly site. > >Thanks for reminding me why I so dislike client-side technologies :) > > Same with Mozilla1.4 (even without taking the pain to register) > > Ah, at least I'm glad I finally see a mail here from someone that > seems to be > *against* iframes ;) > (i was evaluating jetspeed, and it seems usability and xhtml > compliance are > not really taken in account, or is it and i missed a point > somewhere?) > > > g > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : JSR-168 Article Part 1 in JavaWorld
Raphael, I know you're unconvinced by any of the client-side technology arguments. But I will say that you should consider that the history of java is replete with examples of users rejecting "one-size fits all" solutions. They were many great "one size fits all" technologies that users did not embrace because they demanded a richer experience. Technologies such as applets, AWT, Swing. The portal and portlet specification shouldn't become a "one size fits all" solution set. It needs to recognize and specify how users can utilize portlets in both a server-centric manner and a client-centric manner. >From the iView site: "For example, to monitor market data from Bloomberg.com, you can use an iView to add a Bloomberg window to your desktop, for a continuous, real-time display. You can click the window any time to access the full Bloomberg Web site." ... "Other enterprise portals provide static views of data sources, or make you drill down into data sources one at a time. But with iViews, your personalized portal is an always-on, always-active link to all the applications you need." This perfectly represents the kind of interaction that I was referring to with the video portlet example that I used. Some portlets will need to be capable of being "always on, always connected". And video isn't the only example. There are many others uses of real-time live-display data that will require this type of capability. This means not destroying the DOM with continual page reloads as is the case with Jetspeed today and the JSR-168 portlet spec needs to recognize these use cases provide for there existence both in the way the spec is written and in the reference implementation. rgds, Gerry Reno --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > De : Helmut Tammen [mailto:[EMAIL PROTECTED] > > > > Sorry, > > > > I´ve forgot to say that this version of the PDK is only > > running with IE, > > but the release 6.0 of SAP Enterprise Portal should be browser > > independent (I´ve heard). Unfortunetly there is no PDK available > yet. > > > > I didn´t want you to switch from Jetspeed to SAP EP neither > > did I want > > to leave the impession that this product is the best Portal > > at all. It > > has it´s drawbacks like any other products but it´s worth a look > > especially because of it´s client side capabilities. > > Can´t be bad to have a look at products from competitors, can it!? > > > > I can't agree more but I'm still rather unconvinced by portal > solutions > relying heavily on advanced client-side behavior whatever their > benefits > are in terms of GUI: too complex to properly develop in a portable > way > because the meaningful standards aren't properly implemented by all > vendors and you have too high a risk of hitting costly C/S type > deployment > issues and tying your desktop solutions to your server solutions. > > Of course, your mileage may vary :) > > -- > Raphaël Luta - [EMAIL PROTECTED] > Jakarta Jetspeed - Enterprise Portal in Java > http://jakarta.apache.org/jetspeed/ > > ** > Vivendi Universal - HTTP://www.vivendiUniversal.com: > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or > privileged > material of Vivendi Universal which is for the exclusive use of the > individual designated above as the recipient. Any review, > retransmission, > dissemination or other use of, or taking of any action in reliance > upon, > this information by persons or entities other than the intended > recipient > is prohibited. If you received this in error, please contact > immediately > the sender by returning e-mail and delete the material from any > computer. > If you are not the specified recipient, you are hereby notified that > all > disclosure, reproduction, distribution or action taken on the basis > of this > message is prohibited. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : JSR-168 Article Part 1 in JavaWorld
Raphael, I know you're unconvinced by any of the client-side technology arguments. But I will say that you should consider that the history of java is replete with examples of users rejecting "one-size fits all" solutions. They were many great "one size fits all" technologies that users did not embrace because they demanded a richer experience. Technologies such as applets, AWT, Swing. The portal and portlet specification shouldn't become a "one size fits all" solution set. It needs to recognize and specify how users can utilize portlets in both a server-centric manner and a client-centric manner. >From the iView site: "For example, to monitor market data from Bloomberg.com, you can use an iView to add a Bloomberg window to your desktop, for a continuous, real-time display. You can click the window any time to access the full Bloomberg Web site." ... "Other enterprise portals provide static views of data sources, or make you drill down into data sources one at a time. But with iViews, your personalized portal is an always-on, always-active link to all the applications you need." This perfectly represents the kind of interaction that I was referring to with the video portlet example that I used. Some portlets will need to be capable of being "always on, always connected". And video isn't the only example. There are many others uses of real-time live-display data that will require this type of capability. This means not destroying the DOM with continual page reloads as is the case with Jetspeed today and the JSR-168 portlet spec needs to recognize these use cases provide for there existence both in the way the spec is written and in the reference implementation. rgds, Gerry Reno --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > De : Helmut Tammen [mailto:[EMAIL PROTECTED] > > > > Sorry, > > > > I´ve forgot to say that this version of the PDK is only > > running with IE, > > but the release 6.0 of SAP Enterprise Portal should be browser > > independent (I´ve heard). Unfortunetly there is no PDK available > yet. > > > > I didn´t want you to switch from Jetspeed to SAP EP neither > > did I want > > to leave the impession that this product is the best Portal > > at all. It > > has it´s drawbacks like any other products but it´s worth a look > > especially because of it´s client side capabilities. > > Can´t be bad to have a look at products from competitors, can it!? > > > > I can't agree more but I'm still rather unconvinced by portal > solutions > relying heavily on advanced client-side behavior whatever their > benefits > are in terms of GUI: too complex to properly develop in a portable > way > because the meaningful standards aren't properly implemented by all > vendors and you have too high a risk of hitting costly C/S type > deployment > issues and tying your desktop solutions to your server solutions. > > Of course, your mileage may vary :) > > -- > Raphaël Luta - [EMAIL PROTECTED] > Jakarta Jetspeed - Enterprise Portal in Java > http://jakarta.apache.org/jetspeed/ > > ** > Vivendi Universal - HTTP://www.vivendiUniversal.com: > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or > privileged > material of Vivendi Universal which is for the exclusive use of the > individual designated above as the recipient. Any review, > retransmission, > dissemination or other use of, or taking of any action in reliance > upon, > this information by persons or entities other than the intended > recipient > is prohibited. If you received this in error, please contact > immediately > the sender by returning e-mail and delete the material from any > computer. > If you are not the specified recipient, you are hereby notified that > all > disclosure, reproduction, distribution or action taken on the basis > of this > message is prohibited. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi David, > On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote: > > From my perspective this > > is very important since JSR-168 is going to be declared *the* > standard. > > The standard should provide enough flexibility to accomodate all > the > > common types of paradigms and technologies to which users have come > to > > use when utilizing the Web. > > The portlet spec as currently written is analogous to having a > number > > of browsers open on your desktop and each one would represent a > portlet > > and if you were to hit the reload button or minimize or maximize or > > submit a form from any of them, then all of them would reload their > > pages. Well this works great if you don't mind losing any > client-side > > processing that is going on. The problem is that users are > accustomed > > to having client-side processing and in fact expect a consistent > > context when interacting with client-side technologies. As it > stands > > now, the portlet spec is dictating that every portlet mode or > window > > state change causes an action request to be sent to the server. If > you > > understand how the browser and pages and the document object model > and > > browser client-side technologies work you immediately realize that > > constantly reloading pages is not a good thing. > --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > With the portlet api, you are free to handle client-side programming, > > inside the scripts and content generated by your portlet. > However portal-level events such as minimize and maximize, or a > portlet > action, must be passed back to the portal so that the > targeted portlet is notified of the event. Portlets, like servlets, > are > server-side objects and that is what the Java specification focuses > on. > > Im thinking about your maximize example. Wouldn't most cases require > different or more content in maximized mode, requiring a trip back to > > the server? > Same for print friendly mode. This is what I am talking about when I refer to client-side technologies being severely restricted. Any client-side technologies are going to be limited by the fact that they will live only until the next button press on the portal and then they will be destroyed and recreated with the next page load. For client-side technologies it's as a famous catcher once said, "It's deja-vu all over again". As far as the maximize example, if you remember from some of my other threads that what is expensive is server round-trips. My preference would be to see that all the content, both normalized and maximized markup is sent to the browser in the initial request and then window state changes only cause that content to be revealed or hidden as appropriate. The content for the normal display can be sent with the additional content for maximized view being loaded in the background so that there is no delay in the presentation of the portal page to the user. As far as print-friendly, you just go from a CSS attribute of 'media=screen' to 'media=print'. You can just manipulate the DOM to cause this to happen! You don't need to go to the server. > > Your point about reloading and losing state of the other portlets is > > well taken. > Even IFrame portlets require state management and rewriting. > I try to steer clear of applets when working with portlets. > I do think these issues need to be addressed in future versions of > the > spec. The time to address these issues is now, not later. The basic model for portable portlets is being established right now. It isn't going to be possible to 'extend' this model later to accomodate the type of interaction that I'm proposing. The fundamental model needs to be established correctly, right now, in order to be able to extend it later. The reason that you are steering clear of good client-side technologies such as applets is because the current spec prevents you from using them in any meaningful way. > > You also spoke about when a form is submitted from within an IFrame. > In Jetspeed today, we are capable of returning only the content of > the > particular portlet back to the IFrame. > The Portlet API is restrictive here, requiring that all portlets > return > content per request > Jetspeed could add an extended mode to support this, but then your > portlet may not be portable. With the way in which the portlets operate currently, I'm finding myself driven towards doing everything inside IFrames with a reload button on them in order to be able to utilize anything with regard to client-side technologies. This has been my same experience with jsf. I fi
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > Gerry, > > Here is how I envisioned it. You would have a "Request Proxy" > probably a hidden IFrame that has the ability to write both to the > client (DOM manipulation/screen repainting) and the server(record the > user's current page and portlet state/process non trivial portlet > requests). > > This is over-simplified but gives you an idea of how I think it could > be implemented. > The client-side portlet controller should exist in the main page not in it's own iframe. That would be destroyed anyway if the main page were reloaded. The key is that the portlets have to exist in a framework that allows them to be manipulated separately - the only construct that is currently capable of this in a browser is the iframe. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi David, > On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote: > > From my perspective this > > is very important since JSR-168 is going to be declared *the* > standard. > > The standard should provide enough flexibility to accomodate all > the > > common types of paradigms and technologies to which users have come > to > > use when utilizing the Web. > > The portlet spec as currently written is analogous to having a > number > > of browsers open on your desktop and each one would represent a > portlet > > and if you were to hit the reload button or minimize or maximize or > > submit a form from any of them, then all of them would reload their > > pages. Well this works great if you don't mind losing any > client-side > > processing that is going on. The problem is that users are > accustomed > > to having client-side processing and in fact expect a consistent > > context when interacting with client-side technologies. As it > stands > > now, the portlet spec is dictating that every portlet mode or > window > > state change causes an action request to be sent to the server. If > you > > understand how the browser and pages and the document object model > and > > browser client-side technologies work you immediately realize that > > constantly reloading pages is not a good thing. > --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > With the portlet api, you are free to handle client-side programming, > > inside the scripts and content generated by your portlet. > However portal-level events such as minimize and maximize, or a > portlet > action, must be passed back to the portal so that the > targeted portlet is notified of the event. Portlets, like servlets, > are > server-side objects and that is what the Java specification focuses > on. > > Im thinking about your maximize example. Wouldn't most cases require > different or more content in maximized mode, requiring a trip back to > > the server? > Same for print friendly mode. This is what I am talking about when I refer to client-side technologies being severely restricted. Any client-side technologies are going to be limited by the fact that they will live only until the next button press on the portal and then they will be destroyed and recreated with the next page load. For client-side technologies it's as a famous catcher once said, "It's deja-vu all over again". As far as the maximize example, if you remember from some of my other threads that what is expensive is server round-trips. My preference would be to see that all the content, both normalized and maximized markup is sent to the browser in the initial request and then window state changes only cause that content to be revealed or hidden as appropriate. The content for the normal display can be sent with the additional content for maximized view being loaded in the background so that there is no delay in the presentation of the portal page to the user. As far as print-friendly, you just go from a CSS attribute of 'media=screen' to 'media=print'. You can just manipulate the DOM to cause this to happen! You don't need to go to the server. > > Your point about reloading and losing state of the other portlets is > > well taken. > Even IFrame portlets require state management and rewriting. > I try to steer clear of applets when working with portlets. > I do think these issues need to be addressed in future versions of > the > spec. The time to address these issues is now, not later. The basic model for portable portlets is being established right now. It isn't going to be possible to 'extend' this model later to accomodate the type of interaction that I'm proposing. The fundamental model needs to be established correctly, right now, in order to be able to extend it later. The reason that you are steering clear of good client-side technologies such as applets is because the current spec prevents you from using them in any meaningful way. > > You also spoke about when a form is submitted from within an IFrame. > In Jetspeed today, we are capable of returning only the content of > the > particular portlet back to the IFrame. > The Portlet API is restrictive here, requiring that all portlets > return > content per request > Jetspeed could add an extended mode to support this, but then your > portlet may not be portable. With the way in which the portlets operate currently, I'm finding myself driven towards doing everything inside IFrames with a reload button on them in order to be able to utilize anything with regard to client-side technologies. This has been my same experience with jsf. I fi
Re: JSR-168 Article Part 1 in JavaWorld
he DOM instead of reloading the whole main page. The model that is necessary to insure that client-side technologies are usable would involve having the portlets all implemented as iframes with a client-side controller/proxy to talk to the server and to control the presentation of the portlets in the browser itself. This does not mean that you are prevented from having portlets operate in a mode without client-side control. The key is specifying the right model that will permit the case for also allowing a client-side controller that can be used to talk with the portlets (all iframe based) and will permit the main page to remain intact in the browser so that client-side technologies will be able to maintain context and work all the while portlets are changing window states or portlet modes. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : JSR-168 Article Part 1 in JavaWorld
Hi Raphael, --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > If I understand correctly your request in regards to the > JSR 168, you would like to be able to develop a client based portal > that leverages the portlet components developped against the JSR168 > API. Is that correct ? > > I think that what you can do in this case is implementing > a portal "server" on the client, with client side technologies that > interact with a remote portlet container over the network, for > example > through WSRP. In such a setup, your client can control exactly the > aggregation behavior and still leverage any JSR 168 portlets through > WSRP. > > Since JSR 168 assumes a server-based aggregation process, it can not > answer alone your requirement but OTOH I don't think it's a > showstopper > since WSRP will perfectly handle this requirement. > > Am I missing something here ? > Are you suggesting that in order to accomodate client-side technologies that a browser plugin 'portal server' would be necessary? Users would reject this outright. I really don't see how this would solve the problem. It is the whole interaction model that is the problem, not where the 'portal server' lives. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Raphael, >De : Gerry Reno [mailto:[EMAIL PROTECTED] >> >> Erik, Serge (I'm going to respond to both of you here) >> >> >> >> I think that this spec needs to recognize that in order for >> a portal to be able to preserve the context for client-side >> technologies, which by definition means that you must >> maintain the integrity of the main >> page DOM, that it cannot have every portlet action reloading >> the main page. >> >I'll try summarize what has been said so far (I hope I will not >miss a major point somewhere) : >A1. you advocate the need for a strong support of client side >technologies in the JSR 168 portal specificcation Correct. >A2 you propose a portal implementation model based around portlet >content included in IFrame tags and a persistent client-side >controller in the main page. Yes. >A3 Scott has proposed an alternate implementation model for >the client side based around a reqsuest proxy to a hidden >iFrame that is manipulated by the main window, which is >interacting with the user. I took this as essentially the same type of solution as A2. >A4 Erik has stated that he needs to be convinced that advanced >client-side technologies as a viable market right now due to >lack of standard support in IE which has a commanding share >of the browser market. The minor issues with IE are well-known and can easily be worked around. >A5 Serge has stated that the current JSR 168 spec does allow portlet >developers to take advantage a client-side technologies if they >wish but it's a good thing that it does not require them to do so. Well, only if the developer writes all the aggregation code and puts in place all the necessary communication and window control mechanisms. Not exactly the way to insure a portable standardized approach. There would need to be a standard model developed and an implementation that demonstrated the ability of this approach to work in all scenarios. This is the type of thing that I'm looking for the spec to provide. >A6 Several people have expressed the importance of supporting light >clients (like CHTML, WML, etc...) with the spec. Agreed. I don't see the two goals as conflicting. >A7 Serge and myself have pointed out that WSRP would allow you to >invoke a server based portlet and completely control the >aggregation on the client. see A5 comment. > >About A2, I must point out that in this setup *no* real output >aggregation actually occurs since iFrames are really independant >documents based on independant HTTP requests. >I find this setup >- limiting cross-portlet communication (like you can't use request > attributes to pass information around between portlets on the same > page) and portal-portlet communication (how to you refresh a page > navigation title based on a portlet content change if you don't > reload the page ?) Is main page request attributes the only way that inter-portlet communication can take place? I would hope not. >- mush less efficient in terms of network and processing power for > "information oriented" portals (like Yahoo), where probably 90% > of the requests are read the page/update the page. In these > scenarios the client-side code to download, the multiple request > to process and possibly the larger amount of content you send out > initially to the client to allow it to handle the minimize/maximize > features without portal callback quickly add up to reduce the > overall performance I really disagree with this assessment. Yes, you are making more requests but these requests are each much smaller. As far as sending the data for a minimize/maximize without callback, as I stated, you load the normalize view in the foreground and you load the maximize view in the background and the user will not experience any difference in performance. >- difficult to implement for public sites where validating "rich" > client-side portal features against many client configurations > is a costly proposition. We all do this today. It's not a big deal. >- not necessarily extremely user friendly given the nature of > IFRAME rendering, for example implementing a > complete *printable* portal page around IFRAMEs, one that never > truncates content, looks like a real challenge for me. I don't think that most people are going to want to print the portal page. What they want is to be able to print the 'portlet' page. This is a simple manipulation of CSS attribute in the DOM. > >Based on the above, I personnally tend to agree with Erik to A4 >and with Serge would that JSR 168 has set out to standardize a >portlet specification wi
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > I don't see that as a problem. Rewriting the DOM itself is nearly > > instantaneous from the perspective of the user. I see this > happening > > only for *volatile* portlets that much touch the server regularly. > I > > think that I would prefer though that such portlets have their own > > Refresh button for obtaining updated content rather than always > hitting > > the server on every request. > > I don't like the idea of the onus being on the user "refresh" their > portlets manually, seems a bit kludgy to me. I think if we reverse > this, and make it so that portlets that have extensive TTLs, i.e. > they rarely or never need periodic updates use the caching attribute > within their descriptors to effectively skip their ender phases and > portlets like the stock quote, update their content with each request > by using the proxy to do so. > > Now, we are adhering entirely to the spec by using the functionality > provided there in to effectively slow/stop the render phase for a > portlet unless specifically requested by giving a very long cache > period. Ok, but I still think that an optional Refresh button makes sense in some instances. Especially if you've set the TTL out very far and you then decide you want to refresh the portlet without refreshing the whole page. rgds, Gerry Reno > > Regards, > *===* > * Scott T Weaver* > * Jakarta Jetspeed Portal Project * > * [EMAIL PROTECTED] * > *===* > > > > > -Original Message- > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 07, 2003 3:46 PM > > To: Jetspeed Users List > > Subject: RE: JSR-168 Article Part 1 in JavaWorld > > > > Hi Scott, > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > The one thing we have to remember is that portlet content, i.e. > stock > > > quotes, weather, etc should be provided in real-time and as such, > the > > > content of these will need to be updated periodically. What I > am > > > getting at is that if the user only is changing window state we > > > rarely get a chance to get back to the server to update all of > the > > > portlets' content on the page. I think this is the reasoning my > > > statement below. > > > > > > We still need to observe the contract that every page request > invokes > > > each visible portlet's render method whether the request be a > render > > > request or an action request. > > > > The key word is *visible* portlet. > > > > The loophole in this is the fact that > > > cached portlets' render method invocation can be skipped during > the > > > render/request phase. > > > > > > Look between lines 15 - 30 in the spec. > > > > > > Even with this requirement, the main page could still stay intact > as > > > all requests go through the proxy, however we may have to rewrite > the > > > DOM of multiple portlets due to the above issues. > > > > I don't see that as a problem. Rewriting the DOM itself is nearly > > instantaneous from the perspective of the user. I see this > happening > > only for *volatile* portlets that much touch the server regularly. > I > > think that I would prefer though that such portlets have their own > > Refresh button for obtaining updated content rather than always > hitting > > the server on every request. > > > > rgds, > > Gerry > > > > > > > > > > > > > > > > Regards, > > > *===* > > > * Scott T Weaver* > > > * Jakarta Jetspeed Portal Project * > > > * [EMAIL PROTECTED] * > > > *===* > > > > > > > > > > > > > -Original Message- > > > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, August 07, 2003 3:18 PM > > > > To: Jetspeed Users List > > > > Subject: Re: JSR-168 Article Part 1 in JavaWorld > > > > > > > > Hi Scott, > > > > > > > > Yes, this type of model shows some promise. Now, what is > also > > > > important to recognize is that by manipulating the DOM on a > > > maximize, > > > > that all the portlets are actually sti
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, Yes, this type of model shows some promise. Now, what is also important to recognize is that by manipulating the DOM on a maximize, that all the portlets are actually still present. Just not visible. So perhaps we would need to send a message to non-visible portlets so that they could perhaps 'pause' when they weren't visible. rgds, Gerry Reno --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > Can you please clarify how this operates. Are you envisioning a > proxy > > requestor that will allow the main page DOM to remain intact. If > so, > > then this may work. If not, then it definitely would not work. > > Yes the main page stays intact and all portlet url's targets would be > the IFRAME proxy. I have not put a lot of thought into the > specifics, so that is open to discussion. Obviously, the proxy > IFRAME will have to do A LOT of DOM manipulation in the main page. > > Here is a simple scenario: > My apologies if the diagram gets out of whack ;) > > > User click "Maximize" on a portlet > | > --> This request is sent to the proxy IFRAME > | > | > (The proxy IFRAME then checks if DOM Manipulation required?) > || >truefalse > || > The DOM is re-written to Nothing is done to the DOM > facilitate the new window | > state.| > | | > | | > - > | > | > The request is now sent back to the server > to fulfill the JSR-168 requirements > | > Does the request response require a change > In the target portlets content? > | > - > | | >true false > | | > re-write the DOMNothing is done to the DOM > accordingly > > > This is a very high level model of what I envision, it is by no means > complete. > > *===* > * Scott T Weaver* > * Jakarta Jetspeed Portal Project * > * [EMAIL PROTECTED] * > *===* > > > > > -Original Message- > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 07, 2003 1:02 PM > > To: Jetspeed Users List > > Subject: Re: JSR-168 Article Part 1 in JavaWorld > > > > Hi Scott, > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > > Not exactly, the main user interface window would have in this > > > model > > > > a single DOM with no IFRAME (ie true content aggregation), the > > > hidden > > > > iFrame being used as a backround content cache to be used by > the > > > main > > > > window to load content. > > > > > > And act as the physical requestor back to the server. But yes, > > > Raphael, this is exactly what I was getting at, using a single, > > > hidden IFRAME, not an IFRAME for each portlet's content. > > > > Can you please clarify how this operates. Are you envisioning a > proxy > > requestor that will allow the main page DOM to remain intact. If > so, > > then this may work. If not, then it definitely would not work. > > > > > > rgds, > > Gerry Reno > > > > > > __ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site design software > > http://sitebuilder.yahoo.com > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > The one thing we have to remember is that portlet content, i.e. stock > quotes, weather, etc should be provided in real-time and as such, the > content of these will need to be updated periodically. What I am > getting at is that if the user only is changing window state we > rarely get a chance to get back to the server to update all of the > portlets' content on the page. I think this is the reasoning my > statement below. > > We still need to observe the contract that every page request invokes > each visible portlet's render method whether the request be a render > request or an action request. The key word is *visible* portlet. The loophole in this is the fact that > cached portlets' render method invocation can be skipped during the > render/request phase. > > Look between lines 15 - 30 in the spec. > > Even with this requirement, the main page could still stay intact as > all requests go through the proxy, however we may have to rewrite the > DOM of multiple portlets due to the above issues. I don't see that as a problem. Rewriting the DOM itself is nearly instantaneous from the perspective of the user. I see this happening only for *volatile* portlets that much touch the server regularly. I think that I would prefer though that such portlets have their own Refresh button for obtaining updated content rather than always hitting the server on every request. rgds, Gerry > > Regards, > *===* > * Scott T Weaver* > * Jakarta Jetspeed Portal Project * > * [EMAIL PROTECTED] * > *===* > > > > > -Original Message- > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 07, 2003 3:18 PM > > To: Jetspeed Users List > > Subject: Re: JSR-168 Article Part 1 in JavaWorld > > > > Hi Scott, > > > > Yes, this type of model shows some promise. Now, what is also > > important to recognize is that by manipulating the DOM on a > maximize, > > that all the portlets are actually still present. Just not > visible. > > So perhaps we would need to send a message to non-visible portlets > so > > that they could perhaps 'pause' when they weren't visible. > > > > rgds, > > Gerry Reno > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > > Can you please clarify how this operates. Are you envisioning > a > > > proxy > > > > requestor that will allow the main page DOM to remain intact. > If > > > so, > > > > then this may work. If not, then it definitely would not work. > > > > > > Yes the main page stays intact and all portlet url's targets > would be > > > the IFRAME proxy. I have not put a lot of thought into the > > > specifics, so that is open to discussion. Obviously, the proxy > > > IFRAME will have to do A LOT of DOM manipulation in the main > page. > > > > > > Here is a simple scenario: > > > My apologies if the diagram gets out of whack ;) > > > > > > > > > User click "Maximize" on a portlet > > > | > > > --> This request is sent to the proxy IFRAME > > > | > > > | > > > (The proxy IFRAME then checks if DOM Manipulation required?) > > > || > > >truefalse > > > || > > > The DOM is re-written to Nothing is done to the DOM > > > facilitate the new window | > > > state.| > > > | | > > > | | > > > - > > > | > > > | > > > The request is now sent back to the server > > > to fulfill the JSR-168 requirements > > > | > > > Does the request response require a change > > > In the target portlets content? > > > | > > > ----- > > > | | > > >true false > > > |
Re: JSR-168 Article Part 1 in JavaWorld
Hi Erik, --- Erik Bruchez <[EMAIL PROTECTED]> wrote: > > You appear to be responding to the very beginning of the thread. > > You might want to read through the rest of the thread. > > I did read the whole thread. My comments regarded your initial post, > hence I replied to it. > > > They have made a number of improvements to support CSS. Agreed, > > they didn't implement the box model correctly in V5 but this is > well > > known and easily compensated for. > > Really... Yes, really. The latest techniques involve attempting to create a box in the browser and then access the DOM and see what size it thinks it is. Then you can compensate. Or are you thinking that you have to use the old 'box hack' with all the goofy "\"}\"" type stuff? > > > By client-side technologies I"m referring to Flash, SVG, applets, > > DHTML. These aren't at all flaky unless someone doesn't > understand > > how to work with them. > > I like SVG, but no browser natively supports the technology, you have > to use a plugin. Mozilla support is far from being complete and > stable, and IE doesn't care. Look, don't just pick the latest cutting-edge client-side technology to point to. DHTML, javascript, Flash work just fine. >Applets not flaky: right! And applets work just fine if you know anything about what you're doing. Yes, you have to use the tricks with the and tags. Big deal! > > > Totally disagree - round trips make for a completely annoying user > > experience and it's what is wrong with many sites. > > That's unfortunate, but that's the best we have IMO. > > > Any proof-of-concept would have to come from those that are > > interally familiar with the implementation. Perhaps some Jetspeed > > team members might be willing to assist in producing such a proof. > > I really don't think it necessary. I think the arguments and > points > > made in the thread speak for themselves. > > Out of the current 20 messages in this thread, 12 are by you, and > *nobody* has made a single reply to any of your messages. My point is > that there is no real discussion here, and no significant progress or > definitive conclusion. The only arguments I see are yours, and of > course you agree with yourself ;-) Erik, I really have to wonder what your purpose is with these statements? People have been responding my postings otherwise how else would all my comments end up in their postings? I think as in the other threads before on this issue many people are listening and thinking about this issue. There are a lot of lurkers who are trying to absorb this and who maybe don't feel comfortable with posting until they manage to get a full grasp of everything. > > > If you read through all of the threads dealing with the issue you > > will find examples of all of these things. > > I have, and I am not convinced. There are many applications and > framework (mostly commercial) that have attempted to reproduce the > desktop application model by delegating more of the UI logic in Web > browsers. My experience so far is that they have all pretty much > failed, in that they have been fragile, browser-dependent, and have > not significantly improved the usability of Web applications. Just my > $0.02 though. So I need to be convinced, that's all. > > -Erik > The portlet spec is locking out client-side technologies!! If the arguments and points that I have presented have not convinced you then sobeit. I can pretty much guarantee you that going forward with the spec the way it is it will fail. Users are going to reject the slow performance the lack of being able to use good client-side technologies that other portal implementations are going to allow. The only way that I'll even consider designing anything around this current spec is to remove all of the portlet window state buttons and portlet mode buttons so that I can use some client-side technologies in the portal and the user won't be experiencing constant page reloading. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > If we used client-side operations to alter window state, how would we > maintain/persist a user's window state when that user closes their > browser? > > What if a user logs in from a different browser on a different > machine, wouldn't they expect the state of there portlets to be same > no matter where they are accessing the portal from? > Ok, what I think is necessary is the notion of a client=side controller that would notify the server-side of the window states that were being set on the client rather than constantly reloading pages all the time. The immediate model that comes to mind is the one of using iframes for each portlet where you can declare some of these portlets at 'persistent' like a media player portlet and the controller would tell the other 'non-persistent' portlet iframes to 'reload' on certain events. This way the entire page is not reloading and destroying client-side technology contexts. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ann: Simpler Struts based portal
Definitely not a very friendly way of presenting a license. --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > "** The license on the open source does not allow you to use bP > designs in your commercial applications, you have to purchase another > license from us at above rates. Stealing intellectual property is > much like stealing other property - except that baseBeans could end > up owning your company. License and prices are subject to change." > > Hmm, that doesn't sound very "open" to me??? Guess I'll stick to > projects that don't threaten to acquire my company if I use them. > > *===* > * Scott T Weaver* > * Jakarta Jetspeed Portal Project * > * [EMAIL PROTECTED] * > *===* > > > > > -Original Message- > > From: Glen Carl [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 06, 2003 4:21 PM > > To: Jetspeed Users List > > Subject: Re: Ann: Simpler Struts based portal > > > > What is the JSR-168 migration plan for this portal? > > > > D.S. Johnson wrote: > > > > > Vic Cekvenich wrote: > > > > > >> Here is another Java open source Portal/CMS w/ Struts: > > >> http://basebeans.com/do/newsBlgCmntsLstPg?ID=14 > > >> > > >> Download here: > > >> > > >> > > > https://sourceforge.net/project/showfiles.php?group_id=55539&release_id=17 > > 6249 > > >> > > >> > > >> > > >> .V > > >> > > >> > > >> > > > Where's the demo > > > > > > > > > > - > > > 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] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > Not exactly, the main user interface window would have in this > model > > a single DOM with no IFRAME (ie true content aggregation), the > hidden > > iFrame being used as a backround content cache to be used by the > main > > window to load content. > > And act as the physical requestor back to the server. But yes, > Raphael, this is exactly what I was getting at, using a single, > hidden IFRAME, not an IFRAME for each portlet's content. Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSR-168 Article Part 1 in JavaWorld
. To create a portal model that will provide for a good user experience is going to require both server-side and client-side technologies working together. I would much rather see portlets implemented as either all iframes that can be controlled and reloaded individually or even better as something like CSS elements that can dynamically be controlled on the client-side by DHTML, javascript, Flash, SVG, etc. for things like minimizing, maximizing, print-friendly, help, edit. That way the only thing that is going to cause a trip to the server is something like a form submit and even that should be done in a iframe so that the rest of the page doesn't reload. Please take some time to think about this spec and the type of portal behavior into which users will be locked. For a portal operating under my suggested model, when the user want to maximize a portlet, the portlet is nearly instanteously maximized with enhanced content and none of this is requiring a trip to the server. Additionally the user can now maximize, normalize, and minimize the portlet as many times as they like all without any requests being sent to the server. The portal can now even operate in an offline mode, the DOM integrity has been maintained so client-side technologies function as expected, portlets such as Jetspeed's IFramePortlet function properly, and the user is experiencing near instanteous response from the user interface and their overall experience will be much more satisfying. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > Ok, but I still think that an optional Refresh button makes sense > in > > some instances. Especially if you've set the TTL out very far and > you > > then decide you want to refresh the portlet without refreshing the > > whole page. > > Of course, and that would be up to the portlet developer to provide > that sort of functionality within his/her portlets. > I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Raphael, --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > If I understand correctly your request in regards to the > JSR 168, you would like to be able to develop a client based portal > that leverages the portlet components developped against the JSR168 > API. Is that correct ? > > I think that what you can do in this case is implementing > a portal "server" on the client, with client side technologies that > interact with a remote portlet container over the network, for > example > through WSRP. In such a setup, your client can control exactly the > aggregation behavior and still leverage any JSR 168 portlets through > WSRP. > > Since JSR 168 assumes a server-based aggregation process, it can not > answer alone your requirement but OTOH I don't think it's a > showstopper > since WSRP will perfectly handle this requirement. > > Am I missing something here ? > Are you suggesting that in order to accomodate client-side technologies that a browser plugin 'portal server' would be necessary? Users would reject this outright. I really don't see how this would solve the problem. It is the whole interaction model that is the problem, not where the 'portal server' lives. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
-trying to tie this linkage back to the original thread - >De : Gerry Reno [mailto:[EMAIL PROTECTED] >> >> Hi Raphael, >> >> --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: >> > >> > If I understand correctly your request in regards to the >> > JSR 168, you would like to be able to develop a client based portal >> > that leverages the portlet components developped against the JSR168 >> > API. Is that correct ? >> > >> > I think that what you can do in this case is implementing >> > a portal "server" on the client, with client side technologies that >> > interact with a remote portlet container over the network, >> for example >> > through WSRP. In such a setup, your client can control exactly the >> > aggregation behavior and still leverage any JSR 168 portlets through >> > WSRP. >> > >> > Since JSR 168 assumes a server-based aggregation process, >> it can not >> > answer alone your requirement but OTOH I don't think it's a >> > showstopper since WSRP will perfectly handle this requirement. >> > >> > Am I missing something here ? >> > >> >> Are you suggesting that in order to accomodate client-side >> technologies that a browser plugin 'portal server' would be >> necessary? >> Users would reject this outright. I really don't see how >> this would solve the problem. It is the whole interaction >> model that is the problem, not where the 'portal server' lives. >> >No, I don't think you need a plug-in, you just need to write >in Javascript the code that will actually aggregate the content on >the client instead of aggergating on the server. >In such a model, you're really back to standard client/server model >where most of the intelligence is on the client. Such a process flow >could be: >clients open up 2 frames/iframes/windows (1 of which is hidden from the >user with a 0 size or whatever trick you fancy): >1st frame loads from HTTP server the JS/applet code that will be the >portal server and starts displaying the portal page >The JS code fetches the PSML (or equivalent) information from the >portal server and loads it into the second frame, then it parses the >XML information through DOM and activates remote portlet through >WSRP as needed. >If you need to save information to a remote server (liek storing user >preferences), you can do it either through HTTP POST or directly with >a SOAP request. All I see this doing is moving around the portal server and playing tricks with the markup. I think we would need to see some type of an example to examine whether this offered any possibilities. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Marc, --- Marc Tremblay <[EMAIL PROTECTED]> wrote: > While I agree that allowing for the use of rich client side > technologies > is highly desirable, we need to remember that not all user agents > will > be able to support said technologies. I'm thinking specifically of > the > myriad of WML devices out there. Since this is an initial spec, I'm > much happier that it is capable of working with user agents of > limited > ability than if such user agents were forgotten altogether or simply > tacked on at the end. > > Let's get a foundation in place first, then we can tweak it. It > reminds > me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the > foundation for later revisions which were actually usable. > > -- Marc > I just don't think that the current spec is going to be extendable. The fundamental model has to be right and I don't think that it is. As far as WML devices and as I said in a letter that I wrote to JSR-168 team, the small screen device technology is progressing at a very rapid pace and these devices will very shortly be capable of DOM processing. Check out all the buzz about SVG on small screen devices. I think the spec is placing way too much emphasis on the 'lowest common denominator' approach. Users, as the Java community knows all too well, tend to reject these types of approaches. Look at AWT, Swing, applets. They were to be the killer technologies and users didn't embrace them en-masse because they wanted a richer experience. My feeling is that the portlet spec is making the same type of mistake here. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > I'm assuming that there would be an 'API' so that the developer > would > > know how to talk to the proxy and request their portlet refresh. > > Developers should not need to be aware of this. We would have > configuration options that would generate URLs that would be aware of > this and possibly use javascript to intercept these requests and send > them to the proxy. Like I said I don't have all the technical > details figured out. > > We need to hide as much of the implementation as possible from the > developer so their portlets can be used in portals that support > JSR-168 but do not support the extended DOM interaction model you are > proposing. > Something like a Refresh button would be optional and would need to be examined as to whether it could be applied to both models. Ok, I understand. You need to think about it some more for further details to emerge. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, I think you understand what I was proposing and how it has to operate to protect the contexts for client-side technologies. And it sounds potentially like you may have come up with a possible way to design and implement such a model. If this model can be successfully implemented then I think it should be incorporated into JSR-168. I think that is essential. rgds, Gerry Reno --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > I see the "refresh" option as porlet mode/render request, more than > likely the "doView()" mode. > > *===* > * Scott T Weaver* > * Jakarta Jetspeed Portal Project * > * [EMAIL PROTECTED] * > *===* > > > > > -Original Message- > > From: Weaver, Scott [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 07, 2003 4:29 PM > > To: 'Jetspeed Users List' > > Subject: RE: JSR-168 Article Part 1 in JavaWorld > > > > > I'm assuming that there would be an 'API' so that the developer > would > > > know how to talk to the proxy and request their portlet refresh. > > > > Developers should not need to be aware of this. We would have > > configuration options that would generate URLs that would be aware > of this > > and possibly use javascript to intercept these requests and send > them to > > the proxy. Like I said I don't have all the technical details > figured > > out. > > > > We need to hide as much of the implementation as possible from the > > developer so their portlets can be used in portals that support > JSR-168 > > but do not support the extended DOM interaction model you are > proposing. > > > > > > Regards, > > *=======* > > * Scott T Weaver* > > * Jakarta Jetspeed Portal Project * > > * [EMAIL PROTECTED] * > > *===* > > > > > > > > > -Original Message- > > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, August 07, 2003 4:11 PM > > > To: Jetspeed Users List > > > Subject: RE: JSR-168 Article Part 1 in JavaWorld > > > > > > Hi Scott, > > > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > > > Ok, but I still think that an optional Refresh button makes > sense > > > > in > > > > > some instances. Especially if you've set the TTL out very > far and > > > > you > > > > > then decide you want to refresh the portlet without > refreshing the > > > > > whole page. > > > > > > > > Of course, and that would be up to the portlet developer to > provide > > > > that sort of functionality within his/her portlets. > > > > > > > > > > I'm assuming that there would be an 'API' so that the developer > would > > > know how to talk to the proxy and request their portlet refresh. > > > > > > > > > rgds, > > > Gerry Reno > > > > > > > > > > > > __ > > > Do you Yahoo!? > > > Yahoo! SiteBuilder - Free, easy-to-use web site design software > > > http://sitebuilder.yahoo.com > > > > > > > - > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Erik, You appear to be responding to the very beginning of the thread. You might want to read through the rest of the thread. --- Erik Bruchez <[EMAIL PROTECTED]> wrote: > Gerry, > > You are starting a debate very similar to the one around JavaServer > Faces. Both JSRs strictly focus around a strictly server-side > framework as opposed to a client-side framework (or a combination of > both). > > To the defense of JSR-168, I think that client-side technologies are > at best flaky, a situation that hasn't changed much in 4-5 years > now. Microsoft hasn't made one significant improvement to IE since > version 4. They have made a number of improvements to support CSS. Agreed, they didn't implement the box model correctly in V5 but this is well known and easily compensated for. By client-side technologies I"m referring to Flash, SVG, applets, DHTML. These aren't at all flaky unless someone doesn't understand how to work with them. >Mozilla has done better, but represents an almost > insignificant market share. There is just not much happening in that > arena today, partly because of IE's monopoly. The question of chosing > a technology common denominator is difficult. > > The trend in the past few years has been to go back to server-side > technologies generating pretty basic HTML, JavaScript and CSS. Today, > the Web sites and Web apps with the best usability IMO are the ones > that try to minimize the use of fancy client-side technologies. In > theory diminishing the number of round-trips to the server is better, > but the reality is that round-trips work! Totally disagree - round trips make for a completely annoying user experience and it's what is wrong with many sites. It only works from the standpoint of being able to pick up server-side data. > > In addition, the JSR must allows for different types of clients, such > as PDAs. It also must be 100% agnostic wrt the technology used for > the > presentation (JSP, XSLT, etc.). Clearly not everybody has > standardized > on JSP. > > I think some of your concerns are valid (but not too important to > somebody like me I have to say) but remain way too theoretical. The > best approach to convince people would be to point to an > implementation addressing them. Such an proof of concept could be a > good basis for inclusion in a JSR. > > -Erik > Any proof-of-concept would have to come from those that are interally familiar with the implementation. Perhaps some Jetspeed team members might be willing to assist in producing such a proof. I really don't think it necessary. I think the arguments and points made in the thread speak for themselves. The current portlet spec completely destroys the capabilities of client-side technologies. In fact, some of the existing portlets do not even function properly due to the interaction model being dictated by the spec. If you read through all of the threads dealing with the issue you will find examples of all of these things. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
In the broader scope, what I think is necessary for both the portlet spec and for things like jsf is that anytime you are going to require maintaining the contexts for client-side technologies it is necessary that the main page not be reloaded and that the client interact with the server-side technology via a client-side controller/proxy talking to iframes which can be reloaded independently of each other and the main page. This lets you have the best of both worlds - enterprise-level server-side processing and rich, robust and fast client-side technologies. rgds, Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Hi Scott, > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > Gerry, > > > > Here is how I envisioned it. You would have a "Request Proxy" > > probably a hidden IFrame that has the ability to write both to the > > client (DOM manipulation/screen repainting) and the server(record > the > > user's current page and portlet state/process non trivial portlet > > requests). > > > > This is over-simplified but gives you an idea of how I think it > could > > be implemented. > > > > The client-side portlet controller should exist in the main page > not > in it's own iframe. That would be destroyed anyway if the main page > were reloaded. The key is that the portlets have to exist in a > framework that allows them to be manipulated separately - the only > construct that is currently capable of this in a browser is the > iframe. > > rgds, > Gerry Reno > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Serge, --- Serge Huber <[EMAIL PROTECTED]> wrote: > At 08:32 AM 8/6/2003 -0700, you wrote: > >Hi Raphael, > > > >--- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > > > > > If I understand correctly your request in regards to the > > > JSR 168, you would like to be able to develop a client based > portal > > > that leverages the portlet components developped against the > JSR168 > > > API. Is that correct ? > > > > > > I think that what you can do in this case is implementing > > > a portal "server" on the client, with client side technologies > that > > > interact with a remote portlet container over the network, for > > > example > > > through WSRP. In such a setup, your client can control exactly > the > > > aggregation behavior and still leverage any JSR 168 portlets > through > > > WSRP. > > > > > > Since JSR 168 assumes a server-based aggregation process, it can > not > > > answer alone your requirement but OTOH I don't think it's a > > > showstopper > > > since WSRP will perfectly handle this requirement. > > > > > > Am I missing something here ? > > > > > > > Are you suggesting that in order to accomodate client-side > >technologies that a browser plugin 'portal server' would be > necessary? > >Users would reject this outright. I really don't see how this would > >solve the problem. It is the whole interaction model that is the > >problem, not where the 'portal server' lives. > > Actually I think Raphael has an interesting idea. Let's suppose > you're > using Mozilla as a client technology. You could design a XUL client > that > would use LiveConnect to do WSRP requests to a WSRP compliant server > (Jetspeed 2?). Within this server the interface of JSR-168 could be > used to > communicate with the portlets. > > But I also have some ideas for improvements for JSR-168, but I > believe it > can come later. The politics behind this JSR have slowed it down to a > > crawl, and I think it's is best for version 1.0 to get out the door > as soon > as possible, so that work may start on the foundation that's been > laid out. > I must respectfully disagree that it's best to just push this spec out the door. You can't position yourself for the future if the foundation is not set properly and I am asserting that it is not. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP Portlet with Applet
In doing some more tests it appears that the display problem is related to declaring the applet width as 100% in conjunction with nesting it in a table tag. If I declare the applet width as a fixed number of pixels then the applet will display in a tag. This is rather limiting. When using applet width set to 100% it will only display if it is not nested inside any tags. Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > I looking at the applet tag in the page source I can see that it is > sitting in a construction like so: > > > > > > > > > > So I did a little experimentation with applets and table tags and > found that applets will not display in the above type of layout. But > they will display in a table if you just remove the enclosing > tag > so it looks like this: > > > > > > > > Don't know why the tag is a problem, but it is. Anyone know > how > we can get Jetspeed to quit putting the tag around the > tag? > > thx, > Gerry Reno > > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > Ok, with a slight variance on the codebase ( just 'applets' ) the > > applet is loading and starting. However there is another problem - > > the > > applet does not display. I can see in the Java Console that it is > > running and doing all the things that it should be doing but no > > display. I've tried this under a couple different versions of > Tomcat > > and same thing on all of them. I checked the page source and the > > applet tag is there and all the parameters are right but I don't > see > > the applet. > > > > Any suggestions? > > > > thx, > > Gerry Reno > > > > > > --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > > > > > You cannot calculate the codebase relative to the Portlet JSP > > > because this JSP is not accessed directly by the browser. > > > > > > The codebase must be relative to the jetspeed servlet URI, which > > > is /jetspeed/portal/ by default, thus your codebase should > > > certainly be only "../applets", and this will work wherever your > > > portlet JSPs are located :) > > > > > > -- > > > Raphaël Luta - [EMAIL PROTECTED] > > > Jakarta Jetspeed - Enterprise Portal in Java > > > http://jakarta.apache.org/jetspeed/ > > > > > > > > > > -Message d'origine- > > > > De : Gerry Reno [mailto:[EMAIL PROTECTED] > > > > Envoyé : dimanche 3 août 2003 22:33 > > > > À : Jetspeed Users List > > > > Objet : JSP Portlet with Applet > > > > > > > > > > > > Env: > > > > RH8.0 > > > > J2SE 1.4.2 > > > > Tomcat 4.1.24 > > > > Jetspeed 1.4b4 > > > > > > > > I am seeing strange behavior when trying to use an applet in > a > > > JSP > > > > Portlet. The entries in my jsp file within the applet tag are: > > > > > > > > > > > code="com.domain.applet.MyApplet.class" > > > > codebase="../../../../../applets" > > > >archive="domain-applets-myapplet.jar, > > > >../lib/jjj.jar, > > > > " > > > > ... > > > > > > > > > > > > The codebase is set this way due to the jsp file being in the > > > > WEB-INF/templates/jsp/portlets/html/ directory. The codebase > for > > > an > > > > applet is calculated relative to the html/jsp file containing > the > > > > applet tag. > > > > > > > > > > > > Using Mozilla from Linux: > > > > The Java Console shows the following output: > > > > Loading applet ... > > > > Initializing applet ... > > > > Starting applet ... > > > > Connecting > > > > > > > > > > http://localhost:8080/../../../../applets/domain-applets-myapplet.jar > > > > with no proxy > > > > Connecting > > > > > > > > > > http://localhost:8080/../../../../applets/domain-applets-myapplet.jar > > > > with cookie " " > > > > Connecting > > http://localhost:8080/../../../../applets/../lib/jjj.jar > > > > with no proxy > > > > Connecting > > http://localhost:8080/../../../../applets/../lib/jjj.jar > > > > with cookie &quo
RE: JSP Portlet with Applet
I looking at the applet tag in the page source I can see that it is sitting in a construction like so: So I did a little experimentation with applets and table tags and found that applets will not display in the above type of layout. But they will display in a table if you just remove the enclosing tag so it looks like this: Don't know why the tag is a problem, but it is. Anyone know how we can get Jetspeed to quit putting the tag around the tag? thx, Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Ok, with a slight variance on the codebase ( just 'applets' ) the > applet is loading and starting. However there is another problem - > the > applet does not display. I can see in the Java Console that it is > running and doing all the things that it should be doing but no > display. I've tried this under a couple different versions of Tomcat > and same thing on all of them. I checked the page source and the > applet tag is there and all the parameters are right but I don't see > the applet. > > Any suggestions? > > thx, > Gerry Reno > > > --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > > > You cannot calculate the codebase relative to the Portlet JSP > > because this JSP is not accessed directly by the browser. > > > > The codebase must be relative to the jetspeed servlet URI, which > > is /jetspeed/portal/ by default, thus your codebase should > > certainly be only "../applets", and this will work wherever your > > portlet JSPs are located :) > > > > -- > > Raphaël Luta - [EMAIL PROTECTED] > > Jakarta Jetspeed - Enterprise Portal in Java > > http://jakarta.apache.org/jetspeed/ > > > > > > > -Message d'origine- > > > De : Gerry Reno [mailto:[EMAIL PROTECTED] > > > Envoyé : dimanche 3 août 2003 22:33 > > > À : Jetspeed Users List > > > Objet : JSP Portlet with Applet > > > > > > > > > Env: > > > RH8.0 > > > J2SE 1.4.2 > > > Tomcat 4.1.24 > > > Jetspeed 1.4b4 > > > > > > I am seeing strange behavior when trying to use an applet in a > > JSP > > > Portlet. The entries in my jsp file within the applet tag are: > > > > > > > > code="com.domain.applet.MyApplet.class" > > > codebase="../../../../../applets" > > >archive="domain-applets-myapplet.jar, > > >../lib/jjj.jar, > > > " > > > ... > > > > > > > > > The codebase is set this way due to the jsp file being in the > > > WEB-INF/templates/jsp/portlets/html/ directory. The codebase for > > an > > > applet is calculated relative to the html/jsp file containing the > > > applet tag. > > > > > > > > > Using Mozilla from Linux: > > > The Java Console shows the following output: > > > Loading applet ... > > > Initializing applet ... > > > Starting applet ... > > > Connecting > > > > > > http://localhost:8080/../../../../applets/domain-applets-myapplet.jar > > > with no proxy > > > Connecting > > > > > > http://localhost:8080/../../../../applets/domain-applets-myapplet.jar > > > with cookie " " > > > Connecting > http://localhost:8080/../../../../applets/../lib/jjj.jar > > > with no proxy > > > Connecting > http://localhost:8080/../../../../applets/../lib/jjj.jar > > > with cookie " " > > > Connecting > > > http://localhost:8080/../../../../applets/com/domain/applet/My > > > Applet.class > > > with no proxy > > > Connecting > > > http://localhost:8080/../../../../applets/com/domain/applet/My > > > Applet.class > > > with cookie " " > > > Connecting > > > http://localhost:8080/../../../../applets/com/domain/applet/My > > > Applet/class.class > > > with no proxy > > > Connecting > > > http://localhost:8080/../../../../applets/com/domain/applet/My > > Applet/class.class > > with cookie " " > > load: class com.domain.applet.MyApplet.class not found. > > java.lang.ClassNotFoundException: com.domain.applet.MyApplet.class > > at > > sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:154) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:289) > > at > > sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:115) > >
RE: JSP Portlet with Applet
Ok, with a slight variance on the codebase ( just 'applets' ) the applet is loading and starting. However there is another problem - the applet does not display. I can see in the Java Console that it is running and doing all the things that it should be doing but no display. I've tried this under a couple different versions of Tomcat and same thing on all of them. I checked the page source and the applet tag is there and all the parameters are right but I don't see the applet. Any suggestions? thx, Gerry Reno --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > You cannot calculate the codebase relative to the Portlet JSP > because this JSP is not accessed directly by the browser. > > The codebase must be relative to the jetspeed servlet URI, which > is /jetspeed/portal/ by default, thus your codebase should > certainly be only "../applets", and this will work wherever your > portlet JSPs are located :) > > -- > Raphaël Luta - [EMAIL PROTECTED] > Jakarta Jetspeed - Enterprise Portal in Java > http://jakarta.apache.org/jetspeed/ > > > > -Message d'origine- > > De : Gerry Reno [mailto:[EMAIL PROTECTED] > > Envoyé : dimanche 3 août 2003 22:33 > > À : Jetspeed Users List > > Objet : JSP Portlet with Applet > > > > > > Env: > > RH8.0 > > J2SE 1.4.2 > > Tomcat 4.1.24 > > Jetspeed 1.4b4 > > > > I am seeing strange behavior when trying to use an applet in a > JSP > > Portlet. The entries in my jsp file within the applet tag are: > > > > > code="com.domain.applet.MyApplet.class" > > codebase="../../../../../applets" > >archive="domain-applets-myapplet.jar, > >../lib/jjj.jar, > > " > > ... > > > > > > The codebase is set this way due to the jsp file being in the > > WEB-INF/templates/jsp/portlets/html/ directory. The codebase for > an > > applet is calculated relative to the html/jsp file containing the > > applet tag. > > > > > > Using Mozilla from Linux: > > The Java Console shows the following output: > > Loading applet ... > > Initializing applet ... > > Starting applet ... > > Connecting > > > http://localhost:8080/../../../../applets/domain-applets-myapplet.jar > > with no proxy > > Connecting > > > http://localhost:8080/../../../../applets/domain-applets-myapplet.jar > > with cookie " " > > Connecting http://localhost:8080/../../../../applets/../lib/jjj.jar > > with no proxy > > Connecting http://localhost:8080/../../../../applets/../lib/jjj.jar > > with cookie " " > > Connecting > > http://localhost:8080/../../../../applets/com/domain/applet/My > > Applet.class > > with no proxy > > Connecting > > http://localhost:8080/../../../../applets/com/domain/applet/My > > Applet.class > > with cookie " " > > Connecting > > http://localhost:8080/../../../../applets/com/domain/applet/My > > Applet/class.class > > with no proxy > > Connecting > > http://localhost:8080/../../../../applets/com/domain/applet/My > Applet/class.class > with cookie " " > load: class com.domain.applet.MyApplet.class not found. > java.lang.ClassNotFoundException: com.domain.applet.MyApplet.class > at > sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:154) > at java.lang.ClassLoader.loadClass(ClassLoader.java:289) > at > sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:115) > at java.lang.ClassLoader.loadClass(ClassLoader.java:235) > at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:558) > at sun.applet.AppletPanel.createApplet(AppletPanel.java:617) > at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1848) > at sun.applet.AppletPanel.runLoader(AppletPanel.java:546) > at sun.applet.AppletPanel.run(AppletPanel.java:298) > at java.lang.Thread.run(Thread.java:534) > Caused by: java.io.IOException: open HTTP connection failed. > at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:257) > at > sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:43) > at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:144) > at java.security.AccessController.doPrivileged(Native Method) > at > sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:141) > ... 9 more > Exception: java.lang.ClassNotFoundException: > com.domain.applet.MyApplet.class > > > Using IE6 under Windows: > The Java
JSP Portlet with Applet
Env: RH8.0 J2SE 1.4.2 Tomcat 4.1.24 Jetspeed 1.4b4 I am seeing strange behavior when trying to use an applet in a JSP Portlet. The entries in my jsp file within the applet tag are: The codebase is set this way due to the jsp file being in the WEB-INF/templates/jsp/portlets/html/ directory. The codebase for an applet is calculated relative to the html/jsp file containing the applet tag. Using Mozilla from Linux: The Java Console shows the following output: Loading applet ... Initializing applet ... Starting applet ... Connecting http://localhost:8080/../../../../applets/domain-applets-myapplet.jar with no proxy Connecting http://localhost:8080/../../../../applets/domain-applets-myapplet.jar with cookie " " Connecting http://localhost:8080/../../../../applets/../lib/jjj.jar with no proxy Connecting http://localhost:8080/../../../../applets/../lib/jjj.jar with cookie " " Connecting http://localhost:8080/../../../../applets/com/domain/applet/MyApplet.class with no proxy Connecting http://localhost:8080/../../../../applets/com/domain/applet/MyApplet.class with cookie " " Connecting http://localhost:8080/../../../../applets/com/domain/applet/MyApplet/class.class with no proxy Connecting http://localhost:8080/../../../../applets/com/domain/applet/MyApplet/class.class with cookie " " load: class com.domain.applet.MyApplet.class not found. java.lang.ClassNotFoundException: com.domain.applet.MyApplet.class at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:154) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:115) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:558) at sun.applet.AppletPanel.createApplet(AppletPanel.java:617) at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1848) at sun.applet.AppletPanel.runLoader(AppletPanel.java:546) at sun.applet.AppletPanel.run(AppletPanel.java:298) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.IOException: open HTTP connection failed. at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:257) at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:43) at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:144) at java.security.AccessController.doPrivileged(Native Method) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:141) ... 9 more Exception: java.lang.ClassNotFoundException: com.domain.applet.MyApplet.class Using IE6 under Windows: The Java Console shows the following output: java.io.FileNotFoundException: http://localhost:8080/applets/domain-applets-myapplet.jar From the Java Console output it appears as though the portlet is running the jsp file from http://localhost:8080 for Mozilla (and is cutting off one of the "../" in the codebase) and from http://localhost:8080 for IE6 (and is ignoring the ../../../../../ leading path altogether) rather than from the template directory where it is stored. This is not good. It means that for any applet we cannot calculate codebase paths relative to the jsp file which is what you are supposed to do when using an applet. BTW, my applet works correctly in an iframe portlet in both browsers. Has anyone had any success displaying an applet from a JSP Portlet? thx, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems with .xreg updating
You might try just doing a reload on your jetspeed webapp in Tomcat manager. That might work. Gerry Reno --- Jason Weiss <[EMAIL PROTECTED]> wrote: > Is there a flag that can be set in some .properties file to make the > changes go to disk immediately? The problem I have is what if a > number of > portlets were added or ?? and suddenly the server loses power. That > 30 > minutes of work may have been lost all because the info was cached > in-memory. > > Jason > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 1:10 AM > To: [EMAIL PROTECTED] > Subject: AW: problems with .xreg updating > > > It works! > Thanks a lot!!! > > -Ursprüngliche Nachricht- > Von: Gerry Reno [mailto:[EMAIL PROTECTED] > Gesendet am: Freitag, 25. Juli 2003 17:20 > An: Jetspeed Users List > Betreff: Re: problems with .xreg updating > > The registry files are written out on shutdown. Before making > changes > make sure that you have shutdown Tomcat, then make your changes, then > restart Tomcat and you should see your changes. > > Gerry Reno > > --- [EMAIL PROTECTED] wrote: > > Hi! > > > > I have a problem with the updating of my .xreg files, especially > with > > my local-portlets.xreg! I have modified the database-browse-portlet > > > and tried to register my new modified portlet in the > > local-portlets.xreg. This was no problem at all, but now i want to > > change the sql statement in this new portlet-entry. This seems to > be a > > big problem. > > > > First I can't recognise a change in the portlet, when i save the > > modified local-portlets.xreg. How can I "refresh" the view? > > > > Second if I restart the whole tomcat (to be sure to see my > changes), > > my old local-portlets.xreg is restored as if I've never changed it. > So > > the portlet also doesn't change in any way. Even if I delete the > whole > > local-portlets.xreg the file appears after a restart of the tomcat > > again. > > > > I've no idea how to solve this problem. > > Thanks for any help! > > > > My portlet-entry in the local-portlets.xreg: > > > > > parent="DatabaseBrowserPortlet" application="false"> > > > > News > > Simple Test Database Browser by > > Edi > > > > > > > org.apache.jetspeed.portal.portlets.browser.DatabaseBrowserPort > let > > > value="edis-database-browser-portlet" > > hidden="true" cachedOnName="true" > cachedOnValue="true"/> > > > value="database-browser-customize" hidden="true" > > cachedOnName="true" cachedOnValue="true"/> > > > value="portlets.browser.DatabaseBrowserAction" > > hidden="true" > > cachedOnName="true" cachedOnValue="true"/> > > > value="select newsdate, newscontent from news" > > hidden="false" cachedOnName="true" > cachedOnValue="true"/> > > > cachedOnName="true" cachedOnValue="true"/> > > > > > > database > > > > > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > - > 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] > > > ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange window/frame targeting:K@N@!:
Ok. This appears to be a Mozilla 1.0.1 problem. I tried some other browsers and they don't have this problem. Guess it's time to upgrade Mozilla. Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > I have a portlet that has some links that have a target attribute > set > to a framename. I have two webservers that I"m working with, one > dev, > one test. I am getting some strange behavior when I am accessing the > same portal on both webservers. The links are becoming confused and > one of the portlets links start displaying the linked content in the > frame in the browser from the opposite webserver that is on a > different > domain name (different IP). Is this a Jetspeed bug, or a browser > bug? > Or is there someway to ensure that the frame that the link target is > referencing means 'for this domain'? > > BROWSER BROWSER > domain-A(dev) portal-Adomain-B(test) portal-A > --- - > | link1 | FRAME | | link2 | FRAME| > | | | | | | > | | link1 should| | | link1 displays | > | | display here| | | here instead | > | | | | | | > --- - > > Environment: > Linux RH8.0 > Mozilla browser 1.0.1 > J2SE 1.4.2 > Tomcat 4.1.24 > Jetspeed 1.4b4 > > thx, > Gerry Reno > > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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]
Re: Strange window/frame targeting
Ok. This appears to be a Mozilla 1.0.1 problem. I tried some other browsers and they don't have this problem. Guess it's time to upgrade Mozilla. Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > I have a portlet that has some links that have a target attribute > set > to a framename. I have two webservers that I"m working with, one > dev, > one test. I am getting some strange behavior when I am accessing the > same portal on both webservers. The links are becoming confused and > one of the portlets links start displaying the linked content in the > frame in the browser from the opposite webserver that is on a > different > domain name (different IP). Is this a Jetspeed bug, or a browser > bug? > Or is there someway to ensure that the frame that the link target is > referencing means 'for this domain'? > > BROWSER BROWSER > domain-A(dev) portal-Adomain-B(test) portal-A > --- - > | link1 | FRAME | | link2 | FRAME| > | | | | | | > | | link1 should| | | link1 displays | > | | display here| | | here instead | > | | | | | | > --- - > > Environment: > Linux RH8.0 > Mozilla browser 1.0.1 > J2SE 1.4.2 > Tomcat 4.1.24 > Jetspeed 1.4b4 > > thx, > Gerry Reno > > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strange window/frame targeting
I have a portlet that has some links that have a target attribute set to a framename. I have two webservers that I"m working with, one dev, one test. I am getting some strange behavior when I am accessing the same portal on both webservers. The links are becoming confused and one of the portlets links start displaying the linked content in the frame in the browser from the opposite webserver that is on a different domain name (different IP). Is this a Jetspeed bug, or a browser bug? Or is there someway to ensure that the frame that the link target is referencing means 'for this domain'? BROWSER BROWSER domain-A(dev) portal-Adomain-B(test) portal-A --- - | link1 | FRAME | | link2 | FRAME| | | | | | | | | link1 should| | | link1 displays | | | display here| | | here instead | | | | | | | --- - Environment: Linux RH8.0 Mozilla browser 1.0.1 J2SE 1.4.2 Tomcat 4.1.24 Jetspeed 1.4b4 thx, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
