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]


Reply via email to