I didn't seem to have a problem even without adding the deployer user/pwd. I am doing this on: SunOS kupala 5.8 Generic_117350-26 sun4u sparc SUNW,Sun-Fire-15000 with JDK 1.4.2x
-----Original Message----- From: Aaron Evans [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 12:15 PM To: Jetspeed Users List Subject: Re: User information access and cross context You're welcome. I'm glad you got it working. If you find anything more about autodeployment, please post back. Also, note that if you rebuild/redeploy your jetspeed portal, the jetspeed.xml will contain the JAAS realm again and it won't work anymore (so you'll need to go and comment it out of there again). -aaron On 9/19/06, Hu, Yiguang <[EMAIL PROTECTED]> wrote: > Thank you so much Aaron for the detailed instruction. It works (on tomcat > 5.5)! I will further explore the impact on the auto-deployment. > Yiguang > > -----Original Message----- > From: Aaron Evans [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 19, 2006 11:23 AM > To: Jetspeed Users List > Subject: Re: User information access and cross context > > Note: my instructions are for tomcat 5.5. > > See comments inline to your questions below. > > Also, when you do all this, there may be issues with jetspeed trying > to invoke tomcat's autodeployment because I'm not sure if it is > authenticating properly. I suggest adding a jetspeed user with a > password that matches your > > org.apache.jetspeed.services.autodeployment.user > org.apache.jetspeed.services.autodeployment.password > > properties and assigning that user the 'admin' and 'manager' roles. > > Even having done all this, I find that when I deploy and updated > custom portlet application, jetspeed properly updates its registry and > copies it out to the webapps directory and the context reloads, but a > lot of the time the updated .war is not automatically expanded and I > have to do so manually. > > On 9/19/06, Hu, Yiguang <[EMAIL PROTECTED]> wrote: > > Thanks Aaron. I have a couple of more questions. > > 1. How to turn on tomcat SSO? > > In server.xml, in your 'Host' element: > > <Host name="localhost" appBase="webapps"> > <!-- Enable tomcat SSO *** --> > <Valve className="org.apache.catalina.authenticator.SingleSignOn" /> > </Host> > > > 2. I copied the following from Jetspeed.xml to conf/server.xml. do I need > > to remove the Real from Jetspeed.xml then? > > <Realm className="org.apache.catalina.realm.JAASRealm" > > appName="Jetspeed" > > > > userClassNames="org.apache.jetspeed.security.impl.UserPrincipalImpl" > > > > roleClassNames="org.apache.jetspeed.security.impl.RolePrincipalImpl" > > useContextClassLoader="false" > > debug="0"/> > > When you add this to server.xml, make sure it is under your 'Engine' > element. So the first child of an element that looks something like > this: > > <Engine name="Catalina" defaultHost="localhost"> > > And yes, comment it out of jetspeed.xml. > > Also, you must move tomcat's default UserDatabaseRealm *out of* your > 'Engine' element (this block): > > <Realm className="org.apache.catalina.realm.UserDatabaseRealm" > resourceName="UserDatabase"/> > > Put it in conf/localhost/Catalina/manager.xml as the first child of > the 'Context' element. > > Under that 'Context' element there should also be a block like: > > <!-- Link to the user database we will get roles from --> > <ResourceLink name="users" global="UserDatabase" > type="org.apache.catalina.UserDatabase"/> > > If it's not there, then add it because tomcat's UserDatabaseRealm requires it. > > > 3. Does this make userPrincipal available in all context request or > > session? Or where should I get them? > > request.getUserPrincipal and request.isUserInRole from the servlet API > will work in any application context deployed. > > In addition, if you want session data from your portlet session (in > APPLICATION_SCOPE) to be accessible from the servlet API, then in your > server.xml add the emptySessionPath="true" to your AJP connector: > > <Connector port="8009" protocol="AJP/1.3" emptySessionPath="true"/> > > > > > Thanks > > Yiguang > > I hope I haven't forgotten anything, but I think that's it. I run my > environment in this way and it works pretty well. Let me know if you > run into troubles. > -aaron > > > > > -----Original Message----- > > From: Aaron Evans [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, September 19, 2006 9:24 AM > > To: Jetspeed Users List > > Subject: Re: User information access and cross context > > > > If you are using tomcat, turn on tomcat SSO and move the > > authentication Realm from jetspeed's context.xml > > (conf/Catalina/localhost/jetspeed.xml) to conf/server.xml so it serves > > all contexts. > > > > -aaron > > > > On 9/19/06, Hu, Yiguang <[EMAIL PROTECTED]> wrote: > > > Thanks. So is there a easy way to get the user information from different > > > context? Or is there a place (session is context sensitive too) to save > > > the user information from /Jetspeed (like using filter) and can be > > > accessed from different context? > > > Yiguang > > > -----Original Message----- > > > From: Jacek Wiślicki [mailto:[EMAIL PROTECTED] > > > Sent: Monday, September 18, 2006 6:05 PM > > > To: Jetspeed Users List > > > Subject: Re: User information access and cross context > > > > > > Wiadomosc od Jacek Wiślicki z 2006-09-18 23:57 brzmiala: > > > > > > >> How to access this information from another context ? > > > > JSR-168 isolates HTTPServletRequest and PortletRequest. Only > > > > PortletRequest holds this information (by a specification, > > > > HTTPServletRequest returns null from getUserPrincipal() in portal > > > > environments). On the other hand, PortletRequest are limitted to a > > > > portal context. > > > Please, ignore this. I was thinking of something else... :/ > > > > > > -- > > > pozdrawiam, > > > Jacek Wislicki > > > > > > [EMAIL PROTECTED] > > > http://www.nauka-biznes.org.pl/jetspeed/portal/ > > > tel.: +48 502 408 444 > > > gg: 2540358 > > > skype: jacek_wislicki > > > > > > --------------------------------------------------------------------- > > > 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]
