communication between portlets
hi, all Can I use jetspeed to implement the communication betwee two portlets? For example, when I input some text in portlet A and submit it ,then I can see the text in Portlet B. thanks sophy
jakarta-jetspeed-2 CVS
The jakarta-jetspeed-2 CVS repository is now online. cvs co -P jakarta-jetspeed-2 Please note that the code will not compile without the Pluto jar. We are still in the process of getting permission to distribute the Pluto jar. -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mailportlet v0.2 - Jetspeed 2 comments
Here is new mailportlet and now with source code. May be the first commitment to portletforge.net :) Its taken some times. I had some overtimes for it but I have bad feelings because of some demotivation factors like some unclear infos about jetspeed 2. I hope in a short time jetspeed 2 project will start and again we will create a synergy on this channel. I have some question Pluto source code will be closed? (I am working with Wepshpere portal and I feel as on a jail. I like Jetspeed because you can control everything..) All turbine related codes will be dismissed? When jetspeed 2 will be available and at this time design will be finished already or our can we participate with our feedbacks. JS 1 will be still alive or what? What is the IBM role? only a helpfull commiter or owner of project? Why we cannot view codes? Do not put pluto I want to review codes. I dont have to run it but only watcing is enough for me.. for now of course (I know that many person will ask about it and will try to compile, when it fail will curse coders :)) Sorry if I hurt somebody. I like to asking everything clearly without hiding something. http://213.194.65.90/elektromarket/projects/mailportlet/updates.php Ender - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WML Customization Problems
Title: Message I've been trying to build a proof of concept for a client using Jetspeed. I installed the out-of-the-box build of 1.1.4-b4 and was immediately up and running-- accessing both from my desktop web browser and my RIM BlackBerry web browser with success. I then created a Velocity portlet which works GREAT when I access it via HTML. I updated the portlet to support WML as a media type, and wrote the following additional file: Jason I used an indentical template name to that used on the HTML side (the same name listed in the parameters in the .xreg file) and placed the WML card into the WEB-INF/templates/vm/portlets/wml directory. After a restart of Tomcat, I logged in as Tommy Turbine and customized my WML home page. I removed the stock and weather portlets, and added my ProjectHeader portlet. I then grabbed my BlackBerry and tried to log in and it fails. I've probably restarted Tomcat a dozen times in the last 30 minutes. The jetspeed.log file contains little help. Essentially, I can follow the process: I see the CapabilityMaP identify my BlackBerry user agent. The PSMLManager does its thing. GenericMVCPortlet logs a velocity, template = project-header user "turbine" is authorized to portlet set P-f6ae.. TemplateLocator: template exists. (flow.vm) 6 lines of checking for Portlet permission: actions like customize, print_friendly, info, close, etc. BOOM! Error rendering Velocity template: null: null I'm stumpped. Help?!?!?!? I've even tried REMOVING my portlet and going BACK to the MyWeather portlet and it still crashes. Jason -- Jason R. Weiss [EMAIL PROTECTED] Cell Phone: 832.443.7161 <> smime.p7s Description: S/MIME cryptographic signature
RE: New User Account: Timestamps are not entered properly to MySQL tu rbine_user table
Hi Risto, The user is created a few lines down from the createUser() call (data.setUser(user)) ... if you want some custom processing done then you would extend the CreateNewUserAndConfirm class, and then in your new class, simply override createUser()... Hope this helps... Amin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: July 29, 2003 7:13 AM To: [EMAIL PROTECTED] Subject: RE: New User Account: Timestamps are not entered properly to MySQL tu rbine_user table I also tested the effect of changing the Date parameter in org.apache.jetspeed.modules.actions.CreateNewUserAndConfirm´s doPerform() method. Default was like follows: Date now = new Date(); JetspeedUser user = JetspeedSecurity.getUserInstance(); user.setUserName( username ); user.setCreateDate(now); user.setLastLogin(new Date(0)); user.setFirstName( data.getParameters().getString("firstname") ); user.setLastName( data.getParameters().getString("lastname") ); user.setEmail( data.getParameters().getString("email") ); createUser(user, data); I changed it to: Date now = new Date(0); but now, when I added new user, the LAST_LOGIN entry in MYSQL´s user_turbine table changed to 00 from 1970010201. No other changes. Why the user.setCreateDate(now) affected the LAST_LOGIN field? What´s the purpose of user.setLastLogin() then?!? Secondly... The "new user" html-form in the portal seems to call for this class as it´s action, but the createUser() method is empty. Where the creation is actually handled? I´m lost. Thanks for all comments. Risto Kärkkäinen -Ursprüngliche Nachricht- Von: Kaerkkaeinen, Risto Juhani Gesendet: Monday, July 28, 2003 4:01 PM An: [EMAIL PROTECTED] Betreff: New User Account: Timestamps are not entered properly to MySQL tu rbine_user table Hi! While trying to add new user via Jetspeed based portal, the new record is added to MYSQL´s turbine_user table so that the MODIFIED timestamp is just fine as the current time, but CREATED and PASSWORD_CHANGED are a set of zeros and LAST_LOGIN is set to default (the year 1970 etc.). LAST_LOGIN and PASSWORD_CHANGED become correct after the related actions, but CREATED is stuck to zeros. Otherwise the portal seems to be working. I´m using jetspeed-1.4-b4 and mysql-3.23.57-win. The driver is mysql-connector-java-3.1.0-alpha. The DB has been build with the provited sql scripts and the security-schema.xml shows all the earlier fields as similar kind TIMESTAMP. Earlier version of the project was using hypersonic DB and then the MODIFIED and CREATED seemed to be set permanently to NULL. The LAST_LOGIN was working as in the current version with MySQL. The PW_CHANGED field didn´t exist in that version of Jetspeed. The nightly build from 17.7.2003 didn´t help and neither did testing this with only the "default" Jetspeed portal and MySQL. Same problems accure. I was also unable to find any similar problems on the mailing lists or FAQs. Only somehow related comment I found, was at the Apache Bug Database by Mark Orciuch. He wrote: "[FIX] Last login timestamp is not recorded - When the user is originally created last login is initialized but never changes thereafter. I confirmed this problem all the way back to 1.4b1." Any idea what is causing these timestamp variations? Why I´m getting only one field working and the others not? It would be nice to get the timestamps working properly. All help greatly appreciated! Thanks, Risto Kärkkäinen - 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: Re[2]: JSR-168 Comments & Dispatching to portlets
[Moving the thread to Jetspeed Dev] > >My problem is that is seems impossible to do both of: > > a) Have a Portal implemented on top of a standard Servlet > Container > > b) Run multiple Portlet Applications, preferrably in a > standard Portlet > >Container, preferrably -the same- container as the Portal is > running in. > >.. and be able to, in a standard way, to communicate between > the portal > >and the portlets. > I agree that one of the concerns of the JSR 168 is that it does not describe any public standard API for the communication between the servlet container and the portlet container. It does not mean it's impossible, simply that portability between servlet containers will be an implementation specific feature of the portlet container and that you may have to write servlet-container specific adapter code. Note that there's another related area where the portlet container will have to have servlet container specific code: the portlet application deployment requires you to deploy a standard WAR and thus use the servlet colntainer deployment capabilities. :/ On the whole, I don't think this lack of APIs is a real showstopper and would rather see that as an opportunity for an OSS project like Jetspeed to work on the multi-containers approach while vendors will most likely try to focus on tying their servlet and portlet container. > > From what I understand of my discussion in this mailing > list, Pluto does > something in between : it adds within the portlet a proxy > servlet that > allows dispatching to the portlets. This way the system I > have been using > with cross-context dispatching could be adapted, but it's > still not as > efficient as having a portal/portlet full-blown API. Maybe > this is the > subject for a new JSR ? Or maybe in this project (Apache > Jetspeed) we could > develop what we need and then propose this as a reference > implementation > and submit it as a JSR (maybe that way things would move > faster ?). Seeing > how projects such as Xerces and Xalan got accepted throughout > the whole > commercial world it would seem like Apache is in a position > to "impose" > defacto standards. > Yes Pluto implements something like this. The key issue to solve here is request dispatching: how does the portlet container retrieves a portlet pointer while still fullfilling the JSR constraints (like sharing session between the portlet and objects in its WAR (JSPs, etc...) The porxy servlet is mainly a portlet container specific implementation of this request dispatching, using the native servlet API calls and some custom parameters. I don't believe there's a major performance impact there. > > >One way of solving it is apparently using WSRP as the "glue" > between the > >portlet and portal. > > Yes but at what cost. Serializing all objects through XML and > sending them > through sockets that are being opened / closed all the time is very > expensive in terms of performance. > Agreed, I don't think WSRP is the solution to this problem. > > > > > I would have loved a spec where the Portal was the > Container, and had to > >be able to host Portlets within it. This way, one could buy > the Servlet > >Container from Oracle, use JetSpeed as the Portal, and buy > Portlets from > >CompanyA, B and C, plugging them in / installing like nice little > >applications in a normal OS. > That would however seriously duplicate concerns as the portal/portlet container would have to deal with classloading, WAR handling, etc... There is some sense to try to leverage these functions of the servlet container (after all, how many times do you *really* want lo load xerces.jar ? :) The JSR 168 tries to guarantee that any compliant portlet will run on any compliant container. It does not try to address portlet container portability just like EJB does not address portability of EJB container implementations (any luck porting JBoss to Websphere recently ?) > Ok, again I agree. Users of portals should be free to migrate > from one > system to another, without vendor lock-in. After all the J2EE > specs exist > as Sun puts it : "for vendors to compete on implementation, > and agree on > standards". This is a nice vision but reality is more like : "vendors > always compete on anything, Jakarta standardises". > +1. SO we can try to standardize what's missing from the JSR... :) > Now enough with my whining, I'll start a quick proposition > here : this is > what I would have loved to see in JSR-168 : > > 1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ? > Basically be able to do something like this : > > Context context = getInitialContext(); > PortletRepository portletRepository = (PortletRepository) > context.lookup("PortletRepository"); > // list of portlet example : ArrayList portletList = > portletRepository.getPortletList(); > Portlet myPortlet = portletRepository.getPortlet("myPortlet"
Re: Beyond the tutorial and the default jetspeed site
Send me a private mail. You can find my mail in a jetspeed dev mailing list. - Original Message - From: "Pascal DeMilly" <[EMAIL PROTECTED]> To: "Jetspeed Users List" <[EMAIL PROTECTED]> Sent: Monday, July 28, 2003 11:38 PM Subject: Beyond the tutorial and the default jetspeed site > Hi, > > I am volunteering for a non profit organization (my daugther's indian > princess nation) to redesign their website. > > I have looked at all sort of different way of developing it and I have > come to the conclusion that I would like a portal of sort to be the main > page and have people manage the pages directly from the web site. I also > really like the idea of portlets and the user/group/role model. It seems > so natural. > > I am in the process of deciding between Jetspeed and Liferay. (more > complete it seems but the learning curve seems steeper). I also want to > stay with a Java based solution. > > Looking at the example site, I really like what I saw at > http://www.anglonaweb.it/index.jsp or > http://qld.ieaust.org.au/jetspeed/. > > However looking at what comes bundled with Jetspeed I am wondering how > to get there on my limited time and no budget :-). > > Is there examples of semi-complex sites that I can use as a canvas to > the site I want to create. Is somebody willing to share their source > code so I can learn from it. > > Thanks in advance > > -- Pascal > > > - > 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 User Account: Timestamps are not entered properly to MySQL tu rbine_user table
I also tested the effect of changing the Date parameter in org.apache.jetspeed.modules.actions.CreateNewUserAndConfirm´s doPerform() method. Default was like follows: Date now = new Date(); JetspeedUser user = JetspeedSecurity.getUserInstance(); user.setUserName( username ); user.setCreateDate(now); user.setLastLogin(new Date(0)); user.setFirstName( data.getParameters().getString("firstname") ); user.setLastName( data.getParameters().getString("lastname") ); user.setEmail( data.getParameters().getString("email") ); createUser(user, data); I changed it to: Date now = new Date(0); but now, when I added new user, the LAST_LOGIN entry in MYSQL´s user_turbine table changed to 00 from 1970010201. No other changes. Why the user.setCreateDate(now) affected the LAST_LOGIN field? What´s the purpose of user.setLastLogin() then?!? Secondly... The "new user" html-form in the portal seems to call for this class as it´s action, but the createUser() method is empty. Where the creation is actually handled? I´m lost. Thanks for all comments. Risto Kärkkäinen -Ursprüngliche Nachricht- Von: Kaerkkaeinen, Risto Juhani Gesendet: Monday, July 28, 2003 4:01 PM An: [EMAIL PROTECTED] Betreff: New User Account: Timestamps are not entered properly to MySQL tu rbine_user table Hi! While trying to add new user via Jetspeed based portal, the new record is added to MYSQL´s turbine_user table so that the MODIFIED timestamp is just fine as the current time, but CREATED and PASSWORD_CHANGED are a set of zeros and LAST_LOGIN is set to default (the year 1970 etc.). LAST_LOGIN and PASSWORD_CHANGED become correct after the related actions, but CREATED is stuck to zeros. Otherwise the portal seems to be working. I´m using jetspeed-1.4-b4 and mysql-3.23.57-win. The driver is mysql-connector-java-3.1.0-alpha. The DB has been build with the provited sql scripts and the security-schema.xml shows all the earlier fields as similar kind TIMESTAMP. Earlier version of the project was using hypersonic DB and then the MODIFIED and CREATED seemed to be set permanently to NULL. The LAST_LOGIN was working as in the current version with MySQL. The PW_CHANGED field didn´t exist in that version of Jetspeed. The nightly build from 17.7.2003 didn´t help and neither did testing this with only the "default" Jetspeed portal and MySQL. Same problems accure. I was also unable to find any similar problems on the mailing lists or FAQs. Only somehow related comment I found, was at the Apache Bug Database by Mark Orciuch. He wrote: "[FIX] Last login timestamp is not recorded - When the user is originally created last login is initialized but never changes thereafter. I confirmed this problem all the way back to 1.4b1." Any idea what is causing these timestamp variations? Why I´m getting only one field working and the others not? It would be nice to get the timestamps working properly. All help greatly appreciated! Thanks, Risto Kärkkäinen - 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: Re[2]: JSR-168 Comments & Dispatching to portlets
Hi Endre, Well I'm happy to see I'm not the only one with this concern. I was beginning to think that nobody had this problem except me :) At 11:54 AM 7/29/2003 +0200, you wrote: My problem is that is seems impossible to do both of: a) Have a Portal implemented on top of a standard Servlet Container b) Run multiple Portlet Applications, preferrably in a standard Portlet Container, preferrably -the same- container as the Portal is running in. .. and be able to, in a standard way, to communicate between the portal and the portlets. Yes b) is exactly my problem too. I thought a lot about it and it would be possible to develop a "sub portlet container" within the portal, using a custom built portlet container (but that would imply also have to develop a sub-servlet container, with everything that includes such as classloaders, deployment descriptor handling, dispatching, etc). This solution is interesting because it guarantees complete control over the process and *no* vendor lock-in, but it's a bit of a shame because you are no longer using all the tools that are available for the top-level portlet container. So in effect you'd have this : Portlet / Servlet Container --- Portal --- Sub-Portlet / Servlet Container This would be heavy but optimal in terms of performance. In a way this is very close to how Jetspeed currently works, as Jetspeed is a Web application in a servlet container, and defines it's own "sub" portlet container. In my work, I've designed a portal that uses cross context dispatching to dispatch to standard servlets, and although it works quite well, it is not as flexible as the interfaces that the JSR 168 proposes. This is why I was hoping (and unfortunately I got involved to late to be a real part of the JSR process) that they would address this issue, as it seemed critical to me. From what I understand of my discussion in this mailing list, Pluto does something in between : it adds within the portlet a proxy servlet that allows dispatching to the portlets. This way the system I have been using with cross-context dispatching could be adapted, but it's still not as efficient as having a portal/portlet full-blown API. Maybe this is the subject for a new JSR ? Or maybe in this project (Apache Jetspeed) we could develop what we need and then propose this as a reference implementation and submit it as a JSR (maybe that way things would move faster ?). Seeing how projects such as Xerces and Xalan got accepted throughout the whole commercial world it would seem like Apache is in a position to "impose" defacto standards. One way of solving it is apparently using WSRP as the "glue" between the portlet and portal. Yes but at what cost. Serializing all objects through XML and sending them through sockets that are being opened / closed all the time is very expensive in terms of performance. To me, this seems some a kind of vendor lock-in scheme: you buy the Servlet Engine from us, and wow, it also have a Portal in there, effeciently doing proprietary communications with the Portlets. You are suddenly (as it is already) locked to both the Servlet Engine -and- the Portal (application). My guess here is that it's indeed a very political issue. All the current commercial portal vendors involved in JSR-168 could only agree on the most common and minimal specifications, and they didn't want to have too much standardized or they would loose their commercial edge. It might not be the case, but as this process has been entirely closed (even for me, and I am part of the JCP but only as community member !), I can only speculate as to what went on in the expert group. I would have loved a spec where the Portal was the Container, and had to be able to host Portlets within it. This way, one could buy the Servlet Container from Oracle, use JetSpeed as the Portal, and buy Portlets from CompanyA, B and C, plugging them in / installing like nice little applications in a normal OS. Ok, again I agree. Users of portals should be free to migrate from one system to another, without vendor lock-in. After all the J2EE specs exist as Sun puts it : "for vendors to compete on implementation, and agree on standards". This is a nice vision but reality is more like : "vendors always compete on anything, Jakarta standardises". Now enough with my whining, I'll start a quick proposition here : this is what I would have loved to see in JSR-168 : 1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ? Basically be able to do something like this : Context context = getInitialContext(); PortletRepository portletRepository = (PortletRepository) context.lookup("PortletRepository"); // list of portlet example : ArrayList portletList = portletRepository.getPortletList(); Portlet myPortlet = portletRepository.getPortlet("myPortlet"); 2. Direct dispat
Re: Re[2]: JSR-168 Comments
On Wed, 23 Jul 2003, Serge Huber wrote: | 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. I so hugely "agree with your problems" here. The spec is -very- confusing on how to bind together the actual portal application (the one that draws the windows and handles the user comms) and the portlet container. It states very hard that it "only defineds the contract between the portlet and the container". But how interesting is that, if it is impossible to actually -make a PORTAL- using these Portlets? My problem is that is seems impossible to do both of: a) Have a Portal implemented on top of a standard Servlet Container b) Run multiple Portlet Applications, preferrably in a standard Portlet Container, preferrably -the same- container as the Portal is running in. .. and be able to, in a standard way, to communicate between the portal and the portlets. One way of solving it is apparently using WSRP as the "glue" between the portlet and portal. To me, this seems some a kind of vendor lock-in scheme: you buy the Servlet Engine from us, and wow, it also have a Portal in there, effeciently doing proprietary communications with the Portlets. You are suddenly (as it is already) locked to both the Servlet Engine -and- the Portal (application). I would have loved a spec where the Portal was the Container, and had to be able to host Portlets within it. This way, one could buy the Servlet Container from Oracle, use JetSpeed as the Portal, and buy Portlets from CompanyA, B and C, plugging them in / installing like nice little applications in a normal OS. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Beyond the tutorial and the default jetspeed site
Pascal I could show you my sites...(still in development..so they are no on line.) Contact me and settle a way you can see them. I'll put them online for you. If you like them I'll give you the code... Good luck. Ramiro - Original Message - From: "Pascal DeMilly" <[EMAIL PROTECTED]> To: "Jetspeed Users List" <[EMAIL PROTECTED]> Sent: Monday, July 28, 2003 6:38 PM Subject: Beyond the tutorial and the default jetspeed site > Hi, > > I am volunteering for a non profit organization (my daugther's indian > princess nation) to redesign their website. > > I have looked at all sort of different way of developing it and I have > come to the conclusion that I would like a portal of sort to be the main > page and have people manage the pages directly from the web site. I also > really like the idea of portlets and the user/group/role model. It seems > so natural. > > I am in the process of deciding between Jetspeed and Liferay. (more > complete it seems but the learning curve seems steeper). I also want to > stay with a Java based solution. > > Looking at the example site, I really like what I saw at > http://www.anglonaweb.it/index.jsp or > http://qld.ieaust.org.au/jetspeed/. > > However looking at what comes bundled with Jetspeed I am wondering how > to get there on my limited time and no budget :-). > > Is there examples of semi-complex sites that I can use as a canvas to > the site I want to create. Is somebody willing to share their source > code so I can learn from it. > > Thanks in advance > > -- Pascal > > > - > 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: Distributing pdfs securely with jetspeed / slide integration
Hi, I'm trying to integrate Jetspeed with slide as well, but so far I'm not succesful with that. I think I'll give it one more try, but then I'll look for a other sulotion, unless somebody can help you and me. Greetings Bob. http://www.beheervisie.nl/disclaimer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CHTML and PDA support
Hi, I'm a student in computer engineering at Parma University, in Italy. For my degree thesis I've adapted Jetspeed (1.4b4) to CHTML and PDA navigation. My project is nearly complete, if you are interested I can donate all my work (and a report that describes all the things I've done). Regards, Marco Mari. __ Partecipa al concorso Tiscali "collegati e vinci", il primo premio e' un viaggio per 2 persone a Zanzibar! http://point.tiscali.it/numerounico/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Distributing pdfs securely with jetspeed / slide integration
Hi there, I'm kinda new to jetspeed and was wondering if there is a simple way to distribute binary files like pdfs (e.g. financial reports) in a secure way. I was thinking about converting the reports into html and use the HTML portlet (placing the html under web-inf), but we need the pdfs too. In addition, in the long run we probably would like to try to integrate with slide - does anyone have experience with this? Is there any documentation available about this at all? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]