You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2005/09/05 18:19:27 UTC
Re: [Norton AntiSpam] Re: refactoration of Pluto Admin 1.1
Zhong ZHENG wrote:
> BTW, I've already refactoried the admin app by extracting out the
> portal-independent framework and trying to make it easier to use. During
> the refactoration, I referred to the implementation of Struts 1.2.7. Now
> the small portlet framework looks quite like Struts, but is much
> simpler, since lots of Struts features are not necessary to the admin app.
>
> But....the framework does not run well....because of a bug of portlet
> session binding in the container. I posted a mail to the mailing list
> yesterday to report the bug. Last sunday I spent a whole afternoon
> trying to figure that out....but failed.
Zheng,
I'm the creator of the Struts Bridge which I use for several projects using Jetspeed-2
and I never encountered your session binding problem.
But, Jetspeed-2 uses the Pluto 1.0.1-rc4 container and maybe you can test your
session problem against that container?
I know you want this working in Pluto 1.1, but then at least we have a better idea where
to look for the problem.
Ate
>
>
> 2005/9/5, Zhong ZHENG <heavyzheng@gmail.com <ma...@gmail.com>>:
>
> Hi,
>
> I am thinking of separating the pluto admin app into a single
> subproject, like the testsuite, as mentioned earlier. For the
> requirements, there will be no problem for the file upload and war
> deployment functionalities, because they are independent to the
> portal driver. But the ability to update the portal's configuration
> object seems a little bothering to me.
>
> The portal configuration is an object private to the portal webapp.
> Currently it is saved in the portal's servlet context as an
> attribute. So how should the portal expose the operation on the
> config to the admin app?
>
> One way is to separate the portal config API into a single jar file
> (like the descriptors) and put it into tomcat's shared/lib
> directory, to make it shared by all the webapps. But that may have
> some serious problems:
>
> 1) That gives all the webapps the ability to operate the portal's
> configuration object. In fact, only the admin app should have that
> ability, but we cannot prevent other webapps from doing that, if
> some of them really want to do something bad.
>
> 2) Even for the admin app, it needs to use tomcat's cross context
> functionality to retrieve the current configuration object from the
> portal's servlet context. That depends heavily on the servlet
> container's implementation. We have already had an issue about that.
>
> Now I am thinking if we may have an alternate way to perform the
> deployment. Maybe we may ask the portal driver to detect
> automatically the deployed portlet apps, something like how tomcat
> does to deploy webapps. I am not sure if that is feasible...
>
> For the design pattern: if we use the command pattern, we do not
> need to use a portlet framework any more (such as
> portals-bridges/struts or tapestry-portlets). So, what is your
> preference? To implement the admin all by ourselves, or to use an
> existing framework that supports portlets?
>
> I look forward to working with you on the admin. Regards.
>
> ZHENG Zhong
>
>
> 2005/9/5, CDoremus@hannaford.com <ma...@hannaford.com> <
> CDoremus@hannaford.com <ma...@hannaford.com>>:
>
>
> Hi Zheng,
>
> I'd like to collaborate on the Admin portlets for Pluto 1.1 too.
> I like the command pattern that you used in your first try at
> admin portlets for Pluto 1.1. The only change I'd like is too
> add role-based security by checking security-role-ref in
> portlet.xml and doing a PortletRequest.isUserInRole() check
> before control is passed to the action.
>
> Here are my minimum requirements for admin portlets:
> 1. File upload and war deployment into webapps directory.
> a. Modify web.xml and Pluto configuration files as
> necessary
> 2. Ability to undeploy portlets by removing configurations and
> deleting deployments.
> 3. Ability to configure and change layout of a portlet application.
>
> We should also plan for the administration of authenticated
> users and user information attributes (PLT.17) in the admin
> console.
> /Craig
>
>
>
> *Zhong ZHENG <heavyzheng@gmail.com <ma...@gmail.com>>*
>
> 09/03/2005 01:12 PM
> Please respond to
> pluto-dev@portals.apache.org <ma...@portals.apache.org>
>
>
>
> To
> pluto-dev mailing list <pluto-dev@portals.apache.org
> <ma...@portals.apache.org>>
> cc
>
> Subject
> refactoration of Pluto Admin 1.1
>
>
>
>
>
>
>
>
>
> Hi there,
>
> Since you have made some modifications on the Pluto Driver
> subproject, the previous Pluto Admin did not work any more. So I
> am thinking of refactoring the admin app:
>
> 1. Provide a pluto-independent Struts-like MVC framework for
> portlet. I don't know whether Struts supports portlet currently,
> but I think it not necessary to require Struts to run the admin.
> I can write a very simple yet not full-featured MVC framework
> based on which I may facilitate the admin development.
>
> 2. Separate the pluto portal driver dependent codes into a
> single package. Since Pluto 1.1 is still on development, there
> will probably be midifications on the portal driver. So
> separating the dependent code will make it easier to meet the
> future need.
>
> I'd like to collaborate with you on the admin app. So what you
> think about the refactoring plan?
>
> Regards.
>
> --
>
> ZHENG Zhong
> heavyzheng {AT} gmail {D0T} com_
> __http://heavyz.sourceforge.net_ <http://heavyz.sourceforge.net/>
>
>
>
>
> --
>
> ZHENG Zhong
>
> 1 Avenue Alphand
> 75116 Paris, France
> +33 6 76 80 45 90
>
> heavyzheng {AT} gmail {D0T} com
>
> http://heavyz.sourceforge.net
> http://heavyz.blogspot.com <http://heavyz.blogspot.com>
> http://spaces.msn.com/members/zhengzhong
>
>
>
>
>
> --
>
> ZHENG Zhong
>
> 1 Avenue Alphand
> 75116 Paris, France
> +33 6 76 80 45 90
>
> heavyzheng {AT} gmail {D0T} com
>
> http://heavyz.sourceforge.net
> http://heavyz.blogspot.com
> http://spaces.msn.com/members/zhengzhong
>
>
Re: [Norton AntiSpam] Re: refactoration of Pluto Admin 1.1
Posted by Zhong ZHENG <he...@gmail.com>.
Hi Ate,
Thank you very much for the advice. I've checked out the source code of
portals-bridges/struts, and will take a look at it in the following days. In
fact, the session binding problem in Pluto 1.1 comes from the cross context:
in the processAction() method, portlet session is bound to the portal's
servlet context, while in the render() method, portlet session is bound to
the portlet app's servlet context.
I will check that issue on Pluto 1.0.1.
Regards.
2005/9/5, Ate Douma <at...@douma.nu>:
>
> Zhong ZHENG wrote:
> > BTW, I've already refactoried the admin app by extracting out the
> > portal-independent framework and trying to make it easier to use. During
> > the refactoration, I referred to the implementation of Struts 1.2.7. Now
> > the small portlet framework looks quite like Struts, but is much
> > simpler, since lots of Struts features are not necessary to the admin
> app.
> >
> > But....the framework does not run well....because of a bug of portlet
> > session binding in the container. I posted a mail to the mailing list
> > yesterday to report the bug. Last sunday I spent a whole afternoon
> > trying to figure that out....but failed.
> Zheng,
>
> I'm the creator of the Struts Bridge which I use for several projects
> using Jetspeed-2
> and I never encountered your session binding problem.
> But, Jetspeed-2 uses the Pluto 1.0.1-rc4 container and maybe you can test
> your
> session problem against that container?
> I know you want this working in Pluto 1.1, but then at least we have a
> better idea where
> to look for the problem.
>
> Ate
>
>
--
ZHENG Zhong
1 Avenue Alphand
75116 Paris, France
+33 6 76 80 45 90
heavyzheng {AT} gmail {D0T} com
http://heavyz.sourceforge.net
http://heavyz.blogspot.com
http://spaces.msn.com/members/zhengzhong