Re: HEADS UP: Migration of jetspeed repositories to subversion

[Ate Douma]

Santiago Gala wrote:
I created a JIRA issue WRT the migration of lists from
jakarta.apache.org to portals.apache.org and moving jetspeed
repositories from cvs to subversion:
http://issues.apache.org/jira/browse/INFRA-302
We are trying to set up a schedule for the migration. The moment seems
good, I hope nobody has real issues with subversion now that there is a
eclipse plugin and support has greatly improved.
If nobody has major problems we can proceed with the migration.
WDYT?
+1, ASAP
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: found fusion/pluto interaction bug

[Ate Douma]

Fabrice,

First of all, thanks for diving into this problem.
I try to answer below but bear in mind I'm doing it just from the head as
my laptop crashed this morning and I'm in the middle of trying to recover
from it what I can...

Fabrice Dewasmes said:
 Hi all,

 this mail should be of particular interest for David and Ate.

 A few days ago I posted msg15905.html entitled Something weird happening
 with
 fusion/pluto. In fact the navigational state IS the cause of the problem.
 I'd
 like to have your opinion about how to workaround this as several
 solutions are
 possible. Before explaining the solutions, here is the problem :

 When you want to set the action of a form or have a link calling a portlet
 action you must use either a portlet:actionURL or use
 response.createActiontURL() method. This in turns calls the
 PathInfoEncodingPortalURL which extends AbstractPortalURL. This
 implementation
 of AbstractPortalURL adds a _ns:xxx element ni the request URL just after
 contextPath+servletPath (this is for example /jetspeed/portal/) and then
 appends the rest of the original request. This gives something like this :
 /jetspeed/portal/_ns:xx/media-type/html/user/admin/page/new.psml/js_peid/PXXX

 BUT the problem is that turbine reads the URL to get its parameter hashmap
 ready
 this way : first element after context path + servlet path is meant to be
 parameter name, and then URL is supposed to be constructed as an
 alternance
 between paramter names and parameters values. This means that if you have
 such
 a (normal jetspeed)URL :

 /jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXX

 the resulting hashmap will be :

 {
 media-type=html
 user=admin
 page=news.psml
 js_peid=PXXX
 }

 but it the case of the URL returned by pluto, eveything is mixed up
 because
 first element is navigational state which is not what turbine expects and
 has
 nothing to do with a key value pair. This leads to such a hashmap :

 {
 _ns:xx=media-type
 html=user
 admin=page
 js_peid=news.psml
 PXX=
 }

 and of course when jetspeed wants to get the profile, it uses the
 parameters
 found in runData object and searches for the page parameter which it
 doesn't
 find. Jetspeed then constructs a default profile, pointing to default.psml
 page. And this is why when you click on an action button in a JSR168
 portlet
 contained in a PSML page which is NOT default.psml you get redirected to
 default.psml page (which is of course not what we want).

 Now possible solutions are :

 - rewrite DefaultJetspeedParameterParser and override setRequest method so
 that
 it ignores the _ns:XXX element in URL (if it exists) and begins parsing
 right
 after. This is not very elegant and is clearly a workaround
 - Maybe configure pluto to use QueryStringEncodingPortalURL implementation
 of
 AbstractPortletURL so that ns is put as a paramter in the URL. But I would
 know
 how this is done in JSFusion and I don't know if jetspeed will be happy
 with
 this knew and unknown parameter.

I think for just testing out your solution, the last option is the easiest
and quickest to realize and test (in the end, the first might be the
better solution or maybe even another, but for that I'll have to
investigate this first).

Using the QueryStringEncodingPortalURL is configured against Jetspeed, not
Pluto.
You should be able to do so in the jetspeed-spring.xml under
WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition.
One of the constructor arguments (I think the second) defined the
PortalURL implementation to use.

Just try it out. If it solves your problem we will try to define the real
solution after that.

Regards, Ate



 Question is : Ate and David what do you think about the best way to
 circumvent
 this? Do you think it's possible to tell pluto not to add the ns element
 at all
 ?

 Thanks for your help

 Fabrice

 -
 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]

[Fwd: Re: found fusion/pluto interaction bug]

[Ate Douma]

Sorry, didn't notice at first I responded to Fabrice directly and not to
the list.

 Original Message 
Subject: Re: found fusion/pluto interaction bug
From:Ate Douma [EMAIL PROTECTED]
Date:Tue, April 12, 2005 17:44
To:  Fabrice Dewasmes [EMAIL PROTECTED]
--

Fabrice Dewasmes said:
 Hi,


 I think for just testing out your solution, the last option is the easiest
 and quickest to realize and test (in the end, the first might be the
better solution or maybe even another, but for that I'll have to
investigate this first).

 Using the QueryStringEncodingPortalURL is configured against Jetspeed, not
 Pluto.
 You should be able to do so in the jetspeed-spring.xml under
 WEB-INF/assembly. Lookup the NavigationalStateComponent bean
definition. One of the constructor arguments (I think the second)
defined the PortalURL implementation to use.


 yes I found this parameter just after having sent my email.


 Just try it out. If it solves your problem we will try to define the real
 solution after that.

 Changing navaigational state component strategy works like a charm.
Great!

 The only thing I'm unsure is (but I will have to double check
 QueryStringEncodingPortalURL) how this class handles previously existing
parameter in the URL: are they preserved ?
Yes. No difference there.
 Anyway, maybe that we should look for a better way to circumvent the
problem.
I agree.


 What's your opinion ?
I don't have any at the moment. I would need time to investigate this
more, but I won't have time for that before the end of this week.
I expect that David will be able to give a better response (if he reads
the mailing list today, I know he too is covered in work till at least
Thursday).

Regards,

Ate

 regards

 Fabrice


 Regards, Ate

 
 
  Question is : Ate and David what do you think about the best way to
circumvent
  this? Do you think it's possible to tell pluto not to add the ns
 element
  at all
  ?
 
  Thanks for your help
 
  Fabrice
 
  -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
 
 


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




 --





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

Re: Struts Bridge - ActionRequest Related Question

[Ate Douma]

Shah Amit wrote:
...
  init-param
nameViewPage/name
value/r5prAction.do?dispatch=loadDropDowns/name
  /init-param
...
This is ok.
javascript
location='html:rewrite href=/r5prAction.do/';
location=location+?dispatch=loadSecondDropdown
/javascript
This is not ok!
You *must* encode the dispatch=loadSecondDropdown parameter using
the html:rewrite tag itself, *not* append it yourself.
Remember, the Struts Bridge versions of the html tags are created to deliver
a PortletURL. A PortletURL cannot be treated like a normal url as it (can) 
encode
much more than parameters for just your request, it might also need to encode 
the state
of other portlets on the same page. Your postfixed parameter won't be
recognized and thus not remembered by the portal, hence the error message.
Check the Struts documentation for the html:rewrite tag:
  http://struts.apache.org/userGuide/struts-html.html#rewrite
You'll find out its easy to embed your parameters using the paramId and 
paramName
(and possibly paramProperty) attributes.

Now all of this works fine for the first time. I am able to click on the 
link from the menu-navigation system and come to this page, and then the 
dropdowns behave properly. But the thing is, once I fire an OnChange on 
any of the dropdowns, if I try to click on the maximize, minize buttons 
of the portlet, or even try to re-enter the portlet with the link from 
the menu-navigation system, I get the following error --

Request[/r5prAction.do] does not contain handler parameter named 
'dispatch'.

I guess something is happening and I am loosing the dispatch 
parameter. But the thing is, as long as I haven't fired the onChange of 
the dropdown, meaning - as long as the window.top.location has not been 
called, I can click on maximize, minimize buttons and everything else 
works great. Its only that once I fire the window.top.location, I start 
getting this error. And after that, I have to logout and log back in.

I tried everything I can, but I can't figure out why this is happening. 
The problem is I want to use DispatchAction so that I dont have to write 
lot of classes for the same jsp. Also very sorry for such a long email.

Please help 
Thanks,
Amit

-
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: true?

[Ate Douma]

Indeed, this has been implemented a long time ago already.
Thanks for bringing this to our attention. I've immediately corrected the text!
Regards, Ate
Frank Villarreal wrote:
it works ... i believe since release M1.  That file needs to be updated.

-Original Message-
From: Sascha Glass [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 09, 2005 10:32 AM
To: jetspeed-user@jakarta.apache.org
Subject: true?
Hello,
to deploy a portlet the Jetspeed 2 Wiki says: 
Copy the .war file to Jetspeed's deployment directory, by default this
is WEB-INF/deploy. Jetspeed will take care of automatically deplying the
portlet into the portlet registry and will also deploy the portlet as a
web application into the app server Jetspeed is deployed to.

Is this true? Because in this directory ist a Readme.txt that says:
This is were you things to be deployed to Jetspeed (not implemented
yet)
In case it is not true, how does it work then?
Any help is very apprechiated!
Sascha
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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



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

Re: Problems deploying Jetspeed2 into Jboss 3.2.7

[Ate Douma]

Katie,
I'm not sure which instruction you've followed from the wiki for installing on
JBoss as its becoming a very complex set for all the different versions of JBoss
and J2 (M1 and/or M2). I think Tom Pesendorfer has done a great job in trying to
describe all the possible issues and resolutions, but I find it difficult to 
check
if its complete and valid.
I hope to add streamlined installation instructions for JBoss to the main 
documentation
(or update/cleanup the wiki) later this month (one of my major targets for 
J2-M3).
For now, I'd like to point you out the instructions I added to the end of the
JIRA issue JS2-210: http://issues.apache.org/jira/browse/JS2-210.
I wrote those when I tested the new deployment model on JBoss and is valid for
the current M2 release.
In your logging below, I can't find anything wrong (its only INFO level 
messages)
and looks as you should expect. So if it isn't working (and you can't resolve it
by following my instructions from JS2-210) please give a more detailed 
description
of what is *not* working and/or error log messages.
Good luck, Ate
Katie Wilkie wrote:
Hi,
I'm having problems deploying Jetspeed2 into Jboss 3.2.7. I followed all of
the instructions on the wiki using a binary distribution of J2 M2. The first
time I tried to start Jboss I received errors about the database version
being out of date. I removed the hsqldb.1.7.1 jar from the servers lib
directory and replaced it with the original hsqldb jar which came with the
Jboss installation. Now when I start up Jboss, it gets so far and then
sticks when trying to deploy J2. The Jboss output sticks here: 

10:36:04,899 INFO  [TomcatDeployer] deploy, ctxPath=/jetspeed,
warUrl=file:/C:/jboss/server/gtx/deploy/jetspeed.war
/
10:36:06,446 INFO  [ContextConfig] WARNING: Security role name admin used in
an auth-constraint without being defined in a security-
role
10:36:06,508 INFO  [console] Jetspeed Starting Initialization...
10:36:06,540 INFO  [console] JetspeedServlet identifying web application
root...
10:36:06,555 INFO  [console] JetspeedServlet identifed web application root
as C:\jboss\server\gtx\deploy\jetspeed.
war\
10:36:06,946 INFO  [console] JetspeedServlet attempting to create the
portlet engine...
10:36:06,977 INFO  [Jetspeed] Jetspeed environment attempting to initialize
portal Engine...
10:36:10,633 INFO  [STDOUT]  INFO: Starting auto deployment service:
org.apache.jetspeed.deployment.impl.StandardDeploymentManager
10:36:10,633 INFO  [STDOUT]  INFO: Deployment scanning delay: 1
10:36:10,633 INFO  [STDOUT]  INFO: Deployment staging directory:
C:\jboss\server\gtx\deploy\jetspeed.war/WEB-INF/de
ploy
10:36:10,633 INFO  [STDOUT]  INFO: Adding
file:/C:/jboss/server/gtx/deploy/jetspeed.war/WEB-INF/apps/jetspeed-layou
ts/WEB-INF/classes/ to class path for Local PA jetspeed-layouts
10:36:10,633 INFO  [STDOUT]  INFO: Adding
file:/C:/jboss/server/gtx/deploy/jetspeed.war/WEB-INF/apps/jetspeed-layou
ts/WEB-INF/lib/portals-bridges-velocity-0.2.jar to class path for Local PA
jetspeed-layouts
The J2 deployment log shows: 

2005-04-08 10:36:10,633 [main] INFO  deployment - Starting auto deployment
service: org.apache.jetspeed.deployment.impl.StandardDeploymentManager
2005-04-08 10:36:10,633 [main] INFO  deployment - Deployment scanning delay:
1
2005-04-08 10:36:10,633 [main] INFO  deployment - Deployment staging
directory: C:\jboss\server\gtx\deploy\jetspeed.war/WEB-INF/deploy
2005-04-08 10:36:10,633 [main] INFO  deployment - Adding
file:/C:/jboss/server/gtx/deploy/jetspeed.war/WEB-INF/apps/jetspeed-layouts/
WEB-INF/classes/ to class path for Local PA jetspeed-layouts
2005-04-08 10:36:10,633 [main] INFO  deployment - Adding
file:/C:/jboss/server/gtx/deploy/jetspeed.war/WEB-INF/apps/jetspeed-layouts/
WEB-INF/lib/portals-bridges-velocity-0.2.jar to class path for Local PA
jetspeed-layouts
And the last few entries of the J2 log are: 

2005-04-08 10:36:10,540 [main] INFO
org.apache.jetspeed.profiler.impl.JetspeedProfilerImpl - Merging OJB
respository
jar:file:/C:/jboss/server/gtx/deploy/jetspeed.war/WEB-INF/lib/jetspeed-profi
ler-2.0-M2.jar!/META-INF/profiler-ojb.xml for DAO class
org.apache.jetspeed.profiler.impl.JetspeedProfilerImpl
2005-04-08 10:36:10,571 [main] INFO
org.springframework.beans.factory.support.DefaultListableBeanFactory -
Creating shared instance of singleton bean
'org.apache.jetspeed.sso.SSOProvider'
2005-04-08 10:36:10,571 [main] INFO
org.springframework.beans.factory.support.DefaultListableBeanFactory -
Creating shared instance of singleton bean 'PersistenceBrokerSSOProvider'
2005-04-08 10:36:10,586 [main] INFO
org.apache.jetspeed.sso.impl.PersistenceBrokerSSOProvider - Merging OJB
respository
jar:file:/C:/jboss/server/gtx/deploy/jetspeed.war/WEB-INF/lib/jetspeed-sso-2
.0-M2.jar!/META-INF/sso_repository.xml for DAO class
org.apache.jetspeed.sso.impl.PersistenceBrokerSSOProvider
2005-04-08 10:36:10,602 [main] INFO
org.springframework.beans.factory.support.DefaultListableBeanFactory -
Creating 

Re: missing dependency for Jetspeed 1.6-dev (portals-bridges-common-0.2.jar)

[Ate Douma]

Roel van Dijk wrote:
Just checked out a fresh Jetspeed 1.6-dev from the CVS. Building it using
maven gives me this error:
  Attempting to download portals-bridges-common-0.2.jar.
  WARNING: Failed to download portals-bridges-common-0.2.jar.
  The build cannot continue because of the following unsatisfied dependency:
  portals-bridges-common-0.2.jar
