|
You can download a complete geronimo which jetspeed had been installed from here(This file could only be kept for 3 days) Size:123 MB
http://monocerosd.mofile.com/1181156268530806/8443411658745338/99/1A6D83FBDF2737EE66842A4FD7C55CB9/geronimo-1.0-SNAPSHOT-j2.zip or you can download jetspeed.ear from here, Size:29 MB http://normad.mofile.com/5225197481431815/5009669279725268/99/9EBBFC8A88A367AECAC363F12BF34939/jetspeed.ear If I should start up new jira issues, someone tell me :-)
This is an untested class to replace SecurityValveImpl for running j2 in geronimo. It gets the Subject from the geronimo-specific location where geronimo puts it after login. This should let security work with geronimo managing the login and no need for a second "fake" subject constructed by j2. I haven't had time to figure out how to set up the spring configuration files to use this class instead of the normal J2 one, so it is really untested. I've considerably reorganized this so as to build a geronimo server including jetspeed. To compile, unpack geronimo-jetspeed.zip in app-servers, cd geronimo:maven multiproject:install
This will build the new classes, build a derby database, build an ear including jetspeed and the sample portlet apps, build a geronimo configuration for jetspeed, and build a geronimo server including jetspeed. This is roughly how geronimo builds its distributables, so I think this is the best layout for working on the geronimo integration. Unfortunately jetspeed won't start properly. Perhaps someone who knows more spring can try it and give a hint about what is wrong? This patch to jetspeed + previous geronimo-jetspeed.zip builds as much of jetspeed as possible without log4j, commons-logging, or cglib included in wars. It also fixes a version in the geronimo plan. At this point I have jetspeed starting with only exceptions from the bridges wars inclusion of commons-logging. Trying to view the portal gives a bunch of IllegalArgumentException exceptions from missing portlet definitions. Any ideas? Bad db setup? Not registering portlet apps with the portal??
The reason my setup doesn't work is that it uses wars from the maven repo rather than ones from a successfully started jetspeed/tomcat setup. The web.xml from a successfully started war will have the jetspeedContainerServlet added to it: since my web.xml's didn't, the portlet apps never registered with jetspeed, so it is not too surprising I couldn't see anything.
I think I see how to change the geronimo web module builders (at least the one from jetty) so that geronimo will add this servlet for us. David,
Jetspeed provide an offline deployer which you might be able to use from within the Geronimo builders: http://portals.apache.org/jetspeed-2/multiproject/jetspeed-deploy-tools/deploy-tools.html Another thing the deployer can do (optionally) is stripping out logger framework jars (log4J, commons-logging) which seems to be needed for Geronimo too. I'm planning to work again on some fixes and enhancements for the J2 build and installer, starting tomorrow. I will also look into the Geronimo integration and try out you setup. With the enclosed patch I have jetspeed running on geronimo. In order to deal with some classloading problems I moved all the jars out of jetspeed.war lib and added dependencies in the ear file. I also had to modify PortletApplicationManager to determine "local" based on whether the war name starts with "jetspeed-", since in my setup all wars are deployed the same, as wars in the ear.
I actually think this will lead to a better solution for environments with reasonably sophisticated classloading, such as geronimo. I plan to have 2 basic configurations (i.e. classloaders) for jetspeed in geronimo: a base configuration that includes basically the jars put into "shared" in tomcat, and a child configuration that includes as dependencies all the jars normally put into jetspeed.war lib. "regular" portlet applications can then be deployed as children of the base configuration, whereas "local" portlet applications can be deployed as children of the child config. In this way the local portlet apps won't need to use special directories in the unpacked jetspeed war and the jetspeed war probably won't need to be unpacked. However, what I have in this patch is rather crude. This patch is generated with svk: if anyone has trouble applying it please let me know. To get to my local state you should unpack the zip file i provided, then apply patch1.diff and patch4.diff. This file includes a modification to JetspeedDeploy from Jian Liao. I like to contribution my patch for JetspeedDeploy to Apache Jetspeed. I created a new JetspeedDeploy constructor which has 4 parameters, the fourth parameter is for explicitly specify portlet application contextName, since in this case the war file name is not equals to contextName.
With these I have the GeronimoSecurityValve working. I added an alternate https access path /jetspeed/secure. I split the jetspeed configuration into jetspeed-base which includes the shared jars and the jetspeed ear which has the non-shared jars as dependencies. I construct a geronimo-jetspeed war that does not have anything in lib, all the jars are geronimo dependencies in the ear. This will only work with the change to PortletApplicationManager from the previous patch that allows deployment of "local" wars as regular wars.
I fixed the problems in geronimo-jetty that were leading to loss of login info when accessing an unsecured resource after login. The enclosed incremental patch updates to the current version of geronimo head.
This mostly contains some version changes to adapt to the new geronimo version 1.1-SNAPSHOT. Session tracking seems to be working completely under jetty and at least partially under tomcat: the role viewer portlet seems to give correct results consistently.
This version works with geronimo JACC and does not use the jetspeed permission manager or policy. It requires the modifications in
Permissions are set only at deployment time in this implementation. A further step will be to enable changing them while the portal is running. David,
I will have time to test this out next week. Been traveling most of January, and falling way behind unfortunately. Thanks for all the contributions! In an attempt to make it easier for others to reproduce my setup, here are some more files. Instructions:
Make sure you have up to date geronimo-jetty-j2ee-1.1-SNAPSHOT.zip and geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip. These should be downloaded automatically from cvs.apache.org/repository, but you may have better luck building them yourself. I haven't actually checked if this is in the jetspeed repo list. unpack miscchanges9.jar in jetspeed/trunk unpack geronimo-jetspeed8.zip in app-servers/geronimo (you have to create the geronimo sub-dir) get permissions1.jar from Rebuild jetspeed: maven [-o] allBuild cd app-servers/geronimo maven -o multiproject:install cd jetty-assembly java -jar target/geronimo-1.1-SNAPSHOT/bin/server.jar --long Jetspeed should start and run. The permissions are not very sophisticated: they allow all access to anyone. To change them, look at the end of jetty-config/src/plan/plan.xml. geronimo-tomcat is not set up to use geronimo jacc security yet. This includes all files for geronmo-jetspeed and jS2-472 and
The tomcat-assembly now works using JACC. I've added a gbean dependency to assure that the "additional" security information is added after the standard servlet security info. This version does not include the
I've also changed how I build geronimo-jetspeed.war to unpack a normal jetspeed.war and modify it instead of trying to maintain a copy of the entire contents. Applying the changes from this patch related to the security component:
- Changes to the AuthorizationProviderImpl - Addition of JaasPolicyCoordinator Much more elegant way to handle the policy coordination. There is an issue with the geronimo_assembly_plugin_version. The geronimo head is currently building the 1.1.6 version of this plugin.
<GeronimoSrc>/etc/project.properties:geronimo_assembly_plugin_version=1.1.6 So the files tomcat-assembly/project.properties and jetty-assembly/project.properties need to be modified from geronimo_assembly_plugin_version=1.1.3 to, geronimo_assembly_plugin_version=1.1.6 An Update for Integration J2 with Geronimo based on David Jencks's previous work.
Version ---------- Geronimo : 1.2-SNAPSHOT(SVN head) built at 03-14-2006 Jetspeed 2: 2.1-dev(SVN head) built at 03-14-2006 Known issues -------------------- o There is a blocked issue in jetspeed-2 ( o There still have a subject mismatch problem with tomcat-assembly. The subject will be binded to serve thread, but if the serve thread changed, the subject will mismatch for a user session and after the user logout, the subject still exist in the original authentication thread, I think it should be removed. There is no such issue in jetty-assembly cause each user request got reauthenticated and subject got reset after login. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Run Jetspeed 2.0 on Geronimo V1.0
I think it will work with Geronimo V1.0 Final.
Geronimo Web Container must be Tomcat.