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 Ate Douma <at...@douma.nu> on 2005/03/17 03:01:59 UTC
[J2] JS2-210: deployment refactoring branch updated with JBoss 3.2.7
support
Dear all,
Today I committed a big update for the deployment refactoring branch.
I've added the following features:
- Moved Deployment interfaces and related components to the jetspeed-api subproject,
as well as the ApplicationServerManager interface and its new Result component.
This allows access to these services for portlet applications.
- Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
It allows remote control of portlet applications and the registry with the
following functions: start, stop, reload, list, undeploy and deploy (upload).
I also created a new JetspeedConsole CLI using the ManagerServlet which works
well, but which I haven't committed yet because I need to clean it up first.
- The ManagerServlet depends for several of its tasks on a ApplicationServerManager
implementation. With the TomcatManager all of its features can now be used.
The implementations of the JBossManager and WeblogicManager are still empty
shells though and probably someone else with more knowledge of these
application servers should take a look at those.
- A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
naming of these is getting confusing.
This new portlet though provides (almost) the same functionality as the ManagerServlet.
Its lists all registered portlet applications in a table with action links for:
start, stop, undeploy and delete (unregister from the registry).
It also shows if an portlet application actually is running or not.
Because I wanted to provide this functionality in table layout, I decided to not
implement it in the already existing PAM (PortletApplicationBrowser) portlet which
presents the portlet applications and its portlets in a tree.
For now, this portlet is accessible from the Administrative folder (pam2.psml).
We probably need to discuss though if and/or how these two portlets should be
integrated.
This portlet also depends on a ApplicationServerManager. If none is configured (like
for JBoss) it will still show if a portlet application is running or not and allow
to delete (unregister) an portlet application.
- J2 on JBoss
Because one of the premises of this deployment refactoring was that it should make
it easier to deploy J2 on other application servers as well, I decided to prove this
and got my feet wet trying it out for JBoss (3.2.7).
With success!
I wrote a list of things to do to get this branch running on JBoss in a comment to
JS2-210: http://issues.apache.org/jira/browse/JS2-210#action_60983
Once this branch is merged into the head branch I'll provide proper instructions on
the website or wiki (although I'm not much of a wiki jockey yet).
I also tested with JBoss 4.0.1sp1 which looks to be working just as well. I didn't
have time to test that one a lot though.
Of course, there were quite a few problems to solve, but *none* were related to
(re)deployment. And many of the problems as indicated by the wiki pages for JBoss
deployment of the M1 or current head version of J2 seems to be resolved :-)
The following issues are important though:
- commons-logging and Log4J dependencies
JBoss provides commons-logging and Log4J, as well as the Log4J configuration from
a shared classloader to all the applications.
This really is conflicting with the way we use them in Jetspeed-2 under Tomcat
(although Tomcat 5.5 also is giving more headaches with this now).
One simply cannot have the commons-logging and log4j jars anymore in WEB-INF/lib
because it definitely is giving classloader problems under JBoss.
Furthermore, our own log4j configuration conflicts with the global configuration
provided with JBoss. If you initialize a new log4j configuration from a web application
like we do with J2, you end up closing and detaching existing loggers and appenders
and rerouting them into the J2 logging. Likewise, if some other web application
deployed after J2 does the same, the J2 logging might get closed and detached and
rerouted into this other web application its logging.
Anyway you look at it, dynamic log4j configuration is very problematic under JBoss.
And, while scanning the internet for a way around this, I found out many others
encountered the same problem and not only on JBoss but other application servers
as well.
After a long investigation of the concrete implementations of commons-logging and
log4j though I've come up with a solution which I called IsolatedLog4JLogger.
As I put a lot of javadoc into that class I'm not going to reproduce it here.
But, I invite everyone to have a look at it. Its currently only committed to the
deployment_refactoring branch under portal/src/java/org/apache/jetspeed/util.
Whats left is a future solution of the packaging of these jars. Having to remove
them after a war is build is quite dumb and easy to forget as well.
- JBoss UniversalClassLoader
I don't think I have to explain anyone interested in JBoss what this means.
Anyway, with a few tweaks to the JBoss configurations I managed to get it working
"properly" ;-) Other solutions are also possible (like providing a jboss-web.xml
in *all* portlet application war files).
- JAAS authentication
This was quite simple to implement but in the end turned out to be working only
half way.
The authentication itself is easy to do by configuring our DefaultLoginModule in
the JBoss login-config.xml.
But, the propagation of the Subject principals to JBoss is quite a problem.
Simply put: none is.
JBoss requires the Subject to be configured with a java.security.acl.Group named
"Roles" containing all the "Role" principals. As our security principals don't
implement java.securitry.acl.Group (yet) none is recognized by JBoss.
After some further investigation, it turns out other application servers
might require a Group implementation as well. So, we might need to refactor our
security principals a bit to get this to work.
As we don't actually *use* request.isUserInRole(roleName) in our demo portlets
yet (except for the security demo portlet), the default J2 deployment actually
works quite good.
Well, I'd be very interested in others experiences with this branch (the latest and
from before my last changes). I know some are trying it out on different platforms as
well.
Seth Ford is still unsuccessful with getting M1 running on WebSpere. Seth, I can't
really help you out with WebSphere but I really would suggest you try it out with the
latest from this branch (check the JBoss deployment instructions as reference).
I think that with a few success stories of other deployments on different platforms
of this branch it might be almost ready for merging with the head.
Deleting (unregistering) of portlet applications is now provided for, as well as
start, stop, (remote) deployment and undeployment for Tomcat.
If anyone has some requirements which should be fixed/implemented on this branch
before considering it ready for merge with the head (besides more proof it works
too on other platforms), please let me know. If possible and reasonable, I'll try
to provide for it.
Regards, Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] JS2-210: deployment refactoring branch updated with JBoss
3.2.7 support
Posted by Ate Douma <at...@douma.nu>.
Seth Ford wrote:
> Cool I will take a look at what I did wrong.... One question though,
> if Websphere doesn't have a autodeploy feature for applications built
> as Wars, is there any hope of getting this working? Or will this solve
> the problem by deploying the app differently?
I'm afraid not.
I'm no Websphere user so I can't really comment on what is possible or not,
but if it really doesn't support autodeploy you're out of luck (and I guess
all those thousands of WebSphere developers with you because that would
really suck for testing webapplications during development).
I'd expect though WebSphere will have some kind of API though which you
should be able to dynamically add/deploy/start or whatever a new webapplication.
If thats true, it should be able to write a WebSphere DeploymentManager for
J2 handling it. I'd suggest googling for something like that because if it
is possible, certainly someone will have written one already.
>
>
> On Thu, 17 Mar 2005 21:35:02 +0100, Ate Douma <at...@douma.nu> wrote:
>
>>
>>Seth Ford wrote:
>>
>>>I am trying it out but I think I am doing something wrong with the
>>>jetspeed2-layout-portlets.war.... Doesn't it still go in the WEB-INF
>>>deploy folder? I put it there but I am seeing
>>>INFO: Loading portlet application from web archive C:\apps\tomcat\5.0.
>>>\jetspeed\WEB-INF\deploy\jetspeed-layouts.war
>>>INFO: Portlet application "jetspeed": registered=true, deployed=true
>>>INFO: Portlet application "jetspeed" already registered. Skipping ini
>>>yment.
>>>INFO: Portlet application registration target is jetspeed ...
>>>INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
>>>war/WEB-INF/classes/ to class path.
>>>INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
>>>war/WEB-INF/lib/portals-bridges-velocity-0.1.jar to class path.
>>>INFO: Registered portlet app in the class loader registry... jetspeed
>>>INFO: Registered portlet app in the search engine... jetspeed
>>>INFO: Portlet application registration of jetspeed complete.
>>>INFO: Portlet app "jetspeed" successfuly (re)deployed.
>>>
>>>and I get an error coming back from the browser for the branch
>>
>>Seth,
>>
>>I'm not sure which version of J2 you are testing but it certainly isn't
>>the deployment_refactoring branch.
>>Looking at the logging you provided this looks a cvs head version to me.
>>The deployment_refactoring doesn't need temporary deployment folders like
>>/temp/jetspeed-jar-tmp anymore and furthermore the jetspeed-layouts local
>>pa is registered under its own name: jetspeed-layouts (which means I had
>>to change the psml definitions for that too).
>>
>>
>>>Encountered the following problem(s) while attmepting to render
>>>portlet fragment: dp-1
>>>Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
>>>org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
>>>PortletEntity exists for for id dp-1 removing window from cache.
>>>Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
>>>org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
>>>PortletEntity exists for for id dp-1 removing window from cache.
>>>
>>>
>>>
>>>On Thu, 17 Mar 2005 03:01:59 +0100, Ate Douma <at...@douma.nu> wrote:
>>>
>>>
>>>>Dear all,
>>>>
>>>>Today I committed a big update for the deployment refactoring branch.
>>>>I've added the following features:
>>>>
>>>>- Moved Deployment interfaces and related components to the jetspeed-api subproject,
>>>> as well as the ApplicationServerManager interface and its new Result component.
>>>> This allows access to these services for portlet applications.
>>>>
>>>>- Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
>>>> It allows remote control of portlet applications and the registry with the
>>>> following functions: start, stop, reload, list, undeploy and deploy (upload).
>>>> I also created a new JetspeedConsole CLI using the ManagerServlet which works
>>>> well, but which I haven't committed yet because I need to clean it up first.
>>>>
>>>>- The ManagerServlet depends for several of its tasks on a ApplicationServerManager
>>>> implementation. With the TomcatManager all of its features can now be used.
>>>> The implementations of the JBossManager and WeblogicManager are still empty
>>>> shells though and probably someone else with more knowledge of these
>>>> application servers should take a look at those.
>>>>
>>>>- A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
>>>> naming of these is getting confusing.
>>>> This new portlet though provides (almost) the same functionality as the ManagerServlet.
>>>> Its lists all registered portlet applications in a table with action links for:
>>>> start, stop, undeploy and delete (unregister from the registry).
>>>> It also shows if an portlet application actually is running or not.
>>>> Because I wanted to provide this functionality in table layout, I decided to not
>>>> implement it in the already existing PAM (PortletApplicationBrowser) portlet which
>>>> presents the portlet applications and its portlets in a tree.
>>>> For now, this portlet is accessible from the Administrative folder (pam2.psml).
>>>> We probably need to discuss though if and/or how these two portlets should be
>>>> integrated.
>>>> This portlet also depends on a ApplicationServerManager. If none is configured (like
>>>> for JBoss) it will still show if a portlet application is running or not and allow
>>>> to delete (unregister) an portlet application.
>>>>
>>>>- J2 on JBoss
>>>> Because one of the premises of this deployment refactoring was that it should make
>>>> it easier to deploy J2 on other application servers as well, I decided to prove this
>>>> and got my feet wet trying it out for JBoss (3.2.7).
>>>>
>>>> With success!
>>>> I wrote a list of things to do to get this branch running on JBoss in a comment to
>>>> JS2-210: http://issues.apache.org/jira/browse/JS2-210#action_60983
>>>> Once this branch is merged into the head branch I'll provide proper instructions on
>>>> the website or wiki (although I'm not much of a wiki jockey yet).
>>>> I also tested with JBoss 4.0.1sp1 which looks to be working just as well. I didn't
>>>> have time to test that one a lot though.
>>>>
>>>> Of course, there were quite a few problems to solve, but *none* were related to
>>>> (re)deployment. And many of the problems as indicated by the wiki pages for JBoss
>>>> deployment of the M1 or current head version of J2 seems to be resolved :-)
>>>>
>>>> The following issues are important though:
>>>> - commons-logging and Log4J dependencies
>>>> JBoss provides commons-logging and Log4J, as well as the Log4J configuration from
>>>> a shared classloader to all the applications.
>>>> This really is conflicting with the way we use them in Jetspeed-2 under Tomcat
>>>> (although Tomcat 5.5 also is giving more headaches with this now).
>>>> One simply cannot have the commons-logging and log4j jars anymore in WEB-INF/lib
>>>> because it definitely is giving classloader problems under JBoss.
>>>>
>>>> Furthermore, our own log4j configuration conflicts with the global configuration
>>>> provided with JBoss. If you initialize a new log4j configuration from a web application
>>>> like we do with J2, you end up closing and detaching existing loggers and appenders
>>>> and rerouting them into the J2 logging. Likewise, if some other web application
>>>> deployed after J2 does the same, the J2 logging might get closed and detached and
>>>> rerouted into this other web application its logging.
>>>>
>>>> Anyway you look at it, dynamic log4j configuration is very problematic under JBoss.
>>>> And, while scanning the internet for a way around this, I found out many others
>>>> encountered the same problem and not only on JBoss but other application servers
>>>> as well.
>>>>
>>>> After a long investigation of the concrete implementations of commons-logging and
>>>> log4j though I've come up with a solution which I called IsolatedLog4JLogger.
>>>> As I put a lot of javadoc into that class I'm not going to reproduce it here.
>>>> But, I invite everyone to have a look at it. Its currently only committed to the
>>>> deployment_refactoring branch under portal/src/java/org/apache/jetspeed/util.
>>>>
>>>> Whats left is a future solution of the packaging of these jars. Having to remove
>>>> them after a war is build is quite dumb and easy to forget as well.
>>>>
>>>> - JBoss UniversalClassLoader
>>>> I don't think I have to explain anyone interested in JBoss what this means.
>>>> Anyway, with a few tweaks to the JBoss configurations I managed to get it working
>>>> "properly" ;-) Other solutions are also possible (like providing a jboss-web.xml
>>>> in *all* portlet application war files).
>>>>
>>>> - JAAS authentication
>>>> This was quite simple to implement but in the end turned out to be working only
>>>> half way.
>>>> The authentication itself is easy to do by configuring our DefaultLoginModule in
>>>> the JBoss login-config.xml.
>>>> But, the propagation of the Subject principals to JBoss is quite a problem.
>>>> Simply put: none is.
>>>> JBoss requires the Subject to be configured with a java.security.acl.Group named
>>>> "Roles" containing all the "Role" principals. As our security principals don't
>>>> implement java.securitry.acl.Group (yet) none is recognized by JBoss.
>>>> After some further investigation, it turns out other application servers
>>>> might require a Group implementation as well. So, we might need to refactor our
>>>> security principals a bit to get this to work.
>>>> As we don't actually *use* request.isUserInRole(roleName) in our demo portlets
>>>> yet (except for the security demo portlet), the default J2 deployment actually
>>>> works quite good.
>>>>
>>>>Well, I'd be very interested in others experiences with this branch (the latest and
>>>
>>>>from before my last changes). I know some are trying it out on different platforms as
>>>
>>>>well.
>>>>
>>>>Seth Ford is still unsuccessful with getting M1 running on WebSpere. Seth, I can't
>>>>really help you out with WebSphere but I really would suggest you try it out with the
>>>>latest from this branch (check the JBoss deployment instructions as reference).
>>>>
>>>>I think that with a few success stories of other deployments on different platforms
>>>>of this branch it might be almost ready for merging with the head.
>>>>Deleting (unregistering) of portlet applications is now provided for, as well as
>>>>start, stop, (remote) deployment and undeployment for Tomcat.
>>>>
>>>>If anyone has some requirements which should be fixed/implemented on this branch
>>>>before considering it ready for merge with the head (besides more proof it works
>>>>too on other platforms), please let me know. If possible and reasonable, I'll try
>>>>to provide for it.
>>>>
>>>>Regards, Ate
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: [J2] JS2-210: deployment refactoring branch updated with JBoss 3.2.7 support
Posted by Seth Ford <se...@gmail.com>.
Cool I will take a look at what I did wrong.... One question though,
if Websphere doesn't have a autodeploy feature for applications built
as Wars, is there any hope of getting this working? Or will this solve
the problem by deploying the app differently?
On Thu, 17 Mar 2005 21:35:02 +0100, Ate Douma <at...@douma.nu> wrote:
>
>
> Seth Ford wrote:
> > I am trying it out but I think I am doing something wrong with the
> > jetspeed2-layout-portlets.war.... Doesn't it still go in the WEB-INF
> > deploy folder? I put it there but I am seeing
> > INFO: Loading portlet application from web archive C:\apps\tomcat\5.0.
> > \jetspeed\WEB-INF\deploy\jetspeed-layouts.war
> > INFO: Portlet application "jetspeed": registered=true, deployed=true
> > INFO: Portlet application "jetspeed" already registered. Skipping ini
> > yment.
> > INFO: Portlet application registration target is jetspeed ...
> > INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
> > war/WEB-INF/classes/ to class path.
> > INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
> > war/WEB-INF/lib/portals-bridges-velocity-0.1.jar to class path.
> > INFO: Registered portlet app in the class loader registry... jetspeed
> > INFO: Registered portlet app in the search engine... jetspeed
> > INFO: Portlet application registration of jetspeed complete.
> > INFO: Portlet app "jetspeed" successfuly (re)deployed.
> >
> > and I get an error coming back from the browser for the branch
> Seth,
>
> I'm not sure which version of J2 you are testing but it certainly isn't
> the deployment_refactoring branch.
> Looking at the logging you provided this looks a cvs head version to me.
> The deployment_refactoring doesn't need temporary deployment folders like
> /temp/jetspeed-jar-tmp anymore and furthermore the jetspeed-layouts local
> pa is registered under its own name: jetspeed-layouts (which means I had
> to change the psml definitions for that too).
>
> >
> > Encountered the following problem(s) while attmepting to render
> > portlet fragment: dp-1
> > Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
> > org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
> > PortletEntity exists for for id dp-1 removing window from cache.
> > Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
> > org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
> > PortletEntity exists for for id dp-1 removing window from cache.
> >
> >
> >
> > On Thu, 17 Mar 2005 03:01:59 +0100, Ate Douma <at...@douma.nu> wrote:
> >
> >>Dear all,
> >>
> >>Today I committed a big update for the deployment refactoring branch.
> >>I've added the following features:
> >>
> >>- Moved Deployment interfaces and related components to the jetspeed-api subproject,
> >> as well as the ApplicationServerManager interface and its new Result component.
> >> This allows access to these services for portlet applications.
> >>
> >>- Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
> >> It allows remote control of portlet applications and the registry with the
> >> following functions: start, stop, reload, list, undeploy and deploy (upload).
> >> I also created a new JetspeedConsole CLI using the ManagerServlet which works
> >> well, but which I haven't committed yet because I need to clean it up first.
> >>
> >>- The ManagerServlet depends for several of its tasks on a ApplicationServerManager
> >> implementation. With the TomcatManager all of its features can now be used.
> >> The implementations of the JBossManager and WeblogicManager are still empty
> >> shells though and probably someone else with more knowledge of these
> >> application servers should take a look at those.
> >>
> >>- A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
> >> naming of these is getting confusing.
> >> This new portlet though provides (almost) the same functionality as the ManagerServlet.
> >> Its lists all registered portlet applications in a table with action links for:
> >> start, stop, undeploy and delete (unregister from the registry).
> >> It also shows if an portlet application actually is running or not.
> >> Because I wanted to provide this functionality in table layout, I decided to not
> >> implement it in the already existing PAM (PortletApplicationBrowser) portlet which
> >> presents the portlet applications and its portlets in a tree.
> >> For now, this portlet is accessible from the Administrative folder (pam2.psml).
> >> We probably need to discuss though if and/or how these two portlets should be
> >> integrated.
> >> This portlet also depends on a ApplicationServerManager. If none is configured (like
> >> for JBoss) it will still show if a portlet application is running or not and allow
> >> to delete (unregister) an portlet application.
> >>
> >>- J2 on JBoss
> >> Because one of the premises of this deployment refactoring was that it should make
> >> it easier to deploy J2 on other application servers as well, I decided to prove this
> >> and got my feet wet trying it out for JBoss (3.2.7).
> >>
> >> With success!
> >> I wrote a list of things to do to get this branch running on JBoss in a comment to
> >> JS2-210: http://issues.apache.org/jira/browse/JS2-210#action_60983
> >> Once this branch is merged into the head branch I'll provide proper instructions on
> >> the website or wiki (although I'm not much of a wiki jockey yet).
> >> I also tested with JBoss 4.0.1sp1 which looks to be working just as well. I didn't
> >> have time to test that one a lot though.
> >>
> >> Of course, there were quite a few problems to solve, but *none* were related to
> >> (re)deployment. And many of the problems as indicated by the wiki pages for JBoss
> >> deployment of the M1 or current head version of J2 seems to be resolved :-)
> >>
> >> The following issues are important though:
> >> - commons-logging and Log4J dependencies
> >> JBoss provides commons-logging and Log4J, as well as the Log4J configuration from
> >> a shared classloader to all the applications.
> >> This really is conflicting with the way we use them in Jetspeed-2 under Tomcat
> >> (although Tomcat 5.5 also is giving more headaches with this now).
> >> One simply cannot have the commons-logging and log4j jars anymore in WEB-INF/lib
> >> because it definitely is giving classloader problems under JBoss.
> >>
> >> Furthermore, our own log4j configuration conflicts with the global configuration
> >> provided with JBoss. If you initialize a new log4j configuration from a web application
> >> like we do with J2, you end up closing and detaching existing loggers and appenders
> >> and rerouting them into the J2 logging. Likewise, if some other web application
> >> deployed after J2 does the same, the J2 logging might get closed and detached and
> >> rerouted into this other web application its logging.
> >>
> >> Anyway you look at it, dynamic log4j configuration is very problematic under JBoss.
> >> And, while scanning the internet for a way around this, I found out many others
> >> encountered the same problem and not only on JBoss but other application servers
> >> as well.
> >>
> >> After a long investigation of the concrete implementations of commons-logging and
> >> log4j though I've come up with a solution which I called IsolatedLog4JLogger.
> >> As I put a lot of javadoc into that class I'm not going to reproduce it here.
> >> But, I invite everyone to have a look at it. Its currently only committed to the
> >> deployment_refactoring branch under portal/src/java/org/apache/jetspeed/util.
> >>
> >> Whats left is a future solution of the packaging of these jars. Having to remove
> >> them after a war is build is quite dumb and easy to forget as well.
> >>
> >> - JBoss UniversalClassLoader
> >> I don't think I have to explain anyone interested in JBoss what this means.
> >> Anyway, with a few tweaks to the JBoss configurations I managed to get it working
> >> "properly" ;-) Other solutions are also possible (like providing a jboss-web.xml
> >> in *all* portlet application war files).
> >>
> >> - JAAS authentication
> >> This was quite simple to implement but in the end turned out to be working only
> >> half way.
> >> The authentication itself is easy to do by configuring our DefaultLoginModule in
> >> the JBoss login-config.xml.
> >> But, the propagation of the Subject principals to JBoss is quite a problem.
> >> Simply put: none is.
> >> JBoss requires the Subject to be configured with a java.security.acl.Group named
> >> "Roles" containing all the "Role" principals. As our security principals don't
> >> implement java.securitry.acl.Group (yet) none is recognized by JBoss.
> >> After some further investigation, it turns out other application servers
> >> might require a Group implementation as well. So, we might need to refactor our
> >> security principals a bit to get this to work.
> >> As we don't actually *use* request.isUserInRole(roleName) in our demo portlets
> >> yet (except for the security demo portlet), the default J2 deployment actually
> >> works quite good.
> >>
> >>Well, I'd be very interested in others experiences with this branch (the latest and
> >>from before my last changes). I know some are trying it out on different platforms as
> >>well.
> >>
> >>Seth Ford is still unsuccessful with getting M1 running on WebSpere. Seth, I can't
> >>really help you out with WebSphere but I really would suggest you try it out with the
> >>latest from this branch (check the JBoss deployment instructions as reference).
> >>
> >>I think that with a few success stories of other deployments on different platforms
> >>of this branch it might be almost ready for merging with the head.
> >>Deleting (unregistering) of portlet applications is now provided for, as well as
> >>start, stop, (remote) deployment and undeployment for Tomcat.
> >>
> >>If anyone has some requirements which should be fixed/implemented on this branch
> >>before considering it ready for merge with the head (besides more proof it works
> >>too on other platforms), please let me know. If possible and reasonable, I'll try
> >>to provide for it.
> >>
> >>Regards, Ate
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: [J2] JS2-210: deployment refactoring branch updated with JBoss
3.2.7 support
Posted by Ate Douma <at...@douma.nu>.
Seth Ford wrote:
> I am trying it out but I think I am doing something wrong with the
> jetspeed2-layout-portlets.war.... Doesn't it still go in the WEB-INF
> deploy folder? I put it there but I am seeing
> INFO: Loading portlet application from web archive C:\apps\tomcat\5.0.
> \jetspeed\WEB-INF\deploy\jetspeed-layouts.war
> INFO: Portlet application "jetspeed": registered=true, deployed=true
> INFO: Portlet application "jetspeed" already registered. Skipping ini
> yment.
> INFO: Portlet application registration target is jetspeed ...
> INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
> war/WEB-INF/classes/ to class path.
> INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
> war/WEB-INF/lib/portals-bridges-velocity-0.1.jar to class path.
> INFO: Registered portlet app in the class loader registry... jetspeed
> INFO: Registered portlet app in the search engine... jetspeed
> INFO: Portlet application registration of jetspeed complete.
> INFO: Portlet app "jetspeed" successfuly (re)deployed.
>
> and I get an error coming back from the browser for the branch
Seth,
I'm not sure which version of J2 you are testing but it certainly isn't
the deployment_refactoring branch.
Looking at the logging you provided this looks a cvs head version to me.
The deployment_refactoring doesn't need temporary deployment folders like
/temp/jetspeed-jar-tmp anymore and furthermore the jetspeed-layouts local
pa is registered under its own name: jetspeed-layouts (which means I had
to change the psml definitions for that too).
>
> Encountered the following problem(s) while attmepting to render
> portlet fragment: dp-1
> Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
> org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
> PortletEntity exists for for id dp-1 removing window from cache.
> Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
> org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
> PortletEntity exists for for id dp-1 removing window from cache.
>
>
>
> On Thu, 17 Mar 2005 03:01:59 +0100, Ate Douma <at...@douma.nu> wrote:
>
>>Dear all,
>>
>>Today I committed a big update for the deployment refactoring branch.
>>I've added the following features:
>>
>>- Moved Deployment interfaces and related components to the jetspeed-api subproject,
>> as well as the ApplicationServerManager interface and its new Result component.
>> This allows access to these services for portlet applications.
>>
>>- Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
>> It allows remote control of portlet applications and the registry with the
>> following functions: start, stop, reload, list, undeploy and deploy (upload).
>> I also created a new JetspeedConsole CLI using the ManagerServlet which works
>> well, but which I haven't committed yet because I need to clean it up first.
>>
>>- The ManagerServlet depends for several of its tasks on a ApplicationServerManager
>> implementation. With the TomcatManager all of its features can now be used.
>> The implementations of the JBossManager and WeblogicManager are still empty
>> shells though and probably someone else with more knowledge of these
>> application servers should take a look at those.
>>
>>- A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
>> naming of these is getting confusing.
>> This new portlet though provides (almost) the same functionality as the ManagerServlet.
>> Its lists all registered portlet applications in a table with action links for:
>> start, stop, undeploy and delete (unregister from the registry).
>> It also shows if an portlet application actually is running or not.
>> Because I wanted to provide this functionality in table layout, I decided to not
>> implement it in the already existing PAM (PortletApplicationBrowser) portlet which
>> presents the portlet applications and its portlets in a tree.
>> For now, this portlet is accessible from the Administrative folder (pam2.psml).
>> We probably need to discuss though if and/or how these two portlets should be
>> integrated.
>> This portlet also depends on a ApplicationServerManager. If none is configured (like
>> for JBoss) it will still show if a portlet application is running or not and allow
>> to delete (unregister) an portlet application.
>>
>>- J2 on JBoss
>> Because one of the premises of this deployment refactoring was that it should make
>> it easier to deploy J2 on other application servers as well, I decided to prove this
>> and got my feet wet trying it out for JBoss (3.2.7).
>>
>> With success!
>> I wrote a list of things to do to get this branch running on JBoss in a comment to
>> JS2-210: http://issues.apache.org/jira/browse/JS2-210#action_60983
>> Once this branch is merged into the head branch I'll provide proper instructions on
>> the website or wiki (although I'm not much of a wiki jockey yet).
>> I also tested with JBoss 4.0.1sp1 which looks to be working just as well. I didn't
>> have time to test that one a lot though.
>>
>> Of course, there were quite a few problems to solve, but *none* were related to
>> (re)deployment. And many of the problems as indicated by the wiki pages for JBoss
>> deployment of the M1 or current head version of J2 seems to be resolved :-)
>>
>> The following issues are important though:
>> - commons-logging and Log4J dependencies
>> JBoss provides commons-logging and Log4J, as well as the Log4J configuration from
>> a shared classloader to all the applications.
>> This really is conflicting with the way we use them in Jetspeed-2 under Tomcat
>> (although Tomcat 5.5 also is giving more headaches with this now).
>> One simply cannot have the commons-logging and log4j jars anymore in WEB-INF/lib
>> because it definitely is giving classloader problems under JBoss.
>>
>> Furthermore, our own log4j configuration conflicts with the global configuration
>> provided with JBoss. If you initialize a new log4j configuration from a web application
>> like we do with J2, you end up closing and detaching existing loggers and appenders
>> and rerouting them into the J2 logging. Likewise, if some other web application
>> deployed after J2 does the same, the J2 logging might get closed and detached and
>> rerouted into this other web application its logging.
>>
>> Anyway you look at it, dynamic log4j configuration is very problematic under JBoss.
>> And, while scanning the internet for a way around this, I found out many others
>> encountered the same problem and not only on JBoss but other application servers
>> as well.
>>
>> After a long investigation of the concrete implementations of commons-logging and
>> log4j though I've come up with a solution which I called IsolatedLog4JLogger.
>> As I put a lot of javadoc into that class I'm not going to reproduce it here.
>> But, I invite everyone to have a look at it. Its currently only committed to the
>> deployment_refactoring branch under portal/src/java/org/apache/jetspeed/util.
>>
>> Whats left is a future solution of the packaging of these jars. Having to remove
>> them after a war is build is quite dumb and easy to forget as well.
>>
>> - JBoss UniversalClassLoader
>> I don't think I have to explain anyone interested in JBoss what this means.
>> Anyway, with a few tweaks to the JBoss configurations I managed to get it working
>> "properly" ;-) Other solutions are also possible (like providing a jboss-web.xml
>> in *all* portlet application war files).
>>
>> - JAAS authentication
>> This was quite simple to implement but in the end turned out to be working only
>> half way.
>> The authentication itself is easy to do by configuring our DefaultLoginModule in
>> the JBoss login-config.xml.
>> But, the propagation of the Subject principals to JBoss is quite a problem.
>> Simply put: none is.
>> JBoss requires the Subject to be configured with a java.security.acl.Group named
>> "Roles" containing all the "Role" principals. As our security principals don't
>> implement java.securitry.acl.Group (yet) none is recognized by JBoss.
>> After some further investigation, it turns out other application servers
>> might require a Group implementation as well. So, we might need to refactor our
>> security principals a bit to get this to work.
>> As we don't actually *use* request.isUserInRole(roleName) in our demo portlets
>> yet (except for the security demo portlet), the default J2 deployment actually
>> works quite good.
>>
>>Well, I'd be very interested in others experiences with this branch (the latest and
>>from before my last changes). I know some are trying it out on different platforms as
>>well.
>>
>>Seth Ford is still unsuccessful with getting M1 running on WebSpere. Seth, I can't
>>really help you out with WebSphere but I really would suggest you try it out with the
>>latest from this branch (check the JBoss deployment instructions as reference).
>>
>>I think that with a few success stories of other deployments on different platforms
>>of this branch it might be almost ready for merging with the head.
>>Deleting (unregistering) of portlet applications is now provided for, as well as
>>start, stop, (remote) deployment and undeployment for Tomcat.
>>
>>If anyone has some requirements which should be fixed/implemented on this branch
>>before considering it ready for merge with the head (besides more proof it works
>>too on other platforms), please let me know. If possible and reasonable, I'll try
>>to provide for it.
>>
>>Regards, Ate
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: [J2] JS2-210: deployment refactoring branch updated with JBoss 3.2.7 support
Posted by Seth Ford <se...@gmail.com>.
I am trying it out but I think I am doing something wrong with the
jetspeed2-layout-portlets.war.... Doesn't it still go in the WEB-INF
deploy folder? I put it there but I am seeing
INFO: Loading portlet application from web archive C:\apps\tomcat\5.0.
\jetspeed\WEB-INF\deploy\jetspeed-layouts.war
INFO: Portlet application "jetspeed": registered=true, deployed=true
INFO: Portlet application "jetspeed" already registered. Skipping ini
yment.
INFO: Portlet application registration target is jetspeed ...
INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
war/WEB-INF/classes/ to class path.
INFO: Adding file:/C:/apps/tomcat/5.0.28/temp/jetspeed-jar-tmp/jetspee
war/WEB-INF/lib/portals-bridges-velocity-0.1.jar to class path.
INFO: Registered portlet app in the class loader registry... jetspeed
INFO: Registered portlet app in the search engine... jetspeed
INFO: Portlet application registration of jetspeed complete.
INFO: Portlet app "jetspeed" successfuly (re)deployed.
and I get an error coming back from the browser for the branch
Encountered the following problem(s) while attmepting to render
portlet fragment: dp-1
Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
PortletEntity exists for for id dp-1 removing window from cache.
Failed to retrieve Portlet Definition for jetspeed::VelocityTwoColumns
org.apache.jetspeed.container.window.FailedToRetrievePortletWindow: No
PortletEntity exists for for id dp-1 removing window from cache.
On Thu, 17 Mar 2005 03:01:59 +0100, Ate Douma <at...@douma.nu> wrote:
> Dear all,
>
> Today I committed a big update for the deployment refactoring branch.
> I've added the following features:
>
> - Moved Deployment interfaces and related components to the jetspeed-api subproject,
> as well as the ApplicationServerManager interface and its new Result component.
> This allows access to these services for portlet applications.
>
> - Provided a new ManagerServlet somewhat like the ManagerServlet of Tomcat.
> It allows remote control of portlet applications and the registry with the
> following functions: start, stop, reload, list, undeploy and deploy (upload).
> I also created a new JetspeedConsole CLI using the ManagerServlet which works
> well, but which I haven't committed yet because I need to clean it up first.
>
> - The ManagerServlet depends for several of its tasks on a ApplicationServerManager
> implementation. With the TomcatManager all of its features can now be used.
> The implementations of the JBossManager and WeblogicManager are still empty
> shells though and probably someone else with more knowledge of these
> application servers should take a look at those.
>
> - A new PortletApplicationManager portlet. Yes, another PAM indeed, and the
> naming of these is getting confusing.
> This new portlet though provides (almost) the same functionality as the ManagerServlet.
> Its lists all registered portlet applications in a table with action links for:
> start, stop, undeploy and delete (unregister from the registry).
> It also shows if an portlet application actually is running or not.
> Because I wanted to provide this functionality in table layout, I decided to not
> implement it in the already existing PAM (PortletApplicationBrowser) portlet which
> presents the portlet applications and its portlets in a tree.
> For now, this portlet is accessible from the Administrative folder (pam2.psml).
> We probably need to discuss though if and/or how these two portlets should be
> integrated.
> This portlet also depends on a ApplicationServerManager. If none is configured (like
> for JBoss) it will still show if a portlet application is running or not and allow
> to delete (unregister) an portlet application.
>
> - J2 on JBoss
> Because one of the premises of this deployment refactoring was that it should make
> it easier to deploy J2 on other application servers as well, I decided to prove this
> and got my feet wet trying it out for JBoss (3.2.7).
>
> With success!
> I wrote a list of things to do to get this branch running on JBoss in a comment to
> JS2-210: http://issues.apache.org/jira/browse/JS2-210#action_60983
> Once this branch is merged into the head branch I'll provide proper instructions on
> the website or wiki (although I'm not much of a wiki jockey yet).
> I also tested with JBoss 4.0.1sp1 which looks to be working just as well. I didn't
> have time to test that one a lot though.
>
> Of course, there were quite a few problems to solve, but *none* were related to
> (re)deployment. And many of the problems as indicated by the wiki pages for JBoss
> deployment of the M1 or current head version of J2 seems to be resolved :-)
>
> The following issues are important though:
> - commons-logging and Log4J dependencies
> JBoss provides commons-logging and Log4J, as well as the Log4J configuration from
> a shared classloader to all the applications.
> This really is conflicting with the way we use them in Jetspeed-2 under Tomcat
> (although Tomcat 5.5 also is giving more headaches with this now).
> One simply cannot have the commons-logging and log4j jars anymore in WEB-INF/lib
> because it definitely is giving classloader problems under JBoss.
>
> Furthermore, our own log4j configuration conflicts with the global configuration
> provided with JBoss. If you initialize a new log4j configuration from a web application
> like we do with J2, you end up closing and detaching existing loggers and appenders
> and rerouting them into the J2 logging. Likewise, if some other web application
> deployed after J2 does the same, the J2 logging might get closed and detached and
> rerouted into this other web application its logging.
>
> Anyway you look at it, dynamic log4j configuration is very problematic under JBoss.
> And, while scanning the internet for a way around this, I found out many others
> encountered the same problem and not only on JBoss but other application servers
> as well.
>
> After a long investigation of the concrete implementations of commons-logging and
> log4j though I've come up with a solution which I called IsolatedLog4JLogger.
> As I put a lot of javadoc into that class I'm not going to reproduce it here.
> But, I invite everyone to have a look at it. Its currently only committed to the
> deployment_refactoring branch under portal/src/java/org/apache/jetspeed/util.
>
> Whats left is a future solution of the packaging of these jars. Having to remove
> them after a war is build is quite dumb and easy to forget as well.
>
> - JBoss UniversalClassLoader
> I don't think I have to explain anyone interested in JBoss what this means.
> Anyway, with a few tweaks to the JBoss configurations I managed to get it working
> "properly" ;-) Other solutions are also possible (like providing a jboss-web.xml
> in *all* portlet application war files).
>
> - JAAS authentication
> This was quite simple to implement but in the end turned out to be working only
> half way.
> The authentication itself is easy to do by configuring our DefaultLoginModule in
> the JBoss login-config.xml.
> But, the propagation of the Subject principals to JBoss is quite a problem.
> Simply put: none is.
> JBoss requires the Subject to be configured with a java.security.acl.Group named
> "Roles" containing all the "Role" principals. As our security principals don't
> implement java.securitry.acl.Group (yet) none is recognized by JBoss.
> After some further investigation, it turns out other application servers
> might require a Group implementation as well. So, we might need to refactor our
> security principals a bit to get this to work.
> As we don't actually *use* request.isUserInRole(roleName) in our demo portlets
> yet (except for the security demo portlet), the default J2 deployment actually
> works quite good.
>
> Well, I'd be very interested in others experiences with this branch (the latest and
> from before my last changes). I know some are trying it out on different platforms as
> well.
>
> Seth Ford is still unsuccessful with getting M1 running on WebSpere. Seth, I can't
> really help you out with WebSphere but I really would suggest you try it out with the
> latest from this branch (check the JBoss deployment instructions as reference).
>
> I think that with a few success stories of other deployments on different platforms
> of this branch it might be almost ready for merging with the head.
> Deleting (unregistering) of portlet applications is now provided for, as well as
> start, stop, (remote) deployment and undeployment for Tomcat.
>
> If anyone has some requirements which should be fixed/implemented on this branch
> before considering it ready for merge with the head (besides more proof it works
> too on other platforms), please let me know. If possible and reasonable, I'll try
> to provide for it.
>
> Regards, Ate
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org