Hm.. Where can I get this? (I still have 0.1)
I guess you're building with Fusion (org.apache.jetspeed.fusion=true in your
build.properties).
This weekend, Fusion is brought up to date with the just released 
Jetspeed-2.0.-M2
(see: 
http://www.mail-archive.com/jetspeed-user%40jakarta.apache.org/msg15983.html)
So, following the instructions for Fusion, you first have to build/install this
new milestone version of Jetspeed-2 first. The portals-bridges-common-0.2.jar 
will
be automatically installed then in your local maven repository.
Ate
Roel

-
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: missing dependency for Jetspeed 1.6-dev (portals-bridges-common-0.2.jar)

[Ate Douma]

Roel van Dijk wrote:
Ate said:
I guess you're building with Fusion
(org.apache.jetspeed.fusion=true in your
build.properties).

Actually, the default project.properties file that comes with 1.6-dev
states:
  org.apache.jetspeed.fusion=false
Check you're $USER_HOME/build.properties if you haven't defined it there
(it will override any project.properties).
I'll try and install M2 as a quick fix for now, thanks.
Roel

-
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: missing dependency for Jetspeed 1.6-dev (portals-bridges-common-0.2.jar)

[Ate Douma]

Ate Douma wrote:

Roel van Dijk wrote:
Check you're $USER_HOME/build.properties if you haven't defined it there
(it will override any project.properties).

I know, nothing about fusion in there either, but maven still tries to
download that jar file..
Ok. I'm gonna test this right now and correct this in the build script if
need be...
You are correct Roel.
Jetspeed-1 currently depends on this jar (and Jetspeed-2.0-M2 jars as well)
for building it even if you're not gonna build Fusion.
Because the portals-bridges-common-0.2.jar isn't available yet from
bluesunrise/maven repository you're having this problem.
I've thought out a solution which will effectively remove the dependencies
on both this jar and the other Jetspeed-2 jars, but I first need to consult
with David Sean Taylor about it.
So, we will have this fixed by tomorrow either with the jar available from
bluesunrise/maven or with the generic solution I have in mind.
Anyone running into this same problem today can mail me directly and I'll
send you this jar (as I can't send it through the mailing list).
Regards, Ate

Roel

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



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

.

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

Re: missing dependency for Jetspeed 1.6-dev (portals-bridges-common-0.2.jar)

[Ate Douma]

Hema Menon wrote:
Ate,
I am sorry, it is actually 0.3-dev jar not 0.3. I had to drag the
window to see the full name:(
Then you can simple copy it to portals-bridges-common-0.2.jar as it
hasn't changed yet (or build/install Jetspeed-2 M2).
Hema
On Apr 6, 2005 2:46 AM, Ate Douma [EMAIL PROTECTED] wrote:
Hema Menon wrote:
I am running into the same problem. I did build Jetspeed M2, the build
was successful. When M2 is built, I will get
portal-bridges-common-0.3.jar.
This I find odd.
If you checkout the current Jetspeed-2.0 cvs head, you *will* build
portals-bridges-common-0.3-dev.jar as the versions all are bumped up for the
following M3 release (definition in etc/artifact-versions.ent).
There isn't a version 0.3 yet.
If you build M2, you should end up with portals-bridges-common-0.2.jar.
I just checked and its build for me...

I've been looking in the config files for Jetspeed 1.6 to find out
where infact does it have the dependency with 0.2 version of
portal-bridges-commons. Could not find that out:(
Hema
On Apr 6, 2005 1:45 AM, Ate Douma [EMAIL PROTECTED] wrote:

Ate Douma wrote:

Roel van Dijk wrote:

Check you're $USER_HOME/build.properties if you haven't defined it there
(it will override any project.properties).

I know, nothing about fusion in there either, but maven still tries to
download that jar file..
Ok. I'm gonna test this right now and correct this in the build script if
need be...
You are correct Roel.
Jetspeed-1 currently depends on this jar (and Jetspeed-2.0-M2 jars as well)
for building it even if you're not gonna build Fusion.
Because the portals-bridges-common-0.2.jar isn't available yet from
bluesunrise/maven repository you're having this problem.
I've thought out a solution which will effectively remove the dependencies
on both this jar and the other Jetspeed-2 jars, but I first need to consult
with David Sean Taylor about it.
So, we will have this fixed by tomorrow either with the jar available from
bluesunrise/maven or with the generic solution I have in mind.
Anyone running into this same problem today can mail me directly and I'll
send you this jar (as I can't send it through the mailing list).
Regards, Ate

Roel

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



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

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



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




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

Re: Jetspeed 2.0 M2 Released

[Ate Douma]

Jouni Rajala wrote:
I am bit new to maven. Is it possible to check out this
milestone version with maven somehow. If it is could
you provide me exact command line :)
If you're after the source so you can build it and work on yourself
then it might be easier to download the source distribution for Jetspeed-2.0-M2.
You can download it from the same Apache Download Mirrors as indicated in the
announcement. Then follow the links to portals/jetspeed-2/SOURCES.
You will find the jetspeed-2.0-M2-src.zip/tar.gz distributions there.
David Sean Taylor wrote:
The Apache Portals Jetspeed Team is pleased to announce the second 
milestone release of Jetspeed-2.

The release is available for download from the Apache Download Mirrors:
http://www.apache.org/dyn/closer.cgi
Follow the links to portals/jetspeed-2
Two binary releases are provided.
1. Jetspeed-2 + Tomcat 5.0.30 distribution.
2. Jetspeed-2 + Tomcat 5.5.8 distribution.
With this second milestone of Jetspeed-2, new versions of the
Portals Bridges components are released as well. These components are 
now all upgraded to version 0.2. Portals Bridges can be used 
independently of Jetspeed-2 and will eventually migrate to its own 
Portals Bridges project.

Bridges released with M2:
* Struts Bridge 0.2
* Velocity Bridge 0.2
* JSF Bridge 0.2
* Perl Bridge 0.2
* PHP Bridge 0.2
* Portlet Framework 0.2
--
 Jetspeed 2.0-M2 Release
   April 4, 2005
--
* PALM - Portlet Application Lifecycle Manager
  A new administrative portlet for managing the lifecycle of portlet
  applications. Supports start, stop, undeploy and delete operations.
* JBoss Support
   Jetspeed tested and running on JBoss versions 3.2.7 and 4.0.1sp1
* New Improved Deployment
   Deployment overhauled to support application server
   controlled deployment. Class loader and cross-context session control
   issues resolved.
* Struts Bridge Enhancements
* Navigations Refactoring
* Enhanced credential security and validation,
  Login/Password Enhancements
* LDAP Authentication support added.
* Secure Access to Site Resources (Pages, Folders)
* Profiler, Layout, PSML Security Documentation
* SSO Enhancements
* Improved JSF Support
* Finer grain Spring configuration
* Main Jetspeed context no longer requires /jetspeed
---
Bug fixes
---
see M2-bugfixes.html
-
 Tested App Servers:
-
 * Tomcat 5.0.30
 * Tomcat 5.5.8
 * JBoss 3.2.7
 * JBoss 4.0.1sp1
 (Tomcat 5.5 requires a different jetspeed.xml found in the source 
tree under src/resources/jetspeed-tomcat-5.5.xml)

 Check out our wiki page for details: 
http://wiki.apache.org/portals/Jetspeed2

-
 NO Longer Supported:
-
 * Tomcat 4.1.x
Support for Tomcat 4.1.x has been dropped.
---
 Installation Instructions
---
1. Download jetspeed-2.0-M2-Tomcat-5.0.30.tar.gz, or
   Download jetspeed-2.0-M2-Tomcat-5.0.30.zip (windows), or
   Download jetspeed-2.0-M2-Tomcat-5.5.8.tar.gz, or
   Download jetspeed-2.0-M2-Tomcat-5.5.8.zip (windows)
2. Expand jetspeed-2.0-M2-Tomcat-version.tar.gz into a clean 
directory (as example we will use 'jetspeed')

   cd /jetspeed
   tar xfz jetspeed-2.0-M2-Tomcat-version.tar.gz
   For Windows:
   cd c:\jetspeed
   unzip jetspeed-2.0-M2-Tomcat-version.zip
3. start the database
   cd /jetspeed/jetspeed-database
   start-database.sh
   For Windows:
   cd c:\jetspeed\jetspeed-database
   start-database.bat
4. startup Tomcat
   execute /jetspeed/jakarta-tomcat-version/bin/startup.sh
   For Windows:
   execute c:\jetspeed\jakarta-tomcat-version\bin\startup.bat
5. start up a web browser and navigate to 
http://localhost:8080/jetspeed/portal

--
 Configuring Another Database
--
1. cd $TOMCAT_HOME/jetspeed-database/scripts
2. edit the build.properties, set the properties for your database 
connection, save.
3. create a database schema/catalog to hold your database tables
4. type 'ant' to run the database population scripts
5. edit the jetspeed.xml properties
- $TOMCAT_HOME/conf/Catalina/localhost/jetspeed.xml

and set your database connection
6. copy your database driver into Tomcat's common/endorsed directory
7. start up a web browser, navigate to 
http://localhost:8080/jetspeed/portal

 Sample accounts to login as:
 admin/admin
 manager/manager
 user/user

 Upgrading from Jetspeed 2.0 M1

If you are upgrading an installation from Jetspeed 2.0 M1,
remember to delete the M1 jar files found under Tomcat's shared/lib 
directory. The following files should be deleted:

jetspeed-api-2.0-M1.jar
jetspeed-commons-2.0-M1.jar
pluto-1.0.1-rc1.jar
portals-bridges-common-0.1.jar

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

Re: J2 how Undeploy app and how Reload app after change default-page.psml ???

[Ate Douma]

Vladimir Figurov wrote:
Hello!
I try use jetspeed2. I - beginner in jetspeed2
I have a next little questions:
Ferst question:
-How make UNdeploy the old or error portlet, without running maven 
quickStart allways??:

I read in 
http://wiki.apache.org/portals/Jetspeed2/DeployingCustomPortlets, 
chapter Undeployment what need simple DELETE MyApp.war from 
WEB-INF/deploy. But, I looking what after I placed a war in this 
catalog, J2 deleting  himself this war, modify his and placed 
MyApp-modify.war in CATALINA/webapps. Thus, I have already nothing to 
delete in the catalogue deploy
The Wiki information is outdated with the new M2 release. Undeployment
now can (and for the moment: must) be performed directly from the portal
using the new Portlet Application Lifecycle Manager (PALM) which you can
access if you login as admin. You can also stop/start portlet applications
from there which is handy if you need to restart after a manual change to
a configuration file or class files for example.
If I shall remove in manual CATALINA/webapps/MyApp-modify.war and 
CATALINA/webapps/MyApp, and then I shall put new WAR - J2 whence pulls 
out old.

And next question:
-after change [EMAIL PROTECTED] in jetspeed/WEB-INF/pages/default-page.psml 
and stay old [EMAIL PROTECTED] - J2 was run the old MyApp with [EMAIL PROTECTED] # 
newName ?!!
This is a know issue (we're going to work on that soon).
The mapping of a fragment id with a pa::portlet definition is stored in the 
database
(table PORTLET_ENTITY).
You can remove the entry from the database but then you'll have to restart 
Jetspeed.
The easiest solution right now is also using a unique new fragment id when you 
change
the configuration.

-
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: Jetspeed 2.0 M2 Released

[Ate Douma]

Jouni Rajala wrote:
Well i am using cvs head version now and like continue using
it. That way i can change version easily.
it is just that i don't know how to check out certain version or branch 
with maven.
Then take a look at http://maven.apache.org/reference/plugins/scm/
It only supports cvs and thus should work for Jetspeed-2 right now.
But, we're going to move to subversion soon and then you need another solution 
again.
Most users and the Jetspeed-2 team members use Eclipse for working with 
Jetspeed-2 though
and its very easy to checkout the source using its cvs plugin (or subclipse 
plugin for subversion).

--
Jouni Rajala
-
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: Building Jetspeed 2

[Ate Douma]

Under chosen mirror/portals/jetspeed-2 you will find two subfolders:
   BINARIES
   SOURCES
Under BINARIES you will find the files named like in the announcement.
The current versions are (right now at least) the same as those announced.
Steve B. wrote:
Small item - unless I am just looking in the wrong area...
Following the link provided for downloading the release,
   - select the suggested mirror
   - select portals
   - select jetspeed-2
   - the filenames are actually of the form:
 jetspeed-current-Tomcat-5.0.30.tar.gz 
http://apache.intissite.com/portals/jetspeed-2/jetspeed-current-Tomcat-5.0.30.tar.gz  
(or whatever version of tomcat you prefer)

The installation instructions (at the bottom of the release page) don't 
specify drilling down to the files, and the filenames are incorrect.

HTH,
Steve B.
Hema Menon wrote:
Jetspeed M2 version has just been released, you might want to try it
out. Information is here
http://www.mail-archive.com/jetspeed-user%40jakarta.apache.org/msg15983.html 

Hema
On Apr 5, 2005 9:02 AM, Sascha Glass [EMAIL PROTECTED] wrote:
 

Hello,
I am new to Jetspeed 2 and try to install it. I hope very much that
anybody can help me. I got to
http://portals.apache.org/jetspeed-2/getting-started.html and followed
the instructions at 1,2 and 3. Now I am at 4. Building Jetspeed 2. I
changed to the jetspeed-2-home directory
(C:\Sascha\Java\eclipse-workspace\jakarta-jetspeed-2) and typed maven
allClean allBuild.
Now I got this:
Starting the reactor...
BUILD FAILED
File.. C:\Sascha\Java\eclipse-workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line.. 103
Column 31
Error reading XML or initializing
...
Can anybody please help me?
With kind regards,
Sascha Glass
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  

 


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



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

Re: New Problem( was: Jetspeed Jars are *failing* to Download.)

[Ate Douma]

You probably deployed an older version of Jetspeed-2 (before M2)
to the same Tomcat installation. Check your $TOMCAT_HOME/shared/lib folder
and remove the jars from the older version.
Ate
Elam Daly wrote:
David Sean Taylor wrote:
Elam Daly wrote:
Howdy all,
Yesterday and today I've checked out the latest cvs tree for jetspeed 
to and ran a 'maven allClean allBuild' and am getting many 'failed to 
Download' errors:

You are a little ahead of me.
Just finished the M2 release (announcements coming shortly)
Going to start uploading the M3-dev jars to the remote maven repo in a 
few minutes.

In the meantime try building without -o, and the jars should be 
created automatically into your Maven repository



Hi Sean,
Now I have a new problem:
Encountered the following problem(s) while attmepting to render portlet 
fragment: dp-1
org.apache.jetspeed.factory.PortletFactory.getPortletApplicationClassLoader(Lorg/apache/jetspeed/om/common/portlet/PortletApplication;)Ljava/lang/ClassLoader; 

Elam Daly
-
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]

[J2] Getting the new pluto 1.0.1-rc2-patched jar

[Ate Douma]

I've been trying to download the new patched pluto jar from bluesunrise 
repository all day but without success.
Can someone who already has it downloaded mail it to me?
Note: I expect David to be online in an hour or two and I send him a mail too,
so after that it won't be needed anymore.
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [J2] Getting the new pluto 1.0.1-rc2-patched jar

[Ate Douma]

Forget about it: I finally got it downloaded :-)
Ate Douma wrote:
I've been trying to download the new patched pluto jar from bluesunrise 
repository all day but without success.
Can someone who already has it downloaded mail it to me?
Note: I expect David to be online in an hour or two and I send him a 
mail too,
so after that it won't be needed anymore.

Regards, Ate
-
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: Struts Bridge - ActionRequest Related Question

[Ate Douma]

You *must* be using action URLs because this warning is *only* displayed
from within processAction handling. Just make sure to use render URLs.
Shah Amit wrote:
Hi all,
Please pardon my stupidity with the Struts bridge. I have read the 
documentation several times, and I understand what it says. However I 
have a little bit trouble visualizing it in my scenerio.

I have a page with 3 dropdowns. Each dropdown has an onChange=submit 
thing and the secod dropdown is loaded based on value of first, third is 
loaded based on second. And then there is a table on the page that is 
loaded based on the selection of third dropdown.

I am using DispatchAction so that I have only one Action Class per page. 
Now this is an all display only page and actually the state is not 
being changed at all I think. In this case, for each form submission 
from the dropdowns, I am directly using render Actions and I dont have 
any forwards with redirects=true. Due to this I am getting a Warning 
from struts-bridge that -- Using the original action URL for render 
URL:  A redirect should have been issued. So in such scenerios, should 
I have a dummy action which does nothing and has a forward with 
redirect=true to my render action ??

I am sorry to ask this long question, but it is a little bit confusing 
to me .. :-(

Thanks,
Amit

-
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: Struts Bridge - ActionRequest Related Question

[Ate Douma]

Shah Amit wrote:
Hi Ate,
Thanks a lot for the quick reply.
I am submitting a form with html:form method=post 
action=/showPage.do and here is the action mapping

   action path=/showPage
   type=com.company.struts.actions.ViewerActions
   name=viewerForm scope=request validate=false 
parameter=dispatch
   forward name=success 
path=/WEB-INF/view/rule5/rule5viewer.jsp/
   /action

So probably my question would be is it possible to submit a form to a 
render URL at all ... I guess No ?? ... So in that case, I will have to 
use a dummy action with redirect=true ?? ..
You should not POST a form to a render URL.
Encode your parameter(s) in a renderURL (for example using the Struts Bridge 
RewriteTag)
and just point your browser url to it (setting window.top.location).

Thanks,
Amit
Original Message Follows
From: Ate Douma [EMAIL PROTECTED]
Reply-To: Jetspeed Users List jetspeed-user@jakarta.apache.org
To: Jetspeed Users List jetspeed-user@jakarta.apache.org
Subject: Re: Struts Bridge - ActionRequest Related Question
Date: Fri, 01 Apr 2005 16:56:58 +0200
You *must* be using action URLs because this warning is *only* displayed
from within processAction handling. Just make sure to use render URLs.
Shah Amit wrote:
Hi all,
Please pardon my stupidity with the Struts bridge. I have read the 
documentation several times, and I understand what it says. However I 
have a little bit trouble visualizing it in my scenerio.

I have a page with 3 dropdowns. Each dropdown has an onChange=submit 
thing and the secod dropdown is loaded based on value of first, third 
is loaded based on second. And then there is a table on the page that 
is loaded based on the selection of third dropdown.

I am using DispatchAction so that I have only one Action Class per 
page. Now this is an all display only page and actually the state is 
not being changed at all I think. In this case, for each form 
submission from the dropdowns, I am directly using render Actions and 
I dont have any forwards with redirects=true. Due to this I am 
getting a Warning from struts-bridge that -- Using the original 
action URL for render URL:  A redirect should have been issued. So in 
such scenerios, should I have a dummy action which does nothing and 
has a forward with redirect=true to my render action ??

I am sorry to ask this long question, but it is a little bit confusing 
to me .. :-(

Thanks,
Amit

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



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

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



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

Re: Enabling logging for Struts portal bridges

[Ate Douma]

Hema,
The log4j logging configuration *within* jetspeed can/is only be used
for *within* the jetspeed context.
While the current configuration file still contains definitions for
struts, myfaces etc., this is obsolete since we removed the global
commons-logging and log4j jars (in $Tomcat/shared/lib for example).
For your own portlet applications you must provide your own logging
setup like putting log4j (and commons-logging if you want) in WEB-INF/lib
and also provide your own log4j.properties/xml in WEB-INF/classes.
I'm going over the jetspeed log4j.properties right now and will clean out
several of these obsolete definitions as they definitely give the wrong signal.
Thanks for bringing this up ;-) It'll be another small improvement of the M2 
release.
Remark: I do think it would be nice if we *could* provide a generic logging 
service
for the portlet applications, but without getting into classloader problems on
different platforms, right now I don't have a solid solution ready
(although I have an idea which might work but it'll have to wait for now).
Regards, Ate
Hema Menon wrote:
I wanted to enable the logging for struts portal bridges. I added a
new  log4j category for org.apache.portals with DEBUG level and also
added a logfile definition . I find the log file is created but is
empty. Forgive my ignorance, but is there some other configurations
that I am missing? Any help very much appreciated.
Thanks,
Hema
~~
Hema Menon
-
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: J2 new deployment- How to undeploy an application?

[Ate Douma]

The new deployment model may seem more limited at first but actually its not.
The real change is that deployment really now is handled by the web/app server 
you
are using. What J2 deployment manager does when you drop a war in the deploy 
folder
is nothing more than rewriting the web.xml (if needed) so that the required
JetspeedContainerServlet is present. Then it simple *moves* the war file into 
the
configured webapp folder of the web/app server. That will take over from there.
If you have autodeploy enabled in your server it will happen automatically 
after that.
Note: you don't have to drop your war in the deploy folder if it is already 
properly
configured (infused J2 web.xml). You can do this yourself by hand (just look at 
the
changes J2 makes, there are only a few), or use the JetspeedDeploy tool, which 
is
a component in the components/deploy-tool folder. The JetspeedDeploy tool can 
be used
standalone to infuse your war offline.
A infused war can simply be dropped in your web/app server webapp folder and/or 
deployed
any other way your web/app server requires. For the same reason, you can (hot) 
deploy
an expanded *and infused* war yourself using the web/app server functionality.
Undeploy is now something which has to be performed by your web/app server as 
well.
For Tomcat, J2 can already handle this for you through the new PALM portlet (if 
you
configured it correctly like in the default configuration as it comes with J2).
But, you can do this directly from the Tomcat manager itself or through some 
other
way your web/app server supports.
What undeployment *not* does is unregistering the portlet application. This 
isn't
always wanted either because you lose possible stored preferences when you do.
But, the PALM portlet allows you to do this too through its delete function.
Because the delete function is web/app server independent its always available.
So, I hope you agree the new deployment model really brings more flexibility to
the way you can deploy your application. Only undeployment now requires a 
little more
effort (but then, how often do you really do a terminating undeployment).
Another benefit of this solution is the much shorter startup time you might have
noticed already (at least, after the initial deployment has been done).
Regards, Ate
Hema Menon wrote:
How can we undeploy an application with the new deployment model?
Previously you could delete the deployed war from the deploy directory
which would then unregister the application. With the new model, the
deployed WAR is removed from the deploy directory upon deployment. So
how can I undeploy an application?
Also, previous versions would allow you to have a war that is unpacked
to be added to the deploy directory. It appears that it is necessary
to have the application packaged as a WAR to be deployed. If the
unpacked directory is added, the application is not deployed, a
warning of Unrecognized file is displayed. I guess, it is now
necessary to have the application deployed as a WAR, which is OK, I
guess.
Thanks,
Hema

~~
Hema Menon
-
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]

J2/Fusion synchronization: step one done!

[Ate Douma]

Team and Fusion users,
I've committed an updated J1/Fusion in the J1 branch 
j2_deployment_refactoring_sync.
As far as I have been able to test, Fusion now runs with the current J2 CVS 
HEAD.
Please, make sure you update your J2 head first as I committed several changes 
to J2
too which are needed for Fusion.
Tested with Tomcat 5.0.28, 5.0.30 and 5.5.8. Tomcat 4 support is gone!
In J2, there is a new application PALM (Portlet Application Lifecycle 
Management).
You can deploy that on Fusion as replacement of the JSR-168 Application Browser 
which
I removed from Fusion.
I also tested with the JPetstore portlet and several of the J2 demo portlets.
All, please test it out as much as possible. We still plan to release a 
J1/Fusion 1.6RC1
end of next week, so problems we might need to fix before then should be 
reported ASAP.
Please try to be as detailed as possible with problem reports, patches are also 
welcome ;-)
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

J2/Fusion synchronization status

[Ate Douma]

I've got Fusion already compiling again against the latest J2 CVS HEAD.
Tomorrow I'll start testing and as soon as I get it somewhat running again
I'll commit my first changes to the new J1 cvs branch: 
j2_deployment_refactoring_sync.
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [J2] merging the deployment_refactoring branch: start

[Ate Douma]

A last update before I start committing my changes.
I've been delayed considerable today (most of it) as I found a serious
bug in the way we handle cross-context dispatching (on Tomcat).
This had nothing to do with the deployment_refactoring branch but is
something we probably have had all along.
Simply put: all (non-local) portlets share the session of the portal!
I found out about this because of the much better error handling and
logging of Tomcat 5.5 when it tries to deserialize session state after
a restart. There were several ClassNotFoundExceptions which wasn't so
strange as it tried to load classes into the session of the portal which
were private to certain portlets.
After debugging for hours I found out the cause.
Under Tomcat (at least), cross-context dispatching will only result in
a separate session (as required by the Servlet 2.3 specs) when the request
object used for dispatching *is the original Tomcat request*.
In J2, we wrap the original request inside our own ServletRequestImpl inside
a PortletRequest and used it as well for the dispatcher.include call.
This is part one of the problem.
Part two is in the invoked JetspeedContainerServlet.
There, we retrieve the PortletRequest (and PortletResponse) as saved as
request parameters and use them to invoke the Portlet.
But, inside is still the wrapped ServletRequestImpl, wrapping the original
Tomcat request. That Tomcat request contains the original portal session.
Solution part two: replacing the wrapped original Tomcat request inside the
ServletRequestImpl with the new request received by the 
JetspeedContainerServlet.
And viola: we have nicely separated session for each PA!
The ClassNotFoundExceptions at startup are now gone (at least: those related
to this problem). And furthermore, hot redeployment of a pa doesn't cause the
notorious ClassCastExceptions anymore either (JS2-155).
All in all, a lot of work to find out but I think as resolution a big 
improvement!
The real credits have to go to the Pluto team though: only after looking at 
there
solution did I find out how to solve it :-)
Ok. Let's get this over with: starting committing the changes within a few 
minutes!
Regards, Ate
Ate Douma wrote:
Just a short status update:
I've merged the branch locally and all seems to work as expected on 
Tomcat 5.0.28
I'll continue testing tomorrow morning for Tomcat 5.5.8 and JBoss 3.2.7.
If that goes well too, I'll commit the changes.
Now heading for bed :-)

Regards, Ate
-
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: Struts bridge concept related Question

[Ate Douma]

Shah,
I looked briefly at your actionMappings and the first thing I noticed is
that you do a redirect=true on a forward from a RenderAction...
You shouldn't need nor do that.
Forwarding with redirect=true is something you only need after processing
an ActionRequest.
Shah Amit wrote:
Hi Thomas,
Thanks for your reply. I have gone thru the documentation that you 
mentioned. I think I do understand it a little bit.

However I am facing some difficulties --
Following is an excerpt from my portlet.xml file --
portlet
init-param
  nameServletContextProvider/name
  
valueorg.apache.jetspeed.portlet.ServletContextProviderImpl/value
/init-param
   init-param
 nameViewPage/name
 value/showFirstPage.do/value
/init-param
   portlet-nametagportal/portlet-name
   display-nameTag Test Portlet/display-name
   
portlet-classorg.apache.portals.bridges.struts.StrutsPortlet/portlet-class 

expiration-cache-1/expiration-cache
   supports
  mime-typetext/html/mime-type
 portlet-modeVIEW/portlet-mode
   /supports
portlet-info
titleTag Test Portlet/title
short-titleTag Test Portlet/short-title
   /portlet-info
 /portlet

And following are my actionMappings --
   action-mappings
   action path=/displayFirstPage name=firstPageForm 
scope=session
   validate=false include=/WEB-INF/view/firstPage.jsp/
   action path=/showFirstPage
   
type=com.tagaudit.tagportal.struts.actions.FirstPageRenderAction
   name=firstPageForm scope=session validate=false
   forward name=success path=/displayFirstPage.do
   redirect=true/
   /action
   action path=/secondPage include=/WEB-INF/view/secondPage.jsp/
   action path=/thirdPage
   type=com.tagaudit.tagportal.struts.actions.TestAction
   name=secondPageForm scope=session validate=false
   forward name=success path=/secondPage.do redirect=true/
   /action
   /action-mappings


Now the problem is, with this setup, I can see the execute method of 
FirstPageRenderAction.java being called. But it is not being forwarded 
to /displayFirstPage.do as specified in my actionMapping. And as a 
result, I get an empty portlet without any content. The thing is, there 
are no errors anywhere in any logs so :(

I spent almost whole day trying to figure that out ... Any help is very 
very appreciated !!

Thanks,
Amit
Original Message Follows
From: [EMAIL PROTECTED]
Reply-To: Jetspeed Users List jetspeed-user@jakarta.apache.org
To: Jetspeed Users List jetspeed-user@jakarta.apache.org
Subject: Re: Struts bridge concept related Question
Date: Wed, 23 Mar 2005 15:42:35 +0100
i hope it's ok for ate.
i have same words from him:
If you post form data to Struts it should (preferrably) be processed in an
action handling only Struts Action. The form should post using an
ActionURL (required by the specs).
In the ActionRequest, the targetted Struts Action updates your Model (the
M in MVC) if need be and forwards (preferrably with redirect=true) to an

view handling only Struts Action.
Within the following RenderRequest(s), the view handling Struts Action
uses the Model to configure the required JSP rendering state/data if need
be.
Its very easy to use an include only Action mapping for that if nothing
has to be configured: action /index include=/WEB-INF/view/index.jsp/
It is advised to use an ActionMapping even for those situations as it
properly hides the rendering solution.
This applies to all Struts applications in general and a strong
recommendation from the Struts team too.
I also suggest you read up a bit on the Struts Bridge if you haven't done
so yet.
You should start with the README.txt in the Struts Bridge source tree.
Although the README.txt is a bit outdated already (haven't found the time
yet to write a proper userguide), it explains the above recommended flow
of actions.
And for more up todate information about the new features of the current
Struts Bridge 0.2 version:
http://portals.apache.org/jetspeed-2/multiproject/portals-bridges-struts/features.html 


Happy coding, Ate


Hi all,
Please pardon my stupid question because I dont have much experience with
struts or portals !!!
I have gone thru the struts-bridge documentation that is given on the
jetspeed website, and I have a few questions as to what would be the best
way to solve my problem.
I have two pages in a portlet. On the first page there is a submit button,
and a textField. When user clicks the button, the second page should come
up. The second page has a drop down which needs to be loaded based on the
textField value that the user entered on the first page.
From the documentation, I think here is how I should do it ---

I need to have two actions. When user clicks submit button, the first
action
(which is action-URL) gets called, I save the textField value in DB. Then
redirect to the second action in 

Re: [J2] merging the deployment_refactoring branch: DONE

[Ate Douma]

The deployment_refactoring branch is merged now and brings the following
features (in no specific order):
- actual pa deployment is now to be handled by the webserver itself:
  no more classloader issues
- J2 deploys on Tomcat 5.0.28/30, Tomcat.5.5.7/8, JBoss 3.2.7
  Tomcat 4 support is no longer available!
- For JBoss, the JetspeedDeploy tool can be configured to automatically strip
  commons-logging and log4j jars from the war
  (see the JBoss marked comments in the jetspeed-spring.xml in the assembly
   folder for configuration instructions)
- On JBoss, isUserInRole still doesn't work :-(
- On Tomcat, portlet applications can be started/stopped/undeployed from
  the new PorletApplicationManager portlet:
http://localhost/jetspeed/portal/Administrative/pam2.psml
  Unregistration of non-local pa's (delete pa registry definition from db)
  is also available from this portlet on every platform
- PA Sessions are now really separate from the portal Session, solving
  lots of errors after redeploy and restart of the portal (JS2-155)
- The context under which J2 is deployed can now be configured at will
  (JS2-172, JS2-182)
Maybe there are even more features/bug fixes in this update but right now
I can't think of more ;-)
Happy testing.
Regards, Ate
Ate Douma wrote:
A last update before I start committing my changes.
I've been delayed considerable today (most of it) as I found a serious
bug in the way we handle cross-context dispatching (on Tomcat).
This had nothing to do with the deployment_refactoring branch but is
something we probably have had all along.
Simply put: all (non-local) portlets share the session of the portal!
I found out about this because of the much better error handling and
logging of Tomcat 5.5 when it tries to deserialize session state after
a restart. There were several ClassNotFoundExceptions which wasn't so
strange as it tried to load classes into the session of the portal which
were private to certain portlets.
After debugging for hours I found out the cause.
Under Tomcat (at least), cross-context dispatching will only result in
a separate session (as required by the Servlet 2.3 specs) when the request
object used for dispatching *is the original Tomcat request*.
In J2, we wrap the original request inside our own ServletRequestImpl 
inside
a PortletRequest and used it as well for the dispatcher.include call.
This is part one of the problem.
Part two is in the invoked JetspeedContainerServlet.
There, we retrieve the PortletRequest (and PortletResponse) as saved as
request parameters and use them to invoke the Portlet.
But, inside is still the wrapped ServletRequestImpl, wrapping the original
Tomcat request. That Tomcat request contains the original portal session.
Solution part two: replacing the wrapped original Tomcat request inside the
ServletRequestImpl with the new request received by the 
JetspeedContainerServlet.
And viola: we have nicely separated session for each PA!

The ClassNotFoundExceptions at startup are now gone (at least: those 
related
to this problem). And furthermore, hot redeployment of a pa doesn't 
cause the
notorious ClassCastExceptions anymore either (JS2-155).

All in all, a lot of work to find out but I think as resolution a big 
improvement!
The real credits have to go to the Pluto team though: only after looking 
at there
solution did I find out how to solve it :-)

Ok. Let's get this over with: starting committing the changes within a 
few minutes!

Regards, Ate
Ate Douma wrote:
Just a short status update:
I've merged the branch locally and all seems to work as expected on 
Tomcat 5.0.28
I'll continue testing tomorrow morning for Tomcat 5.5.8 and JBoss 3.2.7.
If that goes well too, I'll commit the changes.
Now heading for bed :-)

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



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



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

Re: J2/Fusion synchronisation and release plan (Was: Re: Struts-Bridge Fusion - David/Ate/others- Pls comment)

[Ate Douma]

Hema Menon wrote:
Ate,
HM
I am not sure what's the show stopper for merging the deployment
refactoring branch. As far as I understand from the mails going
around,  the changes in the refactoring branch has been breaking some
Fusion stuff. If you think, the first step in getting to resolve that
is to get it the branch merged, maybe it should. Well, I am not aware
of all the implications, David might be able to say which way to go.
/HM
Synchronizing the merged deployment refactoring branch with Fusion is what I'll
take onto myself. But once that's done, I could use help from you and others
for testing the result and detect possible (other) problems to resolve before
we should release Fusion.

  Getting help from some of you currently working with Fusion might help too:  Hema, Jeff?

HM
Sure. We could offer whatever help that we can provide. A better
product is the need for the community as a whole:)
/HM
Great. Keep monitoring the list for progress and I might just mail you directly
if I have a new Fusion ready for testing. Is that alright with you?
HM
Well, that would be awesome! I guess it could be a Fusion with M2 release :)
/HM
Thats what I'm aiming for...
Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [J2] JS2-210: deployment refactoring branch updated with JBoss 3.2.7 support

[Ate Douma]

Seth Ford wrote:
Cool I will take a look at what I did wrong One question though,
if Websphere doesn't have a autodeploy feature for applications built
as Wars, is there any hope of getting this working? Or will this solve
the problem by deploying the app differently?
I'm afraid not.
I'm no Websphere user so I can't really comment on what is possible or not,
but if it really doesn't support autodeploy you're out of luck (and I guess
all those thousands of WebSphere developers with you because that would
really suck for testing webapplications during development).
I'd expect though WebSphere will have some kind of API though which you
should be able to dynamically add/deploy/start or whatever a new webapplication.
If thats true, it should be able to write a WebSphere DeploymentManager for
J2 handling it. I'd suggest googling for something like that because if it
is possible, certainly someone will have written one already.

On Thu, 17 Mar 2005 21:35:02 +0100, Ate Douma [EMAIL PROTECTED] wrote:
Seth Ford wrote:
I am trying it out but I think I am doing something wrong with the
jetspeed2-layout-portlets.war Doesn't it still go in the WEB-INF
deploy folder? I put it there but I am seeing
INFO: Loading portlet application from web archive C:\apps\tomcat\5.0.
\jetspeed\WEB-INF\deploy\jetspeed-layouts.war
INFO: Portlet application jetspeed: registered=true, deployed=true
INFO: Portlet application jetspeed already registered.  Skipping ini
yment.
INFO: Portlet application registration target is jetspeed ...
INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
war/WEB-INF/classes/ to class path.
INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
war/WEB-INF/lib/portals-bridges-velocity-0.1.jar to class path.
INFO: Registered portlet app in the class loader registry... jetspeed
INFO: Registered portlet app in the search engine... jetspeed
INFO: Portlet application registration of jetspeed complete.
INFO: Portlet app jetspeed successfuly (re)deployed.
and I get an error coming back from the browser for the branch
Seth,
I'm not sure which version of J2 you are testing but it certainly isn't
the deployment_refactoring branch.
Looking at the logging you provided this looks a cvs head version to me.
The deployment_refactoring doesn't need temporary deployment folders like
/temp/jetspeed-jar-tmp anymore and furthermore the jetspeed-layouts local
pa is registered under its own name: jetspeed-layouts (which means I had
to change the psml definitions for that too).

Encountered the following problem(s) while attmepting to render
portlet fragment: dp-1
Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
PortletEntity exists for for id dp-1 removing window from cache.
Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
PortletEntity exists for for id dp-1 removing window from cache.

On Thu, 17 Mar 2005 03:01:59 +0100, Ate Douma [EMAIL PROTECTED] wrote:

Dear all,
Today I committed a big update for the deployment refactoring branch.
I've added the following features:
- Moved Deployment interfaces and related components to the jetspeed-api 
subproject,
as well as the ApplicationServerManager interface and its new Result component.
This allows access to these services for portlet applications.
- Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
It allows remote control of portlet applications and the registry with the
following functions: start, stop, reload, list, undeploy and deploy (upload).
I also created a new JetspeedConsole CLI using the ManagerServlet which works
well, but which I haven't committed yet because I need to clean it up first.
- The ManagerServlet depends for several of its tasks on a 
ApplicationServerManager
implementation. With the TomcatManager all of its features can now be used.
The implementations of the JBossManager and WeblogicManager are still empty
shells though and probably someone else with more knowledge of these
application servers should take a look at those.
- A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
naming of these is getting confusing.
This new portlet though provides (almost) the same functionality as the 
ManagerServlet.
Its lists all registered portlet applications in a table with action links for:
start, stop, undeploy and delete (unregister from the registry).
It also shows if an portlet application actually is running or not.
Because I wanted to provide this functionality in table layout, I decided to not
implement it in the already existing PAM (PortletApplicationBrowser) portlet 
which
presents the portlet applications and its portlets in a tree.
For now, this portlet is accessible from the Administrative folder (pam2.psml).
We probably need to discuss though if and/or how these two portlets should

Re: Duplicate Submissions -- JSR Compliance?

[Ate Douma]

I think it will be quite difficult (although not impossible) for a user to do
duplicate ActionRequest submissions with J2 (or any portal using Pluto) because
Pluto will send a clientside redirect after an ActionRequest.
Frank Villarreal wrote:
To All:
Has anyone come up with a neat way to handle duplicate processAction
requests in a JSR-168 compliant way???  I'm interested in learning how
others have solved this common problem in the context of a portal container.
Food for thought ... utilizing a hidden timestamp on forms, I'm comparing
a session variable to the submitted timestamp to check for duplicate
submissions during the processAction request ... however, I was wondering if
there was a way to ignore/bypass/cancel the processAction processing
if a duplicate form submission was detected and simply make the portal
render the view by executing the doView method based on the previous
submission's render parameters.  I think the problem with that approach is
that the render parameters get reset on every processAction ... or is
there a way to access them before they're wiped out?  Any J2 developers have
any suggestions regarding this potential functionality?
- Frank
-
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: temp solution to run struts-bridge-app in pluto rc1

[Ate Douma]

Thomas,
[EMAIL PROTECTED] wrote:
hi !
i dont know, why i got no answer for my mail rom 03.03 - so two reasons 
are possible.
nobody or everybody knows the answer...
for everybody who is interisting to know how he
could start a struts-bridge-application in pluto rc1:
3: everybody who does know the answer was too damn busy at the time ;-)
Although your solution will work, I can't say I recommend doing it like this.
Once the Bridges subproject is finally started under Apache Portals (hopefully
soon now...) I will provide portal specific providers for the 
ServletContextProvider.
I could do so right now for Pluto except I don't want to bring its dependency 
into
the bridges-common project just to be able to compile it.
I suggest the following solution until we can provide this through the Bridges 
Project:
- Copy the 
jetspeed/commons/src/java/org/apache/jetspeed/portlet/ServletContextProviderImpl.java
  into a new package/folder of your own like:
org.apache.portals.bridges.common.providers.pluto
  and adapt the package in the ServletContextProviderImpl.java file accordingly.
- Make the changes you described below (replacing JetspeedPortletContext with 
PortletContextImpl)
  and replace import statement 
org.apache.jetspeed.container.JetspeedPortletContext with
  org.apache.pluto.core.impl.PortletContextImpl.
  Now you will have a Jetspeed independant ServletContextProvider for pluto.
- Compile the class and put it into $Tomcat/shared/lib and you're done.
  And you *don't* have to use the jetspeed-commons-2.0-M2-dev.jar anymore.
Regards, Ate
at the moment its only a temporary solution with the struts-demo
 go to file:
ServletContextProviderImpl in J2 project :-)
change line:
return 
((JetspeedPortletContext)portlet.getPortletContext()).getServletContext();

into
 return 
((PortletContextImpl)portlet.getPortletContext()).getServletContext();

