You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Randy Watler <wa...@wispertel.net> on 2005/02/02 22:23:44 UTC
[J2] New PAM/Deployer
I have committed a new PAM/deployer implementation that uses the
deploy-tool component to infuse portlet application war files for J2.
This is being done in an attempt to simplify the deployment process and
make it more reliable. Please bear with me on this change... I need
feedback from all of you on how the new approach fairs in your environment.
This implementation, (WarInfusionPAM), eliminates the requirement to
have the Tomcat manager web application in place and all of the
associated configuration options. Instead, this PAM places WAR files,
(or expanded webapp directories and context.xml file sin the case of
Tomcat4), in the container target webapps directory. The assumption is
that the container will support "auto", "live" or "hot" deployment of
some sort. When the portlet application webapp is loaded, it uses the
JetspeedContainerServlet.init() invocation to register the portlet
application in the webapp with the PAM implementation. Hopefully, there
will no longer be a need to specialize deployment implementations per
container.
I have left the preexisting deployer option in place,
(ApplicationServerPAM), so you should be able to roll back the PAM
implementation if you run into problems. You will need to comment out
the WarInfusionPAM bean and uncomment the ApplicationServerPAM and
TomcatManager bean entries.
There is one option that can be set in the spring configuration of
WarInfusionPAM to control whether the PAM interacts with the webapps
directory using expanded webapps directories or with war files. By
default, it uses expanded webapps if a context.xml file is found in the
webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the boolean
field value in jetspeed-spring.xml forces the selected mode.
At the moment, there is a problem with undeploy/redeploy on Windows
platforms. I believe this is due to file read locks on the WEB-INF/lib
jar files, possibly others. I am currently working on a solution and/or
workaround for this problem.
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Roger Ruttimann <ro...@apache.org>.
Thanks Randy that fixed the issue.
What I had to do is the following:
--> put my application context file into the webapps/META-INF directory
and just name it context.xml (and not application.xml)
--> make sure that any copies of the context file )application.xml) were
removed from the conf/catalina/localhost directory before deploying the app
Roger
Randy Watler wrote:
> Roger,
>
> Can/do you have a context.xml file packaged in the webapp in
> /META-INF? See security. I changed the name from tomcat-context.xml to
> context.xml as expected by Tomcat.
>
> Randy
>
> Roger Ruttimann wrote:
>
>> Thanks for helping me. I'm in the middle of organizing a release (not
>> including the portal) ....
>>
>> I use Linux, fresh deploy on Tomcat 5.0.28
>> I have just security and my application in the deploy directory. My
>> application has a context file in the conf/catalina/localhost directory.
>> Security gets deployed fine but my app gets just copied into the
>> webapp directory.
>>
>> It isn't killing me :-() but I just like to resolve the issue....
>>
>> I'll do a fresh deploy (delete the current catalina.log) and send you
>> the error message.
>>
>> Thanks again for looking at it.
>>
>> Roger
>>
>> Randy Watler wrote:
>>
>>> Roger...
>>>
>>> Windows? Fresh deploy after quickStart and cleaning webapps, or a
>>> redeploy? Can you grab the output from catalina.out and/or
>>> jetspeed/logs/deployment.log and forward it?
>>>
>>> Thanks Roger! If this is killing you, try reconfiguring to use the
>>> ApplicationServerPAM/TomcatManager in jetspeed-spring.xml
>>>
>>> Randy
>>>
>>> Randy Watler wrote:
>>>
>>>> Roger,
>>>>
>>>> Security works this way already... so it might be somethign else.
>>>> What tomcat are you using?
>>>>
>>>> Randy
>>>>
>>>> Roger Ruttimann wrote:
>>>>
>>>>> Randy,
>>>>> I have a PA in a war file and a context file. As you described
>>>>> below a war file with a context file won't be expanded. I changed
>>>>> the options in the assembly file but with no luck.
>>>>> What do I have to do so that I can use the WarInfusionPAM with war
>>>>> (need to be expanded) and a context file?
>>>>>
>>>>> Roger
>>>>>
>>>>> Randy Watler wrote:
>>>>>
>>>>>> I have committed a new PAM/deployer implementation that uses the
>>>>>> deploy-tool component to infuse portlet application war files for
>>>>>> J2. This is being done in an attempt to simplify the deployment
>>>>>> process and make it more reliable. Please bear with me on this
>>>>>> change... I need feedback from all of you on how the new approach
>>>>>> fairs in your environment.
>>>>>>
>>>>>> This implementation, (WarInfusionPAM), eliminates the requirement
>>>>>> to have the Tomcat manager web application in place and all of
>>>>>> the associated configuration options. Instead, this PAM places
>>>>>> WAR files, (or expanded webapp directories and context.xml file
>>>>>> sin the case of Tomcat4), in the container target webapps
>>>>>> directory. The assumption is that the container will support
>>>>>> "auto", "live" or "hot" deployment of some sort. When the portlet
>>>>>> application webapp is loaded, it uses the
>>>>>> JetspeedContainerServlet.init() invocation to register the
>>>>>> portlet application in the webapp with the PAM implementation.
>>>>>> Hopefully, there will no longer be a need to specialize
>>>>>> deployment implementations per container.
>>>>>>
>>>>>> I have left the preexisting deployer option in place,
>>>>>> (ApplicationServerPAM), so you should be able to roll back the
>>>>>> PAM implementation if you run into problems. You will need to
>>>>>> comment out the WarInfusionPAM bean and uncomment the
>>>>>> ApplicationServerPAM and TomcatManager bean entries.
>>>>>>
>>>>>> There is one option that can be set in the spring configuration
>>>>>> of WarInfusionPAM to control whether the PAM interacts with the
>>>>>> webapps directory using expanded webapps directories or with war
>>>>>> files. By default, it uses expanded webapps if a context.xml file
>>>>>> is found in the webapps directory, (i.e. jetspeed and
>>>>>> jetspeed.xml). Setting the boolean field value in
>>>>>> jetspeed-spring.xml forces the selected mode.
>>>>>>
>>>>>> At the moment, there is a problem with undeploy/redeploy on
>>>>>> Windows platforms. I believe this is due to file read locks on
>>>>>> the WEB-INF/lib jar files, possibly others. I am currently
>>>>>> working on a solution and/or workaround for this problem.
>>>>>>
>>>>>> Randy
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> jetspeed-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Randy Watler <wa...@wispertel.net>.
Roger,
Can/do you have a context.xml file packaged in the webapp in /META-INF?
See security. I changed the name from tomcat-context.xml to context.xml
as expected by Tomcat.
Randy
Roger Ruttimann wrote:
> Thanks for helping me. I'm in the middle of organizing a release (not
> including the portal) ....
>
> I use Linux, fresh deploy on Tomcat 5.0.28
> I have just security and my application in the deploy directory. My
> application has a context file in the conf/catalina/localhost directory.
> Security gets deployed fine but my app gets just copied into the
> webapp directory.
>
> It isn't killing me :-() but I just like to resolve the issue....
>
> I'll do a fresh deploy (delete the current catalina.log) and send you
> the error message.
>
> Thanks again for looking at it.
>
> Roger
>
> Randy Watler wrote:
>
>> Roger...
>>
>> Windows? Fresh deploy after quickStart and cleaning webapps, or a
>> redeploy? Can you grab the output from catalina.out and/or
>> jetspeed/logs/deployment.log and forward it?
>>
>> Thanks Roger! If this is killing you, try reconfiguring to use the
>> ApplicationServerPAM/TomcatManager in jetspeed-spring.xml
>>
>> Randy
>>
>> Randy Watler wrote:
>>
>>> Roger,
>>>
>>> Security works this way already... so it might be somethign else.
>>> What tomcat are you using?
>>>
>>> Randy
>>>
>>> Roger Ruttimann wrote:
>>>
>>>> Randy,
>>>> I have a PA in a war file and a context file. As you described
>>>> below a war file with a context file won't be expanded. I changed
>>>> the options in the assembly file but with no luck.
>>>> What do I have to do so that I can use the WarInfusionPAM with war
>>>> (need to be expanded) and a context file?
>>>>
>>>> Roger
>>>>
>>>> Randy Watler wrote:
>>>>
>>>>> I have committed a new PAM/deployer implementation that uses the
>>>>> deploy-tool component to infuse portlet application war files for
>>>>> J2. This is being done in an attempt to simplify the deployment
>>>>> process and make it more reliable. Please bear with me on this
>>>>> change... I need feedback from all of you on how the new approach
>>>>> fairs in your environment.
>>>>>
>>>>> This implementation, (WarInfusionPAM), eliminates the requirement
>>>>> to have the Tomcat manager web application in place and all of the
>>>>> associated configuration options. Instead, this PAM places WAR
>>>>> files, (or expanded webapp directories and context.xml file sin
>>>>> the case of Tomcat4), in the container target webapps directory.
>>>>> The assumption is that the container will support "auto", "live"
>>>>> or "hot" deployment of some sort. When the portlet application
>>>>> webapp is loaded, it uses the JetspeedContainerServlet.init()
>>>>> invocation to register the portlet application in the webapp with
>>>>> the PAM implementation. Hopefully, there will no longer be a need
>>>>> to specialize deployment implementations per container.
>>>>>
>>>>> I have left the preexisting deployer option in place,
>>>>> (ApplicationServerPAM), so you should be able to roll back the PAM
>>>>> implementation if you run into problems. You will need to comment
>>>>> out the WarInfusionPAM bean and uncomment the ApplicationServerPAM
>>>>> and TomcatManager bean entries.
>>>>>
>>>>> There is one option that can be set in the spring configuration of
>>>>> WarInfusionPAM to control whether the PAM interacts with the
>>>>> webapps directory using expanded webapps directories or with war
>>>>> files. By default, it uses expanded webapps if a context.xml file
>>>>> is found in the webapps directory, (i.e. jetspeed and
>>>>> jetspeed.xml). Setting the boolean field value in
>>>>> jetspeed-spring.xml forces the selected mode.
>>>>>
>>>>> At the moment, there is a problem with undeploy/redeploy on
>>>>> Windows platforms. I believe this is due to file read locks on the
>>>>> WEB-INF/lib jar files, possibly others. I am currently working on
>>>>> a solution and/or workaround for this problem.
>>>>>
>>>>> Randy
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Roger Ruttimann <ro...@apache.org>.
Thanks for helping me. I'm in the middle of organizing a release (not
including the portal) ....
I use Linux, fresh deploy on Tomcat 5.0.28
I have just security and my application in the deploy directory. My
application has a context file in the conf/catalina/localhost directory.
Security gets deployed fine but my app gets just copied into the webapp
directory.
It isn't killing me :-() but I just like to resolve the issue....
I'll do a fresh deploy (delete the current catalina.log) and send you
the error message.
Thanks again for looking at it.
Roger
Randy Watler wrote:
> Roger...
>
> Windows? Fresh deploy after quickStart and cleaning webapps, or a
> redeploy? Can you grab the output from catalina.out and/or
> jetspeed/logs/deployment.log and forward it?
>
> Thanks Roger! If this is killing you, try reconfiguring to use the
> ApplicationServerPAM/TomcatManager in jetspeed-spring.xml
>
> Randy
>
> Randy Watler wrote:
>
>> Roger,
>>
>> Security works this way already... so it might be somethign else.
>> What tomcat are you using?
>>
>> Randy
>>
>> Roger Ruttimann wrote:
>>
>>> Randy,
>>> I have a PA in a war file and a context file. As you described below
>>> a war file with a context file won't be expanded. I changed the
>>> options in the assembly file but with no luck.
>>> What do I have to do so that I can use the WarInfusionPAM with war
>>> (need to be expanded) and a context file?
>>>
>>> Roger
>>>
>>> Randy Watler wrote:
>>>
>>>> I have committed a new PAM/deployer implementation that uses the
>>>> deploy-tool component to infuse portlet application war files for
>>>> J2. This is being done in an attempt to simplify the deployment
>>>> process and make it more reliable. Please bear with me on this
>>>> change... I need feedback from all of you on how the new approach
>>>> fairs in your environment.
>>>>
>>>> This implementation, (WarInfusionPAM), eliminates the requirement
>>>> to have the Tomcat manager web application in place and all of the
>>>> associated configuration options. Instead, this PAM places WAR
>>>> files, (or expanded webapp directories and context.xml file sin the
>>>> case of Tomcat4), in the container target webapps directory. The
>>>> assumption is that the container will support "auto", "live" or
>>>> "hot" deployment of some sort. When the portlet application webapp
>>>> is loaded, it uses the JetspeedContainerServlet.init() invocation
>>>> to register the portlet application in the webapp with the PAM
>>>> implementation. Hopefully, there will no longer be a need to
>>>> specialize deployment implementations per container.
>>>>
>>>> I have left the preexisting deployer option in place,
>>>> (ApplicationServerPAM), so you should be able to roll back the PAM
>>>> implementation if you run into problems. You will need to comment
>>>> out the WarInfusionPAM bean and uncomment the ApplicationServerPAM
>>>> and TomcatManager bean entries.
>>>>
>>>> There is one option that can be set in the spring configuration of
>>>> WarInfusionPAM to control whether the PAM interacts with the
>>>> webapps directory using expanded webapps directories or with war
>>>> files. By default, it uses expanded webapps if a context.xml file
>>>> is found in the webapps directory, (i.e. jetspeed and
>>>> jetspeed.xml). Setting the boolean field value in
>>>> jetspeed-spring.xml forces the selected mode.
>>>>
>>>> At the moment, there is a problem with undeploy/redeploy on Windows
>>>> platforms. I believe this is due to file read locks on the
>>>> WEB-INF/lib jar files, possibly others. I am currently working on a
>>>> solution and/or workaround for this problem.
>>>>
>>>> Randy
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Randy Watler <wa...@wispertel.net>.
Roger...
Windows? Fresh deploy after quickStart and cleaning webapps, or a
redeploy? Can you grab the output from catalina.out and/or
jetspeed/logs/deployment.log and forward it?
Thanks Roger! If this is killing you, try reconfiguring to use the
ApplicationServerPAM/TomcatManager in jetspeed-spring.xml
Randy
Randy Watler wrote:
> Roger,
>
> Security works this way already... so it might be somethign else. What
> tomcat are you using?
>
> Randy
>
> Roger Ruttimann wrote:
>
>> Randy,
>> I have a PA in a war file and a context file. As you described below
>> a war file with a context file won't be expanded. I changed the
>> options in the assembly file but with no luck.
>> What do I have to do so that I can use the WarInfusionPAM with war
>> (need to be expanded) and a context file?
>>
>> Roger
>>
>> Randy Watler wrote:
>>
>>> I have committed a new PAM/deployer implementation that uses the
>>> deploy-tool component to infuse portlet application war files for
>>> J2. This is being done in an attempt to simplify the deployment
>>> process and make it more reliable. Please bear with me on this
>>> change... I need feedback from all of you on how the new approach
>>> fairs in your environment.
>>>
>>> This implementation, (WarInfusionPAM), eliminates the requirement to
>>> have the Tomcat manager web application in place and all of the
>>> associated configuration options. Instead, this PAM places WAR
>>> files, (or expanded webapp directories and context.xml file sin the
>>> case of Tomcat4), in the container target webapps directory. The
>>> assumption is that the container will support "auto", "live" or
>>> "hot" deployment of some sort. When the portlet application webapp
>>> is loaded, it uses the JetspeedContainerServlet.init() invocation to
>>> register the portlet application in the webapp with the PAM
>>> implementation. Hopefully, there will no longer be a need to
>>> specialize deployment implementations per container.
>>>
>>> I have left the preexisting deployer option in place,
>>> (ApplicationServerPAM), so you should be able to roll back the PAM
>>> implementation if you run into problems. You will need to comment
>>> out the WarInfusionPAM bean and uncomment the ApplicationServerPAM
>>> and TomcatManager bean entries.
>>>
>>> There is one option that can be set in the spring configuration of
>>> WarInfusionPAM to control whether the PAM interacts with the webapps
>>> directory using expanded webapps directories or with war files. By
>>> default, it uses expanded webapps if a context.xml file is found in
>>> the webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the
>>> boolean field value in jetspeed-spring.xml forces the selected mode.
>>>
>>> At the moment, there is a problem with undeploy/redeploy on Windows
>>> platforms. I believe this is due to file read locks on the
>>> WEB-INF/lib jar files, possibly others. I am currently working on a
>>> solution and/or workaround for this problem.
>>>
>>> Randy
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Randy Watler <wa...@wispertel.net>.
Roger,
Security works this way already... so it might be somethign else. What
tomcat are you using?
Randy
Roger Ruttimann wrote:
> Randy,
> I have a PA in a war file and a context file. As you described below a
> war file with a context file won't be expanded. I changed the options
> in the assembly file but with no luck.
> What do I have to do so that I can use the WarInfusionPAM with war
> (need to be expanded) and a context file?
>
> Roger
>
> Randy Watler wrote:
>
>> I have committed a new PAM/deployer implementation that uses the
>> deploy-tool component to infuse portlet application war files for J2.
>> This is being done in an attempt to simplify the deployment process
>> and make it more reliable. Please bear with me on this change... I
>> need feedback from all of you on how the new approach fairs in your
>> environment.
>>
>> This implementation, (WarInfusionPAM), eliminates the requirement to
>> have the Tomcat manager web application in place and all of the
>> associated configuration options. Instead, this PAM places WAR files,
>> (or expanded webapp directories and context.xml file sin the case of
>> Tomcat4), in the container target webapps directory. The assumption
>> is that the container will support "auto", "live" or "hot" deployment
>> of some sort. When the portlet application webapp is loaded, it uses
>> the JetspeedContainerServlet.init() invocation to register the
>> portlet application in the webapp with the PAM implementation.
>> Hopefully, there will no longer be a need to specialize deployment
>> implementations per container.
>>
>> I have left the preexisting deployer option in place,
>> (ApplicationServerPAM), so you should be able to roll back the PAM
>> implementation if you run into problems. You will need to comment out
>> the WarInfusionPAM bean and uncomment the ApplicationServerPAM and
>> TomcatManager bean entries.
>>
>> There is one option that can be set in the spring configuration of
>> WarInfusionPAM to control whether the PAM interacts with the webapps
>> directory using expanded webapps directories or with war files. By
>> default, it uses expanded webapps if a context.xml file is found in
>> the webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the
>> boolean field value in jetspeed-spring.xml forces the selected mode.
>>
>> At the moment, there is a problem with undeploy/redeploy on Windows
>> platforms. I believe this is due to file read locks on the
>> WEB-INF/lib jar files, possibly others. I am currently working on a
>> solution and/or workaround for this problem.
>>
>> Randy
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Roger Ruttimann <ro...@apache.org>.
Randy,
I have a PA in a war file and a context file. As you described below a
war file with a context file won't be expanded. I changed the options in
the assembly file but with no luck.
What do I have to do so that I can use the WarInfusionPAM with war (need
to be expanded) and a context file?
Roger
Randy Watler wrote:
> I have committed a new PAM/deployer implementation that uses the
> deploy-tool component to infuse portlet application war files for J2.
> This is being done in an attempt to simplify the deployment process
> and make it more reliable. Please bear with me on this change... I
> need feedback from all of you on how the new approach fairs in your
> environment.
>
> This implementation, (WarInfusionPAM), eliminates the requirement to
> have the Tomcat manager web application in place and all of the
> associated configuration options. Instead, this PAM places WAR files,
> (or expanded webapp directories and context.xml file sin the case of
> Tomcat4), in the container target webapps directory. The assumption is
> that the container will support "auto", "live" or "hot" deployment of
> some sort. When the portlet application webapp is loaded, it uses the
> JetspeedContainerServlet.init() invocation to register the portlet
> application in the webapp with the PAM implementation. Hopefully,
> there will no longer be a need to specialize deployment
> implementations per container.
>
> I have left the preexisting deployer option in place,
> (ApplicationServerPAM), so you should be able to roll back the PAM
> implementation if you run into problems. You will need to comment out
> the WarInfusionPAM bean and uncomment the ApplicationServerPAM and
> TomcatManager bean entries.
>
> There is one option that can be set in the spring configuration of
> WarInfusionPAM to control whether the PAM interacts with the webapps
> directory using expanded webapps directories or with war files. By
> default, it uses expanded webapps if a context.xml file is found in
> the webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the
> boolean field value in jetspeed-spring.xml forces the selected mode.
>
> At the moment, there is a problem with undeploy/redeploy on Windows
> platforms. I believe this is due to file read locks on the WEB-INF/lib
> jar files, possibly others. I am currently working on a solution
> and/or workaround for this problem.
>
> Randy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Marcel Dullaart <ma...@gmail.com>.
Hi Randy,
I will not be able to test the new PAM/deployer until sunday night.
I'll inform you about the results of using it on JBoss 4.0.1 then.
Cheers,
Marcel
On Wed, 2 Feb 2005 22:54:15 -0700 (MST), watler@wispertel.net
<wa...@wispertel.net> wrote:
> Scott:
>
> More comments below....
>
> > Scott....
> >
> > Thanks for the feedback. I think I understand the scenario.
>
> I take this back. I am not sure how an app can be both unknown to J2 and
> be the subject of a redeploy event/PAM invocation. Can you elaborate? Is
> there a deployer bug underlying all of this?
>
> > Let me look
> > at it for a bit here... I am wondering why we are in the redeploy() case
> > at all if the application was not previously known to J2? Initially,
> > this seems like a deployer issue to me rather than a PAM shortcoming.
>
> I have added a similar test to this in DeployPortletAppListener. Please
> review and let me know if it is equivalent from your perspective.
> Basically, I am claiming that if someone is invoking *PAM.redeploy(), they
> are expecting an unregister and a subsequent deploy.
>
> >>
> >> reason being that it appears that if an app is deployed in the app
> >> server but not in jetspeed, the app is never registered to jetspeed.
>
> Not really. If you drop in an infused app into the container's webapps
> directory, it will be registered via the JetspeedContainerServlet on init.
> This is one of the advantages of this approach.
>
> >> I added a simple check that if we were trying to redeploy an app that
> >> exists in the container but not in jetspeed we just do a full deploy
> >> instead.
>
> Again, this confuses me, (sorry I am being so dense here). If an app is
> simply in the container's webapps directory, as opposed to the jetspeed
> WEB-INF/deploy directory, how did it ever get involved with the deployer?
>
> >> Does this make sense? I was having issues redploying my custom portal
> >> that uses the "pam" app for the LocaleSelector however, the deployment
> >> of the portal DOES NOT remove the pam app from tomcat, hence the issue
> >> I have outlined above rearing its head.
>
> A previously deployed and registered app left in webapps will be
> registered automatically once by jetspeed on startup and once again by the
> app itself on JetspeedContainerServlet init. I think this situation is
> less than optimal since a race condition could surface between these two
> registration attempts... but I doubt that it is causing you problems at
> this point since it seems rare. Bottom line is that I do not see how the
> pam application left in webapps but not in the jetspeed deploy directory
> is causing problems. Perhaps you have an old version of the pam webapp
> that was not infused in the webapps directory? Still, that does not
> explain the redeploy PAM invocation...
>
> >> Adding the above logic seemed
> >> to fix this for me.
>
> Like I said above, I echoed this modification in the deployer portlet app
> listener. Hopefully, this will be an equivalent patch. I'd still like to
> understand more about your custom deployment so that I can make sure other
> bugs like this are found.
>
> Thanks again Scott... talk to you in the morning. :)
>
> Randy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
This statement nailed!
>A previously deployed and registered app left in webapps will be
>registered automatically once by jetspeed on startup and once again by the
>app itself on JetspeedContainerServlet init. I think this situation is
>less than optimal since a race condition could surface between these two
>registration attempts... but I doubt that it is causing you problems at
>this point since it seems rare. Bottom line is that I do not see how the
>pam application left in webapps but not in the jetspeed deploy directory
>is causing problems. Perhaps you have an old version of the pam webapp
>that was not infused in the webapps directory? Still, that does not
>explain the redeploy PAM invocation...
>
The app in question was deployed prior to the new portlet
self-registration logic you added to the container servlet hence it
never tried to register itself. Thanks for your insight Randy.
watler@wispertel.net wrote:
>Scott:
>
>More comments below....
>
>
>
>>Scott....
>>
>>Thanks for the feedback. I think I understand the scenario.
>>
>>
>
>I take this back. I am not sure how an app can be both unknown to J2 and
>be the subject of a redeploy event/PAM invocation. Can you elaborate? Is
>there a deployer bug underlying all of this?
>
>
>
>>Let me look
>>at it for a bit here... I am wondering why we are in the redeploy() case
>>at all if the application was not previously known to J2? Initially,
>>this seems like a deployer issue to me rather than a PAM shortcoming.
>>
>>
>
>I have added a similar test to this in DeployPortletAppListener. Please
>review and let me know if it is equivalent from your perspective.
>Basically, I am claiming that if someone is invoking *PAM.redeploy(), they
>are expecting an unregister and a subsequent deploy.
>
>
>
>>>reason being that it appears that if an app is deployed in the app
>>>server but not in jetspeed, the app is never registered to jetspeed.
>>>
>>>
>
>Not really. If you drop in an infused app into the container's webapps
>directory, it will be registered via the JetspeedContainerServlet on init.
>This is one of the advantages of this approach.
>
>
>
>>>I added a simple check that if we were trying to redeploy an app that
>>>exists in the container but not in jetspeed we just do a full deploy
>>>instead.
>>>
>>>
>
>Again, this confuses me, (sorry I am being so dense here). If an app is
>simply in the container's webapps directory, as opposed to the jetspeed
>WEB-INF/deploy directory, how did it ever get involved with the deployer?
>
>
>
>>>Does this make sense? I was having issues redploying my custom portal
>>>that uses the "pam" app for the LocaleSelector however, the deployment
>>>of the portal DOES NOT remove the pam app from tomcat, hence the issue
>>>I have outlined above rearing its head.
>>>
>>>
>
>A previously deployed and registered app left in webapps will be
>registered automatically once by jetspeed on startup and once again by the
>app itself on JetspeedContainerServlet init. I think this situation is
>less than optimal since a race condition could surface between these two
>registration attempts... but I doubt that it is causing you problems at
>this point since it seems rare. Bottom line is that I do not see how the
>pam application left in webapps but not in the jetspeed deploy directory
>is causing problems. Perhaps you have an old version of the pam webapp
>that was not infused in the webapps directory? Still, that does not
>explain the redeploy PAM invocation...
>
>
>
>>> Adding the above logic seemed
>>>to fix this for me.
>>>
>>>
>
>Like I said above, I echoed this modification in the deployer portlet app
>listener. Hopefully, this will be an equivalent patch. I'd still like to
>understand more about your custom deployment so that I can make sure other
>bugs like this are found.
>
>Thanks again Scott... talk to you in the morning. :)
>
>Randy
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
>
>
--
"Great minds discuss ideas. Average minds discuss events. Small minds discuss people." - Admiral Hyman Rickover
*******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEdit, Website Content Management *
* <http://www.openedit.org> *
*******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by wa...@wispertel.net.
Scott:
More comments below....
> Scott....
>
> Thanks for the feedback. I think I understand the scenario.
I take this back. I am not sure how an app can be both unknown to J2 and
be the subject of a redeploy event/PAM invocation. Can you elaborate? Is
there a deployer bug underlying all of this?
> Let me look
> at it for a bit here... I am wondering why we are in the redeploy() case
> at all if the application was not previously known to J2? Initially,
> this seems like a deployer issue to me rather than a PAM shortcoming.
I have added a similar test to this in DeployPortletAppListener. Please
review and let me know if it is equivalent from your perspective.
Basically, I am claiming that if someone is invoking *PAM.redeploy(), they
are expecting an unregister and a subsequent deploy.
>>
>> reason being that it appears that if an app is deployed in the app
>> server but not in jetspeed, the app is never registered to jetspeed.
Not really. If you drop in an infused app into the container's webapps
directory, it will be registered via the JetspeedContainerServlet on init.
This is one of the advantages of this approach.
>> I added a simple check that if we were trying to redeploy an app that
>> exists in the container but not in jetspeed we just do a full deploy
>> instead.
Again, this confuses me, (sorry I am being so dense here). If an app is
simply in the container's webapps directory, as opposed to the jetspeed
WEB-INF/deploy directory, how did it ever get involved with the deployer?
>> Does this make sense? I was having issues redploying my custom portal
>> that uses the "pam" app for the LocaleSelector however, the deployment
>> of the portal DOES NOT remove the pam app from tomcat, hence the issue
>> I have outlined above rearing its head.
A previously deployed and registered app left in webapps will be
registered automatically once by jetspeed on startup and once again by the
app itself on JetspeedContainerServlet init. I think this situation is
less than optimal since a race condition could surface between these two
registration attempts... but I doubt that it is causing you problems at
this point since it seems rare. Bottom line is that I do not see how the
pam application left in webapps but not in the jetspeed deploy directory
is causing problems. Perhaps you have an old version of the pam webapp
that was not infused in the webapps directory? Still, that does not
explain the redeploy PAM invocation...
>> Adding the above logic seemed
>> to fix this for me.
Like I said above, I echoed this modification in the deployer portlet app
listener. Hopefully, this will be an equivalent patch. I'd still like to
understand more about your custom deployment so that I can make sure other
bugs like this are found.
Thanks again Scott... talk to you in the morning. :)
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by Randy Watler <wa...@wispertel.net>.
Scott....
Thanks for the feedback. I think I understand the scenario. Let me look
at it for a bit here... I am wondering why we are in the redeploy() case
at all if the application was not previously known to J2? Initially,
this seems like a deployer issue to me rather than a PAM shortcoming.
Randy
Scott T. Weaver wrote:
> Seems to be working for me. However, I had to modify the redploy()
> method in FilSystemPAM as such:
>
> // It might be the case were things have become
> unsynchronized and the target app for redploy
> // actully needs the full deploy treatment. if
> (registry.namedPortletApplicationExists(paWar.getPortletApplicationName()))
>
> {
> doUnregister(paWar.getPortletApplicationName(), false);
> String paName = paWar.getPortletApplicationName();
> DirectoryHelper deployedDir = new DirectoryHelper(new
> File(webAppsDir + "/" + paName));
> PortletApplicationWar existingWar = new
> PortletApplicationWar(deployedDir, paName, "/" + paName);
>
> existingWar.removeWar();
> existingWar.close();
> sysDeploy(paWar, DEPLOY_WAR);
> }
> else
> {
> deploy(paWar);
> }
>
> reason being that it appears that if an app is deployed in the app
> server but not in jetspeed, the app is never registered to jetspeed.
> I added a simple check that if we were trying to redeploy an app that
> exists in the container but not in jetspeed we just do a full deploy
> instead.
>
> Does this make sense? I was having issues redploying my custom portal
> that uses the "pam" app for the LocaleSelector however, the deployment
> of the portal DOES NOT remove the pam app from tomcat, hence the issue
> I have outlined above rearing its head. Adding the above logic seemed
> to fix this for me.
>
> Randy Watler wrote:
>
>> I have committed a new PAM/deployer implementation that uses the
>> deploy-tool component to infuse portlet application war files for J2.
>> This is being done in an attempt to simplify the deployment process
>> and make it more reliable. Please bear with me on this change... I
>> need feedback from all of you on how the new approach fairs in your
>> environment.
>>
>> This implementation, (WarInfusionPAM), eliminates the requirement to
>> have the Tomcat manager web application in place and all of the
>> associated configuration options. Instead, this PAM places WAR files,
>> (or expanded webapp directories and context.xml file sin the case of
>> Tomcat4), in the container target webapps directory. The assumption
>> is that the container will support "auto", "live" or "hot" deployment
>> of some sort. When the portlet application webapp is loaded, it uses
>> the JetspeedContainerServlet.init() invocation to register the
>> portlet application in the webapp with the PAM implementation.
>> Hopefully, there will no longer be a need to specialize deployment
>> implementations per container.
>>
>> I have left the preexisting deployer option in place,
>> (ApplicationServerPAM), so you should be able to roll back the PAM
>> implementation if you run into problems. You will need to comment out
>> the WarInfusionPAM bean and uncomment the ApplicationServerPAM and
>> TomcatManager bean entries.
>>
>> There is one option that can be set in the spring configuration of
>> WarInfusionPAM to control whether the PAM interacts with the webapps
>> directory using expanded webapps directories or with war files. By
>> default, it uses expanded webapps if a context.xml file is found in
>> the webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the
>> boolean field value in jetspeed-spring.xml forces the selected mode.
>>
>> At the moment, there is a problem with undeploy/redeploy on Windows
>> platforms. I believe this is due to file read locks on the
>> WEB-INF/lib jar files, possibly others. I am currently working on a
>> solution and/or workaround for this problem.
>>
>> Randy
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
Seems to be working for me. However, I had to modify the redploy()
method in FilSystemPAM as such:
// It might be the case were things have become
unsynchronized and the target app for redploy
// actully needs the full deploy treatment.
if
(registry.namedPortletApplicationExists(paWar.getPortletApplicationName()))
{
doUnregister(paWar.getPortletApplicationName(), false);
String paName = paWar.getPortletApplicationName();
DirectoryHelper deployedDir = new DirectoryHelper(new
File(webAppsDir + "/" + paName));
PortletApplicationWar existingWar = new
PortletApplicationWar(deployedDir, paName, "/" + paName);
existingWar.removeWar();
existingWar.close();
sysDeploy(paWar, DEPLOY_WAR);
}
else
{
deploy(paWar);
}
reason being that it appears that if an app is deployed in the app
server but not in jetspeed, the app is never registered to jetspeed. I
added a simple check that if we were trying to redeploy an app that
exists in the container but not in jetspeed we just do a full deploy
instead.
Does this make sense? I was having issues redploying my custom portal
that uses the "pam" app for the LocaleSelector however, the deployment
of the portal DOES NOT remove the pam app from tomcat, hence the issue I
have outlined above rearing its head. Adding the above logic seemed to
fix this for me.
Randy Watler wrote:
> I have committed a new PAM/deployer implementation that uses the
> deploy-tool component to infuse portlet application war files for J2.
> This is being done in an attempt to simplify the deployment process
> and make it more reliable. Please bear with me on this change... I
> need feedback from all of you on how the new approach fairs in your
> environment.
>
> This implementation, (WarInfusionPAM), eliminates the requirement to
> have the Tomcat manager web application in place and all of the
> associated configuration options. Instead, this PAM places WAR files,
> (or expanded webapp directories and context.xml file sin the case of
> Tomcat4), in the container target webapps directory. The assumption is
> that the container will support "auto", "live" or "hot" deployment of
> some sort. When the portlet application webapp is loaded, it uses the
> JetspeedContainerServlet.init() invocation to register the portlet
> application in the webapp with the PAM implementation. Hopefully,
> there will no longer be a need to specialize deployment
> implementations per container.
>
> I have left the preexisting deployer option in place,
> (ApplicationServerPAM), so you should be able to roll back the PAM
> implementation if you run into problems. You will need to comment out
> the WarInfusionPAM bean and uncomment the ApplicationServerPAM and
> TomcatManager bean entries.
>
> There is one option that can be set in the spring configuration of
> WarInfusionPAM to control whether the PAM interacts with the webapps
> directory using expanded webapps directories or with war files. By
> default, it uses expanded webapps if a context.xml file is found in
> the webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the
> boolean field value in jetspeed-spring.xml forces the selected mode.
>
> At the moment, there is a problem with undeploy/redeploy on Windows
> platforms. I believe this is due to file read locks on the WEB-INF/lib
> jar files, possibly others. I am currently working on a solution
> and/or workaround for this problem.
>
> Randy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
--
"Great minds discuss ideas. Average minds discuss events. Small minds discuss people." - Admiral Hyman Rickover
*******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEdit, Website Content Management *
* <http://www.openedit.org> *
*******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] New PAM/Deployer
Posted by wa...@wispertel.net.
Dev Team:
> At the moment, there is a problem with undeploy/redeploy on Windows
> platforms. I believe this is due to file read locks on the WEB-INF/lib
> jar files, possibly others. I am currently working on a solution and/or
> workaround for this problem.
Yes, there is a major problem with file locking on windows that is causing
redeploy and undeploy to fail. I suspect that this is due to our portlet
application class loaders referencing jar files in the
webapps/*/WEB-INF/lib directories. This problem is much more severe now
that the new deployer is pushing WAR files instead of overwriting the
portlet application webapps directory.
Thanks for being patient with a new committer struggling mightily in the
bowels of the deployer!
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org