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 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
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, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
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 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>*
09/03/2005 01:12 PM
Please respond to
pluto-dev@portals.apache.org <mailto:pluto-dev@portals.apache.org>
To
pluto-dev mailing list <pluto-dev@portals.apache.org
<mailto:pluto-dev@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