you havt to import
import org.apache.pluto.core.impl.PortletContextImpl;
compile an build the j2 project.
find the
jetspeed-commons-2.0-M2-dev.jar (it includes the 
ServletContextProviderImpl)
and copy it into the web-inf/lib




web.xml:
servlet
servlet-nameStrutsPortletDemo/servlet-name
display-nameStrutsPortletDemo Wrapper/display-name
descriptionAutomated generated Portlet Wrapper/description
 servlet-classorg.apache.pluto.core.PortletServlet/servlet-class
init-param
param-nameportlet-class/param-name
 
param-valueorg.apache.portals.bridges.struts.StrutsPortlet/param-value
/init-param
init-param
param-nameportlet-guid/param-name
param-valuestruts-demo.StrutsPortletDemo/param-value
/init-param
/servlet
servlet-mapping
servlet-nameStrutsPortletDemo/servlet-name
url-pattern/StrutsPortletDemo/*/url-pattern
/servlet-mapping
taglib




Portlet.xml
?xml version=1.0 encoding=UTF-8?
portlet-app id=struts-demo version=1.0
  portlet id=StrutsPortletDemo
init-param
  nameServletContextProvider/name
 valueorg.apache.jetspeed.portlet.ServletContextProviderImpl/value
/init-param
init-param
  nameViewPage/name
  value/Welcome.do/value
/init-param
init-param
  nameHelpPage/name
  value/Tour.do/value
/init-param
portlet-nameStrutsPortletDemo/portlet-name
display-nameStruts Portlet Demo/display-name
descriptionThis is the struts MailReader portlet demo/description
 
portlet-classorg.apache.portals.bridges.struts.StrutsPortlet/portlet-class
expiration-cache-1/expiration-cache
supports
  mime-typetext/html/mime-type
  portlet-modeVIEW/portlet-mode
  portlet-modeHELP/portlet-mode
/supports
portlet-info
  titleStruts MailReader Demo/title
  short-titleThis is the short title/short-title
  keywordsStruts/keywords
/portlet-info
  /portlet
/portlet-app



Portletentitieregsitry.xml
application id=5
definition-idstruts-demo/definition-id
portlet id=1
 definition-idstruts-demo.StrutsPortletDemo/definition-id
preferences
pref-nameStrutsPortletDemo/pref-name
pref-valueStrutsPortletDemo/pref-value
read-onlyfalse/read-only
/preferences
/portlet
/application




Pageregistry.xml
?xml version=1.0?
portal
fragment name=navigation 
class=org.apache.pluto.portalImpl.aggregation.navigation.TabNavigation
/fragment
 
fragment name=test type=page
navigation
titleTest/title
description.../description
/navigation

fragment name=row type=row
fragment name=col1 type=column
fragment name=p1 type=portlet
property name=portlet value=3.1/
/fragment
fragment name=p2 type=portlet
property name=portlet value=5.1/
/fragment
/fragment
  

Re: J2/Fusion synchronisation and release plan (Was: Re: Struts-Bridge Fusion - David/Ate/others- Pls comment)

[Ate Douma]

Ate Douma wrote:
I want to propose the following:
- I like to call a vote on merging the J2 deployment_refactoring branch 
with
  CVS HEAD before the end of *this week*
As I have positive responses (and non negative) from at least 3 team members
and several from the community too, I'll try to do the merge this evening 
already
and will start with the Fusion synchronization branch tomorrow evening :-)
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[J2] merging the deployment_refactoring branch

[Ate Douma]

Just a short status update:
I've merged the branch locally and all seems to work as expected on Tomcat 
5.0.28
I'll continue testing tomorrow morning for Tomcat 5.5.8 and JBoss 3.2.7.
If that goes well too, I'll commit the changes.
Now heading for bed :-)
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

J2/Fusion synchronisation and release plan (Was: Re: Struts-Bridge Fusion - David/Ate/others- Pls comment)

[Ate Douma]

David Sean Taylor wrote:
Hema Menon wrote:
Hi,
I have been trying to get our Struts application under JS1.6 with 
Fusion. Here's the env
Latest JS 1.6 build from CVS
Struts-portal bridge 0.2 version.

I find that the application runs as a standalone using Portal bridges
0.2, which means that the portalbridges work as expected outside of
Jetspeed. However inside Jetspeed, the lookup dispatch action fails.
THE INTERESTING FACT IS THAT IF I DEPLOY THIS APPLICATION ON JETSPEED
2, IT WORKS AS EXPECTED. This makes me believe that the Jetspeed 1.6
with Fusion is causing the problem.
I believe there are changes in Struts bridge 0.2 version, which
require it to run with JS-M2 files. However any time, I build Jetspeed
1.6 with fusion, I find that the jetspeed.war contains M1 files. I
have removed the M1 jars from TOMCAT shared/lib directory. However
since JS1.6 is being build against M1 jars, I cannot remove what's in
the jetspeed war.
Here's my situation, Please help
- All our portlets are JS1.5 compliant and we are quite happy with it
- We cannot move to JS2 immediately since it means changing to JSR168 
portlets
- We need support for Struts portlet
- JS1.6 WITH FUSION, was the perfect solution for us since it would
suit all our needs.
- However, if the struts portlet does not work as expected in JS1.6
with Fusion, I don't know what option does we have :(

The changes is Struts-portlet bridge is very very important and neat,
since it requires minor changes to our Struts application. But JS1.6
with Fusion is equally important to us for deploying it. Somehow I
find that JS1.6 With Fusion on JS2M1 jars does not seem to be running
right. I am not sure what option do I have :(
Can you please let us know what your plans are regarding to JS1.6 on
Fusion. Thanks for reading a long email, forgive me, I am desperate :(
Im sorry about your situation.
I recommend running Fusion against the M1 release.
Recently, the dependencies in Fusion were upgraded to match Jetspeed-2's 
Spring dependencies. This may be causing some problems. Try checking out 
Fusion from the same time as the M1 release.

Im in a situation here myself and not finding any time for Jetspeed.
'Up to my ears in it' as they say :(
Really hope to free up next week some, and by the first week in April I 
will get Fusion fixed up and released. Im sorry but thats the best I can 
do right now. If someone else wants to step up and release Fusion before 
 then, please do so!

I want to propose the following:
- I like to call a vote on merging the J2 deployment_refactoring branch with
  CVS HEAD before the end of *this week*
- if/once the deployment_refactoring branch is merged, I'll step up and work
  on getting Fusion running again with the current J2 CVS HEAD. I'll try
  to do so within a few days, (the sooner we decide if/when to merge the
  branch the more time I will have for it)
  Precondition for success though is that there are not other blocking issues
  with Fusion to get it working again. I don't know. Community, David?
  Getting help from some of you currently working with Fusion might help too:
  Hema, Jeff?
- Hopefully, beginning next week we have both J2 and Fusion in sync again
- If all works out well, I'll propose to do a J2-M2 release as well as a
  Fusion 1.6 release next weekend (!) as I can dedicate most of my time that
  weekend doing the release.
  I haven't done a release before though, so getting at least some help from
  someone from the team with previous experience will be important I think.
- Furthermore, I'd like to propose to do releases more often (say once every
  month, maybe two) at least until we reach J2-final.
  The next release (M3) could contain the portlet selector (customizer)
  from David if he won't be able to commit it in time for M2.
  Furthermore, we should try to get most of the outstanding bugs fixed by then.
  I'm willing to work on that a lot.
- Furthermore, I am going to spend more time in April on writing documentation
  as the community really is in dire need of it. I'd say the M3 release should
  contain enough documentation to allow new users to start working with J2
  on their own.
  Hopefully, other team members and/or active community users can step up too
  in providing more documentation...
I know this list is quite ambitious, but well, I am ;-)
Anyone like to comment?
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [J2] JS2-210: deployment refactoring branch updated with JBoss 3.2.7 support

[Ate Douma]

Seth Ford wrote:
I am trying it out but I think I am doing something wrong with the
jetspeed2-layout-portlets.war Doesn't it still go in the WEB-INF
deploy folder? I put it there but I am seeing
INFO: Loading portlet application from web archive C:\apps\tomcat\5.0.
\jetspeed\WEB-INF\deploy\jetspeed-layouts.war
INFO: Portlet application jetspeed: registered=true, deployed=true
INFO: Portlet application jetspeed already registered.  Skipping ini
yment.
INFO: Portlet application registration target is jetspeed ...
INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
war/WEB-INF/classes/ to class path.
INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
war/WEB-INF/lib/portals-bridges-velocity-0.1.jar to class path.
INFO: Registered portlet app in the class loader registry... jetspeed
INFO: Registered portlet app in the search engine... jetspeed
INFO: Portlet application registration of jetspeed complete.
INFO: Portlet app jetspeed successfuly (re)deployed.
and I get an error coming back from the browser for the branch
Seth,
I'm not sure which version of J2 you are testing but it certainly isn't
the deployment_refactoring branch.
Looking at the logging you provided this looks a cvs head version to me.
The deployment_refactoring doesn't need temporary deployment folders like
/temp/jetspeed-jar-tmp anymore and furthermore the jetspeed-layouts local
pa is registered under its own name: jetspeed-layouts (which means I had
to change the psml definitions for that too).
Encountered the following problem(s) while attmepting to render
portlet fragment: dp-1
Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
PortletEntity exists for for id dp-1 removing window from cache.
Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
PortletEntity exists for for id dp-1 removing window from cache.

On Thu, 17 Mar 2005 03:01:59 +0100, Ate Douma [EMAIL PROTECTED] wrote:
Dear all,
Today I committed a big update for the deployment refactoring branch.
I've added the following features:
- Moved Deployment interfaces and related components to the jetspeed-api 
subproject,
 as well as the ApplicationServerManager interface and its new Result component.
 This allows access to these services for portlet applications.
- Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
 It allows remote control of portlet applications and the registry with the
 following functions: start, stop, reload, list, undeploy and deploy (upload).
 I also created a new JetspeedConsole CLI using the ManagerServlet which works
 well, but which I haven't committed yet because I need to clean it up first.
- The ManagerServlet depends for several of its tasks on a 
ApplicationServerManager
 implementation. With the TomcatManager all of its features can now be used.
 The implementations of the JBossManager and WeblogicManager are still empty
 shells though and probably someone else with more knowledge of these
 application servers should take a look at those.
- A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
 naming of these is getting confusing.
 This new portlet though provides (almost) the same functionality as the 
ManagerServlet.
 Its lists all registered portlet applications in a table with action links for:
 start, stop, undeploy and delete (unregister from the registry).
 It also shows if an portlet application actually is running or not.
 Because I wanted to provide this functionality in table layout, I decided to 
not
 implement it in the already existing PAM (PortletApplicationBrowser) portlet 
which
 presents the portlet applications and its portlets in a tree.
 For now, this portlet is accessible from the Administrative folder (pam2.psml).
 We probably need to discuss though if and/or how these two portlets should be
 integrated.
 This portlet also depends on a ApplicationServerManager. If none is configured 
(like
 for JBoss) it will still show if a portlet application is running or not and 
allow
 to delete (unregister) an portlet application.
- J2 on JBoss
 Because one of the premises of this deployment refactoring was that it should 
make
 it easier to deploy J2 on other application servers as well, I decided to 
prove this
 and got my feet wet trying it out for JBoss (3.2.7).
 With success!
 I wrote a list of things to do to get this branch running on JBoss in a 
comment to
 JS2-210: http://issues.apache.org/jira/browse/JS2-210#action_60983
 Once this branch is merged into the head branch I'll provide proper 
instructions on
 the website or wiki (although I'm not much of a wiki jockey yet).
 I also tested with JBoss 4.0.1sp1 which looks to be working just as well. I 
didn't
 have time to test that one a lot though.
 Of course, there were quite a few problems to solve, but *none* were

[J2] JS2-210: deployment refactoring branch updated with JBoss 3.2.7 support

[Ate Douma]

Dear all,
Today I committed a big update for the deployment refactoring branch.
I've added the following features:
- Moved Deployment interfaces and related components to the jetspeed-api 
subproject,
  as well as the ApplicationServerManager interface and its new Result 
component.
  This allows access to these services for portlet applications.
- Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
  It allows remote control of portlet applications and the registry with the
  following functions: start, stop, reload, list, undeploy and deploy (upload).
  I also created a new JetspeedConsole CLI using the ManagerServlet which works
  well, but which I haven't committed yet because I need to clean it up first.
- The ManagerServlet depends for several of its tasks on a 
ApplicationServerManager
  implementation. With the TomcatManager all of its features can now be used.
  The implementations of the JBossManager and WeblogicManager are still empty
  shells though and probably someone else with more knowledge of these
  application servers should take a look at those.
- A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
  naming of these is getting confusing.
  This new portlet though provides (almost) the same functionality as the 
ManagerServlet.
  Its lists all registered portlet applications in a table with action links 
for:
  start, stop, undeploy and delete (unregister from the registry).
  It also shows if an portlet application actually is running or not.
  Because I wanted to provide this functionality in table layout, I decided to 
not
  implement it in the already existing PAM (PortletApplicationBrowser) portlet 
which
  presents the portlet applications and its portlets in a tree.
  For now, this portlet is accessible from the Administrative folder 
(pam2.psml).
  We probably need to discuss though if and/or how these two portlets should be
  integrated.
  This portlet also depends on a ApplicationServerManager. If none is 
configured (like
  for JBoss) it will still show if a portlet application is running or not and 
allow
  to delete (unregister) an portlet application.
- J2 on JBoss
  Because one of the premises of this deployment refactoring was that it should 
make
  it easier to deploy J2 on other application servers as well, I decided to 
prove this
  and got my feet wet trying it out for JBoss (3.2.7).
  With success!
  I wrote a list of things to do to get this branch running on JBoss in a 
comment to
  JS2-210: http://issues.apache.org/jira/browse/JS2-210#action_60983
  Once this branch is merged into the head branch I'll provide proper 
instructions on
  the website or wiki (although I'm not much of a wiki jockey yet).
  I also tested with JBoss 4.0.1sp1 which looks to be working just as well. I 
didn't
  have time to test that one a lot though.
  Of course, there were quite a few problems to solve, but *none* were related 
to
  (re)deployment. And many of the problems as indicated by the wiki pages for 
JBoss
  deployment of the M1 or current head version of J2 seems to be resolved :-)
  The following issues are important though:
  - commons-logging and Log4J dependencies
JBoss provides commons-logging and Log4J, as well as the Log4J 
configuration from
a shared classloader to all the applications.
This really is conflicting with the way we use them in Jetspeed-2 under 
Tomcat
(although Tomcat 5.5 also is giving more headaches with this now).
One simply cannot have the commons-logging and log4j jars anymore in 
WEB-INF/lib
because it definitely is giving classloader problems under JBoss.
Furthermore, our own log4j configuration conflicts with the global 
configuration
provided with JBoss. If you initialize a new log4j configuration from a web 
application
like we do with J2, you end up closing and detaching existing loggers and 
appenders
and rerouting them into the J2 logging. Likewise, if some other web 
application
deployed after J2 does the same, the J2 logging might get closed and 
detached and
rerouted into this other web application its logging.
Anyway you look at it, dynamic log4j configuration is very problematic 
under JBoss.
And, while scanning the internet for a way around this, I found out many 
others
encountered the same problem and not only on JBoss but other application 
servers
as well.
After a long investigation of the concrete implementations of 
commons-logging and
log4j though I've come up with a solution which I called 
IsolatedLog4JLogger.
As I put a lot of javadoc into that class I'm not going to reproduce it 
here.
But, I invite everyone to have a look at it. Its currently only committed 
to the
deployment_refactoring branch under 
portal/src/java/org/apache/jetspeed/util.
Whats left is a future solution of the packaging of these jars. Having to 
remove
them after a war is build is quite dumb and easy to forget as well.
  

Re: getting Jetspeed 2 to work with WebSphere 5.1.2

[Ate Douma]

Seth,
I can't directly help you with WebSphere but I am interested in how you got it 
working
and with which version of Jetspeed 2 you are working.
As you might know, I created a new branch of Jetspeed 2 somewhat more than a 
week ago
(branch: deployment_refactoring, see 
http://issues.apache.org/jira/browse/JS2-210)
in which I've implemented an application server indepedent deployment model.
If you haven't tried that one out yet, you might have a better result doing so.
Note the current limitations of that branch though (see the JS2-210 issue).
I'm working right now on improvements which should resolve those limitations, 
but
it probably will take me a few hours more (or possibly a few days if I run out 
of time)
before I can commit those improvements.
Regarding your question about cross context problem: all portlets deployed with
Jetspeed 2 use cross context. So, if the default portlets provided by Jetspeed 2
*are* working, cross context shouldn't be the problem.
Maybe if you provide us with some more detailed information (like error 
messages and
stacktraces) I or someone else can help you better.
Regards, Ate
Seth Ford wrote:
I have jetspeed 2 working with WebSphere 5.1.2 except for the portals
that are done through a hot deploy Can any explain how to do this
in WebSphere? I have tried to install the portlet WARs seperatly, but
have run into request dispatcher include related issues looks like
a cross context problem
Thanks
Seth
-
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: Struts bridge, lost request parameters

[Ate Douma]

Jeff Sheets wrote:
Colin,
My apologies, because your fix does work for me!!!  Thank you!
My actual code was:
actionResponse.setPortletMode(PortletMode.VIEW);
return mapping.findForward(FORWARD_VIEW);
As this worked before your fix to at least return me to the View page.
 But now we need to forward back to the edit page, so that when we
return to the edit mode we get the page correctly.  So my code now
looks like this:
actionResponse.setPortletMode(PortletMode.VIEW);
return mapping.findForward(FORWARD_EDIT);
Thank you very much for your help!  Ate, hopefully this can be
committed to the baseline soon?
It will ;-)
Probably sometime next week.
-- Jeff
On Thu, 10 Mar 2005 16:18:14 -, Colin O'Toole
[EMAIL PROTECTED] wrote:
Hi Jeff,
That is similar to what I'm doing except that I don't make the portlet
automatically return to the view mode after submitting an edit page change.
I stay in edit until the user explicitly clicks the view button.
If you enable debug logging you should get some detailed information about
what is happening when you click the edit button.  I also found that remote
debugging the app and setting breakpoints in StrutsPortlet.processRequest()
made it easy to figure out what was going on.
I will add the actionResponse.setPortletMode(PortletMode.VIEW); to my edit
action code and see if it breaks anything.  Might tae me a while to get
around to it though :-)
Cheers,
Colin.
-Original Message-
From: Jeff Sheets [mailto:[EMAIL PROTECTED]
Sent: 10 March 2005 15:57
To: Jetspeed Users List
Subject: Re: Struts bridge, lost request parameters
Colin,
Your quick fix didn't work for me.  Perhaps my flow is wrong.  Here is
what I am doing.
Displaying the View page (/myaction.do).  Clicking the edit icon to go
to the Edit page (/editmyaction.do).  Then after hitting save on the
edit page, I have to tell it to go back to the view page by doing this
in the action class:
actionResponse.setPortletMode(PortletMode.VIEW);
It returns to the View page correctly (like it always has).  Clicking
on the edit button simply refreshes the view page, instead of taking
me back to the edit screen.  This is the same result as before I
applied you fix.
Have I done something differently than you?
Thanks,
-- Jeff
On Thu, 10 Mar 2005 11:44:15 -, Colin O'Toole
[EMAIL PROTECTED] wrote:
Ah!  OK I will try this but it will have to wait until tomorrow.  because
of
time constraints I may stick with what I have and do a wholesale upgrade
once M2 is released.
Thanks for the help!
Colin.
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED]
Sent: 10 March 2005 11:30
To: Jetspeed Users List
Subject: Re: Struts bridge, lost request parameters
Colin O'Toole wrote:
Hi Ate,
OK, I made the changes you detailed and tried this and what happens is:
(1) Clicking on link goes to LocaleAction (ActionUrl).  Using remote
debugging in eclipse with a breakpoint in LocaleAction.execute(), the
PortletServletRequestWrapper object contains an ApplicationContextFacade
and
a ServletRequestImpl.  The ServletRequestImpl contains an
ApplicationHttpRequestObject.  The queryParamString member of the
ApplicationHttpRequestObject holds the params
language=jaforward=testredirect.  (This is what I saw in my example
also)
(2) In LocaleAction the following code is run:
target = request.getParameter(FORWARD);
This returns null - the parameter forward=testredirect is not found in
the
request.  This causes the following code to be executed:
if (isBlank(target)) target = mapping.getParameter();

return mapping.findForward(target);
target is the default welcome global mapping from the
struts-config.xml,
so the WelcomeAction is called.
So in fact for me it appears that request params are being lost
wholesale -
irrespective of whether or not it is a redirect or a simple forward.  I
am
using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1.  I will try
later
today with Tomcat 5.0.28 which I also have.
Now we are getting somewhere: you are running Jetspeed 2 M1...
I'm not sure but I think that will be the reason. I don't test or develop
against
M1 anymore. As we are approaching a M2 release very soon, I suggest you
try
your
application with the latest CVS HEAD if possible.

If I run the above code with the old version - which expressly parses
the
querystring in StrutsPortlet and passes it into
PortletServletRequestWrapper, it works as you describe.  I'm a bit
stumped
here. :-)
Can you help me understand where the params go in the new
PortletServletRequestWrapper?  In the old PortletServletRequestWrapper I
could see that in DispatchedHttpServletRequestWrapper they were parsed
into
a map.  I'm unsure as to where they end up now.
Thanks,
Colin.
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED]
Sent: 09 March 2005 22:41
To: Jetspeed Users List
Subject: Re: Struts bridge, lost request parameters
Colin,
I took some time to create a testcase with a similar flow as you
described
earlier.
For this, I used the struts-demo

Re: Struts bridge, lost request parameters

[Ate Douma]

Colin O'Toole wrote:
Hi Ate,
OK, I made the changes you detailed and tried this and what happens is:
(1) Clicking on link goes to LocaleAction (ActionUrl).  Using remote
debugging in eclipse with a breakpoint in LocaleAction.execute(), the
PortletServletRequestWrapper object contains an ApplicationContextFacade and
a ServletRequestImpl.  The ServletRequestImpl contains an
ApplicationHttpRequestObject.  The queryParamString member of the
ApplicationHttpRequestObject holds the params
language=jaforward=testredirect.  (This is what I saw in my example also)
(2) In LocaleAction the following code is run:
target = request.getParameter(FORWARD);
This returns null - the parameter forward=testredirect is not found in the
request.  This causes the following code to be executed:
if (isBlank(target)) target = mapping.getParameter();

return mapping.findForward(target);
target is the default welcome global mapping from the struts-config.xml,
so the WelcomeAction is called.
So in fact for me it appears that request params are being lost wholesale -
irrespective of whether or not it is a redirect or a simple forward.  I am
using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1.  I will try later
today with Tomcat 5.0.28 which I also have.
Now we are getting somewhere: you are running Jetspeed 2 M1...
I'm not sure but I think that will be the reason. I don't test or develop 
against
M1 anymore. As we are approaching a M2 release very soon, I suggest you try your
application with the latest CVS HEAD if possible.
If I run the above code with the old version - which expressly parses the
querystring in StrutsPortlet and passes it into
PortletServletRequestWrapper, it works as you describe.  I'm a bit stumped
here. :-)
Can you help me understand where the params go in the new
PortletServletRequestWrapper?  In the old PortletServletRequestWrapper I
could see that in DispatchedHttpServletRequestWrapper they were parsed into
a map.  I'm unsure as to where they end up now.
Thanks,
Colin.
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED]
Sent: 09 March 2005 22:41
To: Jetspeed Users List
Subject: Re: Struts bridge, lost request parameters
Colin,
I took some time to create a testcase with a similar flow as you described
earlier.
For this, I used the struts-demo as provided with Jetspeed-2.
Could you please check if this is indeed a flow like you have?
If that is the case then could you report back if it indeed doesn't work for
you
(while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP
and JDK 1.4.2_04.
Here is the testcase:
- add a new global-forward to the struts-config.xml:
   forward name=testredirect
path=/Locale.do?language=ruamp;page=/Welcome.do redirect=true/
- in the welcome.jsp change:
 html:link action=/Locale?language=ja
useLocalEncoding=trueJapanese/html:link
   to:
 html:link action=/Locale?language=jaforward=testredirect
useLocalEncoding=trueJapanese/html:link
With these changes and selecting the Japanese language on the welcome
screen, the LocaleAction
will be invoked (ActionURL) to set the Japanese language and than forward to
the new testredirect forward.
The testredirect forward redirects (as in your case the Filter.do) back to
the LocaleAction but now for
setting the Russian language (using query_string parameters) and finally
forward to the Welcome screen again.
The end result for the user is that the Locale is set to Russian instead of
Japanese :-)
This works without problems for me!
I also turned on logging and to show it indeed works as expected, here is a
trimmed part of the logging:
...
PropertyMessageResources - loadLocale(nl)
...
StrutsPortlet - process path: /Locale.do?language=jaforward=testredirect,
requestType: ACTION
processForwardConfig(ForwardConfig[name=testredirect,path=/Locale.do?languag
e=rupage=/Welcome.do,redirect=true,...
StrutsPortlet - action render redirected page:
/Locale.do?language=rupage=/Welcome.do
navstate
decoded=[[window:15,action:true,parameters:[_spage:[/Locale.do?language=jaf
orward=testredirect]]]
navstate
decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Loc
ale.do?language=rupage=/Welcome.do]]]
StrutsPortlet - process path: /Locale.do?language=rupage=/Welcome.do,
requestType: VIEW
processForwardConfig(ForwardConfig[name=null,path=/Welcome.do,redirect=false
,...
...
PropertyMessageResources - loadLocale(ru)
Regards, Ate
Colin O'Toole wrote:
Hi Ate,
I had some time to take a look at this yesterday and the situation is:
PortletServletRequestWrapper now extends HttpServletRequestWrapper rather
than DispatchedHttpServletRequestWrapper.  The
DispatchedHttpServletRequestWrapper constructor accepts the queryString
from
the path and the parameters were parsed into a map.  The params could then
be retrieved by calling getParameter(), getParameterNames() etc.
HttpServletRequestWrapper doesn't make the original params available in
the
same way.
I modified the code from the head to make

Re: Jetspeed 1.6-Fusion HELP!!!!

[Ate Douma]

David Sean Taylor wrote:
Well we now have a new complication with Fusion.
The CVS head for 2.0 will soon change its deployment model.
In the deployment branch, quite a few interfaces that Fusion is 
dependent on are now deleted.
The code doesn't even compile against this branch.

Once again, J2 developers have no consideration for Fusion.
This is a bold statement.
I know and you know that I started in the new deployment branch
from a clean sheet. I explicitly stated that this would *initially*
result in some features gone missing.
I also said these features have to be recreated once we decide this
proposed new deployment model. Right now, I have had no formal
acknowledgment from *anyone* yet to go ahead and commit my changes
to the main branch.
Probably everybody does know though I definitely would like to see
this happen, but I will be the first to acknowledge that it isn't ready
for that yet.
Providing support back for undeployment, unregistration, registration,
ServerManager integration, *AND FUSION* absolutely is a requirement
I will stand for before moving to the new deployment model (if it comes
to that).
Now, I *did* look at Fusion when I started my deployment refactoring and
how it is dependent on the current deployment features of J2.
As far as I can tell (I'm no Fusion expert, I'll admit that), the
currently missing features from the deployment branch are quite easy to
replace, if not easier than it was initially (alright, maybe that's a
bold statement of mine).
The most prominent missing functionality in the new deployment branch for
Fusion is the FilesystemPAM. All of its features (as used by Fusion)
are now available from the new PortletApplicationManager.
Maybe at first sight the deploy and undeploy features are still missing from it,
but Fusion isn't actually using these methods, other than hooking into them
to synchronize the J1 Registry.
The new PortletApplicationManager registerPA and unregisterPA methods provide
functionally the same hooks AFAIK.
And then of course the integration with the ServerManager. This will be quite
easy to bring back online. Actually, I've already done so.
I have the TomcatManager working again.
Furthermore, I created a new (secured) ManagerServlet through which you can 
interact
with the ApplicationManagerServer as well as the PortletApplicationManager.
I've used the Tomcat ManagerServlet as example for this.
Right now I can list, start, stop, unregister and undeploy a PortletApplication
all from the commandline or webbrowser and working without problems. Providing
the same features to Fusion will be a peace of cake.
I'm still working on an deploy command (uploading a deployment object like a
war or decorator). The basic code is already in place, the only thing left to 
implement
is the uploading part in the new commandline tool (JetspeedConsole).
I'm putting in a lot of effort to get this all working even *better* than it 
did before,
and I'm going to provide as much effort as needed to get Fusion working again 
with the new
deployment model, once we decided it will be the used for J2.
Perhaps we should formally call a vote on the jetspeed-dev list:
1. deprecate fusion
Nonsense
-or--
2. require developers to test fusion
I do care about Fusion and, as far you *can* require that, I have no objection 
to make it a policy.
We should think about an easier way to test fusion do though because getting J1 
and J2 to build
right beside each other is quite a hassle...
Frankly the whole situation has led to me becoming less and less 
involved in Jetspeed as my contributions are devaluated.
I think you are over reacting. I value your contributions very highly and I 
know I'm not alone ;-)
You did a hell of a job (and I know it was a hell of a job) to integrate J2 
with J1, AKA Fusion.
I think it is one of the most important contributions to Jetspeed (as a whole, 
J1 and J2 together)
because it not only provides a JSR-168 container but also a view of the power 
of J2 and a migration path
for J1 users not (yet) ready to make the jump to J2.
As Jeff Sheets said in another response: J1 is much more stable and complete 
than J2.
Fusion provides JSR-168 support *now* to end users of Jetspeed.
Anyway, enough of my whining.
;-)
What we could do put out the 1.6 release with 2.0 M1
But since the deployment is changing in M2, this means that Fusion is 
stuck at M1 until someone comes along and refactors the Fusion deployment.
As I said above, I'm more than willing to do so. Doing that with your help 
would make it much
quicker and easier though.
Regards, Ate
Im open to suggestions

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

Re: Struts bridge, lost request parameters

[Ate Douma]

Colin,
I took some time to create a testcase with a similar flow as you described 
earlier.
For this, I used the struts-demo as provided with Jetspeed-2.
Could you please check if this is indeed a flow like you have?
If that is the case then could you report back if it indeed doesn't work for you
(while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP and 
JDK 1.4.2_04.
Here is the testcase:
- add a new global-forward to the struts-config.xml:
  forward name=testredirect path=/Locale.do?language=ruamp;page=/Welcome.do 
redirect=true/
- in the welcome.jsp change:
html:link action=/Locale?language=ja 
useLocalEncoding=trueJapanese/html:link
  to:
html:link action=/Locale?language=jaforward=testredirect 
useLocalEncoding=trueJapanese/html:link
With these changes and selecting the Japanese language on the welcome screen, 
the LocaleAction
will be invoked (ActionURL) to set the Japanese language and than forward to 
the new testredirect forward.
The testredirect forward redirects (as in your case the Filter.do) back to the 
LocaleAction but now for
setting the Russian language (using query_string parameters) and finally 
forward to the Welcome screen again.
The end result for the user is that the Locale is set to Russian instead of 
Japanese :-)
This works without problems for me!
I also turned on logging and to show it indeed works as expected, here is a 
trimmed part of the logging:
...
PropertyMessageResources - loadLocale(nl)
...
StrutsPortlet - process path: /Locale.do?language=jaforward=testredirect, 
requestType: ACTION
processForwardConfig(ForwardConfig[name=testredirect,path=/Locale.do?language=rupage=/Welcome.do,redirect=true,...
StrutsPortlet - action render redirected page: 
/Locale.do?language=rupage=/Welcome.do
navstate 
decoded=[[window:15,action:true,parameters:[_spage:[/Locale.do?language=jaforward=testredirect]]]
navstate 
decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Locale.do?language=rupage=/Welcome.do]]]
StrutsPortlet - process path: /Locale.do?language=rupage=/Welcome.do, 
requestType: VIEW
processForwardConfig(ForwardConfig[name=null,path=/Welcome.do,redirect=false,...
...
PropertyMessageResources - loadLocale(ru)
Regards, Ate
Colin O'Toole wrote:
Hi Ate,
I had some time to take a look at this yesterday and the situation is:
PortletServletRequestWrapper now extends HttpServletRequestWrapper rather
than DispatchedHttpServletRequestWrapper.  The
DispatchedHttpServletRequestWrapper constructor accepts the queryString from
the path and the parameters were parsed into a map.  The params could then
be retrieved by calling getParameter(), getParameterNames() etc.
HttpServletRequestWrapper doesn't make the original params available in the
same way.
I modified the code from the head to make PortletServletRequestWrapper
extend DispatchedHttpServletRequestWrapper once more (and obviously restore
DispatchedHttpServletRequestWrapper to the
org.apache.portals.bridges.struts.util package from where it was deleted).
My app now works correctly as before.
I'm sure DispatchedHttpServletRequestWrapper was removed for a reason, so
this is likely no more than a temporary solution.
Hope this helps,
Colin.

Colin, I will try to look at you problem later this evening or
otherwise tomorrow evening.
Ate
Colin O'Toole wrote:
Hi all,
I was using Struts portlet 0.2 with my app and it was working fine, I've
upgraded to the latest version from CVS and I'm now losing request
parameters.
I have a action that is returning an ActionRedirect (a subclass of
ActionForward used for redirects) to a new action.  Some parameters are
being added to the ActionRedirect. So it looks like this:
(1) ViewAction.do has a submit to Filter.do (This is a portlet
action URL)
(2) Filter.do does a redirect (with parameters) to ViewAction.do
(3) PopulateForm in ViewAction.do calls getParameter(XXX) which returns
null.
In Struts-portlet 0.2, the PortletRequestObject object in Step
(3) contains:
- An ApplicationContextFacade
- A Map of parameters containing the params from the redirect.
- A ServletRequestImpl
In The latest version, the PortletRequestObject object in Step
(3) contains:
- An ApplicationContextFacade
- No parameter map!
- A ServletRequestImpl.  This contains a
ApplicationHttpRequestObject.  The
queryParamString member of the ApplicationHttpRequestObject
holds the params
from the redirect.  In Struts-portlet 0.2 this QueryParamString is null.
So something has changed between 0.2 and now that has broken my
app - I'm
unsure if this is a struts-portlet bug or whether I need to do something
extra to make this work.
Any help would be appreciated,
Colin.
-
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: Struts bridge, lost request parameters

[Ate Douma]

Colin O'Toole wrote:
Hi Jeff,
You're welcome.  If it causes any problems for you please post them here.  I
think it's OK but I'm no portlet expert so it could break something!  Ate
will be able to tell us for sure.
Sure ;-)
I think your fix should do the trick indeed. And I don't think it breaks 
anything!
I'm not sure I'm going to implement it (only) like this though.
One thing not possible with this solution is remembering the PageURL you 
leave when
switching to another mode.
If you come back to the (or a) previous mode, you always re-enter with its 
defaultPage.
I'm thinking of saving the last PageURL for each mode (if unequal to its 
defaultPage) in
a special session scoped object and restoring it when the (or a) previously 
used mode
is re-entered.
Probably this should be configurable too (using an init parameter) so your 
'light' solution
can also be used.
What do you think?
And Jeff, is this indeed a/the solution for your problem?
Regards, Ate
Colin.

-Original Message-
From: Jeff Sheets [mailto:[EMAIL PROTECTED]
Sent: 09 March 2005 14:13
To: Jetspeed Users List
Subject: Re: Struts bridge, lost request parameters
Hey Colin,
I'll try out your quick fix for the edit page bug.  We have really
needed this fixed, and I was stumped on what was wrong, so thank you
very much!
-- Jeff
On Wed, 9 Mar 2005 10:44:22 -, Colin O'Toole
[EMAIL PROTECTED] wrote:
Hi Ate,
This is OT, but there is another problem I have fixed locally.
This is the
edit page problem reported originally reported by Jeff Sheets.
The problem
is that when a submit is performed from an edit page, pressing
the button to
change to view mode doesn't work anymore.
The problem occurs in StrutsPortlet when the defaultPage (from the
portlet.xml) is overridden by the pageURL value from the
StrutsPortletURL.
This mechanism doesn't take into account the fact that the
portlet mode may
have changed.  So what happens is that clicking the icon to go
to VIEW mode
issues a doView(), which calls processRequest(), which pulls
the _edit_ url
from the StrutsPortletURL and uses it instead of the ViewPage
url specified
in portlet.xml.
I needed a fix for a demo, so what I did was:
(1) In StrutsPortletURL v1.4.  Add a portlet mode.
public static final String PORTLETMODE = _mode;
- Line 61 changes from this:
   if (actionURL)
   {
   String originURL = request.getParameter(PAGE);
   if (originURL != null)
   portletURL.setParameter(ORIGIN, originURL);
   }
   return portletURL;
}
- To this:
   if (actionURL)
   {
   String originURL = request.getParameter(PAGE);
 if (originURL != null)
   portletURL.setParameter(ORIGIN, originURL);
   }
   // Add the portlet mode to the request, we will only
use the pageURL param
to override the
   // default page if the portlet mode for this URL is the
same as the current
mode when
   // StrutsPortlet.processRequest() is executed
   PortletRequest portletRequest =
(PortletRequest)request.getAttribute(javax.portlet.request);
   String portletMode = portletRequest.getPortletMode().toString();
   log.debug(portletMode is:  + portletMode);
   portletURL.setParameter(PORTLETMODE, portletMode);
   return portletURL;
}
(2) In StrutsPortlet v1.12.  If there is a pageURL in the
request, only use
it if the mode associated with it is the same as the current
portlet mode:
- Line 313 changes from
String path = null;
String pageURL = request.getParameter(StrutsPortletURL.PAGE);
if (pageURL == null)
   path = defaultPage
else
{
   path = pageURL;
}
- To:
String path = null;
String pageURL = request.getParameter(StrutsPortletURL.PAGE);
String portletModeFromURL =
request.getParameter(StrutsPortletURL.PORTLETMODE);
String portletModeCurrent = request.getPortletMode().toString();
log.debug(portletModeFromURL:  + portletModeFromURL + ,
portletModeCurrent:  + portletModeCurrent);
if (pageURL == null) {
   log.debug(pageURL from request is null, using default page:  +
defaultPage);
 path = defaultPage;
}
else {
   // only use the pageURL if the portlet mode associated
with it is the same
as the
 // portlet mode for the current request
 if(( portletModeFromURL != null) 
(portletModeFromURL.equalsIgnoreCase(portletModeCurrent))) {
   log.debug(pageURL from request is: + pageURL);
   path = pageURL;
   }
 else {
   log.debug(Not using pageURL as portlet mode has changed from 
   + portletModeFromURL +  to  + portletModeCurrent);
   path = defaultPage;
   }
}
- Line 394 changes from:
if (pageURL != null)
{
   if (renderURL == null  log.isWarnEnabled())
   log.warn(Warning: Using the original action URL for
render URL: 
+pageURL+.\nA redirect should have been issued.);
 ((ActionResponse)
response).setRenderParameter(StrutsPortletURL.PAGE,
pageURL);
}
- To:
if (pageURL != null)
{
   if (renderURL == null  log.isWarnEnabled())
   

Re: security_credential - encryption algorithm

[Ate Douma]

Shah Amit wrote:
Did some reasearch in the spi-impl modules and found that it is SHA-1. 
Can someone confirm if I am right 
For the default configuration, yes.
Its a MessageDigest algorithm name and you can configure it through the
Spring context.
For populating the security_credential table with an external program, you don't
need to concern yourself with it though: if you set column is_encoded to false/0
you can use cleartext password values. Jetspeed will then automatically encrypt
it for you on first usage.
The default database population for Jetspeed is done the same way.
Ate
Thanks,
Amit
Original Message Follows
From: Shah Amit [EMAIL PROTECTED]
Reply-To: Jetspeed Users List jetspeed-user@jakarta.apache.org
To: jetspeed-user@jakarta.apache.org
Subject: security_credential - encryption algorithm
Date: Tue, 08 Mar 2005 13:25:23 -0500
Hi all,
Does anyone know what kind of encryption is used on security_credential 
table ... Actually I have some data that I need to translate to jetspeed 
based model and populate the security_credential table with an external 
program so ...

Thanks,
Amit

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

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



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

Re: Struts bridge, lost request parameters

[Ate Douma]

Colin, I will try to look at you problem later this evening or otherwise 
tomorrow evening.
Ate
Colin O'Toole wrote:
Hi all,
I was using Struts portlet 0.2 with my app and it was working fine, I've
upgraded to the latest version from CVS and I'm now losing request
parameters.
I have a action that is returning an ActionRedirect (a subclass of
ActionForward used for redirects) to a new action.  Some parameters are
being added to the ActionRedirect. So it looks like this:
(1) ViewAction.do has a submit to Filter.do (This is a portlet action URL)
(2) Filter.do does a redirect (with parameters) to ViewAction.do
(3) PopulateForm in ViewAction.do calls getParameter(XXX) which returns
null.
In Struts-portlet 0.2, the PortletRequestObject object in Step (3) contains:
- An ApplicationContextFacade
- A Map of parameters containing the params from the redirect.
- A ServletRequestImpl
In The latest version, the PortletRequestObject object in Step (3) contains:
- An ApplicationContextFacade
- No parameter map!
- A ServletRequestImpl.  This contains a ApplicationHttpRequestObject.  The
queryParamString member of the ApplicationHttpRequestObject holds the params
from the redirect.  In Struts-portlet 0.2 this QueryParamString is null.
So something has changed between 0.2 and now that has broken my app - I'm
unsure if this is a struts-portlet bug or whether I need to do something
extra to make this work.
Any help would be appreciated,
Colin.
-
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: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!

[Ate Douma]

Roger Ruttimann wrote:
+1 to drop Tomcat 4 if we fix 5.5 at the same time.
Tomcat 5.5.8 already works without a hitch if you check out branch 
deployment-refactoring!
You only have to set org.apache.jetspeed.catalina.version.major = 5.5
(and point org.apache.jetspeed.server.home to a Tomcat 5.5.8 installation of 
course).
Check it out to see for yourself.
You can find further info about this branch at 
http://issues.apache.org/jira/browse/JS2-210
I'd like to call a vote somewhere next week for merging those changes back into
the HEAD branch. We will try to do a M2 release end of this month and I 
definitely would
like to see this be part of it.
But, I haven't had much reactions yet so if you or anyone else might have an 
hour or so
for testing, please do!
Regards, Ate
Randy Watler wrote:
Ate/All,
Yes, 4.1 is certainly painful when it comes to deployment. I can 
verify most of what Ate has outlined here.

+1 to drop 4.1.
Ate, are you also working on getting 5.5 functional? I suppose it 
would be good to do that before/while we deprecate 4.1 support.

Randy
Ate Douma wrote:
Something I forgot to add:
I will try to upload a preliminary patch for
http://issues.apache.org/jira/browse/JS2-210 tomorrow which for testing
purposes only and which of course will only work with Tomcat 5.0.28 
(or higher).

Regards, Ate
Ate Douma wrote:
Dear developer team and users,
I've been working the last two weeks (off and on) on a new and much 
simplified deployment implementation
for Jetspeed-2 which builds mainly on official Servlet specification 
(2.3) features.
See JIRA: http://issues.apache.org/jira/browse/JS2-210

I expect that with this solution, deployment for Application servers 
other than Tomcat will become much easier
to implement and support.

I've got this working already beautifully on Tomcat 5 (5.0.28) and 
with a few nice side-effects too:
- the Jetspeed-2 context isn't fixed at /jetspeed any more
- multiple layout portlet applications can be deployed/used at the 
same time
  for both see:
http://issues.apache.org/jira/browse/JS2-182
http://issues.apache.org/jira/browse/JS2-172
- no more temporarily expanded wars in the java.io.tmpdir to 
workaround classloading issues
- much quicker startup

To be honest, my refactoring isn't finished yet and some features 
currently available will have to be
reimplemented (differently) like undeployment.

But
I can't get the redeployment working flawlessly under Tomcat 4.1 
(tested with 4.1.30 and 4.1.31).
Tomcat 4 won't always release certain jars in deployed applications 
when doing an undeployment or redeployment while this
is no problem with Tomcat 5.0.
Furthermore, auto redeployment of war files isn't available at all 
in Tomcat 4: you need to use the TomcatManager
to remove an existing application first (which sometimes fails) 
before a new application can tried to be deployed
again.

And then, There are other serious problems with Tomcat 4 too like no 
separate sessions for the portal and portlet applications
(which is a *serious* security breach and the foremost reason I 
myself won't use Tomcat 4 for Portals anymore).

The Pluto Team won't even use Tomcat 5.0 anymore and require Tomcat 
5.5.7 or higher because Tomcat 5.0 also has a session bug
in which a Portlet Application and its Web application don't share 
the same session when invoked independently
(as they should according to the portlet specification).

Both the development of Tomcat 4 and Tomcat 5.0 has largely come to 
an end, except for really nasty bugs, but the onces I
described above aren't regarded as such by the Tomcat team :-(

Al in all, to me the question right now is: do we really, really 
need to keep supporting Tomcat 4.
For my deployment refactorings it poses a problem I don't have time 
left to further investigate (nor do I have any hope it
*can* be resolved). As long as we need to support Tomcat 4, I can't 
commit my changes...

I'd like to hear from both team members and users who absolutely 
require Tomcat 4 support for Jetspeed-2 and why.
And, if there are no big objections, I'd like to vote on dropping 
Tomcat 4 support!

Please comment,
Ate

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



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


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


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



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

Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote! [Results]

[Ate Douma]

I've counted 12 +1 votes so far for dropping Tomcat 4.1 support
(5 team members/ 7 users), with 4 votes under the condition Tomcat 5.5
support should be provided first.
No 0 or -1 votes.
I committed my changes to the deployment-refactoring, which includes Tomcat 5.5
support, for everyone to review and test.
See:
  http://issues.apache.org/jira/browse/JS2-210?page=comments#action_60016
If those changes are merged in CVS HEAD, Tomcat 4.1 support will be dropped.
Regards, Ate
Ate Douma wrote:
Dear developer team and users,
I've been working the last two weeks (off and on) on a new and much 
simplified deployment implementation
for Jetspeed-2 which builds mainly on official Servlet specification 
(2.3) features.
See JIRA: http://issues.apache.org/jira/browse/JS2-210

I expect that with this solution, deployment for Application servers 
other than Tomcat will become much easier
to implement and support.

I've got this working already beautifully on Tomcat 5 (5.0.28) and with 
a few nice side-effects too:
- the Jetspeed-2 context isn't fixed at /jetspeed any more
- multiple layout portlet applications can be deployed/used at the same 
time
  for both see:
http://issues.apache.org/jira/browse/JS2-182
http://issues.apache.org/jira/browse/JS2-172
- no more temporarily expanded wars in the java.io.tmpdir to workaround 
classloading issues
- much quicker startup

To be honest, my refactoring isn't finished yet and some features 
currently available will have to be
reimplemented (differently) like undeployment.

But
I can't get the redeployment working flawlessly under Tomcat 4.1 (tested 
with 4.1.30 and 4.1.31).
Tomcat 4 won't always release certain jars in deployed applications when 
doing an undeployment or redeployment while this
is no problem with Tomcat 5.0.
Furthermore, auto redeployment of war files isn't available at all in 
Tomcat 4: you need to use the TomcatManager
to remove an existing application first (which sometimes fails) before a 
new application can tried to be deployed
again.

And then, There are other serious problems with Tomcat 4 too like no 
separate sessions for the portal and portlet applications
(which is a *serious* security breach and the foremost reason I myself 
won't use Tomcat 4 for Portals anymore).

The Pluto Team won't even use Tomcat 5.0 anymore and require Tomcat 
5.5.7 or higher because Tomcat 5.0 also has a session bug
in which a Portlet Application and its Web application don't share the 
same session when invoked independently
(as they should according to the portlet specification).

Both the development of Tomcat 4 and Tomcat 5.0 has largely come to an 
end, except for really nasty bugs, but the onces I
described above aren't regarded as such by the Tomcat team :-(

Al in all, to me the question right now is: do we really, really need to 
keep supporting Tomcat 4.
For my deployment refactorings it poses a problem I don't have time left 
to further investigate (nor do I have any hope it
*can* be resolved). As long as we need to support Tomcat 4, I can't 
commit my changes...

I'd like to hear from both team members and users who absolutely require 
Tomcat 4 support for Jetspeed-2 and why.
And, if there are no big objections, I'd like to vote on dropping Tomcat 
4 support!

Please comment,
Ate

-
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: jmock-SNAPSHOT.jar

[Ate Douma]

Try maven -o (offline).
SNAPSHOT dependencies are always checked if uptodate by maven.
Andreas Ernst wrote:
Hi,
it seems that 'maven allClean allBuild' tries every run to download 
jmock-SNAPSHOT.jar, but the file is still in 
{userhome}\.maven\repository\jmock\jars\jmock-SNAPSHOT.jar

While running Maven it show very often the message:
Attempting to download jmock-SNAPSHOT.jar.
But as i know Maven, after one download that file is locally saved. Is 
it a problem of  Jetspeed, Maver or i am totally wrong?

regards
Andreas
-
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: M1 and struts App with Tiles

[Ate Douma]

[EMAIL PROTECTED] wrote:
hello !
another problem i have:
my M1 installation works fine.
but the M1-version of the struts-bridge does not support tiles.
when i try it, i get following message:
(when i look for this problem in internet i find sites from 2003 - not 
really new)

in the current subversion version of the bridge - tiles will be supported. 

but, is it possible to fix the tiles problem in the M1 version ?
only changing the bridge does not work - i think there are a lot of 
dependencies...
The M1 release was a milestone only, not a branch.
As we intend to release a M2 soon (hopefully this month) I think you'll have
to work with the CVS HEAD for now or wait for the M2 release.
thanks for answer
best regards
tkoch
2005-03-01 14:51:59,662 FATAL tiles.TilesPlugin - TilesPlugin : Specified 
RequestProcessor not compatible with TilesRequestProcessor
2005-03-01 14:53:45,604 FATAL tiles.TilesPlugin - TilesPlugin : Specified 
RequestProcessor not compatible with TilesRequestProcessor
2005-03-01 14:53:45,604 ERROR struts.StrutsPortlet - Include exception
javax.servlet.ServletException: TilesPlugin : Specified RequestProcessor 
not compatible with TilesRequestProcessor
at 
org.apache.struts.tiles.TilesPlugin.initRequestProcessorClass(TilesPlugin.java:360)
at org.apache.struts.tiles.TilesPlugin.init(TilesPlugin.java:164)
at 
org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:1158)
at 
org.apache.struts.action.ActionServlet.init(ActionServlet.java:473)
at javax.servlet.GenericServlet.init(GenericServlet.java:211)
at 
org.apache.portals.bridges.struts.PortletServlet.init(PortletServlet.java:45)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1029)
at 
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:687)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
at 
org.apache.portals.bridges.struts.StrutsPortlet.processRequest(StrutsPortlet.java:283)
at 
org.apache.portals.bridges.struts.StrutsPortlet.doView(StrutsPortlet.java:221)
at 
javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at 
org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:235)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
at 
org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
at 
org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
at 
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103)
at 
org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88)
at 
org.apache.jetspeed.aggregator.impl.RenderingJob.run(RenderingJob.java:109)
at 
org.apache.jetspeed.aggregator.impl.Worker$1.run(Worker.java:171)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:437)
at org.apache.jetspeed.aggregator.impl.Worker.run(Worker.java:165)
2005-03-01 15:13:36,886 FATAL tiles.TilesPlugin - TilesPlugin : Specified 
RequestProcessor not compatible with TilesRequestProcessor
2005-03-01 15:13:36,886 ERROR struts.StrutsPortlet - Include exception
javax.servlet.ServletException: TilesPlugin : Specified RequestProcessor 
not compatible with TilesRequestProcessor
at 
org.apache.struts.tiles.TilesPlugin.initRequestProcessorClass(TilesPlugin.java:360)

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

Re: changing portlet title

[Ate Douma]

Valerie Lavilla wrote:
Hi I've seen this problem in the mailing archive dated October 25 of 2004. Has there been a patch yet for this issue?
 

Also, the ability to change the JSR168 portlet title is missing.  I 
already tried, overriding getTitle() method of GenericPortlet and 
response.setTitle(SomeTitle).
I don't know, haven't tested this myself.
Have you tried it?
If it isn't working you could create a JIRA ticket for it (if it hasn't been 
done already):
  http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10492

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

Re: M1 and struts App with Tiles

[Ate Douma]

[EMAIL PROTECTED] wrote:
The M1 release was a milestone only, not a branch.

As we intend to release a M2 soon (hopefully this month) I think you'll 
have
to work with the CVS HEAD for now or wait for the M2 release.

ok, thank you for answer !
but with the head there ist another problem you can see in
the other thread. J2 would not like to start correctly:
http://www.mail-archive.com/jetspeed-dev@jakarta.apache.org/msg18970.html
What you are seeing is a mix up of incompatible classes.
I suggest cleaning up your current J2 project (maven allClean would do),
completely cleaning up Tomcat, especially the shared/lib folder,
(or use a fresh Tomcat installation) and build and deploy again.
That should solve your problem.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Newbie: Accessing SVN

[Ate Douma]

Look here:
  http://portals.apache.org/jetspeed-2/cvs-usage.html
and for cvsview access to the Struts Bridge:
  http://cvs.apache.org/viewcvs.cgi/jakarta-jetspeed-2/portals-bridges/struts/
and for the site documentation for the Struts Bridge:
  
http://portals.apache.org/jetspeed-2/multiproject/portals-bridges-struts/index.html
Jetspeed-2 is still maintained in cvs although we hope to move to SVN some time 
soon,
when someone of use finds enough time to bring this through.
Regards, Ate
Derek Richardson wrote:
Hi. I'm new to Jetspeed and want to look at the source for the current
Struts Bridge. I tried:
svn co http://svn.apache.org/repos/asf/portals/site/
But that only gave me txt docs and xml, not the source. Please let me
know how to get to the source.
Thanks,
Derek Richardson
-
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]

Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!

[Ate Douma]

Dear developer team and users,
I've been working the last two weeks (off and on) on a new and much simplified 
deployment implementation
for Jetspeed-2 which builds mainly on official Servlet specification (2.3) 
features.
See JIRA: http://issues.apache.org/jira/browse/JS2-210
I expect that with this solution, deployment for Application servers other than 
Tomcat will become much easier
to implement and support.
I've got this working already beautifully on Tomcat 5 (5.0.28) and with a few 
nice side-effects too:
- the Jetspeed-2 context isn't fixed at /jetspeed any more
- multiple layout portlet applications can be deployed/used at the same time
  for both see:
http://issues.apache.org/jira/browse/JS2-182
http://issues.apache.org/jira/browse/JS2-172
- no more temporarily expanded wars in the java.io.tmpdir to workaround 
classloading issues
- much quicker startup
To be honest, my refactoring isn't finished yet and some features currently 
available will have to be
reimplemented (differently) like undeployment.
But
I can't get the redeployment working flawlessly under Tomcat 4.1 (tested with 
4.1.30 and 4.1.31).
Tomcat 4 won't always release certain jars in deployed applications when doing 
an undeployment or redeployment while this
is no problem with Tomcat 5.0.
Furthermore, auto redeployment of war files isn't available at all in Tomcat 4: 
you need to use the TomcatManager
to remove an existing application first (which sometimes fails) before a new 
application can tried to be deployed
again.
And then, There are other serious problems with Tomcat 4 too like no separate 
sessions for the portal and portlet applications
(which is a *serious* security breach and the foremost reason I myself won't 
use Tomcat 4 for Portals anymore).
The Pluto Team won't even use Tomcat 5.0 anymore and require Tomcat 5.5.7 or 
higher because Tomcat 5.0 also has a session bug
in which a Portlet Application and its Web application don't share the same 
session when invoked independently
(as they should according to the portlet specification).
Both the development of Tomcat 4 and Tomcat 5.0 has largely come to an end, 
except for really nasty bugs, but the onces I
described above aren't regarded as such by the Tomcat team :-(
Al in all, to me the question right now is: do we really, really need to keep 
supporting Tomcat 4.
For my deployment refactorings it poses a problem I don't have time left to 
further investigate (nor do I have any hope it
*can* be resolved). As long as we need to support Tomcat 4, I can't commit my 
changes...
I'd like to hear from both team members and users who absolutely require Tomcat 
4 support for Jetspeed-2 and why.
And, if there are no big objections, I'd like to vote on dropping Tomcat 4 
support!
Please comment,
Ate

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

Re: Force restart/reload

[Ate Douma]

David Sean Taylor wrote:
Christophe Lombart wrote:
I had similar issues with my portlets.
There is a bug in tomcat 5.0.28 with the autoDeploy. It is not used 
correctly in this version.
Now, I use tomcat 5.0.30 and hot deploy works fine.

I usually just deploy the entire webapp (portlet app) by dropping it 
into the jetspeed deploy directory (maven task), although that can be 
expensive if you have a lot jars in your distribution, but it still can 
be quicker than restarting

I still think we need to further look into Jetspeed portlet cache since 
it holds on to the webapp class loader and could be causing this kind of 
problem. Not sure if Ate's latest go at deployment is considering this 
or not
yes ;-)
The main rationale behind my refactoring is relying on the web server
classloader handling only (for non-local portlet applications).


Christophe
Howard Lewis Ship wrote:
Is there a quick and easy way to force Jetspeed to restart?
I'm hot deploying a small portlet into Jetspeed.
I believe (not 100% certain) that it is picking up changes to my
Portlet instance after the hot deploy.
It does not appear to pick up changes to a static helper class.  I see
Portlet is Not Available: ClickLink
Reason: Node has been removed.
At the bottom of my portlet's window.
I'm having to stop/restart Tomcat to pick up such changes and I'm
hoping for something a little quicker and easier.
 


-
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: struts bridge problem

[Ate Douma]

jean charles jabouille said:
 Hi,

 I use Jetspeed2 on Jonas. I have a struts bridge problem, when I try to
 authentifacte on the Jetspeed default page, it means that I successfull
 authentificate but the forward page is the same. So when I try to login on
 admin account, the struts renderRequest is the guest user page. I have
 this log when I authentificate on admin admin.

Jean Charles,
I don't really understand your problem description.

I think you are saying the authentication was successfull, but then you
are still shown *a* guest user page (as you are referring to the *struts*
renderRequest).
Which page in what portlet do you mean?

On the other hand, maybe I really misunderstand your question.

The log below doesn't contain any information to go by, so could you
please be more specific what you do, what happens and what exactly your
problem is...



 2005-02-16 11:12:10,048 : AbstractEngine.getContainerService : No
 ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService
 2005-02-16 11:12:10,073 : AbstractEngine.getContainerService : No
 ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService
 2005-02-16 11:12:10,110 : AbstractEngine.getContainerService : No
 ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService
 2005-02-16 11:12:10,135 : AbstractEngine.getContainerService : No
 ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService
 2005-02-16 11:12:10,156 : AbstractEngine.getContainerService : No
 ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService
 2005-02-16 11:12:10,278 : AbstractEngine.getContainerService : No
 ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService
 2005-02-16 11:12:10,304 : AbstractEngine.getContainerService : No
 ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService
 2005-02-16 11:12:10,347 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 ResourceManager : found /WEB-INF/templates/layout/html/columns/layout.vm
 with loader org.apache.velocity.tools.view.servlet.WebappLoader
 2005-02-16 11:12:10,378 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 ResourceManager : found
 /WEB-INF/decorations/layout/html/tigris/decorator-top.vm with loader
 org.apache.velocity.tools.view.servlet.WebappLoader
 2005-02-16 11:12:10,387 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage : RHS
 of #set statement is null. Context will not be modified.
 /WEB-INF/decorations/layout/html/tigris/decorator-top.vm [line 1, column
 1]
 2005-02-16 11:12:10,394 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage : RHS
 of #set statement is null. Context will not be modified.
 /WEB-INF/decorations/layout/html/tigris/decorator-top.vm [line 39, column
 1]
 2005-02-16 11:12:10,402 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 Warning! The iterative  is an Iterator in the #foreach() loop at [0,0] in
 template /WEB-INF/decorations/layout/html/tigris/decorator-top.vm. Because
 it's not resetable, if used in more than once, this may lead to unexpected
 results.
 2005-02-16 11:12:10,412 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 Warning! The iterative  is an Iterator in the #foreach() loop at [0,0] in
 template /WEB-INF/decorations/layout/html/tigris/decorator-top.vm. Because
 it's not resetable, if used in more than once, this may lead to unexpected
 results.
 2005-02-16 11:12:10,435 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 Warning! The iterative  is an Iterator in the #foreach() loop at [0,0] in
 template /WEB-INF/decorations/layout/html/tigris/decorator-top.vm. Because
 it's not resetable, if used in more than once, this may lead to unexpected
 results.
 2005-02-16 11:12:10,456 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 ResourceManager : found
 /WEB-INF/decorations/portlet/html/tigris/decorator.vm with loader
 org.apache.velocity.tools.view.servlet.WebappLoader
 2005-02-16 11:12:10,481 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 ResourceManager : found
 /WEB-INF/decorations/portlet/html/tigris/decorator.vm with loader
 org.apache.velocity.tools.view.servlet.WebappLoader
 2005-02-16 11:12:10,506 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 ResourceManager : found
 /WEB-INF/decorations/portlet/html/tigris/decorator.vm with loader
 org.apache.velocity.tools.view.servlet.WebappLoader
 2005-02-16 11:12:10,533 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 ResourceManager : found
 /WEB-INF/decorations/portlet/html/tigris/decorator.vm with loader
 org.apache.velocity.tools.view.servlet.WebappLoader
 2005-02-16 11:12:10,570 :
 JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 ResourceManager : found
 

Re: struts bridge problem

[Ate Douma]

jean charles jabouille said:
 Yes, sorry for my poor english...

 I deploy the last CVS of Jetspeed2 on Jonas 4.1.4 . When I go to
 http://localhost:8080/jetspeed, I try to authentificate by the username
 admin and password admin. It seems that the authentification is
 successfull but after this authentification, Jetspeed don't load the
 administration portlet. It's the anonyme(guest) portlet which is
 loaded...
 It seems that the administrator portlet is unexistant or inaccessible.

I still don't quite understand *which* portlet isn't loaded.
Maybe you mean page?
Anyway, after login from the start page as admin, Jetspeed will return
you to a page containing the same set of portlets as you have as guest
user. The administration portlets then are accessible through the
list of links shown to the left.

I'm still not sure we are talking about the same thing here.
Maybe it might help if you create screenshorts from the different pages
you look at before, and after login.
Although I don't think the list will allow screenshots to be attached,
you can create a new JIRA ticket for your problem and attach screenshots
to it: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10492


 In the trace of my last message, the line
 AbstractEngine.getContainerService : No ContainerService defined for
 org.apache.pluto.services.title.DynamicTitleService alerted me.

 I precise that for the good fonctionnement of Jetspeed, I have to hot
 deploy
 the portlet application webapps at the first time that Jetspeed deploying.

 best regards

 Jabouille Jean Charles

 - Original Message -
 From: Ate Douma [EMAIL PROTECTED]
 To: Jetspeed Users List jetspeed-user@jakarta.apache.org
 Sent: Wednesday, February 16, 2005 1:29 PM
 Subject: Re: struts bridge problem


 jean charles jabouille said:
  Hi,
 
  I use Jetspeed2 on Jonas. I have a struts bridge problem, when I try
 to
  authentifacte on the Jetspeed default page, it means that I
 successfull
  authentificate but the forward page is the same. So when I try to
 login
 on
  admin account, the struts renderRequest is the guest user page. I
 have
  this log when I authentificate on admin admin.

 Jean Charles,
 I don't really understand your problem description.

 I think you are saying the authentication was successfull, but then you
 are still shown *a* guest user page (as you are referring to the
 *struts*
 renderRequest).
 Which page in what portlet do you mean?

 On the other hand, maybe I really misunderstand your question.

 The log below doesn't contain any information to go by, so could you
 please be more specific what you do, what happens and what exactly your
 problem is...

 
 
  2005-02-16 11:12:10,048 : AbstractEngine.getContainerService : No
  ContainerService defined for
  org.apache.pluto.services.title.DynamicTitleService
  2005-02-16 11:12:10,073 : AbstractEngine.getContainerService : No
  ContainerService defined for
  org.apache.pluto.services.title.DynamicTitleService
  2005-02-16 11:12:10,110 : AbstractEngine.getContainerService : No
  ContainerService defined for
  org.apache.pluto.services.title.DynamicTitleService
  2005-02-16 11:12:10,135 : AbstractEngine.getContainerService : No
  ContainerService defined for
  org.apache.pluto.services.title.DynamicTitleService
  2005-02-16 11:12:10,156 : AbstractEngine.getContainerService : No
  ContainerService defined for
  org.apache.pluto.services.title.DynamicTitleService
  2005-02-16 11:12:10,278 : AbstractEngine.getContainerService : No
  ContainerService defined for
  org.apache.pluto.services.title.DynamicTitleService
  2005-02-16 11:12:10,304 : AbstractEngine.getContainerService : No
  ContainerService defined for
  org.apache.pluto.services.title.DynamicTitleService
  2005-02-16 11:12:10,347 :
  JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
  ResourceManager : found
 /WEB-INF/templates/layout/html/columns/layout.vm
  with loader org.apache.velocity.tools.view.servlet.WebappLoader
  2005-02-16 11:12:10,378 :
  JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
  ResourceManager : found
  /WEB-INF/decorations/layout/html/tigris/decorator-top.vm with loader
  org.apache.velocity.tools.view.servlet.WebappLoader
  2005-02-16 11:12:10,387 :
  JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 RHS
  of #set statement is null. Context will not be modified.
  /WEB-INF/decorations/layout/html/tigris/decorator-top.vm [line 1,
 column
  1]
  2005-02-16 11:12:10,394 :
  JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
 RHS
  of #set statement is null. Context will not be modified.
  /WEB-INF/decorations/layout/html/tigris/decorator-top.vm [line 39,
 column
  1]
  2005-02-16 11:12:10,402 :
  JetspeedVelocityViewServlet$VelocityEngineLogger.logVelocityMessage :
  Warning! The iterative  is an Iterator in the #foreach() loop at [0,0]
 in
  template /WEB-INF/decorations/layout/html/tigris/decorator-top.vm.
 Because
  it's

Re: Admin password for jetspeed 2

[Ate Douma]

Jack,
The default/demo user accounts are inserted in the database table 
SECURITY_CREDENTIAL
by the database dependent populate-userinfo-for-default-psml.sql scripts which
you can find under the src/sql folder.
For all these accounts the (initial) password is the same as the user name:
  admin/admin
  jetspeed/jetspeed
  user/user
  et cetera
Now, as you probably have tried more than 3 times different passwords for the
admin user, you are in bad luck: the account will be locked out by now by the
default configured security rules!
You can re enable a user account by setting the IS_ENABLED column value for the
admin user back to 1 (it will be 0 if the account is locked out).
To determine which record actually is the one for the admin user, find
the record with:
  SECURITY_CREDENTIAL.PRINCIPAL_ID = SECURITY_PRINCIPAL.PRINCIPAL_ID
  AND SECURITY_PRINCIPAL.FULL_PATH = '/user/admin'
or just set them all back to value 1.
The reason you couldn't find the correct password (anymore) for the admin user
in the database is because it is encrypted by now. Initially, these aren't 
encrypted
as you can find out from the populate scripts, but they will be at first access
(with the default configured security rules that is).
Once you have re enabled the admin user and can login with admin/admin, you can 
use
the administrative UserManagement portlets to enable other user accounts which 
might
have been locked out again.
Note: at first login, you'll be required to change the password again ;-)
And yes, you are right, we should document this more prominently I guess :-)
Regards,
ATe
Jack Lund wrote:
Hi. I apologize if this is a newbie question, but I'm having a lot of
trouble logging in as admin with my jetspeed 2 installation. The
jetspeed 2 docs don't seem to have any indication (that I have seen) of
what the default admin password is, and I've tried the one listed in the
jetspeed 1 docs, plus any others I could think of. I've also tried
looking for docs on where the passwords are kept, with no luck. I've
also tried just looking through the DB tables, again with no luck.
Please, any assistance would be greatly appreciated.
Thanks.

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

Re: Admin password for jetspeed 2

[Ate Douma]

Just to be clear: the correct (initial) password for the admin user *is* admin
(as you can see from your own select results).
Now, it doesn't look your passwords are yet encrypted. That means they haven't
been accessed yet. At least, not from this table. As you don't seem to have 
other
problems during startup (indicating your not connected to any database) I 
suspect
you might be looking at the wrong one.
You probably know already Jetspeed-2 uses two different database/schemas: one 
for
building/tests and one for production.
Is it possible you are using or looking at the wrong schema for the production 
database?
Check the jetspeed.xml in $TOMCAT/conf/Catalina/localhost.
The connection parameters used by the portal at runtime are stored in there.
Jack Lund wrote:
I tried those first off. No luck. Strangely enough, I also looked at the
SECURITY_CREDENTIAL table for the password. I was figuring on seeing
encrypted passwords there. Instead, this is what is in mine:
mysql select * from SECURITY_CREDENTIAL;
+---+--+--+--
+-
+-+++---
++++
++-+
| CREDENTIAL_ID | PRINCIPAL_ID | VALUE| TYPE | CLASSNAME
| UPDATE_REQUIRED | IS_ENCODED | IS_ENABLED | AUTH_FAILURES | IS_EXPIRED
| CREATION_DATE  | MODIFIED_DATE  | PREV_AUTH_DATE | LAST_AUTH_DATE |
EXPIRATION_DATE |
+---+--+--+--
+-
+-+++---
++++
++-+
| 1 |1 | admin|0 |
org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl |
0 |  0 |  1 | 0 |  0 |
20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL
|
| 2 |2 | manager  |0 |
org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl |
0 |  0 |  1 | 0 |  0 |
20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL
|
| 3 |3 | user |0 |
org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl |
0 |  0 |  1 | 0 |  0 |
20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL
|
| 4 |4 | tomcat   |0 |
org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl |
0 |  0 |  1 | 0 |  0 |
20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL
|
| 5 |5 | jetspeed |0 |
org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl |
0 |  0 |  1 | 0 |  0 |
20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL
|
|50 |   50 | subsite  |0 |
org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl |
0 |  0 |  1 | 0 |  0 |
2005010100 | 2005010100 | 20050206144752 | 20050206144752 | NULL
|
|51 |   51 | subsite2 |0 |
org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl |
0 |  0 |  1 | 0 |  0 |
2005010100 | 2005010100 | 20050206144752 | 20050206144752 | NULL
|
+---+--+--+--
+-
+-+++---
++++
++-+
7 rows in set (0.00 sec)
I don't see any encrypted passwords there. I do see what might be
unencrypted passwords, in column 3, but I tried those and it didn't
work. Also, even though I have tried and failed several passwords, the
AUTH_FAILURES and IS_ENABLED columns haven't changed. Obviously, I'm
missing something, but I don't know what it is.
Just for some background, I initially tried the default hypersonic
database, and couldn't get in using admin/admin, admin/jetspeed, or
anything else I could think of to try, and I figured it would be easier
for me to look at the DB tables from mysql, so I moved everything to
mysql (which wasn't too bad, really, thanks to the docs), and got it
going again. I don't have hypersonic running, so I'm pretty sure it's
not going against that DB, but I really can't explain why none of this
is working.
Again, any help would be appreciated.
-Jack
On Sun, 2005-02-06 at 22:36 +0100, Ate Douma wrote:

Jack,
The default/demo user accounts are inserted in the database table 
SECURITY_CREDENTIAL
by the database dependent populate-userinfo-for-default-psml.sql scripts which
you

Re: Security web.xml Example

[Ate Douma]

Stephen Hatfield wrote:
Hello-
I have installed J2 on Linux and all is working properly except the 
login portlet is empty. I saw a previous post on an addition to the 
web.xml file in security/WEB-INF. I have no files at all in that 
directory in webapps in Tomcat (5.0.28).
Then something went wrong during deployment.
You should see numerous files there, all contained within the security.war.
There is no need to add anything else.
I'd suggest stopping Tomcat and removing the empty folder. Also, remove
the security.xml from $TOMCAT/conf/Catalina/localhost.
Then, restart Tomcat and once Jetspeed is up and running, move the
security.war out of the jetspeed/WEB-INF/deploy in some temporary folder.
After a few seconds, Jetspeed will try to undeploy the security application.
Once that is done, you can move the security.war back in the deploy folder,
and Jetspeed will (try to) deploy it again.
Please, check the Tomcat console carefully for error messages. If all goes
well the security/WEB-INF shouldn't be empty now.
 I have a question and a request.
Question - what files should be in the security/WEB-INF directory?
Request - would someone please post a link to an example web.xml file 
for security/WEB-INF?

Thank you!
Stephen Hatfield
-
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: J2 Warning: HttpServletRequest.getContextPath() now returns the contextPath of the Portlet, not the Portal

[Ate Douma]

David Sean Taylor wrote:
Ate Douma wrote:
I've just fixed issue: http://issues.apache.org/jira/browse/JS2-203
Please read it if you are currently are (mis)using the
Portal contextPath from within a Servlet/JSP/Velocity dispatched by a 
Portlet.

Regards, Ate

after a cvs update, when I login Im now getting
--
HTTP Status 404 - /security/login/proxy
type Status report
message /security/login/proxy
description The requested resource (/security/login/proxy) is not 
available.
Apache Tomcat/5.0.30
--

Shouldn't we now be logging on to /login/proxy ?
-
No, to /jetspeed/login/proxy.
I can't reproduce your error. Please check that you indeed have updated
the change-password.jsp and login.jsp from the security application.
In these the required url is now generated with an explicit reference
to the portal (jetspeed) context using the following construction:
c_rt:set var=requestContext
  value=%=request.getAttribute(RequestContext.REQUEST_PORTALENV)%/
c:url context=${requestContext.request.contextPath}
   value=/login/proxy/
This should lead to a url prefixed with the portal (/jetspeed) context.
Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: J2: Absolute URL rendering

[Ate Douma]

I already have a patch ready for issue 
http://issues.apache.org/jira/browse/JS2-204.
It will solve this issue as well.
But, the is one catch related to using non-secure PortletURLs when in a secure 
mode
which I want to discuss first with the Pluto team before I commit it.
[EMAIL PROTECTED] wrote:
Scott,
I think this can be addressed in the layout decorators/macros if you would
like a quick workaround, (it invokes a method in the JetspeedPowerTool
there to convert relative urls into absolute ones: you could use your own
constants or macros there).
Otherwise, I have added it to my todo list,
Thanks,
Randy

Hello all,
I have noticed that whatever renders navigation urls apparently writes
fully-qualified urls instead of relative ones, apparently based on
whatever the hostname is in the incoming request.
Is this a configurable option? The reason I ask is that if not, this
makes it difficult if not impossible to proxy behind say an apache httpd
instance.
In the past, I've been able to route virtual hostnames to specific
webapps in tomcat (or any other container for that matter by this sort
of httpd configuration:
snip
NameVirtualHost *:80
#... other virtual host configurations
VirtualHost *:80
   ServerName app1.mydomain.com
   RewriteEngine on
   RewriteRule ^(.*)$ http://my.tomcat.host:8080/
   ProxyPassReverse / http://my.tomcat.host:8080/
/VirtualHost
/snip
This allows http://app1.mydomain.com to be routed to an internal tomcat
host on a different port, and can even be used to mask the app1
context from the end user.  Since app1 writes its urls using relative
/  prefixed paths, all is well.
I have tried this with J2, and when I navigate to
http://subdomain.myhost.com the left-nav links such as Public Links
render not as /jetspeed/portal/Public but as
http://my.tomcat.host:8080/jetspeed/portal/Public;.  Depending on
network configuration, this linke may or may not even resolve to the end
user.
Since httpd is not performing url rewriting, it would appear that J2 is
writing
protocol:host:port/context instead of relative paths.
What can I do to change this behavior? It is my goal to at some point
mask the fact that my portal is running in a /jetspeed context as well
as to run tomcat behind an httpd front-end in the same manner as my many
other webapps housed in tomcat.
Regards,
--
-Scott
Scott Heaberlin
- To
unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]



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



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

Re: Struts and JSF

[Ate Douma]

Sorry Evian for the delayed response.
I planned on giving a reply but completely forgot.
Here it is:
For migrating Struts applications to portlet I can help you out very soon!
I've developed the Struts Bridge which allows you to run Struts applications
transparently as portlet AND as web application (at the same time!).
Your action mappings must be compliant to a few restrictions
(of the Portlet Specification) as well all your actions, links and resource urls
should be rendered using modified Struts html tags (provided by the Bridge).
I'm writing the docs for the latest Struts Bridge right now (and there aren't 
any
old docs), so if you could hold on for a few more days and you will be ready 
to
go.
Concerning JSF Portlets, we have a JSF Bridge as well, using MyFaces as
JSF implementation. There aren't any docs yet for that either but someone else
of the team maybe can help you out some more.
With the latest default installation of Jetspeed-2 several Portlets are provided
using the Struts as well the JSF Bridge. Just check them out.
About Portlet communication: yes, under a few restrictions.
Check out Portlet Specification chapter PLT.15 and the link Frank Villarreal
provided.
Furthermore, we hope to come up with a mechanism for inter-portlet 
communications
between portlets not in the same portlet application, but I can't tell you much
more about it yet because I'm not the one providing it.
[EMAIL PROTECTED] wrote:
Hi ,
I never got an response.  I would appreciate it if
anybody has anything.  Thanks...Please forgive me if
you think my questions are too newbie!
Evian
n Wed, 26 Jan 2005 05:43:40 -0800 (PST),
[EMAIL PROTECTED] wrote:

Hi, I have two applications.  The first one is build
in
struts and the other one build with JSF framework. 
Are
there some good resource/links/documents/how-to for
converting the struts and JSF application to a portlet
and deploying them in Jetspeed 2.  Also, I assume that
my two protlets I want to deploy will be able to talk
to each other?
Evian./

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

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



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

J2 Warning: HttpServletRequest.getContextPath() now returns the contextPath of the Portlet, not the Portal

[Ate Douma]

I've just fixed issue: http://issues.apache.org/jira/browse/JS2-203
Please read it if you are currently are (mis)using the
Portal contextPath from within a Servlet/JSP/Velocity dispatched by a Portlet.
Regards, Ate

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

Re: [J2] Newbie: Error 404 with login portlet

[Ate Douma]

It seems Weblogic changes the contextPath for an included servlet to the
contextPath of the servlet itself.
According to the servlet spec 2.3 SRV.8.3.1 Included Request Parameters:
Except for servlets obtained by using the getNamedDispatcher method, a servlet
being used from within an include has access to the path by which it was 
invoked.
Jetspeed does *NOT* invoke portlets using getNamedDispatcher so the contextPath
for the Portlet should still be that of the portal itself (/jetspeed).
In the login portlet the form is posted to c:url value=/login/proxy/.
The url tag will prefix this with the contextPath so it should be 
/jetspeed/login/proxy.
You could temporarily fix this for Weblogic by adding attribute 
context=/jetspeed
to the tag: c:url context=/jetspeed value=/login/proxy/
You can find the login.jsp in webapp security/WEB-INF/security/login/login.jsp.
If you do, don't forget to also fix the :url value=/login/logout/ link 
which is
a few lines above it.
That should allow you to login and logout, but of course this isn't a real 
solution.
I suggest you create a JIRA ticket for this problem so.
I don't have Weblogic available but maybe one of the other developers does.
Ate
romain bisse wrote:
Hi,
 
I've just installed Jetspeed2-M1 on Weblogic 8.1
Most of the modules work fine, however, I can't log in.
 
I obtain a 404 error when I clik on the login button.
There is no exception, neither in jetspeed nor in weblogic logs.
 
The URL in my browser at this moment is
http://localhost:7001/security/login/proxy;
 
Did I forget something during the installation process?
 
Thanks in advance if you have any clue!


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

Re: [J2] Newbie: Error 404 with login portlet

[Ate Douma]

Ate Douma wrote:
It seems Weblogic changes the contextPath for an included servlet to the
contextPath of the servlet itself.
According to the servlet spec 2.3 SRV.8.3.1 Included Request Parameters:
Except for servlets obtained by using the getNamedDispatcher method, a 
servlet
being used from within an include has access to the path by which it was 
invoked.
I should also have quoted the following part of SRV.8.3.1 I think:
The following request attributes are set:
 javax.servlet.include.request_uri
 javax.servlet.include.context_path
 javax.servlet.include.servlet_path
 javax.servlet.include.path_info
 javax.servlet.include.query_string
  These attributes are accessible from the included servlet via the getAttribute
method on the request object.
  If the included servlet was obtained by using the getNamedDispatcher
method these attributes are not set.
After rereading this paragraph three times over, I must admit it does not
explicitly say the request.getContextPath() for an included servlet should
remain the same. But, if that would not be the intention of this paragraph,
then one would never *need* the javax.servlet.include._context_path attribute
or the others.
So, my interpretation of this is that the request.getContextPath() *should*
remain the same. Seems the Weblogic developers think differently...
Jetspeed does *NOT* invoke portlets using getNamedDispatcher so the 
contextPath
for the Portlet should still be that of the portal itself (/jetspeed).

In the login portlet the form is posted to c:url value=/login/proxy/.
The url tag will prefix this with the contextPath so it should be 
/jetspeed/login/proxy.

You could temporarily fix this for Weblogic by adding attribute 
context=/jetspeed
to the tag: c:url context=/jetspeed value=/login/proxy/
You can find the login.jsp in webapp 
security/WEB-INF/security/login/login.jsp.

If you do, don't forget to also fix the :url value=/login/logout/ 
link which is
a few lines above it.

That should allow you to login and logout, but of course this isn't a 
real solution.

I suggest you create a JIRA ticket for this problem so.
I don't have Weblogic available but maybe one of the other developers does.
Ate
romain bisse wrote:
Hi,
 
I've just installed Jetspeed2-M1 on Weblogic 8.1
Most of the modules work fine, however, I can't log in.
 
I obtain a 404 error when I clik on the login button.
There is no exception, neither in jetspeed nor in weblogic logs.
 
The URL in my browser at this moment is
http://localhost:7001/security/login/proxy;
 
Did I forget something during the installation process?
 
Thanks in advance if you have any clue!


-
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: Portlets and filters

[Ate Douma]

I guess you are not running under Servlet 2.4?
Then it won't work.
Only since Servlet 2.4 will filters work for dispatched requests.
Xavier Lawrence wrote:
Hello,
I have a working struts application that I am trying to change to a
portlet. I was asking myself how were filters managed in the portlet
world. I seem to have a slight problem with those, they seem to be not
considered by the portlet.
That is, the non-portlet webApp works fine, but the portlet struts app
encounters problems because some filter methods don't seem to be called...
Any help is appreciated on the subject. Below is a piece of my web.xml file
filter
filter-nameXSLT Filter/filter-name
filter-classedu.rpi.sss.util.servlets.ConfiguredXSLTFilter/filter-class
init-param
  param-namedebug/param-name
  param-value0/param-value
/init-param
init-param
  param-namedirectoryBrowsingDisallowed/param-name
  param-valueno/param-value
/init-param
  /filter
  filter
filter-nameSvcI Filter/filter-name
filter-classedu.rpi.cct.uwcal.webcommon.UWCalSvciFilter/filter-class
init-param
  param-namedebug/param-name
  param-value0/param-value
/init-param
  /filter
-
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: Portlets and filters

[Ate Douma]

No, 2.4 has a Schema definition.
Use the following:
?xml version=1.0 encoding=ISO-8859-1?
  web-app xmlns=http://java.sun.com/xml/ns/j2ee;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
   http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
   version=2.4
and read Servlet 2.4 SRV.6.2.5 Filters and the RequestDispatcher.
Xavier Lawrence wrote:
So to do that, I need to specify the DTD version 2.4 in the DOCTYPE ???

Tomcat 5 still supports Servlet 2.3 and if you don't define your web.xml
as requiring 2.4
it will behave as a 2.3 container.
Xavier Lawrence wrote:
I am using Tomcat 5.0.28

I guess you are not running under Servlet 2.4?
Then it won't work.
Only since Servlet 2.4 will filters work for dispatched requests.
Xavier Lawrence wrote:

Hello,
I have a working struts application that I am trying to change to a
portlet. I was asking myself how were filters managed in the portlet
world. I seem to have a slight problem with those, they seem to be not
considered by the portlet.
That is, the non-portlet webApp works fine, but the portlet struts app
encounters problems because some filter methods don't seem to be
called...
Any help is appreciated on the subject. Below is a piece of my web.xml
file
filter
  filter-nameXSLT Filter/filter-name
  filter-classedu.rpi.sss.util.servlets.ConfiguredXSLTFilter/filter-class
  init-param
param-namedebug/param-name
param-value0/param-value
  /init-param
  init-param
param-namedirectoryBrowsingDisallowed/param-name
param-valueno/param-value
  /init-param
/filter
filter
  filter-nameSvcI Filter/filter-name
  filter-classedu.rpi.cct.uwcal.webcommon.UWCalSvciFilter/filter-class
  init-param
param-namedebug/param-name
param-value0/param-value
  /init-param
/filter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



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



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




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

[J2] Struts Bridge updated again

[Ate Douma]

I've committed several fixed and a few enhancements to the Struts Bridge.
If you currently are using the Script Tag, make sure to read the following 
(they are gone):
- Support anchor tag in link and rewrite tags
- Improved and corrected struts-el handling and dropped all BeanInfo classes 
(no longer needed)
- Added PortletURLType.RESOURCE which allows link and rewrite tags to also 
render resource urls
  You can specify attribute resourceURL=true and/or define in
  the struts-portlet-config.xml a resource path=url prefix/ as subelement
  of the PortletUrlType elements (just like the action and render elements).
  A resourceURL will be rendered just like that: a context relative url, instead
  of a PortletURL (the contextPath will be prefixed, just as with images).
  This allows you to reference a javascript source with:
script language=Javascript1.1 src=html:rewrite href=../js/staticJavascript.jsp 
resourceURL=true//
  or by using for example resource path=/js// in struts-portlet-config.xml:
script language=Javascript1.1 src=html:rewrite 
href=../js/staticJavascript.jsp//
  Also (the reason I started out adding this feature):
table background=html:rewrite href=../images/bkg-topbar.gif/
using a resource path=/images// in struts-portlet-config.xml for 
jpetstore
  instead of what I current have:
table background=c:out 
value=${pageContext.request.contextPath}//images/bkg-topbar.gif
  This allowed me to remove the jstl dependency from jpetstore again (I only 
use it for the above)
  as well as REMOVE the ScriptTag and ELScriptTag!!!
- DROPPED all Script Tags as it functionality can now be realized by the 
rewrite tag (see above)
  I never liked it to have to add a non-struts based tag in the struts-portlet 
tld.
  But because providing an additional tld for only those tags seemed a bit too 
much.
  Now, with the new resourceURL support in html:link and html:rewrite I don't 
really
  need the script tags anymore.
Regards, Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jetspeed2 deploy to non /jetspeed context?

[Ate Douma]

It isn't possible right now.
The problem is in the layout portlets which are run under the /jetspeed context 
and which
also expect to be run under the J2 context.
Scott Weaver started refactoring the layout portlets to allow them to run 
independently from
the J2 context (see: http://issues.apache.org/jira/browse/JS2-182).
I also need to be able to run J2 under a different context so I'm also 
interested to know
what the status is right now.
Scott: are you still working on this and can you give some information what is 
still to do?
Maybe I can help out with this.
Regards, Ate
Chris Custine wrote:
I posted this to the dev list with no reply.  Anyone else had luck
with deploying J2 to context other than /jetspeed?
Thanks,
Chris
-- Forwarded message --
From: Chris Custine [EMAIL PROTECTED]
Date: Mon, 17 Jan 2005 19:09:08 -0500
Subject: Deploy to non /jetspeed context?
To: Jetspeed Developers List jetspeed-dev@jakarta.apache.org
I saw some commits a few weeks ago relating to this but a quick
attempt to deploy a Jetspeed2 portal to a context other than /jetspeed
doesn't look to be working.  Is this -supposed- to be working in the
current CVS code?  If there is more work to be done and someone could
give me a nudge in the right direction I would be happy to try to work
on this.
Thanks,
Chris
-
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]

[J2] Major new version of the Struts Bridge: version 0.2 now available

[Ate Douma]

I'm happy to bring the news of a major upgrade of the Struts Bridge.
A short summary of its new features:
- Based on the latest Struts-1.2.4
- Provides new struts-1.2.4-portlet-html.tld and 
struts-1.2.4-portlet-html-el.tld, as
  well as a new struts-portlet-el.tld.
  The first two tld files are full replacements for the struts-html and 
struts-html-el tlds.
  By using these tlds instead of the struts-portlet and struts-portlet-el tlds, 
migrating
  existing Struts applications becomes much easier (just change the taglib 
definition).
  Furthermore, there is now full struts-el support Bridge for all the tags 
(including the
  new onces).
- New Portlet supporting extended Struts tags ImgTag and ImageTag and largely 
extended
  LinkTag and RewriteTag.
  These tags now support relative image src paths and href link
  paths (including ../ elements).
- Provides transparent (non-code based) definition of request attribute values 
to be saved
  during ActionRequest handling which will be restored in the subsequent 
RenderRequest(s).
- Provides transparent (non-code based) definition of url (prefixes) which must 
be
  rendered as Action or Render PortletURL.
  This removes the need to specify the renderURL attribute for link and rewrite 
tags (its
  still supported though, and then will override).
- xml based configuration of above two features loaded at Portlet 
initialization.
  Default configuration file name: WEB-INF/struts-portlet-config.xml, but this 
is
  configurable itself as well.
  Example configuration (from the new JPetstore demo Portlet):
?xml version=1.0 encoding=UTF-8?
config
  render-context
attribute name=errors/
attribute name=message/
  /render-context
  portlet-url-type default=render
action path=/shop/add/
action path=/shop/switch/
action path=/shop/remove/
action path=/shop/signoff/
action path=/shop/viewCategory/
action path=/shop/viewItem/
action path=/shop/viewProduct/
action path=/shop/viewCart/
action path=/shop/newOrder/
render path=/shop/newOrderForm/
action path=/shop/listOrders/
  /portlet-url-type
/config
- IMPORTANT:
  Default PorletURL created by link and rewrite tag changed from ActionURL to 
RenderURL.
  This change is made because in the most cases this turned out to be 
RenderURLs.
  For migrating of existing Struts Bridge based Portlets to the new version 
there is an
  very simple configuration option to revert this to the old style:
  Define a WEB-INF/struts-portlet-config.xml containing (at least):
?xml version=1.0 encoding=UTF-8?
config
  portlet-url-type default=action/
/config
  That'll switch the default back to the old style. For the old Struts 
MailReader Demo Portlet
  also provided with Jetspeed-2, I've put in a configuration file just like 
that.
- New demo portlet application: JPetstore Portlet.
  This very know example web application from iBatis (www.ibatis.com) is now 
also available as
  Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it 
out.
- Deploy as Portlet or as web application!
  The Struts Bridge can now be used in a non-Portlet context, and then will 
simply fall back to
  the basic Struts functionality.
  This allows the deployment of the same Portlet Application war as web 
application and as portlet
  application. You can thus also test the application in a web server only (as 
long as you
  don't use Portlet features specifically).
  Try out the JPetstore Portlet demo and access it as Portlet from within 
Jetspeed-2 or
  directly from the webserver (e.g. http://localhost:8080/jpetstore).
- Abstracted the access to the ServletContextProvider with protected methods in 
StrutsPortlet
  allowing Portal Vendor specific extensions to be used (like VAP).
- Still no real documentation ;-)
  I'm working on it and plan to deliver real usage documentation, as well as a 
tutorial and instructions
  for migrating existing Struts applications, within a week.
Regards, Ate Douma
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [J2] Major new version of the Struts Bridge: version 0.2 now available

[Ate Douma]

Jeff Sheets wrote:
Wow, this is great Ate!  These are many of the features that I was
hoping for!  I will try this out first thing tomorrow morning.  Do you
know if it handles the EditPage better than the last version?  I'm
hoping it fixes a problem that I was having.
Actually, I don't know to which problem you are referring.
I don't think I fixed anything in that area, but if you can give me more
details, I'll be more than happy to so.
Ate
Thanks again!
-- Jeff Sheets
On Thu, 20 Jan 2005 03:49:32 +0100, Ate Douma [EMAIL PROTECTED] wrote:
I'm happy to bring the news of a major upgrade of the Struts Bridge.
A short summary of its new features:
- Based on the latest Struts-1.2.4
- Provides new struts-1.2.4-portlet-html.tld and 
struts-1.2.4-portlet-html-el.tld, as
  well as a new struts-portlet-el.tld.
  The first two tld files are full replacements for the struts-html and 
struts-html-el tlds.
  By using these tlds instead of the struts-portlet and struts-portlet-el tlds, 
migrating
  existing Struts applications becomes much easier (just change the taglib 
definition).
  Furthermore, there is now full struts-el support Bridge for all the tags 
(including the
  new onces).
- New Portlet supporting extended Struts tags ImgTag and ImageTag and largely 
extended
  LinkTag and RewriteTag.
  These tags now support relative image src paths and href link
  paths (including ../ elements).
- Provides transparent (non-code based) definition of request attribute values 
to be saved
  during ActionRequest handling which will be restored in the subsequent 
RenderRequest(s).
- Provides transparent (non-code based) definition of url (prefixes) which must 
be
  rendered as Action or Render PortletURL.
  This removes the need to specify the renderURL attribute for link and rewrite 
tags (its
  still supported though, and then will override).
- xml based configuration of above two features loaded at Portlet 
initialization.
  Default configuration file name: WEB-INF/struts-portlet-config.xml, but this 
is
  configurable itself as well.
  Example configuration (from the new JPetstore demo Portlet):
   ?xml version=1.0 encoding=UTF-8?
   config
 render-context
   attribute name=errors/
   attribute name=message/
 /render-context
 portlet-url-type default=render
   action path=/shop/add/
   action path=/shop/switch/
   action path=/shop/remove/
   action path=/shop/signoff/
   action path=/shop/viewCategory/
   action path=/shop/viewItem/
   action path=/shop/viewProduct/
   action path=/shop/viewCart/
   action path=/shop/newOrder/
   render path=/shop/newOrderForm/
   action path=/shop/listOrders/
 /portlet-url-type
   /config
- IMPORTANT:
  Default PorletURL created by link and rewrite tag changed from ActionURL to 
RenderURL.
  This change is made because in the most cases this turned out to be 
RenderURLs.
  For migrating of existing Struts Bridge based Portlets to the new version 
there is an
  very simple configuration option to revert this to the old style:
  Define a WEB-INF/struts-portlet-config.xml containing (at least):
   ?xml version=1.0 encoding=UTF-8?
   config
 portlet-url-type default=action/
   /config
  That'll switch the default back to the old style. For the old Struts 
MailReader Demo Portlet
  also provided with Jetspeed-2, I've put in a configuration file just like 
that.
- New demo portlet application: JPetstore Portlet.
  This very know example web application from iBatis (www.ibatis.com) is now 
also available as
  Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it 
out.
- Deploy as Portlet or as web application!
  The Struts Bridge can now be used in a non-Portlet context, and then will 
simply fall back to
  the basic Struts functionality.
  This allows the deployment of the same Portlet Application war as web 
application and as portlet
  application. You can thus also test the application in a web server only (as 
long as you
  don't use Portlet features specifically).
  Try out the JPetstore Portlet demo and access it as Portlet from within 
Jetspeed-2 or
  directly from the webserver (e.g. http://localhost:8080/jpetstore).
- Abstracted the access to the ServletContextProvider with protected methods in 
StrutsPortlet
  allowing Portal Vendor specific extensions to be used (like VAP).
- Still no real documentation ;-)
  I'm working on it and plan to deliver real usage documentation, as well as a 
tutorial and instructions
  for migrating existing Struts applications, within a week.
Regards, Ate Douma
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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

Re: [J2] Major new version of the Struts Bridge: version 0.2 now available

[Ate Douma]

Jeff, if this problem still exists in the new Bridge could you create a
JIRA issue for this problem? I'll pick it up then from there.
Ate
Jeff Sheets wrote:
Thanks for the quick reply.
Our problem is with the EditPage when using Fusion.  The problem might
be unique to fusion, but I've been assuming it is due to a bug in the
struts bridge.  The old struts-demo didn't use an EditPage, so maybe
you never saw the issue.
When you have an EditPage, you can get to it from the first screen in
your app from the pencil icon.  After saving from the EditPage and
telling the PortletRequest to return to the View Mode, you are
returned to the correct page.  But now every refresh of the page takes
you to the EditPage instead of the ViewPage.  Also, if you navigate
between pages in the View Mode then the pencil icon no longer takes
you to the ViewPage.
Also, I updated from cvs yesterday and the bug still seems to exist
using Jetspeed1 from HEAD and Jetspeed2 tagged M1.
Good work, and we really like the bridge so far.  We've gotten around
our issue by leaving all portlets in the View Mode at all times, but
I'd really like to use the Edit Mode.
On Thu, 20 Jan 2005 04:40:56 +0100, Ate Douma [EMAIL PROTECTED] wrote:
Jeff Sheets wrote:
Wow, this is great Ate!  These are many of the features that I was
hoping for!  I will try this out first thing tomorrow morning.  Do you
know if it handles the EditPage better than the last version?  I'm
hoping it fixes a problem that I was having.
Actually, I don't know to which problem you are referring.
I don't think I fixed anything in that area, but if you can give me more
details, I'll be more than happy to so.
Ate

Thanks again!
-- Jeff Sheets
On Thu, 20 Jan 2005 03:49:32 +0100, Ate Douma [EMAIL PROTECTED] wrote:

I'm happy to bring the news of a major upgrade of the Struts Bridge.
A short summary of its new features:
- Based on the latest Struts-1.2.4
- Provides new struts-1.2.4-portlet-html.tld and 
struts-1.2.4-portlet-html-el.tld, as
 well as a new struts-portlet-el.tld.
 The first two tld files are full replacements for the struts-html and 
struts-html-el tlds.
 By using these tlds instead of the struts-portlet and struts-portlet-el tlds, 
migrating
 existing Struts applications becomes much easier (just change the taglib 
definition).
 Furthermore, there is now full struts-el support Bridge for all the tags 
(including the
 new onces).
- New Portlet supporting extended Struts tags ImgTag and ImageTag and largely 
extended
 LinkTag and RewriteTag.
 These tags now support relative image src paths and href link
 paths (including ../ elements).
- Provides transparent (non-code based) definition of request attribute values 
to be saved
 during ActionRequest handling which will be restored in the subsequent 
RenderRequest(s).
- Provides transparent (non-code based) definition of url (prefixes) which must 
be
 rendered as Action or Render PortletURL.
 This removes the need to specify the renderURL attribute for link and rewrite 
tags (its
 still supported though, and then will override).
- xml based configuration of above two features loaded at Portlet 
initialization.
 Default configuration file name: WEB-INF/struts-portlet-config.xml, but this is
 configurable itself as well.
 Example configuration (from the new JPetstore demo Portlet):
  ?xml version=1.0 encoding=UTF-8?
  config
render-context
  attribute name=errors/
  attribute name=message/
/render-context
portlet-url-type default=render
  action path=/shop/add/
  action path=/shop/switch/
  action path=/shop/remove/
  action path=/shop/signoff/
  action path=/shop/viewCategory/
  action path=/shop/viewItem/
  action path=/shop/viewProduct/
  action path=/shop/viewCart/
  action path=/shop/newOrder/
  render path=/shop/newOrderForm/
  action path=/shop/listOrders/
/portlet-url-type
  /config
- IMPORTANT:
 Default PorletURL created by link and rewrite tag changed from ActionURL to 
RenderURL.
 This change is made because in the most cases this turned out to be RenderURLs.
 For migrating of existing Struts Bridge based Portlets to the new version 
there is an
 very simple configuration option to revert this to the old style:
 Define a WEB-INF/struts-portlet-config.xml containing (at least):
  ?xml version=1.0 encoding=UTF-8?
  config
portlet-url-type default=action/
  /config
 That'll switch the default back to the old style. For the old Struts 
MailReader Demo Portlet
 also provided with Jetspeed-2, I've put in a configuration file just like that.
- New demo portlet application: JPetstore Portlet.
 This very know example web application from iBatis (www.ibatis.com) is now 
also available as
 Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it 
out.
- Deploy as Portlet or as web application!
 The Struts Bridge can now be used in a non-Portlet

Jetspeed-2 site updated again: New documentation for defining and using User Attributes

[Ate Douma]

I've added a new document describing how User Attributes are to be defined,
how custom attribute mapping is possible in Jetspeed-2, and how to use them.
Checkout: http://portals.apache.org/jetspeed-2/user-attributes.html
NB: I also removed all the old sites on the server.
Regards,
Ate Douma
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

J2 Site updated

[Ate Douma]

I've generated and uploaded a new site for the current jetspeed-2 cvs head 
(2.0-M2-dev).
Checkout the new: http://portals.apache.org/jetspeed-2/
Regards,
Ate Douma
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Announce] Graffito (ex JCMS) has entered Incubator (and some Portals PMC questions)

[Ate Douma]

Sorry, I intended to send this message only to [EMAIL PROTECTED]
Ate Douma wrote:
Congratulations!
Great to see this get into motion!
Raphaël, concerning new Portals sub projects: there was a vote a few 
months ago
about portals-bridges. Do you have any information about its status?
I didn't hear anything about it after the vote, but as I'm not a PMC member
I might have missed discussions on the PMC list.

Concerning Portals PMC membership:
I remember a few weeks ago Nick Lothian from the Pluto team wanted to 
become
PMC member, but then you advised to wait till early January. I also 
would like to
request to become a PMC member. Should I send a formal mail to 
[EMAIL PROTECTED] or
is this informal request enough?

Regards, Ate Douma
Raphaël Luta wrote:
On behalf of the Graffito team and the Apache Portals PMC, I'm please 
to announce
that Graffito, formerly known as JCMS, has completed its transition to 
the
Apache Incubator.

The main objective of Graffito is to create a portal oriented content 
management
system. It's currently build on top of Apache Slide and the team also 
plans to
support access to JCR content repositories through Jackrabbit.
Graffito user interface is managed with a set of JSR-168 portlets that 
can be
deployed in compatible portal systems such as Apache Jetspeed.

If you are interested to learn more on Graffito, please consult the 
project
website at:

http://incubator.apache.org/graffito/
To join the user and developper community, please subscribe to
[EMAIL PROTECTED] by sending a mail to
[EMAIL PROTECTED]
To checkout the current codebase, you can download it through
our Subversion repository:
https://svn.apache.org/repos/asf/incubator/graffito/trunk/

-
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: Jetspeed2 M1 security setup

[Ate Douma]

Randy Watler wrote:
Doug,
Portlet level security constraints are apparently the responsibility of 
the portlet writer to implement, so the portal and portlet container 
will always display the portlet. We just received clarification on this 
from the pluto mail list:

http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261msgNo=2160
One small correction: only the portlet container should not
enforce security constraints according to the portlet specification.
The portal can, as Randy showed in the example below.
Another solution would be to use security constraints on a page, restricting
(certain type of) access to only certain users, roles or groups.
Furthermore, this should not only be possible on page level but even on
(psml) fragment level, but that isn't yet implemented I think (Randy?).
If (when) it is, you can simply restrict certain parts of a page to certain
users, groups and/or roles.

So, one way to achieve what you are after is to use the profiler. When 
the user is not logged in, they are known as 'guest'. By default, users 
are profiled using the 'j1' rule. This all boils down to the fact that 
unauthenticated users can be directed to pages placed in the 
.../WEB-INF/pages/_user/guest directory. Place your stripped down 
version of your pages in this 'guest' directory, (without your role 
security), and then secure all the rest of the pages in your site by role.

HTH,
Randy
Doug Schnelzer wrote:
I've been working through this thread.  It's very helpful.  Thanks to 
Marina
and Randy for providing some good documentation here.  As I have worked
through this, I have a follow up question...

Is there a way in a psml file or in one of the deployment descriptors to
require a role before displaying some of the portlets on a page?  I 
want
to modify the default page so that only the login portlet is visible 
until a
user logs in.  If I make the entire page require a role, then I can't 
log in
to establish my identity.

Thanks, Doug
-Original Message-
From: Marina [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 
4:35 PM
To: Jetspeed Users List
Subject: RE: Jetspeed2 M1 security setup

Randy, thanks a lot for your help! I was able to setup
a basic access control to my portlet's view and Edit
mode.
I do have more questions on the user management in J2,
though :)
I've created a new user, dce-admin,  using the
Administrative Portlets as 'admin' user. This worked
fine, and I was able to detect this user through the
PortletResponse.getUserPrincipal().
I've also tried to create a new role, say
dce-admin-role, and assign this role to the new user.
This , unfortunately, did not work. I entered the new
role name into the corresponding form (Add Role) of
the Role Management tab, but it was never added to
the list of the available roles and when I tried to
assign this role to the new user I've got an error
from J2 complaining that this role does not exist:
*** New Full Path: /role/dce-admin-role
failed to add user to role: dce-admin,
dce-admin-roleorg.apache.jetspeed.security.SecurityException:
The role does not exist. dce-admin-role
*** New Full Path: /role/dce-admin-role
Any idea why this is not working?
Thanks,
Marina

--- Randy Watler [EMAIL PROTECTED] wrote:
 

Marina,
Thanks for using the jetspeed user list!
Comments below.
Randy
  

-Original Message-
From: Marina
To: 'Jetspeed Users List '
Sent: 12/6/04 5:06 PM
Subject: RE: Jetspeed2 M1 security setup (was:

jetspeed-newbie
Roles-Groups-Users)
  

Hi,
I've successfully built and installed J2 M1 and

was
  

looking into the demo applications to figure out

how
  

to setup access control for portlets/pages.
After checking out some example portlets , like
RoleSecurityTest and Login, and their source code,

I
  

think I have some idea of how to approach the task

but
  

I would like to clarify some topics.
First, I'll list my assumptions and then ask
questions:
1.

tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security
  

file specifies 'Edit'/'View' permissions for the
default Portal's page, defined in default-page.psml

The /page.security file defines named security
constraints that can be
referenced here or in individual page, folder meta
data, link, or document
set documents. The scope of this file is global
across the entire site.
References take the form of
global-security-constraints-ref/, (which
appear only in /page.security), or
security-constraints-ref/.
  

Thus, this part :
security-constraints-def name=admin
  security-constraint
rolesadmin/roles
permissionsview, edit/permissions
  /security-constraint
/security-constraints-def
means that only a user with the role 'admin' can

edit
  

the layout of the page.

Yes, since this fragment is referenced in a
global-security-constraints-ref/, it applies to
all documents in the site.
  

And this fragment:
security-constraints-def name=manager
  security-constraint
rolesmanager/roles

Re: PortletRequest using struts portals bridge

[Ate Douma]

See Portlet Specification Chapter 16: Dispatching Requests to Servlets and JSP
PLT.16.3.2 Included Request A ttributes
In addition to the request attributes specified in Servlet Specification 2.3, 
SRV.8.3.1
Section, the included servlet or JSP must have the following request attributes 
set:
  Request Attribute   Type
  javax.portlet.configjavax.portlet.PortletConfig
  javax.portlet.request   javax.portlet.RenderRequest
  javax.portlet.response  javax.portlet.RenderResponse
Example:
 RenderRequest renderRequest = 
(RenderRequest)servletRequest.getAttribute(javax.portlet.request);
Jeff Sheets wrote:
Does anyone know how to get the PortletRequest from inside the struts
execute() method when using the struts portals bridge?  I need to
access the PortletPreferences.  I tried casting the HttpServletRequest
to a PortletRequest but that didn't work.  Is it stored in the session
or elsewhere?
Thank you,
-- Jeff
-
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: struts bridge submits twice

[Ate Douma]

This has been solved by Jeff himself, he mailed me directly.
The solution is to define the PortletRequestProcessor as controller in the 
struts-config file:
  controller pagePattern=$M$P
  inputForward=true
  
processorClass=org.apache.portals.bridges.struts.PortletRequestProcessor/
Without this, the Struts framework uses its own PortletRequestProcessor under 
certain
conditions (not always) with as result that the StrutsPorlet isn't informed 
about the end
state of the actionRequest. Then, it will use the original Struts page URL for 
the renderRequest
again, leading to the double processing of the action.
I'm currently working on some improvements and enhancements for the Struts 
Bridge which
I hope to commit in a few days or a week or so. I will then also provide proper 
usage documentation,
including a checklist and instructions to enable existing Struts applications 
as portlets.
Regards, Ate
Jeff Sheets wrote:
Here are the debug statements showing the progression through the
struts bridge.  Sorry to reply to my own message, but I wanted to
relay this extra information.  It looks like the action is processed
once for requestType ACTION and another time for requestType VIEW, but
the action should really only be processed once.
-- Jeff
DEBUG org.apache.portals.bridges.struts.StrutsPortlet.processRequest(StrutsPortl
et.java:263) org.apache.portals.bridges.struts.StrutsPortlet : process
path: /myService.do, query string: null, requestType: ACTION
Start MyServiceAction
End MyServiceAction
DEBUG org.apache.portals.bridges.struts.PortletServletRequestDispatcher.invoke(P
ortletServletRequestDispatcher.java:62) org.apache.portals.bridges.struts.Portle
tServletRequestDispatcher : saving  dispatch to :/myViewer.jsp, from
ACTION /myService.do
DEBUG org.apache.portals.bridges.struts.StrutsPortlet.processRequest(StrutsPortl
et.java:321) org.apache.portals.bridges.struts.StrutsPortlet : action render pag
e: /myService.do
WARN  org.apache.jetspeed.engine.AbstractEngine.getContainerService(AbstractEngi
ne.java:382) org.apache.jetspeed.engine.AbstractEngine : No ContainerService def
ined for org.apache.pluto.services.title.DynamicTitleService
DEBUG org.apache.portals.bridges.struts.StrutsPortlet.processRequest(StrutsPortl
et.java:263) org.apache.portals.bridges.struts.StrutsPortlet : process
path: /myService.do, query string: null, requestType: VIEW
Start MyServiceAction
java.lang.Exception: Error: 
   [stack trace cutout, but occurs since MyServiceAction entered twice
on same request]
DEBUG org.apache.portals.bridges.struts.PortletServletRequestDispatcher.invoke(P
ortletServletRequestDispatcher.java:108) org.apache.portals.bridges.struts.Portl
etServletRequestDispatcher : invoking   dispatch to :/errorPage.jsp, from VIEW /
myService.do


On Tue, 14 Dec 2004 09:02:01 -0600, Jeff Sheets [EMAIL PROTECTED] wrote:
We are having an issue with the struts portals bridge, where a submit
is trying to go through the action class twice.  As soon as the action
is completed and the forward happens, the action is invoked again.
Has anyone else seen this?  Does anyone have any tips?
Thanks,
-- Jeff

-
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: Session information for a Struts portlet in JS1.6

[Ate Douma]

Hema Menon wrote:
Hi,
How can a struts application deployed as a JSR 168 portlet in Jetspeed
1.6 with fusion get the user information and other session variables
in Jetspeed's context? In other words we have some jetspeed 1.5 which
are running under jetspeed 1.6 with fusion. We converted an existing
struts application to be deployed as a portlet in Jetspeed. We have
authentication done thru sybase and when the user logs in user
information and some other relevant information are added to the
session. These variables are available to all the portlets in
jetspeed. However when a struts portlet is added to jetspeed, the
context seems to be different even though it resides in the jetspeed
portal. The question is
1. Is it possible for the struts application to access the session
variables that are added on login?
Yes :-)
2. If it is how can it be done?
There are several factors at play here.
First of all, cross-context restrictions. In contrast to other (non-JSR168)
portlets, Jetspeed-2 (fusion) deploys its portlet applications as separate
web applications and accesses them using the cross-context feature of Tomcat.
According to the servlet specs, each web application *must* have its own
session, so formally, access to cross-context session is not supported.
But, there are two solutions to this problem I know of (if you find more I'd
would like to know about it).
1) Use Tomcat 4
Tomcat 4 has the annoying bug in that it does *not* create separate sessions
for cross-context access. Normally, this is quite a security breach and one of
the reasons why I'm never going to use Tomcat 4 again.
But, it might be helpful in your situation. Then, you should have direct access
to your login variables.
2) Make use of (J2) org.apache.jetspeed.Jetspeed.getCurrentRequestContext().
That returns a RequestContext instance which gives you access to the session of 
the
portal (getSessionAttribute() and setSessionAttribute()).
Note: while the RequestContext is defined in the public (J2) jetspeed-api 
package,
the Jetspeed class is *not*. So, you will have to build against the J2 portal.
Furthermore, this is not (yet) a formal supported feature of Jetspeed-2: we (the
team) might conclude that this is too much of a security breach and close that
backdoor in the future. But, in that case I expect us to at least leave 
read-only
access in place as we rely on it ourselves for the J2 management portlets.
Good luck, Ate
Any inputs very much appreciated.
Thanks,
Hema

~~
Hema Menon
-
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: Session information for a Struts portlet in JS1.6

[Ate Douma]

Jeff Sheets wrote:
I just want to clarify one point of your post.
You're saying that all of the portlets in one war file, thus a part of
the same application, share the same session.  But it's not true that
each portlet has it's own session, just each portlet application
[war], right?
Correct.
At least that's how I understood it, but I just wanted to get some
clarification from the experts :-)
-- Jeff Sheets
On Sat, 11 Dec 2004 10:13:17 +0100, Ate Douma [EMAIL PROTECTED] wrote:

Hema Menon wrote:
Hi,
How can a struts application deployed as a JSR 168 portlet in Jetspeed
1.6 with fusion get the user information and other session variables
in Jetspeed's context? In other words we have some jetspeed 1.5 which
are running under jetspeed 1.6 with fusion. We converted an existing
struts application to be deployed as a portlet in Jetspeed. We have
authentication done thru sybase and when the user logs in user
information and some other relevant information are added to the
session. These variables are available to all the portlets in
jetspeed. However when a struts portlet is added to jetspeed, the
context seems to be different even though it resides in the jetspeed
portal. The question is
1. Is it possible for the struts application to access the session
variables that are added on login?
Yes :-)

2. If it is how can it be done?
There are several factors at play here.
First of all, cross-context restrictions. In contrast to other (non-JSR168)
portlets, Jetspeed-2 (fusion) deploys its portlet applications as separate
web applications and accesses them using the cross-context feature of Tomcat.
According to the servlet specs, each web application *must* have its own
session, so formally, access to cross-context session is not supported.
But, there are two solutions to this problem I know of (if you find more I'd
would like to know about it).
1) Use Tomcat 4
Tomcat 4 has the annoying bug in that it does *not* create separate sessions
for cross-context access. Normally, this is quite a security breach and one of
the reasons why I'm never going to use Tomcat 4 again.
But, it might be helpful in your situation. Then, you should have direct access
to your login variables.
2) Make use of (J2) org.apache.jetspeed.Jetspeed.getCurrentRequestContext().
That returns a RequestContext instance which gives you access to the session of 
the
portal (getSessionAttribute() and setSessionAttribute()).
Note: while the RequestContext is defined in the public (J2) jetspeed-api 
package,
the Jetspeed class is *not*. So, you will have to build against the J2 portal.
Furthermore, this is not (yet) a formal supported feature of Jetspeed-2: we (the
team) might conclude that this is too much of a security breach and close that
backdoor in the future. But, in that case I expect us to at least leave 
read-only
access in place as we rely on it ourselves for the J2 management portlets.
Good luck, Ate


Any inputs very much appreciated.
Thanks,
Hema

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


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


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



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

Re: login form problem

[Ate Douma]

Thanks for the report Graeme.
I applied your fix.
I never experienced that problem using Firefox or Internet Explorer.
Regards,
Ate
Graeme Elsworthy wrote:
Hi all,
I have a problem with Jetspeed 2's login form.  The out-of-the-box
jetspeed 2 I've been downloading from the cvs, and the latest
M1 release all show the same problem.
Problem is, from Mozilla when I enter a username/password and
hit the Login button I get a page send back that shows
the text of an html form, and not an html page containing a form.
I tried IE and this problem does not happen, the login proceeds
as expected.
I fixed this by adding the line
response.setContentType(text/html);
into portal/src/java/org/apache/jetspeed/login/LoginServlet.java
Am using tomcat 4.1.27 and Mozilla 1.7.3 on Linux.  Is this a
problem with my tomcat install (like incorrect/outdated jar files
or something), or is everybody using IE on Windows, or something else?
Cheers,
Graeme.
-
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]

What's Happening with Jetspeed-2? A great interview on java.net

[Ate Douma]

An interview given by David Sean Taylor on the new Jetspeed-2 to come!
Check it out: http://today.java.net/cs/user/print/a/151
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fusion Struts Demo

[Ate Douma]

Jeff,
Thanks for providing this information.
I will look into this tonight but I expect your changes can be
incorporated without harm or side-effect.
I created the EmptyHttpServletResponseImpl as the lightest implementation
to nullify any usage of the HttpServletResponse.
Using a wrapper instead allows one to access the original response which is
exactly what I wanted to prevent, but anyone doing so should be careful anyway.
You also wrote in a previous message you encountered a problem with missing
taglib classes. Could you tell me which these were, and when they are accessed?
I'm puzzled because I created this portlet version of the mail-reader demo and
didn't have this problem yet.
Ate Douma
Jeff Sheets wrote:
I think I have a better fix now, and I would be happy to submit a
patch if someone shows me how.
I changed the EmptyHttpServletResponseImpl into a
EmptyHttpServletResponseWrapper.  Then I modified this line in
StrutsPortlet, line 269:
if (actionRequest) {
res = new EmptyHttpServletResponseImpl();
}
to this:
if (actionRequest) {
res = new EmptyHttpServletResponseWrapper(res);
}
Weblogic seems to be okay with it, and now I feel much better about
the code itself.
-- Jeff
-
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: Fusion Struts Demo

[Ate Douma]

Jeff Sheets wrote:
Ate,
Actually, now that I look at it, it was only missing the
src\java\org\apache\struts\webapp\example\CheckLogonTag.java file.  I
believe I saw the compile error when trying to access the logon
screen, or possibly the register screen.
I scanned the source tree and you are right: it is still referenced
from the app.tld although I stripped it usage from the sources.
It seems Weblogic actually scans the tld and requires each referenced
tag implementation class to be present. Tomcat/Jasper doesn't have this
'requirement' :-)
I'll remove the reference from the app.tld too this evening.
Thanks for the report!
Could you tell me if the ServletContextProvider spi interface implementation
was easy for Weblogic?
I have a report from another dev team using the Struts-Bridge on Vignette
Application Portal (successfully) who needed to change the interface to be able
to realize the implementation.
(Guys, if you are reading this: I haven't found the time yet to see if I
can incorporate your requirements but I have that still on my todo list.)
Maybe if could be interesting to create a repository of spi implementations
for different portals providing a quick start for new users.
Would you be allowed and willing to submit your implementation under ASF 
license?
Regards, Ate
Also, I suspect Weblogic might be accessing the original response
anyway, although this should be a bug in their code.
And I must say, great working in writing the struts bridge!  This will
save us many hours when we portletize our apps!
Thanks!
-- Jeff
On Wed, 17 Nov 2004 22:14:15 +0100, Ate Douma [EMAIL PROTECTED] wrote:
Jeff,
Thanks for providing this information.
I will look into this tonight but I expect your changes can be
incorporated without harm or side-effect.
I created the EmptyHttpServletResponseImpl as the lightest implementation
to nullify any usage of the HttpServletResponse.
Using a wrapper instead allows one to access the original response which is
exactly what I wanted to prevent, but anyone doing so should be careful anyway.
You also wrote in a previous message you encountered a problem with missing
taglib classes. Could you tell me which these were, and when they are accessed?
I'm puzzled because I created this portlet version of the mail-reader demo and
didn't have this problem yet.
Ate Douma

Jeff Sheets wrote:
I think I have a better fix now, and I would be happy to submit a
patch if someone shows me how.
I changed the EmptyHttpServletResponseImpl into a
EmptyHttpServletResponseWrapper.  Then I modified this line in
StrutsPortlet, line 269:
   if (actionRequest) {
   res = new EmptyHttpServletResponseImpl();
   }
to this:
   if (actionRequest) {
   res = new EmptyHttpServletResponseWrapper(res);
   }
Weblogic seems to be okay with it, and now I feel much better about
the code itself.
-- Jeff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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


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



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

Re: Fusion Struts Demo

[Ate Douma]

Jeff Sheets wrote:
Sorry for a second post, but I think I know where you are going with
this now.  I deployed the struts-demo in Jetspeed on Weblogic Server. 
I didn't try to deploy the struts-demo in Weblogic Portal.  That
hopefully answers your question...
Your previous message hasn't reached me yet (?), so no worries about second 
posts :-)
Thanks for the answer.
Ate

On Wed, 17 Nov 2004 17:48:24 -0600, Jeff Sheets [EMAIL PROTECTED] wrote:
I never even looked at the ServletContextProvider spi interface.
Deploying to Weblogic was nearly as easy as deploying to Tomcat or
JBoss.  I only needed to modify the two things that I mentioned
earlier...

On Wed, 17 Nov 2004 22:58:15 +0100, Ate Douma [EMAIL PROTECTED] wrote:
Jeff Sheets wrote:

Ate,
Actually, now that I look at it, it was only missing the
src\java\org\apache\struts\webapp\example\CheckLogonTag.java file.  I
believe I saw the compile error when trying to access the logon
screen, or possibly the register screen.
I scanned the source tree and you are right: it is still referenced
from the app.tld although I stripped it usage from the sources.
It seems Weblogic actually scans the tld and requires each referenced
tag implementation class to be present. Tomcat/Jasper doesn't have this
'requirement' :-)
I'll remove the reference from the app.tld too this evening.
Thanks for the report!
Could you tell me if the ServletContextProvider spi interface implementation
was easy for Weblogic?
I have a report from another dev team using the Struts-Bridge on Vignette
Application Portal (successfully) who needed to change the interface to be able
to realize the implementation.
(Guys, if you are reading this: I haven't found the time yet to see if I
can incorporate your requirements but I have that still on my todo list.)
Maybe if could be interesting to create a repository of spi implementations
for different portals providing a quick start for new users.
Would you be allowed and willing to submit your implementation under ASF 
license?
Regards, Ate


Also, I suspect Weblogic might be accessing the original response
anyway, although this should be a bug in their code.
And I must say, great working in writing the struts bridge!  This will
save us many hours when we portletize our apps!
Thanks!
-- Jeff
On Wed, 17 Nov 2004 22:14:15 +0100, Ate Douma [EMAIL PROTECTED] wrote:

Jeff,
Thanks for providing this information.
I will look into this tonight but I expect your changes can be
incorporated without harm or side-effect.
I created the EmptyHttpServletResponseImpl as the lightest implementation
to nullify any usage of the HttpServletResponse.
Using a wrapper instead allows one to access the original response which is
exactly what I wanted to prevent, but anyone doing so should be careful anyway.
You also wrote in a previous message you encountered a problem with missing
taglib classes. Could you tell me which these were, and when they are accessed?
I'm puzzled because I created this portlet version of the mail-reader demo and
didn't have this problem yet.
Ate Douma

Jeff Sheets wrote:

I think I have a better fix now, and I would be happy to submit a
patch if someone shows me how.
I changed the EmptyHttpServletResponseImpl into a
EmptyHttpServletResponseWrapper.  Then I modified this line in
StrutsPortlet, line 269:
  if (actionRequest) {
  res = new EmptyHttpServletResponseImpl();
  }
to this:
  if (actionRequest) {
  res = new EmptyHttpServletResponseWrapper(res);
  }
Weblogic seems to be okay with it, and now I feel much better about
the code itself.
-- Jeff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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


-

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


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


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



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

[J2] Security component updated again: table structure changes required!!!

[Ate Douma]

Hi All,
I've implemented and checked in a major part of the JS2-151 
(http://issues.apache.org/jira/browse/JS2-151) feature list.
1) storing password encoded
2) requiring a minimum length and a minimum number of numeric characters in a 
password
4) automatically expire password after a configurable time
6) locking a user out when the current password is expired
8) disable a password after a certain number of failures to authenticate, reset 
check after success
The other items below I will hopefully finish soon. Part of it, data and object 
model and some behavior is already in place though.
3) keeping a history (queue) of previously used password and preventing a user 
to reuse one from this queue (with a configurable queue size)
5) warning a user its password is going to be expired (with a configurable time 
before)
7) forcing a user to change a password on first use
9) enable/disable principals: users,groups,roles
As result of the above changes, a two security tables have additional columns:
Table SECURITY_CREDENTIAL:
- column UPDATE_REQUIRED, BIT, NOT NULL
- column IS_ENCODED, BIT, NOT NULL
- column IS_ENABLED, BIT, NOT NULL
- column AUTH_FAILURES, SMALLINT, NOT NULL
- column IS_EXPIRED, BIT, NOT NULL
- column LAST_LOGON_DATE, TIMESTAMP, NULL
- column EXPIRATION_DATE, DATE, NULL
Table SECURITY_PRINCIPAL:
- column IS_ENABLED, BIT, NOT NULL
As default configuration (just temporary, just to let you guys test this) I've 
defined the following:
- 1) a SHA-1 encoder for the passwords: MessageDigestCredentialPasswordEncoder
- 2) no requirements for password length or number of digits, but
 I've supplied a SimpleCredentialPasswordValidator which can do so.
 See: TestPasswordCredentialProvider and its security context definition 
spcpv.xml
- 4) a maxLifeSpanInDays of 60 for password (expiration) and,
  6) a maxNumberOfAuthenticationFailures of 3, and
  8) disable a password after a certain number of failures to authenticate, 
reset check after success
 with: InternalPasswordCredentialStateHandlingInterceptor
Because this configuration will encode passwords, getting the correct values 
into the database from
outside Jetspeed might seem a bit of a problem, but it isn't!
When inserting data in the SECURITY_CREDENTIAL table itself, use the plain text 
value for the VALUE column and
for IS_ENCODED 0 (zero, false). As soon as a credential is loaded by Jetspeed 
it will be encoded.
Same goes for EXPIRATION_DATE: if you leave that null, Jetspeed will fill it in 
on first access.
I've also added a Password tab to the User Details Portlet through which an 
administrator can set new password,
enabled/disable a password and toggle the update password required flag (item 7 
from the list above).
Be warned now: try a wrong password three times in a row and your locked out. 
Lucky, the User Browser Portlet
isn't secured yet, so fixing it (setting the user password enabled again) is 
still easy.
(guys, we have to think about a build in/predefined admin role or permissions 
to secure this thing)
Regards, Ate

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

[J2] Security component updated: existing SECURITY_CREDENTIAL table data changes required!!!

[Ate Douma]

Hi all,
To be able to implement the enhanced password security (see: 
http://issues.apache.org/jira/browse/JS2-151)
I had to make a few changed to the security component interfaces and quite a lot in 
its implementation.
Tonight changes only lay the foundation for JS2-151 which implementation I will start 
with now.
The current functionality of J2 isn't changed so far, but the security credential data 
as stored in
the database is changed.
I've changed the PasswordCredential class to an interface (to allow more flexibility) and added 
o.a.j.security.spi.impl.DefaultPasswordCredentialImpl as replacement for the old PasswordCredential.

The CLASSNAME field of the SECURITY_CREDENTIAL table contains the class name of the 
PasswordCredential class
used by the CredentialHandler and thus is changed from 
o.a.j.security.PasswordCredential to the above mentioned.
The maven db.recreate goal (called from the quickStart goal) will automatically insert 
the corrected demo data,
but for those creating users themselves (including their password) through SQL will 
have to adapt their scripts
used for that and update their current data in the database as well.
Forgetting to do so will result in users not being able anymore to login and a 
LoginException with message
Authentication failed: Password does not match will be thrown from the 
DefaultLoginModule which is displayed on
the Tomcat console.
The upcoming changes I'll have to make for the implementation of JS2-151 will require 
further changes to the
SECURITY_CREDENTIAL table (additional fields). When that happens I'll put out another 
warning to the list.
Regards,
Ate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JS2/Fusion cvs problem

[Ate Douma]

dan myers wrote:
David -
I guess I misspoke.  Yes, the fusion sources are in JS1.  That
is simply the site at which build failures are occurring.  My apologies
for not being more specific.
There appear to be unresolvable class references when the JS1
attribute enabling fusion 
org.apache.jetspeed.fusion=true
is set in project.properties, even though I had built JS2 according
to the directions.  The missing classes seem to be from
org.apache.jetspeed.container.session (which I believe _is_ supposed
to be delivered by the JS2 build):

[javac] 
C:\Apache\jetspeed-1.6\jakarta-jetspeed\fusion\src\java\org\apache\jetspeed\fusion\modules\actions\FusionAccessController.java:27:
 package org.apache.jetspeed.container.session does not exist
[javac] import org.apache.jetspeed.container.session.NavigationalStateComponent;
[javac]  ^
[javac] 
C:\Apache\jetspeed-1.6\jakarta-jetspeed\fusion\src\java\org\apache\jetspeed\fusion\portal\controls\FusionPortletControl.java:30:
 package org.apache.jetspeed.container.session does not exist
[javac] import org.apache.jetspeed.container.session.NavigationalState;
[javac]  ^
Is this a symptom of fusion being broken right now? If so, is there a
mechanism for getting the last working version of sources to work
with, or must I simply wait for things to get fixed?
The J2 cvs version with tag: pre_portalurl_refactor_20041015 is your last working 
version.
Tnx,
Dan
-- Original message -- 


dan myers wrote: 


Hello - 
And now, for my next problem... 
I have been attempting to build JS2/Fusion and then JS1.6 using the results of 
that build. 


However, it appears that the fusion sources are not being placed in the JS2 
source tree during checkout. 

The Fusion sources are in the J1 tree 


I have tried both the documented maven checkout scheme and cvsgrab, both with 
the same results. 

I believe I'm getting HEAD sources (I'm specifying no other tags), though it 
appears that the fusion sources may be on a branch usin 

g fusion*rc2 or fusion*prerelease*. Any clues as to what I may be missing 
here? Any help is appreciated. 

Cheers, 
Dan 
Fusion is currently broken in the CVS head. 
We hope to have it fixed over the next few days 

If you are going to use one of the tags above, make sure to check out 
both J1 and J2 with that tag 

- 
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]

[J2] Tomcat 5 JAASRealm patch no longer needed, version 5.0.28 or higher now required

[Ate Douma]

All,
I just checked in additional configuration of J2 when using Tomcat 5 which 
removes the need for the JAASRealm patch.
This new configuration option is available since Tomcat 5.0.28 and therefore 
this version is now the required minimum when using Tomcat 5.

Please upgrade your Tomcat 5 version before using the latest cvs version, if you 
haven't done so already.

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

Re: ojb related exception leads to blank page on jetspeed2 install

[Ate Douma]

Did you set the (new required) maven property org.apache.jetspeed.project.home?
See: http://portals.apache.org/jetspeed-2/getting-started.html.
I encountered the same problem yesterday while I *have* this property set but 
because I've currently 4 different J2 projects on my machine, it was pointing to 
the wrong one (a somewhat older version).
Could be that not having this property defined leads to the same error (didn't 
check that one out though).

Regards,
Ate
Dan Moore wrote:
Hi folks.
I'm trying to install jetspeed2.  I've downloaded the latest version
from CVS today.
I'm having an issue when I visit http://localhost:8080/jetspeed: the
dreaded 'blank page'.
My setup:
Tomcat 5.0.28
Java 1.4.2_03
using default hsqldb setup
Windows XPSP2 w/cygwin
I've run the allClean allBuild targets twice, and they succeed.  I use
'maven quickStart' to deploy (along with 'maven
start.production.server' for the hsqldb).  I also checked out
http://wiki.apache.org/portals/Jetspeed2/OkayItBuildsWhyTheHeckWontItRun
removed all pluto references, and removed all the jar files from the
shared/lib directory.
On searching the maillist archives, I see there are folks getting the
'Failed to initialize prefs api' error message, but no one seems to be
getting the 'org.apache.jetspeed.prefs.om.impl.NodeImpl not found in
OJB Repository' error message.  I looked in my jre/lib/ext directory,
and I don't have OJB in there.  I do have a version of OJB installed,
but it's in an entirely different Tomcat tree (4.1.30).
Would love to hear any suggestions.
Thanks,
Dan
PS Here's the full text of the error logs:

2004-09-30 16:53:37,064 [main] FATAL
org.apache.jetspeed.engine.JetspeedServlet - Jetspeed: init() failed: 
org.apache.jetspeed.exception.JetspeedException: Unable to create
Engine
	at org.apache.jetspeed.Jetspeed.createEngine(Jetspeed.java:76)
	at
org.apache.jetspeed.engine.JetspeedServlet.init(JetspeedServlet.java:137)
	at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1029)
	at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:862)
	at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4013)
	at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4357)
	at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
	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:903)
	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:216)
	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.catalina.util.CatalinaDigester.endElement(CatalinaDigester.java:76)
	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
	at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(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.DTDConfiguration.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:488)
	at
org.apache.catalina.core.StandardHost.install(StandardHost.java:863)
	at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:483)
	at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
	at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
	at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
	at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
	at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
	at
org.apache.catalina.core.StandardService.start(StandardService.java:480)
	at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
	at 

Re: library struts-1.2.1.jar missing

[Ate Douma]

Shen, Ching wrote:
Hi,
Am I the only person has problem to build jetspeed 2?
When I am trying to build, I get following errors:
Attempting to download struts-1.2.1.jar.
WARNING: Failed to download struts-1.2.1.jar.
 
BUILD FAILED
File.. /root/jakarta-jetspeed-2/maven.xml
Element... maven:reactor
Line.. 151
Column 40
The build cannot continue because of the following unsatisfied dependency:
 
struts-1.2.1.jar

I checked ibiblio site, and the library is not there!  Where can  get this version of status? 
I would appreciate any guideline
Its in http://cvs.apache.org/repository/
Make sure your own build.properties (in your user home) doesn't override the 
maven.repo.remote property as specified in the project.properties in the J2 
source tree.

Thank you!
Ching Shen

-
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]

Pointers for asking problem related questions on the list [Was: j2: http://localhost:8080/jetspeed yields blank page]

[Ate Douma]

tony kerz wrote:
just built js2 according to direx and
http://localhost:8080/jetspeed is yielding a blank
page
is this the expected result or is there something
wrong with my setup?
i noticed some discussion of jaas issue, but it seems
like the patch is present in the tomcat directory...
any guidance appreciated, thanks, tony.
No, a blank page is not the expected result  :-)
Without any more information though we won't be able to help you.
A few pointers I can give you:
When asking about unexpected behavior it can be helpful in some cases to specify 
your general setup (Tomcat version, os, db, jdk etc.)

Make sure to try out a *clean* setup, meaning (for J2) using only a default 
installed Tomcat (no other apps deployed), do a maven allClean before building 
J2, try it out using the default hsqldb database, etc.

First thing to look into is the general server logfile:
  for Tomcat those can (by default) be found in $CATALINA_HOME/logs
Next comes the J2 logfiles, especially the jetspeed.log:
  those are found under webapps/jetspeed/WEB-INF/logs
If you find error messages, stacktraces etc. those usually give an indication 
whats wrong (no/invalid db connection, port in use, syntax errors in jsp files etc.)

Then, if you still can't figure it out, check out the user or dev list and the 
wiki. Maybe someone else already had the same problem.

If you can't find anything about your particular problem, not enough to solve it 
yourself, or just don't understand what it is all about, then feel free to post 
a question on the list. We will be glad to help you out in that case.

Note:
i'm new to apache community, and just coming up to
speed with  interactive facilities, so i also posted
this to wiki, but then thought that this type of
dialog may not be appropriate for wiki. any etiquette
pointers welcome.
In general: don't post questions on the wiki. Although there isn't a policy or 
kind, my personal opinion is that the wiki is best suited to be used as a 
knowledge base. Which can mean your problem *might* end up there, together with 
a solution (or if its really bad: as a know problem).
If you have additional information which might help others though, please feel 
free to post it on the wiki, or on the list if you prefer.

Regards,
Ate
-
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]

Pointers for asking problem related questions on the list [Was: j2: http://localhost:8080/jetspeed yields blank page]

[Ate Douma]

tony kerz wrote:
just built js2 according to direx and
http://localhost:8080/jetspeed is yielding a blank
page
is this the expected result or is there something
wrong with my setup?
i noticed some discussion of jaas issue, but it seems
like the patch is present in the tomcat directory...
any guidance appreciated, thanks, tony.
No, a blank page is not the expected result :-)
Without any more information though we won't be able to help you.
A few pointers I can give you:
When asking about unexpected behavior it can be helpful in some cases to specify 
your general setup (Tomcat version, os, db, jdk etc.)

Make sure to try out a *clean* setup, meaning (for J2) using only a default 
installed Tomcat (no other apps deployed), do a maven allClean before building 
J2, try it out using the default hsqldb database, etc.

First thing to look into is the general server logfile:
  for Tomcat those can (by default) be found in $CATALINA_HOME/logs
Next comes the J2 logfiles, especially the jetspeed.log:
  those are found under webapps/jetspeed/WEB-INF/logs
If you find error messages, stacktraces etc. those usually give an indication 
whats wrong (no/invalid db connection, port in use, syntax errors in jsp files 
etc.)

Then, if you still can't figure it out, check out the user or dev list and the 
wiki. Maybe someone else already had the same problem.

If you can't find anything about your particular problem, not enough to solve it 
yourself, or just don't understand what it is all about, then feel free to post 
a question on the list. We will be glad to help you out in that case.

Note:
i'm new to apache community, and just coming up to
speed with  interactive facilities, so i also posted
this to wiki, but then thought that this type of
dialog may not be appropriate for wiki. any etiquette
pointers welcome.
In general: don't post questions on the wiki. Although there isn't a policy or 
kind, my personal opinion is that the wiki is best suited to be used as a 
knowledge base. Which can mean your problem *might* end up there, together with 
a solution (or if its really bad: as a know problem).
If you have additional information which might help others though, please feel 
free to post it on the wiki, or on the list if you prefer.

Regards,
Ate
-
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: Jetspeed 2 build failed

[Ate Douma]

Waqar Sadiq wrote:
 

I have downloaded jetspeed-2 source and am trying to build it.  However the
build fails because it cannot load the jdbc drivers.  The error is
ClassNotFound error that fails to load com.p6spy.engine.spy.P6SpyDriver.  I
have downloaded the P6Spy driver but am not clear how to configure it so
that jetspeed-2 build system will find it.  Any help is appreciated.
The P6Spy driver is only used in the sample build.properties. It is not used or
required for J2.
I've updated the build.properties.sample to using the default hsqldb configuration
and added a separate build.properties.sample.oracle9i configuration for oracle9i
without the P6Spy drivers.
Please, read the online documentation
  http://portals.apache.org/jetspeed-2/getting-started.html
and
  http://portals.apache.org/jetspeed-2/database.html
All what is needed to get Jetspeed 2 up and running is specified there.
 

 

___
Waqar Sadiq
 

President
Practice Pacs, LLC
5809 Dove Creek Lane
Plano, TX 75093
 

Phone: (469) 556-1354
Email:  mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
___
 



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

Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

Paul Farnan wrote:
With respect to the windows configuration I had to also add the property:
org.apache.jetspeed.portal.dir=${org.apache.jetspeed.deploy.war.dir}/jetspeed
to my build.properties file. When I used the command maven quickStart it was putting 
the .war files into an unspecified location (D:\jetspeed\WEB-INF\deploy). I had to copy these 
files to the correct location to get the jetspeed site up and running. However, once I modified 
the build.properties file to include the above definition it worked fine.
Did you have this problem before or after I cleaned up the maven properties configuration and changed the maven 
requirement to 1.0-rc3 (yesterday, see: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15414).

I certainly don't need this property defined. It is used by the J2 maven-plugin which 
defines as default value
for it:
  
org.apache.jetspeed.portal.dir=${org.apache.jetspeed.deploy.war.dir}/${org.apache.jetspeed.portal.name}
The org.apache.jetspeed.portal.name property is also defined by the plugin:
  org.apache.jetspeed.portal.name=jetspeed
This leads to the same definition you used. If you have used the latest cvs head maybe 
you should clear/delete
the plugin from your ${MAVEN_HOME}/plugins and ${MAVEN_HOME_LOCAL}/plugins and try 
again.

Paul
-Original Message-
From: Bob Fleischman [mailto:[EMAIL PROTECTED]
Sent: 18 June 2004 17:37
To: 'Jetspeed Users List'
Subject: RE: Jetspeed 2 - Sample files for Windows, Tomcat 4.1
Thanks. I'm not sure exactly what the tipping point was (adding these
properties or amending the tomcat-users.xml) but now it works.
Some suggestions. It is now clear from the getting started page if Tomcat
should be running at any point. I found it must be stopped before the
quickStart. My friend was a bit confused by the instructions.
Also, I would suggest you include your build.properties file (since it is
Windows based) as an alternative sample on the CVS site.
Again, thanks for the help. Now I'm going to work with my friend trying to
make this work in Tomcat5.
Bob
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 18, 2004 12:07 PM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

Bob Fleischman wrote:

Should the directory definitions have a trailing slash? The get starting
page shows them, however your example and the build.properties.sample page
do not.
No, they don't need them.
Below properties are directly from my build.properties (I'm on WindowsXP)

-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 18, 2004 11:29 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

And, make sure you define the following (yet undocumented) required
properties
in ${USER_HOME}/build.properties:
org.apache.jetspeed.catalina.version = ${catalina.version.major}
org.apache.jetspeed.server.home = ${catalina.home}
org.apache.jetspeed.server.shared =
${org.apache.jetspeed.server.home}/shared/lib
org.apache.jetspeed.deploy.war.dir =
${org.apache.jetspeed.server.home}/webapps
Ate Douma wrote:

Bob Fleischman wrote:

I looked at http://nagoya.apache.org/jira/browse/JS2-74#action_36045 
but I
was not sure what I was supposed to do.
That comment addresses the requirement to define a user scott with 
password scott
and role manager in tomcat-users.xml:

 ?xml version='1.0' encoding='utf-8'?
 tomcat-users
   role rolename=manager/
   user username=scott password=scott roles=manager/
 /tomcat-users
I described this also in:
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15312
I'm in the process (awaiting a positive vote from the other committers) to
simplify the whole properties configuration (depends on maven-1.0-rc3) and
also addresses the currently hard coded user configuration in 
tomcat-users.xml.
If my proposal is accepted expect all this trouble to be over very soon.


Where should I add these properties and what should I set them to for the
generic out of the box J2.
Bob
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 
10:59 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

Bob Fleischman wrote:


Here is the body of the build.properties file in my
c:\eclipse\workspace\jakarta-jetspeed-2
catalina.home=c:\\Program Files\\Apache Group\\Tomcat 4.1
catalina.version.major=4
catalina.shared.lib=c:\\Program Files\\Apache Group\\Tomcat

4.1\\shared\\lib

deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps

maven.repo.remote=http://www.bluesunrise.com/maven,http://www.ibiblio.org/ma

ven
Also, I needed to modify the project.properties in the J2/portal 
directory
to change
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps

You should define those properties in ${USER_HOME}/build.properties as
described
on: http://portals.apache.org/jetspeed-2/getting-started.html
On WindowsXP if thats what

Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

David Sean Taylor wrote:
On Jun 17, 2004, at 4:33 PM, Bob Fleischman wrote:
I am trying to build Jetspeed 2 from source using the steps in
http://portals.apache.org/jetspeed-2/getting-started.html on a Window 
XP PC.

However it seems that the instructions differ slightly from the current
files. For example, they point at apache/tomcat5 in the 
project.properties
files; the paths are in 'Linux Speak' ${USER_HOME}/build.properties, 
which
turns out to be the build.properties file in the Jetspeed2 home dir; the
instructions say that catalina.home should point to $(CATALINA_HOME}/ 
and in
the existing properties file it points to tomcat/Jetspeed; and 
finally, the
build.properties files has references to Oracle. I found that I had to
remove those to get the project to build.

When I try to deploy I am being stopped with
BUILD FAILED
File.. C:\eclipse\workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line.. 485
Column 40
Unable to obtain goal [fullDeploy] --
C:\eclipse\workspace\jakarta-jetspeed-2\portal\maven.xml:250:41:
attainGoal No goal [jetspeed2:deploy]
Total time: 33 seconds
Finished at: Thu Jun 17 19:32:25 EDT 2004
I would be glad to write the Windows version if I could get everything to
work.

The document is not specific to any operating system
You can always specify forward slashes in your paths in property files, 
and they will be interpreted correctly
Make sure to edit your build.properties in your home directory
These props will override the settings in the J2 project
On Windows that can be found somewhere like c:\Documents and Settings\bob

The error you are getting means that the plugin didn't get installed
That was fixed recently. I built J2 yesterday on a clean system (empty 
local repo) and I didn't get that error

I did a new build on a clean system yesterday and I can confirm this error.
To solve this go to the J2/maven-plugin directory after the allBuild and issue:
  maven plugin:install
Then navigate back to J2/ and run fullDeploy.
The plugin:install only has to be done once and it installs the plugin in the
$MAVEN_HOME/plugins folder. It has *nothing* to do with the local repository.
I'll see if I can get this be done automatically after allBuild (but only when
needed). It has been discussed last week but not fixed by anyone yet.
Regards,
Ate

-
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: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

I've updated the logic for the J2 maven-plugin installation.
Now, if the plugin hasn't been installed yet (or an older version)
it will be installed instead of deployed.
Checkout the new maven-plugin/maven.xml deploy-plugin goal.
Note: their are a few new, yet undocumented, properties you have to
provide in your ${USER_HOME}/build.properties to get portlets
in the current version of J2 properly deployed.
You can read about it here:
  http://nagoya.apache.org/jira/browse/JS2-74#action_36045
I will see if I can properly update/fix today the build.properties
definitions and the instructions in
  http://portals.apache.org/jetspeed-2/getting-started.html
Ate Douma wrote:

David Sean Taylor wrote:
On Jun 17, 2004, at 4:33 PM, Bob Fleischman wrote:
I am trying to build Jetspeed 2 from source using the steps in
http://portals.apache.org/jetspeed-2/getting-started.html on a Window 
XP PC.

However it seems that the instructions differ slightly from the current
files. For example, they point at apache/tomcat5 in the 
project.properties
files; the paths are in 'Linux Speak' ${USER_HOME}/build.properties, 
which
turns out to be the build.properties file in the Jetspeed2 home dir; the
instructions say that catalina.home should point to $(CATALINA_HOME}/ 
and in
the existing properties file it points to tomcat/Jetspeed; and 
finally, the
build.properties files has references to Oracle. I found that I had to
remove those to get the project to build.

When I try to deploy I am being stopped with
BUILD FAILED
File.. C:\eclipse\workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line.. 485
Column 40
Unable to obtain goal [fullDeploy] --
C:\eclipse\workspace\jakarta-jetspeed-2\portal\maven.xml:250:41:
attainGoal No goal [jetspeed2:deploy]
Total time: 33 seconds
Finished at: Thu Jun 17 19:32:25 EDT 2004
I would be glad to write the Windows version if I could get 
everything to
work.

The document is not specific to any operating system
You can always specify forward slashes in your paths in property 
files, and they will be interpreted correctly
Make sure to edit your build.properties in your home directory
These props will override the settings in the J2 project
On Windows that can be found somewhere like c:\Documents and Settings\bob

The error you are getting means that the plugin didn't get installed
That was fixed recently. I built J2 yesterday on a clean system (empty 
local repo) and I didn't get that error

I did a new build on a clean system yesterday and I can confirm this error.
To solve this go to the J2/maven-plugin directory after the allBuild and 
issue:

  maven plugin:install
Then navigate back to J2/ and run fullDeploy.
The plugin:install only has to be done once and it installs the plugin 
in the
$MAVEN_HOME/plugins folder. It has *nothing* to do with the local 
repository.

I'll see if I can get this be done automatically after allBuild (but 
only when
needed). It has been discussed last week but not fixed by anyone yet.

Regards,
Ate

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



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



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

Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

LOMBART Christophe wrote:
It seems the paramater org.apache.jetspeed.portal.dir is not mentionned into the getting-started.html which is used in the J2 plugin.
org.apache.jetspeed.portal.dir actually is derived from required property
org.apache.jetspeed.server.home which should point to ${tomcat.home}.
Other undocumented properties I already know of are:
  org.apache.jetspeed.catalina.version
  org.apache.jetspeed.server.shared
  org.apache.jetspeed.deploy.war.dir

I just added this parameter  which point to the TOMCAT_HOME/webapps/jetspeed. Now, 
everything is ok when I deploy jetspeed application into Tomcat.
I'm not sure if other parameters are still used.
Christophe
-Original Message-
From:   Ate Douma [mailto:[EMAIL PROTECTED]
Sent:   Fri 6/18/2004 1:21 PM
To: Jetspeed Users List
Cc: 
Subject:Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1
I've updated the logic for the J2 maven-plugin installation.
Now, if the plugin hasn't been installed yet (or an older version)
it will be installed instead of deployed.
Checkout the new maven-plugin/maven.xml deploy-plugin goal.
Note: their are a few new, yet undocumented, properties you have to
provide in your ${USER_HOME}/build.properties to get portlets
in the current version of J2 properly deployed.
You can read about it here:
   http://nagoya.apache.org/jira/browse/JS2-74#action_36045
I will see if I can properly update/fix today the build.properties
definitions and the instructions in
   http://portals.apache.org/jetspeed-2/getting-started.html
Ate Douma wrote:
David Sean Taylor wrote:

On Jun 17, 2004, at 4:33 PM, Bob Fleischman wrote:

I am trying to build Jetspeed 2 from source using the steps in
http://portals.apache.org/jetspeed-2/getting-started.html on a Window 
XP PC.

However it seems that the instructions differ slightly from the current
files. For example, they point at apache/tomcat5 in the 
project.properties
files; the paths are in 'Linux Speak' ${USER_HOME}/build.properties, 
which
turns out to be the build.properties file in the Jetspeed2 home dir; the
instructions say that catalina.home should point to $(CATALINA_HOME}/ 
and in
the existing properties file it points to tomcat/Jetspeed; and 
finally, the
build.properties files has references to Oracle. I found that I had to
remove those to get the project to build.

When I try to deploy I am being stopped with
BUILD FAILED
File.. C:\eclipse\workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line.. 485
Column 40
Unable to obtain goal [fullDeploy] --
C:\eclipse\workspace\jakarta-jetspeed-2\portal\maven.xml:250:41:
attainGoal No goal [jetspeed2:deploy]
Total time: 33 seconds
Finished at: Thu Jun 17 19:32:25 EDT 2004
I would be glad to write the Windows version if I could get 
everything to
work.

The document is not specific to any operating system
You can always specify forward slashes in your paths in property 
files, and they will be interpreted correctly
Make sure to edit your build.properties in your home directory
These props will override the settings in the J2 project
On Windows that can be found somewhere like c:\Documents and Settings\bob

The error you are getting means that the plugin didn't get installed
That was fixed recently. I built J2 yesterday on a clean system (empty 
local repo) and I didn't get that error

I did a new build on a clean system yesterday and I can confirm this error.
To solve this go to the J2/maven-plugin directory after the allBuild and 
issue:

 maven plugin:install
Then navigate back to J2/ and run fullDeploy.
The plugin:install only has to be done once and it installs the plugin 
in the
$MAVEN_HOME/plugins folder. It has *nothing* to do with the local 
repository.

I'll see if I can get this be done automatically after allBuild (but 
only when
needed). It has been discussed last week but not fixed by anyone yet.

Regards,
Ate

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



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



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




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

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

Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

Bob Fleischman wrote:
Here is the body of the build.properties file in my
c:\eclipse\workspace\jakarta-jetspeed-2
catalina.home=c:\\Program Files\\Apache Group\\Tomcat 4.1
catalina.version.major=4
catalina.shared.lib=c:\\Program Files\\Apache Group\\Tomcat 4.1\\shared\\lib
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps
maven.repo.remote=http://www.bluesunrise.com/maven,http://www.ibiblio.org/ma
ven
Also, I needed to modify the project.properties in the J2/portal directory
to change
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps
You should define those properties in ${USER_HOME}/build.properties as described
on: http://portals.apache.org/jetspeed-2/getting-started.html
On WindowsXP if thats what you are using it would be in:
C:\Documents and Settings\username\build.properties
Those properties override all others you define. You won't need to
change the J2/portal/project.properties then anymore.

Everything works up through quickStart, however when I go to
localhost:8080/Jetspeed all I get is a blank screen.
Did you read
  http://nagoya.apache.org/jira/browse/JS2-74#action_36045 ?
Check your Tomcat console. There must be errors otherwise you wouldn't have
a blank screen.
Please try to be more explicit, I can't be much of help on blank screen
reports...
If its the deployment manager see also:
  http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15312
Bob
Ps. A friend tried this today on a clean machine using Tomcat5 and got the
same blank screen.
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 18, 2004 7:46 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1


LOMBART Christophe wrote:

It seems the paramater org.apache.jetspeed.portal.dir is not mentionned
into the getting-started.html which is used in the J2 plugin.
org.apache.jetspeed.portal.dir actually is derived from required property
org.apache.jetspeed.server.home which should point to ${tomcat.home}.
Other undocumented properties I already know of are:
   org.apache.jetspeed.catalina.version
   org.apache.jetspeed.server.shared
   org.apache.jetspeed.deploy.war.dir

I just added this parameter  which point to the
TOMCAT_HOME/webapps/jetspeed. Now, everything is ok when I deploy jetspeed
application into Tomcat.
I'm not sure if other parameters are still used.
Christophe
-Original Message-
From:   Ate Douma [mailto:[EMAIL PROTECTED]
Sent:   Fri 6/18/2004 1:21 PM
To: Jetspeed Users List
Cc: 
Subject:Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1
I've updated the logic for the J2 maven-plugin installation.
Now, if the plugin hasn't been installed yet (or an older version)
it will be installed instead of deployed.
Checkout the new maven-plugin/maven.xml deploy-plugin goal.
Note: their are a few new, yet undocumented, properties you have to
provide in your ${USER_HOME}/build.properties to get portlets
in the current version of J2 properly deployed.
You can read about it here:
  http://nagoya.apache.org/jira/browse/JS2-74#action_36045
I will see if I can properly update/fix today the build.properties
definitions and the instructions in
  http://portals.apache.org/jetspeed-2/getting-started.html
Ate Douma wrote:

David Sean Taylor wrote:

On Jun 17, 2004, at 4:33 PM, Bob Fleischman wrote:

I am trying to build Jetspeed 2 from source using the steps in
http://portals.apache.org/jetspeed-2/getting-started.html on a Window 
XP PC.

However it seems that the instructions differ slightly from the current
files. For example, they point at apache/tomcat5 in the 
project.properties
files; the paths are in 'Linux Speak' ${USER_HOME}/build.properties, 
which
turns out to be the build.properties file in the Jetspeed2 home dir; the
instructions say that catalina.home should point to $(CATALINA_HOME}/ 
and in
the existing properties file it points to tomcat/Jetspeed; and 
finally, the
build.properties files has references to Oracle. I found that I had to
remove those to get the project to build.

When I try to deploy I am being stopped with
BUILD FAILED
File.. C:\eclipse\workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line.. 485
Column 40
Unable to obtain goal [fullDeploy] --
C:\eclipse\workspace\jakarta-jetspeed-2\portal\maven.xml:250:41:
attainGoal No goal [jetspeed2:deploy]
Total time: 33 seconds
Finished at: Thu Jun 17 19:32:25 EDT 2004
I would be glad to write the Windows version if I could get 
everything to
work.

The document is not specific to any operating system
You can always specify forward slashes in your paths in property 
files, and they will be interpreted correctly
Make sure to edit your build.properties in your home directory
These props will override the settings in the J2 project
On Windows that can be found somewhere like c:\Documents and Settings\bob

The error you are getting means that the plugin didn't get installed
That was fixed recently. I built J2

Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

Bob Fleischman wrote:
Thanks for the quick reply. I will move my build properties to where you
suggested. If I have other maven projects I assume I just append these new
properties.
Sorry I can not be more specific. We both get simple a blank white screen
with 'Done' in the status bar. There are no errors on the Tomcat console
(4.129).
I've been running J1 for years and I know my Tomcat is fine. Also, as I
said, a friend on a different PC got the same results running Tomcat5.
Is there an error log file I should check??
  ${TOMCAT_HOME}/logs/
  ${TOMCAT_BASE}/webapps/jetspeed/logs/
Thanks
Bob
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 18, 2004 10:59 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

Bob Fleischman wrote:

Here is the body of the build.properties file in my
c:\eclipse\workspace\jakarta-jetspeed-2
catalina.home=c:\\Program Files\\Apache Group\\Tomcat 4.1
catalina.version.major=4
catalina.shared.lib=c:\\Program Files\\Apache Group\\Tomcat
4.1\\shared\\lib
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps
maven.repo.remote=http://www.bluesunrise.com/maven,http://www.ibiblio.org/ma
ven
Also, I needed to modify the project.properties in the J2/portal directory
to change
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps
You should define those properties in ${USER_HOME}/build.properties as
described
on: http://portals.apache.org/jetspeed-2/getting-started.html
On WindowsXP if thats what you are using it would be in:
C:\Documents and Settings\username\build.properties
Those properties override all others you define. You won't need to
change the J2/portal/project.properties then anymore.

Everything works up through quickStart, however when I go to
localhost:8080/Jetspeed all I get is a blank screen.

Did you read
   http://nagoya.apache.org/jira/browse/JS2-74#action_36045 ?
Check your Tomcat console. There must be errors otherwise you wouldn't have
a blank screen.
Please try to be more explicit, I can't be much of help on blank screen
reports...
If its the deployment manager see also:
   http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15312

Bob
Ps. A friend tried this today on a clean machine using Tomcat5 and got the
same blank screen.
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 18, 2004 7:46 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1


LOMBART Christophe wrote:

It seems the paramater org.apache.jetspeed.portal.dir is not mentionned
into the getting-started.html which is used in the J2 plugin.
org.apache.jetspeed.portal.dir actually is derived from required property
org.apache.jetspeed.server.home which should point to ${tomcat.home}.
Other undocumented properties I already know of are:
  org.apache.jetspeed.catalina.version
  org.apache.jetspeed.server.shared
  org.apache.jetspeed.deploy.war.dir


I just added this parameter  which point to the
TOMCAT_HOME/webapps/jetspeed. Now, everything is ok when I deploy jetspeed
application into Tomcat.

I'm not sure if other parameters are still used.
Christophe
-Original Message-
From:   Ate Douma [mailto:[EMAIL PROTECTED]
Sent:   Fri 6/18/2004 1:21 PM
To: Jetspeed Users List
Cc: 
Subject:Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1
I've updated the logic for the J2 maven-plugin installation.
Now, if the plugin hasn't been installed yet (or an older version)
it will be installed instead of deployed.
Checkout the new maven-plugin/maven.xml deploy-plugin goal.
Note: their are a few new, yet undocumented, properties you have to
provide in your ${USER_HOME}/build.properties to get portlets
in the current version of J2 properly deployed.
You can read about it here:
 http://nagoya.apache.org/jira/browse/JS2-74#action_36045
I will see if I can properly update/fix today the build.properties
definitions and the instructions in
 http://portals.apache.org/jetspeed-2/getting-started.html
Ate Douma wrote:

David Sean Taylor wrote:


On Jun 17, 2004, at 4:33 PM, Bob Fleischman wrote:


I am trying to build Jetspeed 2 from source using the steps in
http://portals.apache.org/jetspeed-2/getting-started.html on a Window 
XP PC.

However it seems that the instructions differ slightly from the current
files. For example, they point at apache/tomcat5 in the 
project.properties
files; the paths are in 'Linux Speak' ${USER_HOME}/build.properties, 
which
turns out to be the build.properties file in the Jetspeed2 home dir;
the
instructions say that catalina.home should point to $(CATALINA_HOME}/ 
and in
the existing properties file it points to tomcat/Jetspeed; and 
finally, the
build.properties files has references to Oracle. I found that I had to
remove those to get the project to build.

When I try to deploy I am being stopped with
BUILD FAILED
File.. C:\eclipse\workspace\jakarta-jetspeed-2\maven.xml
Element

Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

Bob Fleischman wrote:
I looked at http://nagoya.apache.org/jira/browse/JS2-74#action_36045 but I
was not sure what I was supposed to do.
That comment addresses the requirement to define a user scott with password scott
and role manager in tomcat-users.xml:
   ?xml version='1.0' encoding='utf-8'?
   tomcat-users
 role rolename=manager/
 user username=scott password=scott roles=manager/
   /tomcat-users
I described this also in:
  http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15312
I'm in the process (awaiting a positive vote from the other committers) to
simplify the whole properties configuration (depends on maven-1.0-rc3) and
also addresses the currently hard coded user configuration in tomcat-users.xml.
If my proposal is accepted expect all this trouble to be over very soon.
Where should I add these properties and what should I set them to for the
generic out of the box J2.
Bob
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 18, 2004 10:59 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

Bob Fleischman wrote:

Here is the body of the build.properties file in my
c:\eclipse\workspace\jakarta-jetspeed-2
catalina.home=c:\\Program Files\\Apache Group\\Tomcat 4.1
catalina.version.major=4
catalina.shared.lib=c:\\Program Files\\Apache Group\\Tomcat
4.1\\shared\\lib
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps
maven.repo.remote=http://www.bluesunrise.com/maven,http://www.ibiblio.org/ma
ven
Also, I needed to modify the project.properties in the J2/portal directory
to change
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps
You should define those properties in ${USER_HOME}/build.properties as
described
on: http://portals.apache.org/jetspeed-2/getting-started.html
On WindowsXP if thats what you are using it would be in:
C:\Documents and Settings\username\build.properties
Those properties override all others you define. You won't need to
change the J2/portal/project.properties then anymore.

Everything works up through quickStart, however when I go to
localhost:8080/Jetspeed all I get is a blank screen.

Did you read
   http://nagoya.apache.org/jira/browse/JS2-74#action_36045 ?
Check your Tomcat console. There must be errors otherwise you wouldn't have
a blank screen.
Please try to be more explicit, I can't be much of help on blank screen
reports...
If its the deployment manager see also:
   http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15312

Bob
Ps. A friend tried this today on a clean machine using Tomcat5 and got the
same blank screen.
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 18, 2004 7:46 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1


LOMBART Christophe wrote:

It seems the paramater org.apache.jetspeed.portal.dir is not mentionned
into the getting-started.html which is used in the J2 plugin.
org.apache.jetspeed.portal.dir actually is derived from required property
org.apache.jetspeed.server.home which should point to ${tomcat.home}.
Other undocumented properties I already know of are:
  org.apache.jetspeed.catalina.version
  org.apache.jetspeed.server.shared
  org.apache.jetspeed.deploy.war.dir


I just added this parameter  which point to the
TOMCAT_HOME/webapps/jetspeed. Now, everything is ok when I deploy jetspeed
application into Tomcat.

I'm not sure if other parameters are still used.
Christophe
-Original Message-
From:   Ate Douma [mailto:[EMAIL PROTECTED]
Sent:   Fri 6/18/2004 1:21 PM
To: Jetspeed Users List
Cc: 
Subject:Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1
I've updated the logic for the J2 maven-plugin installation.
Now, if the plugin hasn't been installed yet (or an older version)
it will be installed instead of deployed.
Checkout the new maven-plugin/maven.xml deploy-plugin goal.
Note: their are a few new, yet undocumented, properties you have to
provide in your ${USER_HOME}/build.properties to get portlets
in the current version of J2 properly deployed.
You can read about it here:
 http://nagoya.apache.org/jira/browse/JS2-74#action_36045
I will see if I can properly update/fix today the build.properties
definitions and the instructions in
 http://portals.apache.org/jetspeed-2/getting-started.html
Ate Douma wrote:

David Sean Taylor wrote:


On Jun 17, 2004, at 4:33 PM, Bob Fleischman wrote:


I am trying to build Jetspeed 2 from source using the steps in
http://portals.apache.org/jetspeed-2/getting-started.html on a Window 
XP PC.

However it seems that the instructions differ slightly from the current
files. For example, they point at apache/tomcat5 in the 
project.properties
files; the paths are in 'Linux Speak' ${USER_HOME}/build.properties, 
which
turns out to be the build.properties file in the Jetspeed2 home dir;
the
instructions say that catalina.home should point to $(CATALINA_HOME}/ 
and in
the existing

Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

[Ate Douma]

And, make sure you define the following (yet undocumented) required properties
in ${USER_HOME}/build.properties:
org.apache.jetspeed.catalina.version = ${catalina.version.major}
org.apache.jetspeed.server.home = ${catalina.home}
org.apache.jetspeed.server.shared = ${org.apache.jetspeed.server.home}/shared/lib
org.apache.jetspeed.deploy.war.dir = ${org.apache.jetspeed.server.home}/webapps
Ate Douma wrote:

Bob Fleischman wrote:
I looked at http://nagoya.apache.org/jira/browse/JS2-74#action_36045 
but I
was not sure what I was supposed to do.
That comment addresses the requirement to define a user scott with 
password scott
and role manager in tomcat-users.xml:

   ?xml version='1.0' encoding='utf-8'?
   tomcat-users
 role rolename=manager/
 user username=scott password=scott roles=manager/
   /tomcat-users
I described this also in:
  http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15312
I'm in the process (awaiting a positive vote from the other committers) to
simplify the whole properties configuration (depends on maven-1.0-rc3) and
also addresses the currently hard coded user configuration in 
tomcat-users.xml.
If my proposal is accepted expect all this trouble to be over very soon.

Where should I add these properties and what should I set them to for the
generic out of the box J2.
Bob
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 
10:59 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1

Bob Fleischman wrote:

Here is the body of the build.properties file in my
c:\eclipse\workspace\jakarta-jetspeed-2
catalina.home=c:\\Program Files\\Apache Group\\Tomcat 4.1
catalina.version.major=4
catalina.shared.lib=c:\\Program Files\\Apache Group\\Tomcat

4.1\\shared\\lib
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps
maven.repo.remote=http://www.bluesunrise.com/maven,http://www.ibiblio.org/ma 


ven
Also, I needed to modify the project.properties in the J2/portal 
directory
to change
deploy.war.dir=c:\\Program Files\\Apache Group\\Tomcat 4.1\\webapps

You should define those properties in ${USER_HOME}/build.properties as
described
on: http://portals.apache.org/jetspeed-2/getting-started.html
On WindowsXP if thats what you are using it would be in:
C:\Documents and Settings\username\build.properties
Those properties override all others you define. You won't need to
change the J2/portal/project.properties then anymore.

Everything works up through quickStart, however when I go to
localhost:8080/Jetspeed all I get is a blank screen.

Did you read
   http://nagoya.apache.org/jira/browse/JS2-74#action_36045 ?
Check your Tomcat console. There must be errors otherwise you wouldn't 
have
a blank screen.
Please try to be more explicit, I can't be much of help on blank screen
reports...

If its the deployment manager see also:
   http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15312

Bob
Ps. A friend tried this today on a clean machine using Tomcat5 and 
got the
same blank screen.

-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 
7:46 AM
To: Jetspeed Users List
Subject: Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1


LOMBART Christophe wrote:

It seems the paramater org.apache.jetspeed.portal.dir is not 
mentionned

into the getting-started.html which is used in the J2 plugin.
org.apache.jetspeed.portal.dir actually is derived from required 
property
org.apache.jetspeed.server.home which should point to ${tomcat.home}.

Other undocumented properties I already know of are:
  org.apache.jetspeed.catalina.version
  org.apache.jetspeed.server.shared
  org.apache.jetspeed.deploy.war.dir


I just added this parameter  which point to the

TOMCAT_HOME/webapps/jetspeed. Now, everything is ok when I deploy 
jetspeed
application into Tomcat.


I'm not sure if other parameters are still used.
Christophe
-Original Message-
From:Ate Douma [mailto:[EMAIL PROTECTED]
Sent:Fri 6/18/2004 1:21 PM
To:Jetspeed Users List
Cc:   
Subject:Re: Jetspeed 2 - Sample files for Windows, Tomcat 4.1
I've updated the logic for the J2 maven-plugin installation.
Now, if the plugin hasn't been installed yet (or an older version)
it will be installed instead of deployed.
Checkout the new maven-plugin/maven.xml deploy-plugin goal.

Note: their are a few new, yet undocumented, properties you have to
provide in your ${USER_HOME}/build.properties to get portlets
in the current version of J2 properly deployed.
You can read about it here:
 http://nagoya.apache.org/jira/browse/JS2-74#action_36045
I will see if I can properly update/fix today the build.properties
definitions and the instructions in
 http://portals.apache.org/jetspeed-2/getting-started.html
Ate Douma wrote:

David Sean Taylor wrote:


On Jun 17, 2004, at 4:33 PM, Bob Fleischman wrote:


I am trying to build Jetspeed 2 from source using the steps in
http://portals.apache.org/jetspeed-2