Re: Jetspeed 2.0 M2 Released
Congratulations to all involved ! cheers, Serge... 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] - 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)
I'd go further and say that in a perfect world, user documentation shouldn't be needed at all because the software would be so intuitive that users would be able to understand it immediately. Nobody really likes writing documentation... and nobody really likes reading it to get the job done :) Please note I said in a perfect world and I'm only talking about user documentation :) On a more serious (and realistic) note, I agree with Rafaël completely. cheers, Serge... Raphaël Luta wrote: Hema Menon wrote: I tend to agree to the good developers/bad documentors theory. However its not always easy to work with lack of/no documentation to a product. Yes, user experience is the best form of documentation. Will try to use Wiki to give more feedback, that could help others too. My point was not to imply that user should document the product with their experiences, simply that user feedback is a great tool for developers to build a *useful* documentation without spending too much energy documenting every features in one go... It enables us to identify where explanations are needed and what can be made more intuitive. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.6-Fusion HELP!!!!
Hi all, I just wanted to say that I also think that the work that went into Fusion is important on multiple levels : - first of all I integrate J2 with my product in a way very similar to what Fusion does, so if J2 changes a lot, I spend my time refactoring my code and understanding the changes, but this is my problem (btw currently I've frozen the version of J2 I use so that I can work on the integration) - Fusion is a great test case for using J2 as a component library, and I think that this has generally been a very good influence on the design of J2 - as other have said Fusion is a great migration path Anyway, I didn't have time to follow the whole refactoring work on deployment, but as long as it's able to deploy from a directory and maybe has a listener interface I think it should be ok. Regards, Serge Huber. David Sean Taylor wrote: Ate Douma wrote: 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. Here is my acknowledgement: resolve the Fusion issues before merging. 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. Me too 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. Great 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 I'll take that as a -1 on deprecating Fusion ;) -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. Well, we did everything except put out a release, and its long overdue. We need to figure out if we want to release 1.6 with: 2.0 M1 2.0 M2 2.0 Final Release We could do a 1.6.1 release with M2, 1.6.2 with the Final Release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JetSpeed2 build failed. TorqueDataModelTask cannot be found
Did you delete your plugin directory ?
Regards,
Serge Huber.
At 07:00 25.06.2004, you wrote:
I download and install Maven 1.0rc3, but I got same error.
What is wrong???
Thanks.
You might want to recycle your Maven plugins by deleted the content of
${user.home}/.maven/plugins. Oh and upgrading to Maven 1.0 rc 3 since it
is
required now for proper compilation of J2.
Regards,
Serge Huber.
At 07:57 24.06.2004, you wrote:
Hi all,
I have checkouted JetSpeed2. When I tried to build it using command
maven
allClean allBuild, i got the follow error:
BUILD FAILED
File.. file:/C:/Documents and
Settings/sam/.maven/plugins/maven-torque-plugi
n-3.2/plugin.jelly
Element... taskdef
Line.. 51
Column 63
taskdef class org.apache.torque.task.TorqueDataModelTask cannot be found
Total time: 5 seconds
Maven correctly download all dependences.
What is wrong? Somebody can help me?
Thanks!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- -- --- -=[ shuber2 at jahia dot com ]= --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JetSpeed2 build failed. TorqueDataModelTask cannot be found
You might want to recycle your Maven plugins by deleted the content of
${user.home}/.maven/plugins. Oh and upgrading to Maven 1.0 rc 3 since it is
required now for proper compilation of J2.
Regards,
Serge Huber.
At 07:57 24.06.2004, you wrote:
Hi all,
I have checkouted JetSpeed2. When I tried to build it using command maven
allClean allBuild, i got the follow error:
BUILD FAILED
File.. file:/C:/Documents and
Settings/sam/.maven/plugins/maven-torque-plugi
n-3.2/plugin.jelly
Element... taskdef
Line.. 51
Column 63
taskdef class org.apache.torque.task.TorqueDataModelTask cannot be found
Total time: 5 seconds
Maven correctly download all dependences.
What is wrong? Somebody can help me?
Thanks!
- -- --- -=[ shuber2 at jahia dot com ]= --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 2 Release?
At 09:46 24.06.2004, you wrote: Hi, Does anyone know a timeframe for when there will be an official release of Jetspeed 2.0? We are looking at developing a portal based application and it is important that we follow the JSR 168 spec for future portability. Does anyone know what the migration from 1.5 to 2.0 be like if we were to start with 1.5 and port to 2.0 when it is released - or is this advisable? As far as I know there is no time frame yet for J2 alpha (it hasn't reached that stage yet). The code is getting more stable everyday, but there are still some parts that need completion, especially on the layout side (there was some talk about menu generation on the dev list yesterday). Basically it's already quite functional if you want to do some testing, but as far as dates go, nothing is set in stone (and I too wish it would be :)). About migration from J1 to J2 I don't know much about that except that I guess it would be possible to develop a wrapper portlet for J1 portlets. But this hasn't been done yet, and there might be some technical difficulties about it (I'm especially thinking about the RunData structure which would have to be built for the J1 portlet). This is my report on the State of Jetspeed 2 :) Regards, Serge... - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to create custom portlet modes?
At 06:33 23.06.2004, you wrote: On Jun 22, 2004, at 8:15 AM, [EMAIL PROTECTED] wrote: We would like to create a new portlet mode to display a help page on a per-portlet basis (similar to other modes, like info, configure, etc.) Is there an easy way to do this with Jetspeed 1.5? - Create a new permission for your new custom mode - I think you will need to extend the VelocityPortletControl to handle your custom mode, see the buildActionList method - Then see jetspeed.vm, as you will need to have a new image for your new action name - create a new action class for the new mode, see o.a.j.modules.controls for examples Also, will there be direct support for this sort of thing in Jetspeed 2? Yes, its in the portlet spec, but not required that the portal support extended modes Jetspeed-2 currently has no support for extended modes although if you are interested in implemented it I'd be glad to help I've actually been looking at the custom portlet modes for J2, and I was trying to figure out a way to make a generic extension mechanism. Basically what we have for custom portlet modes is : - has to be supported by the portlet before being displayed to the user - server may need code specific to this mode, that might influence navigation, rendering (for example a clipboard mode or a print portlet mode). So we would need to have a way to specify a way to plugin the extra functionality. For custom window states : - has to be supported by the portlet before being display to the user - server definitely needs to know how to handle the custom window states, as it will influence layout, so again ideally we need a way to plugin the extra functionality. It's not very clear to me how to provide the plugin functionality must be implemented as it may concern multiple parts of J2. It will mostly influence layout but it might also have to toy with navigational state or other sub-systems. I unfortunately am not familiar with J1's custom mode's system and we might be able to reuse some of that design. Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TR : Problem during jetspeed2 compil
If you're using Maven RC 2, try the following :
1. Uninstall Maven
2. Download the ZIP install of Maven RC 2
3. Completely empty the ${user.home}/.maven/plugins directory
4. Uncompress the Maven ZIP, NOT over a previous install of Maven
5. Set the environment MAVEN_HOME to point to your Maven install dir
6. Set the PATH to include MAVEN_HOME/bin directory (or MAVEN_HOME\bin if
you're using Windows)
Normally that should do the trick.
Regards,
Serge Huber.
At 12:00 31.03.2004, you wrote:
C:\Apps\jetspeed2\portalmaven war
(...)
test:compile:
test:test:
[junit] Running org.apache.jetspeed.cache.file.TestFileCache
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 3,36 sec
[junit] [ERROR] TEST org.apache.jetspeed.cache.file.TestFileCache FAILED
( ... )
BUILD FAILED
File.. file:/C:/Documents and
Settings/fyom7305/.maven/plugins/maven-test-plugin-1.5/plugin.jelly
Element... fail
Line.. 148
Column 54
There were test failures.
Total time: 1 minutes 12 seconds
Finished at: Wed Mar 31 11:34:33 CEST 2004
What's wrong ?
François
- -- --- -=[ shuber2 at jahia dot com ]= --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : RE : TR : Problem during jetspeed2 compil
At 17:54 31.03.2004, you wrote: On the other hand it works well with a tomcat 4 version. Is there any problems with version 5 ? Yes, the jetspeed.xml file needs to be moved under Tomcat 5 to tomcat/conf/Catalina/localhost Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem building jetspeed2
I'm not entirely sure yet but I think it might be possible to set a dependency to a plugin in the project.xml. That would solve the problem we have currently with RC2. Regards, Serge Huber. At 16:40 29.03.2004, you wrote: Hi François, It's a problem with RC2 of Maven. RC2 does not include the Torque plugin like previous versions of Maven have. There was a recent thread on Jetspeed-dev about the same issue and how to solve it; you may want to check there. Basically, you need to download the Torque plugin from the Torque project manually. Hth, ** | Scott T Weaver | | [EMAIL PROTECTED]| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | ** -Original Message- From: zze-MORON François FTRD/DMI/REN [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 9:07 AM To: [EMAIL PROTECTED] Subject: Problem building jetspeed2 First I'm totally new in jetspeed. I downloaded (cvs) jetspeed2 yesterday and I didn't manage to build it. Here are the messages : C:\Temp\jakarta-jetspeed-2quick_build JETSPEED_HOME: . __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2 BUILD FAILED File.. file:/C:/Temp/jakarta-jetspeed-2/maven.xml Element... attainGoal Line.. 55 Column 39 No goal [torque:init] Total time: 1 seconds Finished at: Mon Mar 29 15:52:23 CEST 2004 What's wrong ? François - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed2 and Tomcat5.
A lot of times it's just because Tomcat 4 and 5 have different version of JAR, maybe even that have been moved. I've solved most problems going from one platform to another by moving JARs around (for example by copying them in the WEB-INF/lib directory of the application if they weren't there). Regards, Serge... At 02:03 PM 3/10/2004, you wrote: I had problems with Jetspeed2 and Tomcat5 too. Pavel Stehule V St, 10. 03. 2004 v 14:01, Dalton, Michael D pí¹e: I have Jetspeed 1.4 up and running under Tomcat 5.0.19 if that is any help. I am sure Jetspeed 2 works too under Tomcat 5. Michael Dalton -Original Message- From: Rani Kavirajan [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 10:56 PM To: [EMAIL PROTECTED] Subject: Jetspeed2 and Tomcat5. Is jetspeed-2 supposed to work on Tomcat 5.0.16? If not, are there any plans to support Tomcat 5 in the near future? I am getting a series of exceptions when I try to access the portal(build works ok and portal works on Tomcat4) thanks, Rani. Caused by: javax.management.ReflectionException: The MBean class could not be lo aded by the context classloader at com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.loadClass(MBeanInstanti atorImpl.java:444) at com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClass(MBeanInstanti atorImpl.java:80) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(Def aultMBeanServerInterceptor.java:286) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(Def aultMBeanServerInterceptor.java:234) at com.sun.jmx.mbeanserver.JmxMBeanServer.createMBean(JmxMBeanServer.jav a:362) at org.apache.jetspeed.services.jmx.JetspeedJMXService.initRemoteAccess( JetspeedJMXService.java:337) - Do you Yahoo!? Yahoo! Search - Find what you're looking for faster. - 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] - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 planning
I'll second that, thanks David and Scott for taking the time to answer our frustrations over and over :) I've been lurking a bit since I'm very busy at work with an upcoming product release, but I see the same question coming over and over about when will Pluto finally be delivered and I'm still surprised nobody has landed a replacement by now :) If somebody did maybe it would change the view of the people in the PMC that are reluctant to open source it ? But before I go down that road again, I must say if the code for Pluto was also entirely developed by IBM that in a way we should be thankful that they are willing to contribute it for free ! After all this code didn't write itself, and just like we are thankful to all the contributors to the Apache Foundation I think we will have to thank IBM for their contributions as soon as they finally land it :) As for the PMC members and the process, I understand a small group of volunteers must be able to decide for the masses on some issues. But I'm sure that corporate issues can get in the way of the committee but hey that's just how the world is :) Regards, Serge Huber. At 10:08 AM 9/29/2003 +0200, you wrote: David and Scott: Thanks for the informative answers! .. And I didn't know that the PMC meeting minutes were available like this - but the last one is from 2002 January 30?? Anyways, looking forward to JS2 and pluto! Thanks Endre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JetSpeed 2
At 08:43 AM 9/3/2003 -0700, you wrote: On Wednesday, September 3, 2003, at 02:16 AM, Eric Chow wrote: Hello, Is there any timeline to rollout JetSpeed 2 ? Its ready when its ready. It will be ready that much sooner if you get involved! I wish I could get involved, but sadly I'm still missing a JAR to compile Jetspeed 2 :) Ok ok I'll stop nagging :) Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JetSpeed 2
Hi Ron, Well for the moment there is no real relationship. We have used some of Jakarta's libraries and would like to contribute where we can, and Jetspeed 2 seems like the best match for us at the time. Also I thought that instead of trying to do on our side our own new version of the portlet dispatcher, why not participate in Jetspeed 2 and Pluto, contributing where I can, and helping out both my company's product as well as Jetspeed. I don't really like reinventing the wheel so I think most people interested in this project will want to do the same. Unfortunately I am not in the expert group of the JSR-168 and therefore I don't have the Pluto JAR, so I can't help much for the moment. I've already looked at the code that was contributed in the CVS and I like the new architecture, but in order to go further I'd need to get the code to actually execute. I even thought along the lines of re-implementing Pluto if this situation drags along because I think this closed-source stuff in an Apache project is getting a bit annoying. Before working on Jahia, I worked on OpenJODA, which was a packaging of Jetspeed. The experience was great in terms of community, but we were having a lot of trouble attracting developers because they had to learn a lot about Turbine to work with Jetspeed at the time. I understand this has gotten easier. I still believe that Jetspeed should also offer a clean migration path for people that have existing servlet-based web applications to migrate to portlets, and hopefully the upcoming final release of the JSR-168 will help this. Regards, Serge Huber. At 07:24 AM 9/4/2003 -0400, you wrote: Serge, I'm curious as to the relationship, if any, between Jahia and Jetspeed. You have answered some of my Jahia questions in the past, but I have seen you post here on the JetSpeed list as well. -Ron Cordell -Original Message- From: Serge Huber [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 7:14 AM To: Jetspeed Users List Subject: Re: JetSpeed 2 At 08:43 AM 9/3/2003 -0700, you wrote: On Wednesday, September 3, 2003, at 02:16 AM, Eric Chow wrote: Hello, Is there any timeline to rollout JetSpeed 2 ? Its ready when its ready. It will be ready that much sooner if you get involved! I wish I could get involved, but sadly I'm still missing a JAR to compile Jetspeed 2 :) Ok ok I'll stop nagging :) Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
At 08:32 AM 8/6/2003 -0700, you wrote: Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] wrote: If I understand correctly your request in regards to the JSR 168, you would like to be able to develop a client based portal that leverages the portlet components developped against the JSR168 API. Is that correct ? I think that what you can do in this case is implementing a portal server on the client, with client side technologies that interact with a remote portlet container over the network, for example through WSRP. In such a setup, your client can control exactly the aggregation behavior and still leverage any JSR 168 portlets through WSRP. Since JSR 168 assumes a server-based aggregation process, it can not answer alone your requirement but OTOH I don't think it's a showstopper since WSRP will perfectly handle this requirement. Am I missing something here ? Are you suggesting that in order to accomodate client-side technologies that a browser plugin 'portal server' would be necessary? Users would reject this outright. I really don't see how this would solve the problem. It is the whole interaction model that is the problem, not where the 'portal server' lives. Actually I think Raphael has an interesting idea. Let's suppose you're using Mozilla as a client technology. You could design a XUL client that would use LiveConnect to do WSRP requests to a WSRP compliant server (Jetspeed 2?). Within this server the interface of JSR-168 could be used to communicate with the portlets. But I also have some ideas for improvements for JSR-168, but I believe it can come later. The politics behind this JSR have slowed it down to a crawl, and I think it's is best for version 1.0 to get out the door as soon as possible, so that work may start on the foundation that's been laid out. Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: master detail records displayed in a portlet
At 11:27 AM 8/7/2003 -0400, you wrote: I would not be surprised if there is a speed penalty but then again my first programming language was assembler and I have no doubt that writting software in assembler will result in fast execution. I am not about to go back to that. You almost always pay for productivity with speed but that I know you said you weren't going to back it up, but believe me : it is possible to write slow code in assembly language. One of the ways is accessible very low performance memory such as old-time VGA cards. The overall speed of the software is not only the speed of execution of the application's main code, but also all the sub-systems that it communicates with. As for Jetspeed's performance. If it's the only problem you have with the software, you should not shy away, because you can always : - buy faster hardware (as you said it's the cheapest solution) - contribute more efficient designs One thing I don't know about Jetspeed because I was away from the project for a few years is if it's easily to set up in a cluster. This is one of my main points of interest right now. Regards, Serge Huber. -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 11:01 AM To: 'Jetspeed Users List' Subject: RE: master detail records displayed in a portlet I tried to do a few things with JetSlow, and then I went Struts. Okay, that comment was uncalled for. Please try and refrain from mud slinging as it does no one any good and is fodder for a flame war, which is not conducive to the goals of this list. Regards, *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 9:29 AM To: [EMAIL PROTECTED] Subject: Re: master detail records displayed in a portlet I tried to do a few things with JetSlow, and then I went Struts. This is using JSTL, not Velocity, but same concept, Struts supports Velocity. Master detail processing is done all the time, and several working samples are in there: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/bP/WEB- INF/portlets/newsBlg/NewsBlgCmntsLst.jsp Note that it using the core master tag and then iterating a list. This is usnig nested beans. I think that is the key conecpt I recommend, nest beans and then use dot notation to get to each of the 3 iterating collections/beans. So you can have one bean, that nests your 3 beans. You can download and look at sample (or CVS source). Here is an example of how to click in, and get detail: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/bP/WEB- INF/portlets/cms/ContentAdminLst.jsp KISS, .V ps: And here is a navigation, but I do not think you asked for that: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/bP/WEB- INF/config/navigation.xml D.S. Johnson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ron Wheeler wrote: We are fairly new to Jetspeed and have made pretty good progress dispite the documentation. We are wondering how to create the following fairly common web page structure. We have three identical problems. List of case studies, list of white papers, list of training courses. In each case, we want to present the user with the list and when they click on one of them, show them the details of that item. The information is in one or more XML files. (list of items in one XML that links to the many individual XML files containing the details of te item.) The first problem is that we do not see how we can use separate portlets since we only want either the list or one of the items on the screen at once and we do not the menu to change while the user navigates within the topic. If we use a single portlet, then we need to be able to respond to selection of one item (a Case Study for example) by clearing the list and displaying the selected document (the Case Study). We have the xsl stylesheets to display the initial list and the details of the idividual item. 1) Are we on the right track and understanding the problem in a reasonable way? 2) Which portlet type would be the best way to handle this? 3) Does anyone have a model that we could see/use for this type of application? 4) Should we be looking at Velocity/DVSL rather than XSLT if we are going to work with Jetspeed? Thanks for the help. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I don't use Velocity very much so I don't know if this will work for you. But, I have used java server pages and servlets to switch between pages
Re: Re[2]: JSR-168 Comments Dispatching to portlets
to portlet. Continuing on the above code : myPortlet.render(renderRequest, renderResponse); As you can see not much extra is needed to have the complete picture. It's a shame the JSR-168 only specifies point 2 when point 1 could have been achieved in a minimal way without much effort. I hope this will indeed be specified later, but given the time it has taken to specify point 2 I had hope point 1 was being addressed too. Maybe it's not too late and before the final release this can be added ? Can somebody here shed some light on the possibilities still open ? Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
At 08:16 AM 7/24/2003 -0700, you wrote: Im sorry, but I don't follow your logic. The proxy servlet is a part of the portlet container implementation. You can still take your exact same Portlet Application and drop it in any other compliant container. From the portlet's point of view, it shouldn't matter how the container is implemented, as long as the portlet container is compliant. Ok I hadn't noticed the proxy servlet was part of the container's implementation (did I miss this in the spec ? could you point me to it ? thanks) Or is it only available in the Pluto implementation ? I agree that from the portlet's point of view it shouldn't matter, and that's the whole point of the current spec. What I was asking was how do we make Jetspeed portable to any Portlet API and Servlet API 2.3 compliant container ? How does Jetspeed dispatch to portlets deployed in a portal container (for exemple how does Jetspeed dispatch to a portlet deployed in WebLogic's portal container?). It seems to me the current spec doesn't cover this, but if it does I'm happy :) Now I am not saying that this is the only way to implement a portlet container. I think the most common implementation will be to put it in the servlet container. We have considered moving the portlet container into Tomcat, but as you pointed out, it will couple Jetspeed to working with only Tomcat. That may be the direction we take in the future, or it may be another project based in Tomcat. This is all up to the Jetspeed community. Ok I think I understand. You've managed to find a portable way to provide an implementation of the Portlet API by including it in the web application itself. But unfortunately this is not specified by the JCP as far as I can tell and therefore will not be officially recognized by other portlet containers which is unfortunate. Oh Pluto, well that's what Im talking about too. Why didn't you just say Pluto :), Pluto uses the same approach as I am describing above. You will soon have the opportunity to see what Im talking about. We were planning on opening up a new CVS on Monday, jakarta-jetspeed-2. However, we are still waiting to get the directories created on the CVS server at Apache. As soon as this happens, I'll let you know. Cool, can't wait to see, and help out if possible ! Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: JSR-168 Comments
What's interesting about that document is page 14 What The Portlet Specification Does Not Address, notably : Portlet Aggregators, Pre-built Portlets and Administration and Portlet Deployment. One of the issues I see for Jetspeed 2, using the new Portlet API, is how to port Jetspeed to other application servers than Tomcat. From what I understand of the specification, nothing concerning the dispatching to portlets is standardized, meaning there is no standard way to lookup a portlet and then to call the render or action methods on that portlet. As portlets are special classes in a standard Web application, this means it will be left to every servlet container implementation to do this in it's own way. And most servlet containers protect web applications contexts from one another, meaning they are in different class loader, so there is no way that Jetspeed, being a web application itself, could access the class of another web application in another context and dispatch to it. Sure Jetspeed could include a complete servlet container, but that's kinda unfortunate since we usually want to let the application server do that. Another way to look at this problem is : how do we port Jetspeed to other platforms than Tomcat ? In Tomcat we can access the whole source code and add interceptors into the servlet lookup to dispatch to a portlet from Jetspeed. How would we do this on Orion, or Resin, or WebLogic, or WebSphere ? Regards, Serge Huber. At 11:06 AM 7/23/2003 +0700, you wrote: http://developers.sun.com/prodtech/portalserver/reference/techart/jsr168/pb_whitepaper.pdf Jetspeed 2.0 is JSP taglib for Portlet?? what do you think Regards, Frans Thamura [EMAIL PROTECTED] Intercitra Innovation Center +62 855 7888 699 We help you manage and control. -- Tertarik dengan Java Open Source Integration discussion?? bergabung ke JUG Indonesia mailing list, untuk subscribe email aja ke [EMAIL PROTECTED] Website: http://jug-indonesia.dev.java.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- --- -=[ serge.huber at jahia dot com ]= --- -- - Jahia : A collaborative source CMS and Portal Server www.jahia.org Community and product web site www.jahia.com Commercial services company - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: JSR-168 Comments
At 09:05 AM 7/23/2003 -0700, you wrote: Tomcat and Resin have a cross-context invoker feature. See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html Yes I am aware of those, but it still doesn't solve the problem of dispatching to a Portlet API portlet. The entry point for one of those portlets is a class that complies to a certain interface. For a Servlet in a different web application we can dispatch by doing something like this : ServletContext otherWebAppContext = ServletContext.getContext(otherWebAppContextPath); RequestDispatcher otherWebAppDispatcher = otherWebAppContext.getRequestDispatcher(otherWebAppURI) otherWebAppDispatcher.include(request, response); But there is no equivalent for portlets. How can I call the doView method of a certain portlet ? You'd need a way to access the classloader of the other context. From what I understand in the implementation that is being proposed to the ASF there will be a JAR that integrates with Tomcat (meaning it will not be deployed in a context class loader but in Tomcat's classloader, providing access down to all sub class loaders) to provide access to the portlets, but this is very container specific and will have to be modified to run on any other application server. Regards, Serge Huber. - -- --- -=[ shuber2 at jahia dot com ]= --- -- - www.jahia.org : A collaborative source CMS and Portal Server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
