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 "David H. DeWolf" <dd...@apache.org> on 2005/08/03 14:42:28 UTC
[1.1] Admin Portlets Question
Zheng,
Your PlutoAdmin wiki states:
"This is really a strange problem. I removed castor-0.9.6,
pluto-descriptor-api-<version>.jar and
pluto-descriptor-impl-<version>.jar from
$CATALINA_HOME/webapps/pluto/WEB-INF/lib directory (they are already in
$CATALINA_HOME/shared/lib), and the problem is resolved."
I attempted to resolve this issue and was unable to duplicate with a
clean build. The only jars that I'm seeing that should not belong in
both the testsuite and portal wars are xml-apis and junit. These are
appearing due to secondary dependencies scoping them as compile vs.
provided or test. I'm working to discover how to fix this problem in m2.
Would you please either:
1) Tell me how to duplicate the error of those jars being placed in the
WEB-INF/lib
2) Retest to see if you have some left over remnants from former
versions other than the head revision in svn.
I definately like what you've done with the portlets so far and am
looking forward to you donating them to the ASF. I'm hoping Craig (the
original author of the admin portlets) will weigh in with his thoughts
on them as well.
Thanks,
David
Re: [1.1] Admin Portlets Question
Posted by Zhong ZHENG <he...@gmail.com>.
Hi David,
I think i found the problem.
The 3 JAR files that should not appear in WEB-INF/lib are added because i
modified the pom.xml of pluto-portal subproject. I added the following
dependency entry:
<dependency>
<groupId>org.apache.pluto</groupId>
<artifactId>pluto-deploy</artifactId>
<version>1.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
I thought the deploy JAR should be of compile scope because only pluto
portal admin needs it. But since the deploy JAR itself needs castor and
descriptors (and in compile scope), these JARs are also added to the portal
WAR.
So what should happen is that the deploy JAR is added to the WAR while
castor and descriptors stay in Tomcat's shared/lib. I am not very familiar
with Maven 2, and don't know yet how to tell m2 to do that correctly...
BTW, I noticed the following issue in JIRA:
Admin Portlet fails to add Page -
http://issues.apache.org/jira/browse/PLUTO-107
The new Pluto admin do not update the driver config object currently used
with their changes. A restart is also required for the changes to take
effect. I don't know if you want the admin to support hot deployment or not.
If you want the feature, I will add it.
Regards.
ZHENG Zhong
On 8/3/05, David H. DeWolf <dd...@apache.org> wrote:
>
> Zheng,
>
> Your PlutoAdmin wiki states:
>
> "This is really a strange problem. I removed castor-0.9.6,
> pluto-descriptor-api-<version>.jar and
> pluto-descriptor-impl-<version>.jar from
> $CATALINA_HOME/webapps/pluto/WEB-INF/lib directory (they are already in
> $CATALINA_HOME/shared/lib), and the problem is resolved."
>
> I attempted to resolve this issue and was unable to duplicate with a
> clean build. The only jars that I'm seeing that should not belong in
> both the testsuite and portal wars are xml-apis and junit. These are
> appearing due to secondary dependencies scoping them as compile vs.
> provided or test. I'm working to discover how to fix this problem in m2.
>
> Would you please either:
>
> 1) Tell me how to duplicate the error of those jars being placed in the
> WEB-INF/lib
>
> 2) Retest to see if you have some left over remnants from former
> versions other than the head revision in svn.
>
> I definately like what you've done with the portlets so far and am
> looking forward to you donating them to the ASF. I'm hoping Craig (the
> original author of the admin portlets) will weigh in with his thoughts
> on them as well.
>
> Thanks,
>
> David
>
--
ZHENG Zhong
heavyzheng{aT}gmail{d0t}com
Re: [1.1] Admin Portlets Question
Posted by "David H. DeWolf" <dd...@apache.org>.
Thanks Craig!
CDoremus@hannaford.com wrote:
>
> David,
>
> I'm sorry, but have been busy lately with my job that pays the bills, so
> I have not had time to grok the Admin Portlet App that Zheng produced
> for Pluto 1.1 (or Pluto 1.1, for that matter). But a cursory glance at
> Zheng's work indicates that he has done a good job of extending my code.
I totally understand. That was my excuse for several months :)
> Matter of fact, I was also heading in the direction of using a Command
> pattern to dispatch portlet actions.
>
I'm all for it!
> Right now, when I have the time, I'm trying to concentrate on finishing
> my Pluto 1.0.1 work before moving onto Pluto 1.1. Specifically, I'd like
> to close out PLUTO-92 and get the new command-line deployer
> (org.apache.pluto.driver.deploy.Deploy) to work with the Admin Portlet
> App in Pluto 1.0.1. so all the web.xml elements will be carried over to
> when the new portlet app is deployed. I'd appreciate any help on this
> that Zheng or you could give me on this issue. There appears to be some
> sort of problem with the new Deploy class (specifically its
> updateDescriptors() method) use of the
> AbstractPortletAppDescriptorService
> (FilePortletAppDescriptorServiceImpl) to map portlets in portlet.xml to
> the PortletAppDD class. I imagine that the
> AbstractWebappDescriptorService will have the same problem and I believe
> that the visibility of the Castor mapping files within the webapp
> environment is the culprit. The Deploy class does work on the command
> line, but, as you know, the classloader environment is very different in
> a webapp. I've attached a copy of my latest DeployWarService class where
> I have refactored the processFileUpload() method. As I said, any help is
> appreciated.
Interesting. I'll see if I can find some time in the next few days.
>
> I'm very interested in working on Pluto 1.1 and collaborating with Zheng
> on the Admin Portlets.
Zheng, yes, thank you for all your efforts. It's definately good to see
this community start to branch out a little. Craig, we look forward to
having you back.
But we have a responsibility to provide a solid
> product, since we are a reference implementation and the entry point for
> many developers investigating the Portlet API. Therefore, I think it
> would be a good idea to clear all the bugs and cobwebs out of Pluto
> 1.0.1 before moving onto the next version.
I appreciate your willingness to finish up 1.0.1. I must say that I've
lost some motivation on it and find 1.1 much more exciting. That said,
I hear what you're saying and am also willing to put in the effort to
bring 1.0.1 to a general availability level (though I will recomend that
we don't enhance it - rather just fix bugs).
Off to work on finalizing the 1.0.1-rc4 release . . . :)
David
> /Craig
> ----------------------------------------------------
> Craig Doremus
> Senior J2EE Application Developer
> Hannaford Bros
> ----------------------------------------------------
>
>
>
>
> *"David H. DeWolf" <dd...@apache.org>*
>
> 08/03/2005 08:42 AM
> Please respond to
> pluto-dev@portals.apache.org
>
>
>
> To
> pluto-dev@portals.apache.org
> cc
>
> Subject
> [1.1] Admin Portlets Question
>
>
>
>
>
>
>
>
> Zheng,
>
> Your PlutoAdmin wiki states:
>
> "This is really a strange problem. I removed castor-0.9.6,
> pluto-descriptor-api-<version>.jar and
> pluto-descriptor-impl-<version>.jar from
> $CATALINA_HOME/webapps/pluto/WEB-INF/lib directory (they are already in
> $CATALINA_HOME/shared/lib), and the problem is resolved."
>
> I attempted to resolve this issue and was unable to duplicate with a
> clean build. The only jars that I'm seeing that should not belong in
> both the testsuite and portal wars are xml-apis and junit. These are
> appearing due to secondary dependencies scoping them as compile vs.
> provided or test. I'm working to discover how to fix this problem in m2.
>
> Would you please either:
>
> 1) Tell me how to duplicate the error of those jars being placed in the
> WEB-INF/lib
>
> 2) Retest to see if you have some left over remnants from former
> versions other than the head revision in svn.
>
> I definately like what you've done with the portlets so far and am
> looking forward to you donating them to the ASF. I'm hoping Craig (the
> original author of the admin portlets) will weigh in with his thoughts
> on them as well.
>
> Thanks,
>
> David
>
Re: [1.1] Admin Portlets Question
Posted by CD...@hannaford.com.
David,
I'm sorry, but have been busy lately with my job that pays the bills, so I
have not had time to grok the Admin Portlet App that Zheng produced for
Pluto 1.1 (or Pluto 1.1, for that matter). But a cursory glance at Zheng's
work indicates that he has done a good job of extending my code. Matter of
fact, I was also heading in the direction of using a Command pattern to
dispatch portlet actions.
Right now, when I have the time, I'm trying to concentrate on finishing my
Pluto 1.0.1 work before moving onto Pluto 1.1. Specifically, I'd like to
close out PLUTO-92 and get the new command-line deployer
(org.apache.pluto.driver.deploy.Deploy) to work with the Admin Portlet App
in Pluto 1.0.1. so all the web.xml elements will be carried over to when
the new portlet app is deployed. I'd appreciate any help on this that
Zheng or you could give me on this issue. There appears to be some sort of
problem with the new Deploy class (specifically its updateDescriptors()
method) use of the AbstractPortletAppDescriptorService
(FilePortletAppDescriptorServiceImpl) to map portlets in portlet.xml to
the PortletAppDD class. I imagine that the AbstractWebappDescriptorService
will have the same problem and I believe that the visibility of the Castor
mapping files within the webapp environment is the culprit. The Deploy
class does work on the command line, but, as you know, the classloader
environment is very different in a webapp. I've attached a copy of my
latest DeployWarService class where I have refactored the
processFileUpload() method. As I said, any help is appreciated.
I'm very interested in working on Pluto 1.1 and collaborating with Zheng
on the Admin Portlets. But we have a responsibility to provide a solid
product, since we are a reference implementation and the entry point for
many developers investigating the Portlet API. Therefore, I think it would
be a good idea to clear all the bugs and cobwebs out of Pluto 1.0.1 before
moving onto the next version.
/Craig
----------------------------------------------------
Craig Doremus
Senior J2EE Application Developer
Hannaford Bros
----------------------------------------------------
"David H. DeWolf" <dd...@apache.org>
08/03/2005 08:42 AM
Please respond to
pluto-dev@portals.apache.org
To
pluto-dev@portals.apache.org
cc
Subject
[1.1] Admin Portlets Question
Zheng,
Your PlutoAdmin wiki states:
"This is really a strange problem. I removed castor-0.9.6,
pluto-descriptor-api-<version>.jar and
pluto-descriptor-impl-<version>.jar from
$CATALINA_HOME/webapps/pluto/WEB-INF/lib directory (they are already in
$CATALINA_HOME/shared/lib), and the problem is resolved."
I attempted to resolve this issue and was unable to duplicate with a
clean build. The only jars that I'm seeing that should not belong in
both the testsuite and portal wars are xml-apis and junit. These are
appearing due to secondary dependencies scoping them as compile vs.
provided or test. I'm working to discover how to fix this problem in m2.
Would you please either:
1) Tell me how to duplicate the error of those jars being placed in the
WEB-INF/lib
2) Retest to see if you have some left over remnants from former
versions other than the head revision in svn.
I definately like what you've done with the portlets so far and am
looking forward to you donating them to the ASF. I'm hoping Craig (the
original author of the admin portlets) will weigh in with his thoughts
on them as well.
Thanks,
David