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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
