[jira] Created: (JS2-235) Cleanup PageManager to enforce Page/Folder security symmetrically
Cleanup PageManager to enforce Page/Folder security symmetrically - Key: JS2-235 URL: http://issues.apache.org/jira/browse/JS2-235 Project: Jetspeed 2 Type: Task Versions: 2.0-M3 Reporter: Randy Watler Assigned to: Randy Watler Priority: Minor Fix For: 2.0-M3 PageManager and related implementations do not enforce Page/Folder security constraints/permissions consistantly across all APIs. PageManager.getFolder() and PageManager.newPage() probably need to restrict VIEW and EDIT access assuming an end user is attempting to perform these operations as part of a site management/customization process. Will need to review site admin portlets to ensure that tightened APIs do not hinder operation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JS2-236) PageManager Folder/Page security needs to support multiple page.security files
PageManager Folder/Page security needs to support multiple page.security files -- Key: JS2-236 URL: http://issues.apache.org/jira/browse/JS2-236 Project: Jetspeed 2 Type: Improvement Components: PSML Versions: 2.0-M3 Reporter: Randy Watler Assigned to: Randy Watler Priority: Minor Fix For: 2.0-M3 PageManager Page/Folder constraints security implementation, (bronco), does not support multiple page.security files as documented. At a minimum, subsites need to support their own page.security files. Generalizing the implementation to support page.security definitions embedded within the site hierarchy should be considered... probably with a strict replacement aggregation policy within the hierarchy to limit performance overhead. The current implementation restricts the location of the page.security file to the site root folder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating a CMS with J2
Jean, Please use the Jetspeed user list for these kinds of questions. There has been work to integrate J2 and Graffito. Please search the archives: http://marc.theaimsgroup.com/?l=jetspeed-userw=2r=1s=graffitoq=b I am currently on task for delivering the J2 site PSML via Grafitto CMS in the near future. Randy Jean Goffinet wrote: Hi everyone, We are looking for a CMS which could be integrated into Jetspeed2: - content would be displayed into portlets - and portlets would be used for the back office too (publication, validation, ...) Does someone have such an experience ? I've heard of Cofax beeing integrated into J1, but few information is available... Thanks in advance, Jean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting Folder from path
At the moment, there is no really good, (read clean), way to do this... especially if you use the profiler. I will be working on this stuff this week if you can use a development CVS copy. If you are NOT depending on the profiler, you can do the following as a workaround: 1. grab the folder or page from the $site variable. 2. use the getParent() method to access the parent folders all the way up to '/'. 3. navigate around the hierarchy from there using getFolders() and getPages(). Again, this will NOT work well if you are using the profiler to define user, role, group, or subsite specific site configurations. It is also relative to the current and root site paths, not a full portal request path. I am guessing you can work around that as needed to generate breadcrumbs, (see the absolute URL generation methods on the $jetspeed object). I am attempting to get support for this kind of site access in place for M2. Randy zazo wrote: Wiadomo Oryginalna Od: zazo [EMAIL PROTECTED] Do: jetspeed-dev@jakarta.apache.org Data: Tue, 29 Mar 2005 13:32:16 +0200 Temat: Getting Folder from path Hi all, I am writing custom layout for my Jetspeed site. To have it fully work I need one more, little thing -- Is there a way to get Folder object having only path pointing to it? Ex. Let's say I have String http://localhost:8080/jetspeed/portal/Public; and by using some tricky API function I can get object of Folder bounded to public folder. Then I can check its name, title etc Can anyone help me, or at least point where should I look for solution? I am using J2-M1. Thank you in advance. Best wishes. Tomasz Yesterday, I found that interface PageManager has getFolders(String) method which according to javadoc 'Locates a folder for the given path.'. Yes!, this is what I am looking for. But... Can anyone suggest me the easiest way to use it. Should I take a closer look to CastorXmlPageManager which implements PageManager? I need this functionality to build (full) breadcrumbs for my site, get folders only from root folder, build navigation from files located in some directory and so on... It's getting urgent :( Thanks for any tips. Best regards Tomasz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Folder semantics issue
Raphael, The reason all of this is so confusing is due to the use of the Profiler by the PageManager. Because the getParent*() methods are coming from the physical folder/page nodes and various collections in the $site object are presenting a logical view, there is often disagreement. The easiest way to stay sane is to never use the getParent*() methods... :-( However, everyone wants to navigate the $site folder hierarchies to generate menus. I am proposing that this be fixed in the latest Portal Navigations proposal that has been discussed lately on another thread. The idea is to build a proxy site definition that mostly delegates to the underlying physical files and folders, but hides the real file system getParent*() methods. For now, you can employ nested document sets to generate hierarchical menus. However, as noted by others, it is not intuitive to do so. If you need to create some complex portal navigations using M1 and cannot wait for the M2 refactoring, let me know and I can give you a hand. Randy Raphaël Luta wrote: We've been playing around the Profiler and Folder stuff to implement our portal navigation and we came across this oddity: If I put this code in my page decorator velocity template Parent Folder $parentFolder Parent Folder Children #foreach($obj in $site.parentFolder.Folders(true).iterator()) $obj #end Siblings #foreach($obj in $site.siblingFolders.iterator()) $obj #end I get the following results, as guest, default profiler settings: In default page: Parent Folder $parentFolder Parent Folder Children Siblings /folder1 /folder2 /folder3 In default page of folder1: Parent Folder / Parent Folder Children /folder1 /folder2 /folder3 /_user /_role Siblings That means that contrary to my expectations, $site.parentFoler.Folders is not equal to $site.siblingFolders or said differently the children folders of my parent folder are not my sibling folders ! I guess this is mostly a semantic issue but I believe the API should make it clearer what we are calling parentFolder and siblingFolders. My understanding is that : $site.parentFolder = the parent folder of the current *folder* $site.siblingFolders = the siblings folders of the current *page* I believe we should stick to having the same reference point, either current page or current folder. What do you think ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Folder semantics issue
Raphael, BTW, getFolders(), getPages(), etc. have the same problems as getParent*() since these too attempt to navigate the logical profiled view by following physical file system relationships :( Randy Randy Watler wrote: Raphael, The reason all of this is so confusing is due to the use of the Profiler by the PageManager. Because the getParent*() methods are coming from the physical folder/page nodes and various collections in the $site object are presenting a logical view, there is often disagreement. The easiest way to stay sane is to never use the getParent*() methods... :-( However, everyone wants to navigate the $site folder hierarchies to generate menus. I am proposing that this be fixed in the latest Portal Navigations proposal that has been discussed lately on another thread. The idea is to build a proxy site definition that mostly delegates to the underlying physical files and folders, but hides the real file system getParent*() methods. For now, you can employ nested document sets to generate hierarchical menus. However, as noted by others, it is not intuitive to do so. If you need to create some complex portal navigations using M1 and cannot wait for the M2 refactoring, let me know and I can give you a hand. Randy Raphaël Luta wrote: We've been playing around the Profiler and Folder stuff to implement our portal navigation and we came across this oddity: If I put this code in my page decorator velocity template Parent Folder $parentFolder Parent Folder Children #foreach($obj in $site.parentFolder.Folders(true).iterator()) $obj #end Siblings #foreach($obj in $site.siblingFolders.iterator()) $obj #end I get the following results, as guest, default profiler settings: In default page: Parent Folder $parentFolder Parent Folder Children Siblings /folder1 /folder2 /folder3 In default page of folder1: Parent Folder / Parent Folder Children /folder1 /folder2 /folder3 /_user /_role Siblings That means that contrary to my expectations, $site.parentFoler.Folders is not equal to $site.siblingFolders or said differently the children folders of my parent folder are not my sibling folders ! I guess this is mostly a semantic issue but I believe the API should make it clearer what we are calling parentFolder and siblingFolders. My understanding is that : $site.parentFolder = the parent folder of the current *folder* $site.siblingFolders = the siblings folders of the current *page* I believe we should stick to having the same reference point, either current page or current folder. What do you think ? - 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]
Re: Finalizing Portal Navigation, [JIRA JS2-69]
Ate, If I am understanding your usecase correctly, you do not need profiling but you are depending on security constraints to modify the site/menu definitions per user. The site session context object is meant to be accessed directly by the layout templates, so I had intended to apply the security constraints while the site and menu definitions are being constructed out of the Folder/Page/Document proxies. I believe that in your usecase the caching would be optimally done per group/role instead of per session. However, if any security constraint specified in the PSML references a user, (even guest), the group/role optimization potentially breaks down and degenerates into the session context case. At the moment, I do not think it would be worth scanning the PSML security constraints in an attempt to determine the appropriate/safe caching level for all site/menu definitions. Perhaps an advanced performance tuning flag might be appropriate in the Spring configuration for the PortalNavigations component. In the end, caching by group/role might not be significantly different from the session context caching... we'll have to see. Thanks for the feedback! I will think about this usecase more... let me know if this response makes sense or if I managed to confuse the usecase somehow. Randy Ate Douma wrote: Randy sorry for the late response but I've been too busy with the deployment refactoring till now. I think your plan looks good and I'm +1 in general. For one usecase I don't yet see if/how your solution will handle it optimally though. My client has a setup which doesn't actually need real profiling. There is only one content-type: html, one language/country: dutch, and there are no different pages based on user/role/group: access is based only on role and you either have it or you don't (no alternatives). As far as I see, this setup doesn't really need a Site definition stored in each user session: one instance for the whole portal would suffice. The same applies to the menu requirements: there is only need for one set of menu definitions shared by all users. Role restrictions should determine which menu items are visible or not. This usecase is very simple but nonetheless not uncommon for intranet business application portals I think. I can't think of a much lighter weight solution, and just for that reason only it would already be good to have optimal and out-of-the-box support for. Ate [EMAIL PROTECTED] wrote: Team, After devoting some time to this issue over the week I think I have come up with the heart of a proposal. I plan on commiting it to an official design document in all of its glory soon, but I would like some feedback first. Here is the general scheme: 1. An inital request comes in for a authenticated user immediately after login on some request url, (usually the portal root). Since this is the first request in a new session for the end user, the PageManager, Profiler, and new PortalNavigations component initializes a new context object that is attached to the session. This object will hold all cached profiled site information for the session to maximize reuse/scaling and hold sufficient state information about the user, pages, and active profiling rules to allow it to compute profiled site portal navigations dynamically later in the execution of the request pipeline. 2. The site session context object is initialized/reset with only these elements when the ProfilerValve is invoked in the pipeline: the root folder, the current page, and a creation timestamp. All Folder, Page, and other document instances managed within the site session context object will be proxies that are arranged into a standard hirarchical site definition with the aid of the PageManager and Profiler. Unlike the current implementation, all elements managed by the site session context can be navigated to locate relative profiled site content, (i.e. getParent(), getSiblingFolders(), getFolders(), etc. will reflect the profiled site). These proxies will delegate all access and operations to the underlying objects managed by the PageManager, except those that maintain the proxy hierarchy. As mentioned, the initial site session context object will be sparsely populated. As the end user navigates through the portal and the Page Layout Templates are constructed, the site session context object will cache more of the profiled site definition by constructing the proxy hierarchy dynamically. The cached proxy hierarchy will be cleared when the session is destroyed or the PageManager cache is cleared due to a change in the physical PSML content. 3. Basic utilities will be implemented by the site session context object that mimic the existing PageManager/Profiler features. These will minimally include: getPage(), getFolder(), getSiblingFolders(), getSiblingPages(), and getRootLinks(). The new getRootFolder(), getRootPages(), and getRootFolders() access will also implemented to facilitate ad-hoc
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Ate/All, Yes, 4.1 is certainly painful when it comes to deployment. I can verify most of what Ate has outlined here. +1 to drop 4.1. Ate, are you also working on getting 5.5 functional? I suppose it would be good to do that before/while we deprecate 4.1 support. Randy Ate Douma wrote: Something I forgot to add: I will try to upload a preliminary patch for http://issues.apache.org/jira/browse/JS2-210 tomorrow which for testing purposes only and which of course will only work with Tomcat 5.0.28 (or higher). Regards, Ate Ate Douma wrote: Dear developer team and users, I've been working the last two weeks (off and on) on a new and much simplified deployment implementation for Jetspeed-2 which builds mainly on official Servlet specification (2.3) features. See JIRA: http://issues.apache.org/jira/browse/JS2-210 I expect that with this solution, deployment for Application servers other than Tomcat will become much easier to implement and support. I've got this working already beautifully on Tomcat 5 (5.0.28) and with a few nice side-effects too: - the Jetspeed-2 context isn't fixed at /jetspeed any more - multiple layout portlet applications can be deployed/used at the same time for both see: http://issues.apache.org/jira/browse/JS2-182 http://issues.apache.org/jira/browse/JS2-172 - no more temporarily expanded wars in the java.io.tmpdir to workaround classloading issues - much quicker startup To be honest, my refactoring isn't finished yet and some features currently available will have to be reimplemented (differently) like undeployment. But I can't get the redeployment working flawlessly under Tomcat 4.1 (tested with 4.1.30 and 4.1.31). Tomcat 4 won't always release certain jars in deployed applications when doing an undeployment or redeployment while this is no problem with Tomcat 5.0. Furthermore, auto redeployment of war files isn't available at all in Tomcat 4: you need to use the TomcatManager to remove an existing application first (which sometimes fails) before a new application can tried to be deployed again. And then, There are other serious problems with Tomcat 4 too like no separate sessions for the portal and portlet applications (which is a *serious* security breach and the foremost reason I myself won't use Tomcat 4 for Portals anymore). The Pluto Team won't even use Tomcat 5.0 anymore and require Tomcat 5.5.7 or higher because Tomcat 5.0 also has a session bug in which a Portlet Application and its Web application don't share the same session when invoked independently (as they should according to the portlet specification). Both the development of Tomcat 4 and Tomcat 5.0 has largely come to an end, except for really nasty bugs, but the onces I described above aren't regarded as such by the Tomcat team :-( Al in all, to me the question right now is: do we really, really need to keep supporting Tomcat 4. For my deployment refactorings it poses a problem I don't have time left to further investigate (nor do I have any hope it *can* be resolved). As long as we need to support Tomcat 4, I can't commit my changes... I'd like to hear from both team members and users who absolutely require Tomcat 4 support for Jetspeed-2 and why. And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! Please comment, 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59846 ] Randy Watler commented on JS2-69: - Team, After devoting some time to this issue over the week I think I have come up with the heart of a proposal. I plan on commiting it to an official design document in all of its glory soon, but I would like some feedback first. Here is the general scheme: 1. An inital request comes in for a authenticated user immediately after login on some request url, (usually the portal root). Since this is the first request in a new session for the end user, the PageManager, Profiler, and new PortalNavigations component initializes a new context object that is attached to the session. This object will hold all cached profiled site information for the session to maximize reuse/scaling and hold sufficient state information about the user, pages, and active profiling rules to allow it to compute profiled site portal navigations dynamically later in the execution of the request pipeline. 2. The site session context object is initialized/reset with only these elements when the ProfilerValve is invoked in the pipeline: the root folder, the current page, and a creation timestamp. All Folder, Page, and other document instances managed within the site session context object will be proxies that are arranged into a standard hirarchical site definition with the aid of the PageManager and Profiler. Unlike the current implementation, all elements managed by the site session context can be navigated to locate relative profiled site content, (i.e. getParent(), getSiblingFolders(), getFolders(), etc. will reflect the profiled site). These proxies will delegate all access and operations to the underlying objects managed by the PageManager, except those that maintain the proxy hierarchy. As mentioned, the initial site session context object will be sparsely populated. As the end user navigates through the portal and the Page Layout Templates are constructed, the site session context object will cache more of the profiled site definition by constructing the proxy hierarchy dynamically. The cached proxy hierarchy will be cleared when the session is destroyed or the PageManager cache is cleared due to a change in the physical PSML content. 3. Basic utilities will be implemented by the site session context object that mimic the existing PageManager/Profiler features. These will minimally include: getPage(), getFolder(), getSiblingFolders(), getSiblingPages(), and getRootLinks(). The new getRootFolder(), getRootPages(), and getRootFolders() access will also implemented to facilitate ad-hoc access to the root of the profiled site. 4. Document sets will be deprecated and replaced with named menu definitions that will appear in the folder.metadata files. In the broadest terms, these new folder based menu definitions will be a super set of the existing document set features. In addition to the ability to define and profile multiple menu definitions using alternate profiling rules and regular expression path sets, new capabilities based on explicit XML menu tags to define ragged nested menus inline will be implemented. Also, common menu design patterns/idioms can be easily specified using the declarative XML menu tags, (e.g. it would be trivial to define a simple XML definition to specify a menu tree composed of all root level folders and their pages). Individually named menu definitions will be inherited, (in a strictly non-aggregating style), down the profiled PSML hierarchy as one would expect so that they can be overriden in lower levels in the site. When accessed by the Page Layout Templates, the site session context object will construct and cache each named menu definition using another hierarchy of proxied Folder, Page and other document instances. This proxy hierarchy can be easily navigated by the Page Layout Templates to generate many simple or cascading Portal Navigation styles. 5. The implementation of the functionality behind the site session context object and its proxy hierarchies will be encapsulated in a separate component I am referring to as the PortalNavigations component. I am also considering the implementation of another compatible component that simply returns underlying Folders, Pages, and other documents from the PageManager without employing the Profiler or Security; this would also eliminate the need for proxies and delegation. Given the flexibilty of the intended APIs outlined above, I am not sure there is a need to micro componentize the full function PortalNavigations functionality. By only computing exactly what a Page Layout Template requests and employing session based caching, it is not clear that any performance advantage would be realized by further decomposition. However, I am still considering the implementation of individual menu definition idioms as components. 6. At the moment, I am
[jira] Assigned: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=history ] Randy Watler reassigned JS2-69: --- Assign To: Randy Watler Finallizing Portal Navigation using the Profiler Key: JS2-69 URL: http://issues.apache.org/jira/browse/JS2-69 Project: Jetspeed 2 Type: New Feature Components: Profiling/Portal Navigation Versions: 2.0-dev/cvs, 2.0-a1 Reporter: Scott T Weaver Assignee: Randy Watler Priority: Critical We still haven't settled on how we are going to generate navigations in J2. I have some modifications to the Profiler and to the theme logic which may give us some direction. I am bringing this up as I have been privellage to quite a few vendor portal demos lately allowing me to see both the good and the bad of multiple implementations. - I would say we replace the getDesktop() with getFolders(). There is really no need for a root item or Folder per se since we will be leaving this job to the current set of profilling rules that have been assigned to the Profiler. - Folders will contain any number of pages and/or folders. - Folder items would be ordered the following way: first by assigned index then by alphabetical order. - Remove defaultPage logic from Folder, the focused Folder item would be set in this fashion: set the focus to the last selected child in that Folder then by Folder Item ordering algothrim defined above. - It should be the Profiler's responsibility to preserve a user's active item on a per Folder basis. - A Folder would still posses the defaultTheme capabillity but with the added abillity to enforce the defaultTheme on its childern and its childrens' children by overriding the theme settings for those items with its own. - Rendering the contents of the Profiler.getFolders() would be left entirely up to the theme (currently called the layout decorator). Example: a theme could render the first 2 levels as tabs and the rest as a hierarchical menu to the left of the layout area. - DO NOT introduce the idea of controls and controllers. It has been stated before that these easily confuse people and I agree 100%. We need to keep things simple. I think the first profiling/navgation implementation would be assigning n number of roles to a top-level folder. Then allow the Profiler to aggregate what Folders a user has access to by comparing the roles that user is assigned to the ones required the Folders required roles (ACL?) I think this approach is already somewhat in place but it just needs some final implementation details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JS2-215) security email extensions: password reminder/user creation
security email extensions: password reminder/user creation -- Key: JS2-215 URL: http://issues.apache.org/jira/browse/JS2-215 Project: Jetspeed 2 Type: Improvement Components: Security Versions: 2.0-M1 Reporter: Randy Watler Fix For: 2.0-M2 From Ate Douma [EMAIL PROTECTED] Subject Re: More Login/Security Enhancements Date Sun, February 20, 2005 1:44 pm To Jetspeed Developers List jetspeed-dev@jakarta.apache.org Randy Watler wrote: Ate/All, I have these additional Login/Security requirements that have made there way into a formal requirements process for our portal implementation: - Send email to end user for forgotten passwords, (offered on failed login attempts if user email address known). +1 - Ability of a non-authenticated end user to create and populate a disabled user account to be enabled later by admin/moderator, (includes automatic email notification of the request and approved/denied messages if user email address known). +1 I think these features are fairly typical for most sites requiring end user authentication. Is there any interest in, (or objections to), these features being added to J2 proper? If there is interest, I will generate a JIRA issue and we can see if there are other similar capabilities that can be added at the same time. +1 I myself have been asked by my client to provide more/correct feedback to a user trying to login but whose account already has been disabled (too many failed login attempts). The current functionality clearly isn't giving good feedback at all. The problem to do this better though is that there isn't a formal way to communicate information back *through* the JAAS implementation (i.e. the Tomcat JAASRealm) to the client (J2). We need to provide our own channel or such for that. Thanks! Randy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59481 ] Randy Watler commented on JS2-69: - From Ate Douma [EMAIL PROTECTED] Subject Re: Declarative or Modal Page Layout Navigation? Date Sun, February 20, 2005 1:57 pm To Jetspeed Developers List jetspeed-dev@jakarta.apache.org Randy Watler wrote: Team, David and I have been discussing potential options to the current profiler/page-manager generated page layout navigations. While what we have seems to be fairly powerful and flexible, it also seems to be too complex and/or scalable for use by many users. It often raises questions on the lists and certainly does not seem self documenting! Fully agreed! We have discussed implementing a declarative navigation definition, (i.e. J1 menus), that could be specified globally or at the folder level. We have also pondered some modal configuration settings/hints to the existing solution that correspond to different navigational styles, (i.e. relative forward/back navigation as we currently have, constant navigation elements that reflect the physical folder structures, logical view specifications like document sets, etc.). Obviously, changes to support these different modes would also involve modifications to the various velocity layout templates. Related efforts might include support for javascript pull down menus or other portal navigation interfaces. +1 ;-) One of my own outstanding requirements I haven't found time yet to find a solution for. We've been here before and several solutions have been suggested in the past (including one of my own). Lets try to get this right once and for all! Finallizing Portal Navigation using the Profiler Key: JS2-69 URL: http://issues.apache.org/jira/browse/JS2-69 Project: Jetspeed 2 Type: New Feature Components: Profiling/Portal Navigation Versions: 2.0-dev/cvs, 2.0-a1 Reporter: Scott T Weaver Assignee: Randy Watler Priority: Critical We still haven't settled on how we are going to generate navigations in J2. I have some modifications to the Profiler and to the theme logic which may give us some direction. I am bringing this up as I have been privellage to quite a few vendor portal demos lately allowing me to see both the good and the bad of multiple implementations. - I would say we replace the getDesktop() with getFolders(). There is really no need for a root item or Folder per se since we will be leaving this job to the current set of profilling rules that have been assigned to the Profiler. - Folders will contain any number of pages and/or folders. - Folder items would be ordered the following way: first by assigned index then by alphabetical order. - Remove defaultPage logic from Folder, the focused Folder item would be set in this fashion: set the focus to the last selected child in that Folder then by Folder Item ordering algothrim defined above. - It should be the Profiler's responsibility to preserve a user's active item on a per Folder basis. - A Folder would still posses the defaultTheme capabillity but with the added abillity to enforce the defaultTheme on its childern and its childrens' children by overriding the theme settings for those items with its own. - Rendering the contents of the Profiler.getFolders() would be left entirely up to the theme (currently called the layout decorator). Example: a theme could render the first 2 levels as tabs and the rest as a hierarchical menu to the left of the layout area. - DO NOT introduce the idea of controls and controllers. It has been stated before that these easily confuse people and I agree 100%. We need to keep things simple. I think the first profiling/navgation implementation would be assigning n number of roles to a top-level folder. Then allow the Profiler to aggregate what Folders a user has access to by comparing the roles that user is assigned to the ones required the Folders required roles (ACL?) I think this approach is already somewhat in place but it just needs some final implementation details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ]
Randy Watler commented on JS2-69:
-
After reviewing Ate's proposal and comments from 7/3/2004,
(http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=15857), and
factoring in recent discussions on the topic, it seems that there is the
beginning of a consensus around providing a profiled view of folders and pages
from the root to a specified depth. This top level site map could be used to
drive global portal navigations that supplement or replace the existing page
relative navigation elements.
Generally, the goal is to provide some basic information out of the box,
(i.e. w/o the need for document sets or other configuration information), to
support typical navigations for small to medium sized portals.
Support for profiling is a must, so simply returning a reference to the
underlying physical view of the portal content is not acceptable. However, a
hierarchical object representation of the site map that contains profiled
folders and documents is probably required to allow nested menu representations
including javascript dhtml pulldown renderings to be constructed easily.
The desired depth of the root level site map would probably need to be
somewhat variable to support ragged pulldown menu trees. Consequently, it seems
that some form of a menu definition will be required, minimally some kind of
path set specification like: {/*,/*/,/deep0/*,/deep1/*,/deeper/*/}. Of
course, a simple default like {/*,/*/*} would due in many cases. If paths are
too limiting, a full XML menu definition might be required... but there have
been other votes against such a thing.
This site map would probably be specified globally, or possibly at the
individual folder level. If folder level specification is required, it should
support some form of inheritance so that navigations specified in the root or
parent folders would serve as the default folder menu definition.
Given that the profiler would be used to generate this site map, it does not
seem that any capability to specify multiple menu definitions per user, group,
role, mediatype, etc. would be needed or desirable. Instead, the contents of a
single site map would be determined by profiler folder aggregation and
security filtering. If folder level specification is implemented, the specific
folder and menu definition could also be selected by the profiler as a by
product of selecting the portal page to be displayed.
Caching of these portal site maps can be significantly easier than reusing
the existing navigational elements generated today. In fact, if folder level
specification is not supported and a single global menu definition is allowed,
the resulting site map can be generated once and cached per session. This
advantage should be carefully considered when making the decision to support
folder level specification.
Finallizing Portal Navigation using the Profiler
Key: JS2-69
URL: http://issues.apache.org/jira/browse/JS2-69
Project: Jetspeed 2
Type: New Feature
Components: Profiling/Portal Navigation
Versions: 2.0-dev/cvs, 2.0-a1
Reporter: Scott T Weaver
Assignee: Randy Watler
Priority: Critical
We still haven't settled on how we are going to generate navigations in J2.
I have some modifications to the Profiler and to the theme logic which may
give us some direction. I am bringing this up as I have been privellage to
quite a few vendor portal demos lately allowing me to see both the good and
the bad of multiple implementations.
- I would say we replace the getDesktop() with getFolders(). There is really
no need for a root item or Folder per se since we will be leaving this job
to the current set of profilling rules that have been assigned to the
Profiler.
- Folders will contain any number of pages and/or folders.
- Folder items would be ordered the following way: first by assigned index
then by alphabetical order.
- Remove defaultPage logic from Folder, the focused Folder item would be set
in this fashion: set the focus to the last selected child in that Folder then
by Folder Item ordering algothrim defined above.
- It should be the Profiler's responsibility to preserve a user's active item
on a per Folder basis.
- A Folder would still posses the defaultTheme capabillity but with the added
abillity to enforce the defaultTheme on its childern and its childrens'
children by overriding the theme settings for those items with its own.
- Rendering the contents of the Profiler.getFolders() would be left entirely
up to the theme (currently called the layout decorator). Example: a theme
could render the first 2 levels as tabs and the rest as a hierarchical menu
to the left of the layout area.
- DO NOT introduce the idea of controls and controllers. It has been
Re: J2 - Menu Navigation - Root Folder
Shah, Comments below Shah Amit wrote: I have been able to implement all that you have pointed me. Thanks a lot for helping me out with this. I think I do get the idea of having document sets. Its a good concept. Good. There is much to grasp here. There is a design document I failed to mention that might be helpful to some degree on the Profiler. It is located in CVS at: /design-docs/src/profiler/J2-page-manager-profiling.sxw. This is an OpenOffice document... let me know if you need another format. I have a couple of confusions though. - In the document sets, there is a profile-locatorpage/profile-locator. I dont know what that is for. This is used to specify an alternate profiling locator name/rule to use when determining the document set elements. page is the default profiling locator name used to identify the profiling rule for the user that selects pages and navigational elements for a request url. - Also you wanted to explain me on how to get this more dynamic with the help of profiler. I guess you can shoot that and I will try to grasp the concept. The profiler is used to define a logical view of the pages, folders, and other documents that exist in the physical file system. Essentially, it filters and/or aggregates various folders and their contents into a contiguous content space accessible via the portal request urls. It does this by applying profiling rules that can map portal content by user, roles, groups, subsites, and other criteria to construct the end user's view of the portal content. In your case, you can use the profiler to generate a different view for the guest user by placing a modified version of customer_area.ds in /_user/guest/customer-area.ds. It could define no document paths at all and make the customer-area.ds content essentially invisible. This works because the profiler aggregates /* and /_user/guest/* portal content, with the more specific content taking precedence. The profiler can also be used to control what content is visible for logged in users. For example, if your users are assigned the group-fallback page profiling rule, different versions of the customer-area content could be placed in separate group-specific folders. Say you had two versions of customer-area content for your two user groups p1 and p2. If you left the document sets as defined earlier, you could put various psml pages in: /_group/p1/customer-area/comparison-tools/*.psml and /_group/p2/customer-area/comparison-tools/*.psml. Then, when users that belonged to the p1 group were authenticated, they would see the aggregation of the global and group-specific comparison-tools content. Security specifications in the files can be used to further filter pages, folders, and other documents selected by the profiler. Again, take a look at the J2 demo content and you will find many test cases for the profiler and security functionality. Log in and out using the following user/passwords to see various profiling and security effects: user/user, manager/manager, jetspeed/jetspeed, and admin/admin. Of course, please ask questions! - (This is not so relevant to this discussion, but) the pages directory that we are talking about --- I still have to put it under tomcatInstall/webapps/jetspeed/WEB-INF/pages/... I asked a question before and David said I can have the pages under my own portlet webapp and access it on the internet with -- http://localhost:8080/jetspeed/portlet/myApp/myPage.psml I tried that and it did not work. This however is not that big of an issue, but just a nice thing to have... I am not sure about this... David will have to clarify. AFAIK, the location of the pages directory is specified in the bean specification of the document handlers in /portal/src/webapp/WEB-INF/assembly/page-manager.xml. Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 - Menu Navigation - Root Folder
Amit, Shah Amit wrote: Also just a thought -- I dont know if this is already there, but wouldn't it be a good thing for a document set to have a default page too (just like a folder has). This way even a .ds can be a link and when clicked on, the active page can be shown ?? .. This can be not a very smart idea, but I dont know too much stuff around so just tossing it. I suppose this could be done, however, there is no functionality like this at the moment. I will add it to my J2 list of items to consider. Please let me know if this becomes something that you need for your implementation. Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More Login/Security Enhancements
Ate/All, I have these additional Login/Security requirements that have made there way into a formal requirements process for our portal implementation: - Send email to end user for forgotten passwords, (offered on failed login attempts if user email address known). - Ability of a non-authenticated end user to create and populate a disabled user account to be enabled later by admin/moderator, (includes automatic email notification of the request and approved/denied messages if user email address known). I think these features are fairly typical for most sites requiring end user authentication. Is there any interest in, (or objections to), these features being added to J2 proper? If there is interest, I will generate a JIRA issue and we can see if there are other similar capabilities that can be added at the same time. Thanks! Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Declarative or Modal Page Layout Navigation?
Team, David and I have been discussing potential options to the current profiler/page-manager generated page layout navigations. While what we have seems to be fairly powerful and flexible, it also seems to be too complex and/or scalable for use by many users. It often raises questions on the lists and certainly does not seem self documenting! We have discussed implementing a declarative navigation definition, (i.e. J1 menus), that could be specified globally or at the folder level. We have also pondered some modal configuration settings/hints to the existing solution that correspond to different navigational styles, (i.e. relative forward/back navigation as we currently have, constant navigation elements that reflect the physical folder structures, logical view specifications like document sets, etc.). Obviously, changes to support these different modes would also involve modifications to the various velocity layout templates. Related efforts might include support for javascript pull down menus or other portal navigation interfaces. I would like to get input from the team on whether it is time to consider such an effort and indeed what the effort should look like and include. Any and all input will be appreciated! Thanks, Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 - Menu Navigation - Root Folder
Shah, Right the problem is that the API is not designed to allow arbitrary use of the getParent() method because the profiler does not construct a complete view of the site on each page request. The reason is that it can be costly generate views of the site that are not necessarily going to be visited by the user. Instead, we would expect this to be done using document sets. Perhaps it is easy, perhaps not. Can you please generate an example set of folders and pages you'd like to add to your layout and I'd be glad to assist. Thanks, Randy Shah Amit wrote: Hi David, Reposing my question on the developer thread. The problem is org.apache.jetspeed.profiler.ProfiledPageContext interface and all the other related interfaces are very convinient to navigate child elements. But it is tough to reach the root folder, or to traverse up the tree. Now the reason I need to traverse up the tree is because I need to display a tabbed menu interface which goes 3 levels deep. Something similar to amazon.com. Now all the samples included in J2 display all the child folders and sub-elements, but there is no example that basically displays everything under pages directory in like a tree format and let user choose where he wants to go. Would really appreciate any help. For now the I am thinking of workaround where I will go 5 levels down. I dont think I need to worry for more than that. Also to reach the root folder, I am using following macro - #macro(createTree $folder) #set($parent = $folder.getParent()) #if($parent != /) #createTree($parent) #else #set($folder=$parent) #end #end Thanks for all your helps, Amit - 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]
Re: J2 - Menu Navigation - Root Folder
Shah, Ok does not look too difficult at this point. How do you want to arrange the psml pages physically in your file system? Do you have other profiling requirements... other views based on user/role/group or authentication? Randy Shah Amit wrote: Hi Randy, Here is the tree that I want to create for my website - - Home (psml) - Contact Us (psml) - About Us (psml) - Products (SubMenu) - Product 1 (psml) - Product 2 (psml) - Product 3 (psml) - Customer Area (SubMenu) - Download Reports (SubMenu) - Report 1 (psml) - Report 2 (psml) - Comparision tools (SubMenu) - Tool 1 (psml) - Tool 2 (psml) How should I lay it out and how should I write my decorator so that I can display this tree on the left as my navigation menu ... Thanks, Amit Original Message Follows From: Randy Watler [EMAIL PROTECTED] Reply-To: Jetspeed Developers List jetspeed-dev@jakarta.apache.org To: Jetspeed Developers List jetspeed-dev@jakarta.apache.org Subject: Re: J2 - Menu Navigation - Root Folder Date: Wed, 16 Feb 2005 10:54:52 -0700 Shah, Right the problem is that the API is not designed to allow arbitrary use of the getParent() method because the profiler does not construct a complete view of the site on each page request. The reason is that it can be costly generate views of the site that are not necessarily going to be visited by the user. Instead, we would expect this to be done using document sets. Perhaps it is easy, perhaps not. Can you please generate an example set of folders and pages you'd like to add to your layout and I'd be glad to assist. Thanks, Randy Shah Amit wrote: Hi David, Reposing my question on the developer thread. The problem is org.apache.jetspeed.profiler.ProfiledPageContext interface and all the other related interfaces are very convinient to navigate child elements. But it is tough to reach the root folder, or to traverse up the tree. Now the reason I need to traverse up the tree is because I need to display a tabbed menu interface which goes 3 levels deep. Something similar to amazon.com. Now all the samples included in J2 display all the child folders and sub-elements, but there is no example that basically displays everything under pages directory in like a tree format and let user choose where he wants to go. Would really appreciate any help. For now the I am thinking of workaround where I will go 5 levels down. I dont think I need to worry for more than that. Also to reach the root folder, I am using following macro - #macro(createTree $folder) #set($parent = $folder.getParent()) #if($parent != /) #createTree($parent) #else #set($folder=$parent) #end #end Thanks for all your helps, Amit - 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] - 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]
Re: [J2] New PAM/Deployer
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Re: [J2] New PAM/Deployer
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [J2] New PAM/Deployer
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetspeed2 and jboss
Marek, We are in the middle of changing the webapp deployer implementation. Are you using the J2 M1 binary or a recent cvs HEAD? What OS platform are you running on? You might want to check out the archives of the user and dev lists... there has been some recent J2/JBoss traffic. Randy [EMAIL PROTECTED] wrote: Hello I deployed JS2 at jboss4.0.1. I started jboss, I saw some output at its console, until it freezes. Jboss is working properly, except the console (standard output) is frozen and no message appeares there (neither in log files boot.log and server.log). After console freezes I can see these messages (JNDI System Property flag null is the last message). Well maybe it's something about log4j - it's only mu suspicion: 23:36:13,375 INFO [Engine] StandardContext[/demo] Velocity [info] Velocity successfully started. 23:36:13,445 INFO [Engine] StandardContext[/demo] Velocity [info] ServletTool boxManager: Using config file '/WEB-INF/velocity/toolbox.xml' 23:36:13,445 INFO [Engine] StandardContext[/demo] Velocity [debug] XMLToolboxM anager: Loading toolbox... 23:36:13,475 INFO [Engine] StandardContext[/demo] Velocity [debug] XMLToolboxM anager: Toolbox loaded. 23:36:13,475 INFO [Engine] StandardContext[/demo] Velocity [info] ServletTool boxManager: Toolbox setup complete. 23:36:13,475 INFO [Engine] StandardContext[/demo] Velocity [info] VelocityVie wServlet: Default content-type is: text/html 23:36:13,745 INFO [TomcatDeployer] deploy, ctxPath=/jetspeed, warUrl=file:/E:/j boss/server/default/deploy/jetspeed.war/ 23:36:16,620 INFO [console] Jetspeed Starting Initialization... 23:36:16,690 INFO [console] JetspeedServlet identifying web application root... 23:36:16,690 INFO [console] JetspeedServlet identifed web application root as E :\jboss\server\default\deploy\jetspeed.war\ 23:36:16,910 INFO [console] JetspeedServlet attempting to create the portlet e ngine... 23:36:17,050 INFO [Jetspeed] Jetspeed environment attempting to initialize port al Engine... 23:36:17,070 INFO [STDOUT] JNDI System Property flag null Any idea? Regards Marek - 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]
Re: Stackoverflow with JetspeedPowerTool
Christophe, Yes, David had this bug yesterday/last night. He'll have to comment since I have not seen it. Randy Christophe wrote: Hi All, With a recent cvs update, I got a StackOverFlow when I connect to the default J2 application. This issue occur only when I'm running Tomcat in debug mode within eclipse :-( When running in a normal mode, everything works like a charm. I'm just wondering if someone can reproduce this strange problem ? Thanks, Christophe Here is the velocity.log file : 2005-02-03 23:13:26,907 [http-8080-Processor25] ERROR velocity - Method getTitle threw exception for reference $jetspeed in template /WEB-INF/decorations/portlet/html/tigris/decorator.vm at [40,13] 2005-02-03 23:13:26,907 [http-8080-Processor25] ERROR velocity - VelocityViewServlet: Exception processing the template: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getTitle' in class org.apache.jetspeed.velocity.JetspeedPowerTool threw exception class java.lang.StackOverflowError : null - 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]
Re: [J2] New PAM/Deployer
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
latest FileSystemPAM mods
Scott,
I am confused by this change to FileSystemPAM:
@@ -387,6 +387,12 @@
// save it to the registry
log.info(Saving the portlet.xml in the registry...);
+if(registry.namedPortletApplicationExists(app.getName()))
+{
+log.warn(Deployment has found an app with the application name, +app.getName()+
+. The existing app will be removed in favor of this one.);
+undeploy(paWar);
+}
registry.registerPortletApplication(app);
log.info(Committing registry changes...);
I would like this logic to somehow be moved to the
DeployPortletAppEventListener instead of bailing out in the middle of a
registration process here by undeploying. Under what conditions were you
trying to undeploy here? I do not understand how this could even happen
unless there were some kind of race condition involved... what am I missing?
I was not able to port this change forward into my version of
FileSystemPAM. We need to resolve this issue if we need to preserve this
functionality.
Randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JS2 deployment
Marcel, I am not familiar with deployment under JBoss. However, the implementation is stubbed out because the inderlying file system PAM deployment strategy might have been thought to be sufficient. Perhaps it is not. I am wondering what you intended to do while customizing/implementing the JBossManager. I was also looking for any insight you might have on the general approach of letting JBoss simply pick up webapps war files dynamically dropped into its deployment directory. In otherwords, how and does JBoss implement an autoDeploy or liveDeploy Tomcat equivalant? Anyway, if you do develop/implement JBossManager, I still plan on being able to support it since I am leaving the existing PAM implementation functional. Randy Marcel Dullaart wrote: Hi Randy, Thanx for your answer. I only want to make J2 run on JBoss 4.0.1. At this moment I got J2 showing only title bars for the portlets but lacking any content. Since the JBossManager takes care of deploying the portlets under JBoss, and it is not fully implemented, it only contains stub impl's AFAIK. That's why I thought I needed to implement it. Marcel On Mon, 31 Jan 2005 10:36:25 -0700 (MST), [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Marcel, I am working on this for the team. Can you post the details of what you would like to accomplish in your custom ApplicationServerManager? The hope is that we no longer need these custom implementations that are difficult for us to support. The general approach is to rely on the auto/live deployment features of the container instead of trying to interface to each. Details would be much appreciated at this point since I am reworking the PAM implementation. I am also trying to keep the old deployer functional, so if I succeed, you can always go back an use your ASM implementation if necessary... hopefully not. Randy Hi David, This means that we will no longer need specific code for application deployment to each app server. In theory, this may solve our race condition issues. Does this in anyway influence the ApplicationServerManager interface and its implementations? I noticed that the JBossManager is not implemented, only stubs are provided, and planned on implementing it. Thanx, Marcel - 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] - 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]
Re: Creating a new portlet from scratch
Try here first: http://wiki.apache.org/portals/Jetspeed2 And then the archives for this mail list. Randy Gaurav Vaish wrote: Hi, I just downloaded JetSpeed-2, the overlay format, and got it integrated on Tomcat. Where do I start with to create a new portlet? I mean... how do I register new portlet? Where and what changes do I need to make? Happy Hacking, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com - - 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]
[J2] Unix style page/folder permissions/constraints
After letting the existing page/folder security implemention accumulate some road miles, we have revised its operation slightly to eliminate unexpected behavior. No changes have been made to the constraint syntax in the *.psml, folder.metadata, page.security, etc. files. Only these new rules have been implemented within the PageManager and its pieces parts to deliver a Unix type file system behavior: - view permissions are checked on the entity and all folders recursively up through root. - edit, (or other), permissions are checked only on the entity. Only *.link files to absolute urls are exempt from the view permissions checks, (but still require the recursive folder view checks). This change also required a slight change to the visibility rules for folder navigation elements. Instead of simply checking the folder view permissions, the PageManager now checks to see if there are any accessible files in the directory according to the active profiler rules. If not, the folder is filter from the navigational set. Along with this change, I have also revised the permissions and constraints on many of the pages and folders in the root directory. By default, most of the pages require a login with the user role. To make any particular page publicly visible, modify its constraints as follows: security-constraints security-constraints-refpublic-view/security-constraints-ref /security-constraints or security-constraints security-constraints-refpublic-edit/security-constraints-ref /security-constraints or move it to the /Public folder with no constraints. If you are feeling particularly brave and you did not simply move the page to the /Public folder, also edit the four populate-userinfo-for-default-psml.sql variants, copying the entries in SECURITY_PERMISSION and PRINCIPAL_PERMISSION for '/rss.psml' and rename the page name accordingly. Of course, you can just ask me to promote a page to public access and I'll take care of it when I get an opportunity! Randy
[J2] Subsite Isolation/Partitioning Profling
I have implemented a new feature in the PageManager to leverage use of the navigation profiling rule to provide subsite isolation/partitioning. I have also extended the J2 demo site to add a subsite. While not related to subsites per se, this example also has two users associated with it to demonstrate a handy profiling technique that can be used to specify default pages for users with multiple roles. Login and subsite/subsite or subsite2/subsite2 to navigate to the subsite. Note that you will be deposited in different default pages depending on the user's profiling rule and that the global navigation elements from the root directory are not included in the subsite. The content for this subsite is located in ../WEB-INF/pages/__subsite-root, (note that subsites will always be denoted by the __ prefix). See the remaining configuration details in populate-userinfo-for-default-psml.sql. Security configuration is not partitioned and is still controlled globally by the principal configurations in the security DB tables and the /page.security file. Consequently, a principle will have to have view permissions on / in order to view the subsite. We can consider partitioning the security infomation per site if it seems appropriate in the future... I did not see the immediate value in attempting this at this point without input from others. No doubt the subsite profiling and related security issues may need tuning as they are used. Feedback is always welcome! Randy
[J2] Tigris/Jetspeed Layout Decorator Enhancement
The Tigris and Jetspeed layout decorators have been modified to more gracefully handle the lack of Folders and Pages and Additional Links navigational content. These panes will now disappear alltogether instead of remaining on the page if they are empty. Furthermore, the entire navigational column will not appear if no navigational elements are present. This leaves the entire browser window width for the portlets in this case. As an additional note, the NodeSet implementation has been extended to support the standard Collections isEmpty() method. This means that the various navigation collections accessed via the $site variable in the Velocity templates can be tested for the empty state using this method instead of checking size(). Randy
Re: [J2] page update from layout portlets implementation question
Team, I have simply protected the calls into the PageManager from the MultiColumnPortlet to prevent it from disrupting the generation of the page in a SecurityException. I think it is necessary to leave the updates in place to save the results of running the Customizer. Of course, if you do not have edit permission to the underlying page, you should never be given the Customization option/buttons. I am still testing this solution out, but it has been committed. Please let me know if you see any fatal page generation failures. Instead, you should see an informational message in the logs like this: Unable to update page /default-page.psml layout due to security permission/constraint. Randy Randy Watler wrote: Ate, Thanks for the reply. Inline clarifications below. Randy Ate Douma wrote: Randy Watler wrote: Team, Ate found a situation where page security implemented in the PageManager is causing a permitted page view to fail. As some of you know the page layout portlet attempts to update the page if it has had to adjust rows and columns while laying out the fragments. This request is made via the PageManager, (David was not aware this was being done, so perhaps someone can recall why this is being done at all)? If the user does not have edit permission when the layout update is requested, I was simply going to silently skip the persistent update, leaving the trasient edits in place. The problem with this is that if a page owner comes back in later, the previous update will not need to be done and thus the page update would not be done as intended either. I could: - let the layout portlet simply skip the update, Not sure what the consequences are. Really depends on *why* the updates are done. I don't know for sure. Others will have to comment, but the layout edit really does take place... it is just not being stored persistently. - try to perfrom the update as admin by changing the login for the duration of the update, That might still fail if even the admin doesn't have edit privs (strange maybe, but true in my usecase) Yes, but then it just degenerates to the first case, (silently skips the update). - add some kind of dirty flag to the page, or And then what? Actually perform the update when/if a privleged user uses the page. In otherwords, keep trying the update from the layout portlets if the transient dirty flag is set and clear the flag if it succeeds. - add an API to PageManager that allowed the usual security checks to be skipped. Looks like a backdoor construction to me. And know that the LayoutPortlets probably won't be running under the jetspeed context in the near future (the issue about allowing jetspeed to run under a different context). Than such a solution would really need to open up the security. I think this is why David is asking why this is being done at all... :). Thoughts? Sorry for not giving any real positive answer :-) 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JS2 deployment
David/Scott, I like this solution... it is MUCH cleaner codewise than trying to deal with the various application servers/environments. I'll give it a try sometime tomorrow. A few questions for the uninformed: - I am assuming that the various portlet apps would never actually invoke the JetspeedContainerServlet... is that right? If so, perhaps it would be better to use a listener/ServletContextListener hook: this might be easier to infuse in the web.xml. - All of this works because Jetspeed-commons resides in a shared class loader, right? Is that functionality part of the Servlet Container spec... must be, no? - Are you imagining this as strictly a build time tool or are you thinking we could encorporate the logic in the deploy-tool to the existing File based PAM and deploy complete war files into webapps at runtime? I will ponder more while I get some sleep... Randy -Original Message- From: David Sean Taylor To: Jetspeed Developers List Sent: 1/18/05 1:55 PM Subject: JS2 deployment Randy, Since you are working on deployment issues, thought I share this with you. We (Scott and I) would like to consider a new (old) method to deployment. This method would hook into the servlet init, and register the portlet application to Jetspeed during servlet initialization. If you set the app to init at startup, then your PA will get registered during app server startup. This means that we will no longer need specific code for application deployment to each app server. In theory, this may solve our race condition issues. Start with a look at the JetspeedContainerServlet in the commons directory. It has a registerAtInit init parameter. I added this functionality a while back as a solution to register with Jetspeed during servlet init - so that we don't have to worry about deployment issues specific to app servers. In the long run the current method won out, but we are now reconsidering this method. Finally, there is also a command line utility for registering portlet applications. See the deploy-tool component, and the uberjar goal Give it a spin and let us know what you think, -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[J2] page update from layout portlets implementation question
Team, Ate found a situation where page security implemented in the PageManager is causing a permitted page view to fail. As some of you know the page layout portlet attempts to update the page if it has had to adjust rows and columns while laying out the fragments. This request is made via the PageManager, (David was not aware this was being done, so perhaps someone can recall why this is being done at all)? If the user does not have edit permission when the layout update is requested, I was simply going to silently skip the persistent update, leaving the trasient edits in place. The problem with this is that if a page owner comes back in later, the previous update will not need to be done and thus the page update would not be done as intended either. I could: - let the layout portlet simply skip the update, - try to perfrom the update as admin by changing the login for the duration of the update, - add some kind of dirty flag to the page, or - add an API to PageManager that allowed the usual security checks to be skipped. Thoughts? Randy
[J2] supported hidden document attribute in PageManager
I have added filtering of hidden pages, folders, (folder.metadata), links, and document sets to the PageManager. This provides a way to remove a page or other document from the site navigations, but still allows the page or folder to be accessed directly by url. The following navigation elements are now filtered if the hidden attribute is set in the navigation targets: sibling pages, sibling folders, parent folder, document sets, document set nodes, and root links. The new utility pages in /Administrative/choosers and the folder that contains them are marked as hidden. I have also marked the my-account.psml page as hidden on a trial basis. It is still accessible by the profiling rules invoked for an expired login and explicitly by the link in the security login portlet. Ate: feel free to revert this change if you feel the page should always be visible! As usual, let me know if I broke anything! Randy
Re: Help! Not able to setup Jetspeed2 properly
Carlos, Please use the user list instead of the dev list. Others have reported seeing this. Make sure that the jetspeed.xml file is located in the proper tomcat conf subdirectory, (TOMCAT_HOME/conf/Catalina/localhost and that you are using the default server.xml names for the Tomcat Service, Engine, and Host tags. AFAIK, starting with a clean Tomcat install and an original server.xml file has eliminated this problem for others. Randy Carlos Ortiz wrote: I have the same problem. Anybody nice enough to put a step-by-step guide to compliment the jetspeed2 installer? Thanks, Carlos. -Original Message- From: Roland Ukor [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 04, 2005 4:01 PM To: 'Jetspeed Developers List' Subject: Help! Not able to setup Jetspeed2 properly Hi everyone, Kudos for the work you're all doing. I had successfully experimented with Jetspeed 1.5. I download Jetpseed2 M1 and unzipped it on top of my existing tomcat 5.0.27 folder. I started tomcat but it reported the following exception which could not allow the application to initialize. 004-12-23 16:16:04 StandardContext[/jetspeed] Velocity [error] Problem loading toolbox '/WEB-INF/toolbox.xml' : java.lang.NullPointerException 2004-12-23 16:16:04 StandardContext[/jetspeed] Velocity [error] java.lang.NullPointerException at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 40) at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 66) at org.apache.commons.digester.Digester.endElement(Digester.java:1061) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unk nown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis patcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno wn Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1567) at org.apache.velocity.tools.view.XMLToolboxManager.load(Unknown Source) at org.apache.velocity.tools.view.servlet.ServletToolboxManager.getInstance (Unknown Source) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.initToolbox(U nknown Source) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.init(Unknown Source) at org.apache.jetspeed.velocity.JetspeedVelocityViewServlet.init(JetspeedVe locityViewServlet.java:132) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav a:1029) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:862) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.j ava:4013) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4357 ) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja va:823) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeplo yer.java:903) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:2 52) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1058) at org.apache.catalina.util.CatalinaDigester.endElement(CatalinaDigester.ja va:76) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unk nown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis patcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno wn Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at
Re: jetspeed2,portlet,jsf
Carlos, Again, please stick to the user list. Yes, this is possible. There are JSF example portlets and a JSF bridge using myfaces developed by other dev team members. Randy Carlos Ortiz wrote: It is going to be possible to use jsf within jetspeed2 container? I have existing jsf apps that I would like to quickly port to portlets with minimal re-coding like the jsf-portlet-bridge. Thanks, Carlos. - 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]
Re: M1 Security Schema MSSQL Constraints
Gang, Ok, I will look into extending the Torque macros to add support at the DB level via triggers. I am not sure it is possible, (it will depend on what cross table access to the schema definition is available from the velocity templates). BTW, it does not appear that commons-sql supports MS SQL Server triggers either. Randy David Sean Taylor wrote: On Dec 20, 2004, at 7:35 AM, Scott T. Weaver wrote: I am getting the same thing now. We need to role back the SQL logic to the point before the M1 release when this was not an issue. If we role back the logic, then the cascading deletes will no longer work leaving orphaned records requiring us to programmatically implement cascading deletes Im -1 on that and much prefer the backend database to manage data integrity But i don't care about MSSQL. If you all need to remove the FK for MSSQL then thats fine by me. We could make it configurable in the build Randy Watler wrote: David/Ate/Scott, While executing the M1 scripts for DB configuration of MS SQL Server 2K, I ended up with these errors: db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security- schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SSO_PRINCIPAL_TO_REMOTE ADD CONSTRAINT SSO_PRINCIPAL_TO_REMOTE_FK_2 FOREIGN KEY (REMOTE_PRINCIPAL_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SSO_PRINCIPAL_TO_REMOTE_FK_2' on table 'SSO_PRINCIPAL_TO_REMOTE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. -- db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security- schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SECURITY_USER_ROLE ADD CONSTRAINT SECURITY_USER_ROLE_FK_2 FOREIGN KEY (USER_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SECURITY_USER_ROLE_FK_2' on table 'SECURITY_USER_ROLE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. -- db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security- schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SECURITY_USER_GROUP ADD CONSTRAINT SECURITY_USER_GROUP_FK_2 FOREIGN KEY (USER_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SECURITY_USER_GROUP_FK_2' on table 'SECURITY_USER_GROUP' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. -- db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security- schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SECURITY_GROUP_ROLE ADD CONSTRAINT SECURITY_GROUP_ROLE_FK_2 FOREIGN KEY (ROLE_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SECURITY_GROUP_ROLE_FK_2' on table 'SECURITY_GROUP_ROLE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. I worked around this by patching the constraints setting them to DELETE NO ACTION, but I have not attempted to diagnose or fix this issue for real. Anyone else seen these errors
Re: M1 Security Schema MSSQL Constraints
I believe that changes to security-schema.xml on 12/3 just before the M1 release that included adding on delete cascade to these foreign keys is what broke the MSSQL configuration for me. While I believe these constraints are appropriate schema wise, I am afraid they are hitting a MS SQL Server 2000 limitation. Fixing this probably involves customizing Torque... something Ate is pondering replacing... not sure it is worth the trouble. If we want to keep the cascading deletes, a Simpler fix might involve splitting the usage of the SECURITY_PRINCIPAL into its separate usages, (i.e. USER_PRINCIPAL, ROLE_PRINCIPAL, GROUP_PRINCIPAL, and REMOTE_PRINCIPAL). This way, the cascading delete will not attempt to visit the same table twice. Will this change cause problems in the admin portlets? Any thoughts on preserving the SECURITY_PRINCIPAL heterogeneous mapping vs. cascading deletes? Does anyone want to even consider extending Torque? Randy Randy Watler wrote: Guys, Apparently, multiple foreign keys to a single related table with an ON DELETE CASCADE constraint is not supported in MS SQL Server by design. It requires use of yet another trigger to implement. Unfortunately, this is not the first time I have been told to use a trigger for basic constraints, (such as ON DELETE SET NULL), in MS SQL Server, :-(. I am no SQL Server expert, so does anyone else care to attempt this before I do? Randy rwatler wrote: David/Ate/Scott, While executing the M1 scripts for DB configuration of MS SQL Server 2K, I ended up with these errors: db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security-schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SSO_PRINCIPAL_TO_REMOTE ADD CONSTRAINT SSO_PRINCIPAL_TO_REMOTE_FK_2 FOREIGN KEY (REMOTE_PRINCIPAL_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SSO_PRINCIPAL_TO_REMOTE_FK_2' on table 'SSO_PRINCIPAL_TO_REMOTE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. ... - 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]
M1 Security Schema MSSQL Constraints
David/Ate/Scott, While executing the M1 scripts for DB configuration of MS SQL Server 2K, I ended up with these errors: db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security-schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SSO_PRINCIPAL_TO_REMOTE ADD CONSTRAINT SSO_PRINCIPAL_TO_REMOTE_FK_2 FOREIGN KEY (REMOTE_PRINCIPAL_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SSO_PRINCIPAL_TO_REMOTE_FK_2' on table 'SSO_PRINCIPAL_TO_REMOTE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. -- db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security-schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SECURITY_USER_ROLE ADD CONSTRAINT SECURITY_USER_ROLE_FK_2 FOREIGN KEY (USER_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SECURITY_USER_ROLE_FK_2' on table 'SECURITY_USER_ROLE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. -- db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security-schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SECURITY_USER_GROUP ADD CONSTRAINT SECURITY_USER_GROUP_FK_2 FOREIGN KEY (USER_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SECURITY_USER_GROUP_FK_2' on table 'SECURITY_USER_GROUP' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. -- db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security-schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SECURITY_GROUP_ROLE ADD CONSTRAINT SECURITY_GROUP_ROLE_FK_2 FOREIGN KEY (ROLE_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SECURITY_GROUP_ROLE_FK_2' on table 'SECURITY_GROUP_ROLE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. I worked around this by patching the constraints setting them to DELETE NO ACTION, but I have not attempted to diagnose or fix this issue for real. Anyone else seen these errors? Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: M1 Security Schema MSSQL Constraints
Guys, Apparently, multiple foreign keys to a single related table with an ON DELETE CASCADE constraint is not supported in MS SQL Server by design. It requires use of yet another trigger to implement. Unfortunately, this is not the first time I have been told to use a trigger for basic constraints, (such as ON DELETE SET NULL), in MS SQL Server, :-(. I am no SQL Server expert, so does anyone else care to attempt this before I do? Randy rwatler wrote: David/Ate/Scott, While executing the M1 scripts for DB configuration of MS SQL Server 2K, I ended up with these errors: db.execute: [echo] Executing scripts for ./sql/DDL/mssql/security-schema.sql [sql] Executing file: /usr/share/tomcat5/jetspeed-database/scripts/sql/DDL/mssql/security-schema.sql [sql] Failed to execute: BEGIN ALTER TABLE SSO_PRINCIPAL_TO_REMOTE ADD CONSTRAINT SSO_PRINCIPAL_TO_REMOTE_FK_2 FOREIGN KEY (REMOTE_PRINCIPAL_ID) REFERENCES SECURITY_PRINCIPAL (PRINCIPAL_ID) ON DELETE CASCADE END BUILD FAILED /usr/share/tomcat5/jetspeed-database/scripts/build.xml:64: The following error occurred while executing this line: /usr/share/tomcat5/jetspeed-database/scripts/build.xml:38: java.sql.SQLException: Introducing FOREIGN KEY constraint 'SSO_PRINCIPAL_TO_REMOTE_FK_2' on table 'SSO_PRINCIPAL_TO_REMOTE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 M1 Binary Install Notes
David, Of course. I was just documenting for our own consumption here on the dev list... especially given the ongoing work on the installer. Randy David Sean Taylor wrote: Randy Watler wrote: A few notes on the M1 install process for Tomcat 4/5 and Linux: Thanks Randy I will update the README notes I was aware of your issues with the install procedure, but I figured it would make it easy for the majority of the users. Users such as yourself with Linux knowledge can easily adapt the tar expansion to meet the custom needs of your configuration. I had limited time for the install and I hope we can improve on the procedure in future releases You may also want to try out the installer that Scott checked in yesterday. I haven't had a chance to try it yet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 autodeployment.catalina.base jetspeed.properties setting
David,
David Sean Taylor wrote:
Scott T. Weaver wrote:
Randy Watler wrote:
I use JPackage RPM installs for tomcat4 and tomcat5 on Linux. Over
the last day or two, I have been struggling to get a clean startup
on tomcat5. After I eliminated all of my stupid user tricks, I was
able to get everything to deploy cleanly only after customizing the
setting of autodeployment.catalina.base in
jetspeed.properties/override.properties. The reason this is
necessary is that the default setting, ${applicationRoot}/../../,
does not resolve to the base tomcat5 install directory that contains
conf, (primarily due to copious use of symbolic links and the
relocation of config files to /etc on Linux). The deployer requires
access to this directory to install the security.xml file in
conf/Catalina/localhost.
Doesn't Tomcat have a way to deploy an xml descriptor ?
I would prefer this approach if possible
I'll look into it before I make any changes.
Randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JS2-170) Im getting org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null'
Matthew, Please make sure that your jetspeed.xml configuration file is installed in the correct location. For Tomcat5, it should be installed in $TOMCAT_HOME/conf/Catalina/localhost. For Tomcat4, it should be installed in $TOMCAT_HOME/webapps. Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M1 problem -- velocity tools?
John, Indeed, I believe that the problem you saw was due to a tomcat 5 setup problem that leads to an incorrect J2 initialization. I saw the same thing when the tomcat5 conf entry Catalina/localhost/jetspeed.xml is not found. In my case, it was due to changing the tomcat Engine and Host names. HTH, Randy -Original Message- From: Randy Watler To: Jetspeed Developers List Sent: 12/6/04 11:38 AM Subject: Re: M1 problem -- velocity tools? John, ok, i am looking into it more now Randy John West wrote: You mean webapps/jetspeed/WEB_INF/toolbox.xml? It's the same as the one in CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat5 Engine/Host config, was: Re: M1 problem -- velocity tools?
John, I would get things working with Catalina/localhost first... changing the Engine name and Host name so that the installation and deployer function properly is apparently not trivial. The maven.xml quickStart goal appears to assume Catalina/localhost. So, you'd have to move things around in the tomcat5 conf directory to get it configured properly, (before tomcat5 is started). Then, you'd have to probably use override.properties to specify your engine to replace Catalina specified in jetspeed.properties, (of course, the host name is specified in your custom build.properties). Instead of going through all of this, I am going to try to use Catalina/localhost with an Alias for the production host name specified in the tomcat5 Host definition. I might clean this up a bit for the next J2 milestone release if I get a chance and we can come up with a cleaner implementation. Thanks for hanging in there! Randy John West wrote: Ah, that explains it then. I had recently changed the Engine and Host in my old install, and have not changed them in my reinstall. Thanks for your help! Randy Watler wrote: John, Indeed, I believe that the problem you saw was due to a tomcat 5 setup problem that leads to an incorrect J2 initialization. I saw the same thing when the tomcat5 conf entry Catalina/localhost/jetspeed.xml is not found. In my case, it was due to changing the tomcat Engine and Host names. HTH, Randy -Original Message- From: Randy Watler To: Jetspeed Developers List Sent: 12/6/04 11:38 AM Subject: Re: M1 problem -- velocity tools? John, ok, i am looking into it more now Randy John West wrote: You mean webapps/jetspeed/WEB_INF/toolbox.xml? It's the same as the one in CVS. - 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]
J2 autodeployment.catalina.base jetspeed.properties setting
Guys,
I use JPackage RPM installs for tomcat4 and tomcat5 on Linux. Over the
last day or two, I have been struggling to get a clean startup on
tomcat5. After I eliminated all of my stupid user tricks, I was able to
get everything to deploy cleanly only after customizing the setting of
autodeployment.catalina.base in jetspeed.properties/override.properties.
The reason this is necessary is that the default setting,
${applicationRoot}/../../, does not resolve to the base tomcat5 install
directory that contains conf, (primarily due to copious use of symbolic
links and the relocation of config files to /etc on Linux). The deployer
requires access to this directory to install the security.xml file in
conf/Catalina/localhost.
I'd like to propose setting the autodeployment.catalina.base property
from the org.apache.jetspeed.server.home customized build.properties
setting. In development, this could be integrated into portal/maven.xml
as is done with the other autodeployment properties. Of course, this
will definitely kill the property-less install goal.
We could also apply some kind of search path specification there as
well, (i.e. '${applicationRoot}/../../,
/etc/tomcat${autodeployment.catalina.version.major}/,
/usr/share/tomcat${autodeployment.catalina.version.major}/, c:/Program
Files/Tomcat/'), that would work for most common deployments.
If this were only a production issue, I'd just set the property in
override.properties and be done with it. However, my primary concern is
for development ease of use.
Thoughts?
Randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: M1 problem -- velocity tools?
John, This does not seem to be a Velocity issue, but rather a J2 startup problem, (velocity is just the first victim) The first problem is the weirdest... it is having problems reading the /WEB-INF/toolbox.xml config file. Can you validate its contents in the tomcat install directory against the CVS version? Randy -Original Message- From: John West To: [EMAIL PROTECTED] Sent: 12/6/04 9:55 AM Subject: M1 problem -- velocity tools? I got overly excited about M1 and decided to start over with a nice clean new install of everything (except MySQL). I'm using Tomcat 5.0.30, J2 from HEAD, j2sdk1.4.2_03. allClean, allBuild, and quickStart go smoothly, but when I launch Tomcat I get errors. Lots of errors. The first one is: ...[snip]... 2004-12-06 11:07:08 StandardContext[/jetspeed] Velocity [info] Velocity successfully started. 2004-12-06 11:07:08 StandardContext[/jetspeed] Velocity [info] ServletToolboxManager: Using config file '/WEB-INF/toolbox.xml' 2004-12-06 11:07:08 StandardContext[/jetspeed] Velocity [debug] XMLToolboxManager: Loading toolbox... 2004-12-06 11:07:08 StandardContext[/jetspeed] Velocity [warn] ServletToolboxManager: Unknown scope 'null' - toolLoader will be request scoped. 2004-12-06 11:07:08 StandardContext[/jetspeed] Velocity [error] Problem loading toolbox '/WEB-INF/toolbox.xml' : java.lang.NullPointerException 2004-12-06 11:07:08 StandardContext[/jetspeed] Velocity [error] java.lang.NullPointerException at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 40) at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 66) at org.apache.commons.digester.Digester.endElement(Digester.java:1061) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unk nown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis patcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno wn Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) ... Followed by: 2004-12-06 11:07:08 StandardContext[/jetspeed] Velocity [info] VelocityViewServlet: Default content-type is: text/html 2004-12-06 11:07:08 StandardContext[/jetspeed]StandardWrapper.Throwable java.lang.NullPointerException at org.apache.jetspeed.velocity.JetspeedVelocityViewServlet.init(JetspeedVe locityViewServlet.java:136) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav a:1044) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:876) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.j ava:4017) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337 ) ... Which makes sense given the previous error. Then: 2004-12-06 11:07:08 StandardContext[/jetspeed]Servlet /jetspeed threw load() exception javax.servlet.ServletException: Servlet.init() for servlet velocity threw exception at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav a:1085) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:876) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.j ava:4017) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337 ) ...[snip]... - Root Cause - java.lang.NullPointerException at org.apache.jetspeed.velocity.JetspeedVelocityViewServlet.init(JetspeedVe locityViewServlet.java:136) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav a:1044) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:876) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.j ava:4017) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337 ) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja va:823) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeplo yer.java:903) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:2 16) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1058) at org.apache.catalina.util.CatalinaDigester.endElement(CatalinaDigester.ja
J2 Autodeploy Decorators
Last night David committed a patch from me that enables deployment of layout, portlet, and generic decorators. Deploy, undeploy, and redeploy are all supported, (note that redeploy is essentially an undeploy followed by a deploy). The inclusion of multiple locale specific decorator content is supported by the decorator deployer. A deployable decorator must have the following properties set or defaulted in the decorator.properties configuration: id=xxx media.type=(html|...) decorates=(layout|portlet|any) To avoid conflicts with the locale logic and runtime locators, decorators should be named with ids longer than 2 characters in length. The media.type property defaults to 'html'. The 'any' value for the decorates property is mapped to the generic deployment directory. Here is a table listing of an example jar archive file that deploys with locale specific content: 0 Fri Dec 03 00:29:48 MST 2004 META-INF/ 71 Fri Dec 03 00:29:48 MST 2004 META-INF/MANIFEST.MF 0 Fri Dec 03 00:15:38 MST 2004 css/ 4656 Thu Dec 02 11:53:58 MST 2004 css/styles.css 760 Thu Dec 02 11:48:18 MST 2004 decorator-bottom.vm 3491 Thu Dec 02 11:48:18 MST 2004 decorator-macros.vm 723 Thu Dec 02 11:52:58 MST 2004 decorator.properties 3930 Thu Dec 02 11:52:38 MST 2004 decorator-top.vm 0 Thu Dec 02 23:41:52 MST 2004 fr/ 3937 Thu Dec 02 23:41:52 MST 2004 fr/decorator-top.vm 0 Thu Dec 02 11:50:46 MST 2004 images/ 2568 Thu Dec 02 11:48:18 MST 2004 images/jetspeed-logo.gif 2259 Thu Dec 02 11:48:18 MST 2004 images/jetspeed-powered.gif 51 Thu Dec 02 11:48:18 MST 2004 images/nw_maj_rond.gif 0 Thu Dec 02 23:42:26 MST 2004 ja/ 3937 Thu Dec 02 11:54:52 MST 2004 ja/decorator-top.vm 0 Thu Dec 02 23:50:46 MST 2004 ja/images/ 2568 Thu Dec 02 23:48:18 MST 2004 ja/images/jetspeed-logo.gif 0 Thu Dec 02 23:42:36 MST 2004 ja/JP/ 3937 Thu Dec 02 23:42:36 MST 2004 ja/JP/decorator-top.vm The decorator.properties file must be located in the root directory of the jar archive and contain the properties outlined above to be identified as a decorator by the autodeployment system. The deployer will relocate the locale specific content to satisfy J2 content locators as necessary on deploy and undeploy. The current implementation supports only 2 character language and country codes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
VelocityEngine status
David, Ok, code complete and initial tests passed. Am headed home now. Will patch for you when I get there. Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
J2 /WEB-INF/templates/navigation deprecated
Gang,
David has committed another patch from me that has replaced the
/WEB-INF/templates/navigation infrastructure with general purpose macros
defined as part of decorations. This not only makes the usage of macros more
straight forward, but also facilitates decorator deployment. To make this
happen, multiple VelocityEngine instances, (one per decoration), are now
created and managed by the JetspeedVelocityViewServlet. Decorations that do
not utilize the new macro capability are processed by the default
VelocityEngine singleton that is initialized as before.
I have simplified and transferred what was in the navigation templates and
jetspeed_macros.vm into macro source files that are part of the tigris and
jetspeed layouts. Please refer to the following files for examples of how
this is and can be used:
/WEB-INF/decorations/layout/html/{jetspeed,tigris}/decorator.properties
/WEB-INF/decorations/layout/html/{jetspeed,tigris}/decorator-macros.vm
Of course, other macros can be defined to suite the needs of the decorator!
The jetspeed_macros.vm file is still included in the macro path for all
VelocityEngines. However, only truely global macros should be defined there!
The caching of VelocityEngine is controlled by init params for the
JetspeedVelocityViewServlet located in /WEB-INF/web.xml. By default, the
implementation will cache up to 25 VelocityEngines and check every 10
seconds for updates to the decorators.
I am now attempting to blow the dust off of the existing decoration
deployment code and get it running for M1. As usual, questions and feedback
are always welcome.
Randy
Re: cvs commit: jakarta-jetspeed-2/jetspeed-api/src/java/org/apache/jetspeed/om/folder Folder.java
Ate, That would be me. Sorry I missed it. Will fix in the testcase. This method is insecure and should not be publicly visible. Randy [EMAIL PROTECTED] wrote: ate 2004/11/23 12:31:24 Modified:jetspeed-api/src/java/org/apache/jetspeed/om/folder Folder.java Log: Added getAllNodes() back to Folder interface to allow TestCastorXmlPageManager to compile again. If the removal of this method was intential, then please correct the testcase too! Revision ChangesPath 1.9 +13 -1 jakarta-jetspeed-2/jetspeed-api/src/java/org/apache/jetspeed/om/folder/Folder.java Index: Folder.java === RCS file: /home/cvs/jakarta-jetspeed-2/jetspeed-api/src/java/org/apache/jetspeed/om/folder/Folder.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Folder.java 23 Nov 2004 00:01:32 - 1.8 +++ Folder.java 23 Nov 2004 20:31:24 - 1.9 @@ -195,4 +195,16 @@ * @throws NodeException */ PageSecurity getPageSecurity() throws DocumentNotFoundException, NodeException; + +/** + * + * p + * getAllNodes + * /p + * + * @return All Nodes immediatley under this Folder. + * @throws DocumentException + * @throws FolderNotFoundException + */ +NodeSet getAllNodes() throws FolderNotFoundException, DocumentException; } - 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]
page-manager tests
Gang: Ate noticed that the page-manager component test cases were not compiling. However, the problems are deeper than that. I am currently attempting to fix it and hope to have a patch out this evening. In the interim, please ignore the failing tests! Thanks, sorry for any inconvenience. Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 Customizer Issues
Ate: I see the security stuff is working for you, :). See inline comments below: Randy Ate Douma wrote: Is a message missing from the list or did you get a message from 'David' privately? Yes, David sent a message to Scott and I wonding about issues he was having with the Customizer. I'd like to add another problem I encountered. Because the guest user now is a proper user, we should think of some way to disallow login to this user as it is meant to be used as buildin/internal user only. A simple solution to that would be setting the user is_enabled flag to false, but that still leaves the possibility someone enables it again through the UserManager. I personally would like to see a stronger protection against login of this user. This could be done by adding one more boolean attribute to the security_credential table (like is_buildin) or a hardcoded check in the UserManager.authenticate against the anonymous username. This name (default 'guest') is now managed by the Profiler though, so maybe we should move it to the UserManager then. +1, seems like a good idea to limit the login. Another issue: the security rules on the Administrative folder won't allow a non-admin user to change its password. I will move the change-password.psml into the root folder to fix this. I checked in this change to restrict access to the Administrative folder, but I did not spend a whole bunch of time to reorganize the demo site to make sense. David has mentioned over and over again that he was going to go for it one of these days, so I left it to him. Of course, change password needs to be available to every user! Sorry if this caused you too much grief... If time permits, I will also check in tonight the second part of my JS2-151 issue containing enforced password change on first login. This includes automatic navigation to the Change Password psml with no way to navigate from it until the password is changed (logoff is still a way out though). Also included is a configurable set of days before password expiration when a user will be asked to change its password. The last day before expiration will require the password to be changed. These features are currently *not* (longer) working though as result of the new 'guest' user configuration which now *also* is required to change its password, even if this user isn't logged on at all. Kinda blocking problem :( I need this handled before I will check in my changes. Thanks for the notice. I will hold off on upgrading my production site until we get this worked out. Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 Customizer Issues
David, I have done some significant cleanup in the PageManager and the Customizer updates seem to be working for me at this point. I think it is safe to say that the CastorXmlPageManager version out there now is causing at least some of the problems you are encountering. Will have a patch in the morning at some point. As I replied earlier, the security settings on / are preventing you from viewing the root folder back link after decending into the Public folder. It is possible to define the access permissions on a folder to be the union of all of its children's access permissions, but that seems like it might be too computationally intense to be worth it. I don't know what is best. For now, you can propagate the current constraints in / folder.metadata to its children and open the permissions on the / folder itself to allow guest access. I am currently having issues with the SiteBrowserPortlet: it apparently does not set the JAAS subject before it accesses the PageManager. Since the access is now checked in the PageManager and Folder access methods, it is getting SecurityExceptions. I have just started looking into this, but am taking a break until morning. Talk to you then, Randy
Decorators/Templates
Dev Team, After putting a bit more time into security to finish it off for now and implementing cascading document sets, I am going to take a pass at refining the decorators and related templates implementation. While the latest upgrade to Tigris is awesome, I think there are some additional things that could use some attention before M1. Here are some things on the plate already: - Make decorators fully deployable. - Allow for some form of branding so that color scheme and/or graphic elements can be varied easily against a common decorator base. - Add a decorator implementation with cascading pull down DHTML menus for navigation in place of the left menu pane. - Some documentation and/or refactoring to clarify usage for those not familar with the internals of J2, (like the profiled page context). I am only in the early stages of this and am trying to organize and prioritize what this effort might encompass. If you have anything releated to the decorators that you think needs my or other's attention, please comment on this thread! I'd like to get as much community input as possible before I dig in to maximize the value of my work. I am hoping to get started on this mid next week. Thanks in advance, Randy
11/18 Security/Misc Patch
Gang, FYI, here is a quick summary of what David reviewed and committed for me yesterday. As usual, feel free to ask any questions that come to mind! Randy -- To test: 1. When you start the portal, you should see only the default page and additional links, (no customizer buttons) 2. Login as user: you should see everything as before except the testsuite page and the Administrative sub directory, (customizer buttons only visible on user pages) 3. Login as manager: everything should be be visible except the testsuite page, (no customizer buttons) 4. Login as jetspeed: everything should be visible, (no customizer buttons) 5. Login as admin: everything should be visible, (full customizer buttons) Notes: - Both permissions, (JAAS), and constraints, (J1 style), are enabled, (in assembly/page-manaager.xml on the CastorXmlPageManager init) - Both are configured to secure the same entities, except the testsuite page access is specified only in the constraints. - The permissions are configured in the 4 populate-userinfo sql scripts. - The constraints are set up in WEB-INF/pages: /page.security /folder.metadata /Administrative/folder.metadata /default-page.psml /testsuite.psml /_user/user/folder.metadata In addition to the core Security functionality, the following bonus changes are in this patch: - Corrected various page document tags to use lower-dash case instead of lowerCamel case. - Removed security checks from PageAggregator. - Deprecated ACL members from page documents and usage in SiteDetailPortlet.java - Removed logging from FolderPermission in commons. - Added 403 returns in ProfilerValveImpl for SecurityExceptions - Added short-title support to pages, (see nested-layout.psml), and decorators/templates. - Cleaned up SecurityValveImpl to ensure RequestContext Subject is propagated using Subject.doAsPrivileged(). - Added groups to user and jetspeed logins to use for testing purposes. - Added code in JPT that uses page.checkAccess() to limit customizer page actions. - Added rollovers for full title display in tigris and jetspeed page layout decorators/templates. Things that remain to be done: - Implement view/edit action checks in PageManager for get/new/update/remove APIs.
Re: Tigris Title Rollovers
Shinsuke, I have added the HTML title attribute throughout the tigris/jetspeed decorators and templates. Seems to work as one would expect on modern browsers. It is part of the security patch that David will be reviewing tomorrow. Let me know what you think when it gets committed! Randy Shinsuke SUGAYA wrote: I think the short tiltle is a good feature. Currently, tab labels are long... I'll check it when it is applied, and if I have any comments, let you know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tigris Title Rollovers
Shinsuke, I have submitted a patch to David that supports a short-title/ tag, (and its locale sensitive metadata variants), for pages, folders, etc. He hopes to look at it later today, so perhaps it will be applied when you get this email! The patch also modifies the various decorators to use the new getShortTitle($preferredLocale) accessor, (except for the HTML title tag content). If no short-title tags are defined, the folders and documents objects return the full title content. This feature was added to allow full titles to be reserved for rollover/tool tip text, (HTML title attribute), and to optionally support use of compact titles as links, tabs, etc. Do you have any objections to adding the title attribute as getTitle($preferredLocale) in the Tigris decorators? Is there any other applicable Tigris guideline we should be following? I have not added this functionality to any of the decorators in the patch. I was holding off until we had a chance to discuss the implementation. Let me know! Thanks, Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
portal project deployment in WEB-INF/classes vs. WEB-INF/lib
Gang, The deployment of individual class files from the portal project in WEB-INF/classes instead of packaging as a jar and deploying in WEB-INF/lib is causing java Permission checks to be significantly slower than they could be. The reason for this is that each individual *.class file is being treated as a separate CodeSource/PermissionDomain and must be tested individually when AccessController.checkPermission() is invoked. All classes deployed in a jar file reuse a single CodeSource/PermissionDomain. Minimizing the number of CodeSources/PermissionDomains will limit the number of access to RdbmsPolicy.getPolicies(), because each unique CodeSource on the call stack between the SecurityValveImpl.invoke() and AccessController.checkPermission() invocations will result in an additional RdbmsPolicy.getPolicies() hit, (per each user/unique call stack). Do any of you have a problem with me modifying the maven build to package the class files into a single jar? Was there a reason to deploy in WEB-INF/classes instead of WEB-INF/lib in the first place? Any input or comments are appreciated. Thanks, Randy
Re: portal project deployment in WEB-INF/classes vs. WEB-INF/lib
David, I think this is (or was) Maven's standard way of packaging a war file. Im not opposed to changing it, but if you do, please make sure nothing else breaks (such as the hotdeploy goal) Really? Wow. I have never used WEB-INF/classes for anything other than properties files. Ok, I'll look into it more carefully. Looking at RdbmsPolicy.getDefaultPolicy(): I private static String defaultPolicy = sun.security.provider.PolicyFile; then Class policyClass = Class.forName(RdbmsPolicy.defaultPolicy); return (Policy) policyClass.newInstance(); Is that where the performance hit is? Or is it in getPermissons(). This code also looks suspect to me, especially the policy.refresh(): // TODO Is there a better way to do this? // If the permission is not found here then delegate it // to the standard java Policy class instance. Policy.setPolicy(RdbmsPolicy.getDefaultPolicy()); Policy policy = Policy.getPolicy(); policy.refresh(); PermissionCollection defaultPerms = policy.getPermissions(codeSource); // Revert back to the current policy. Policy.setPolicy(this); // Return the default permission collection. return defaultPerms; The issue is that RdbmsPolicy.getPermissions() gets called many times for a single checkPermission() invocation, (once per CodeSource/PermissionDomain). In the AbstractPageManager case, it is called 4-6 instead of perhaps 2-3 times per unique checkPermission() per user session. Each time, it invokes PermissionManager.getPermissions() which hits the DB, (or look like it does anyway). Worse case, we might consider caching in the principal impls to eliminate redundant lookup. Ideally, I'd like to get it down to just one access RdbmsPolicy.getPermissions(), but I do not know how to use the Subject.doAs*() methods to accomplish that yet. DLS? Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compilation problem
Serge, Known problem. Waiting for a fix from the dev team. Randy Serge Huber wrote: Hi guys, I'm having some trouble compiling the current Jetspeed 2 CVS. I'm getting the following error : java:compile: [echo] Compiling to C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php/target/classes [javac] Compiling 4 source files to C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\target\classes [javac] C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\src\java\org\apache\portals\bridges\php\PHPApplicationPortlet.java:329: cann ot resolve symbol [javac] symbol : method setUseInternalPage () [javac] location: class com.itgroundwork.portlet.php.servlet [javac] phpServletImpl.setUseInternalPage(); [javac] ^ [javac] C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\src\java\org\apache\portals\bridges\php\PHPApplicationPortlet.java:351: cann ot resolve symbol [javac] symbol : method getSourcePage () [javac] location: class com.itgroundwork.portlet.php.servlet [javac] StringBuffer page = phpServletImpl.getSourcePage(); [javac] ^ [javac] 2 errors Is there something I'm missing ? Regards, Serge Huber. - 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]
Re: Compilation problem
Roger, Perhaps I am missing something, but the project.xml still has a dependency to phpportlet.jar under itgroundwork. Randy Roger Ruttimann wrote: I updated the dependency to the phpportlet.jar which is now phpportlet-1.0.jar. The library is posted on bluesunrise/maven repository (http://bluesunrise.com/maven/itgroundwork/jars/phpportlet-1.0.jar) Do you have bluesunrise in the maven repository path? Roger Randy Watler wrote: Serge, Known problem. Waiting for a fix from the dev team. Randy Serge Huber wrote: Hi guys, I'm having some trouble compiling the current Jetspeed 2 CVS. I'm getting the following error : java:compile: [echo] Compiling to C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php/target/classes [javac] Compiling 4 source files to C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\target\classes [javac] C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\src\java\org\apache\portals\bridges\php\PHPApplicationPortlet.java:329: cann ot resolve symbol [javac] symbol : method setUseInternalPage () [javac] location: class com.itgroundwork.portlet.php.servlet [javac] phpServletImpl.setUseInternalPage(); [javac] ^ [javac] C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\src\java\org\apache\portals\bridges\php\PHPApplicationPortlet.java:351: cann ot resolve symbol [javac] symbol : method getSourcePage () [javac] location: class com.itgroundwork.portlet.php.servlet [javac] StringBuffer page = phpServletImpl.getSourcePage(); [javac] ^ [javac] 2 errors Is there something I'm missing ? Regards, Serge Huber. - 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] - 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]
Re: Compilation problem
Roger: This is strange: I modifed the dep in portals-bridges/php/project.xml to use phpportlet-1.0.jar. Now I see cvs diffs, so I do not we are in sync with this file. However, now I have new errors: PHPServletContextProviderImpl.java:40: cannot resolve symbol: class JetspeedPortletContext Randy Roger Ruttimann wrote: Make sure that you have the latest. I just checked cvs and it points to version 1.0 of phpportlet Roger Randy Watler wrote: Roger, Perhaps I am missing something, but the project.xml still has a dependency to phpportlet.jar under itgroundwork. Randy Roger Ruttimann wrote: I updated the dependency to the phpportlet.jar which is now phpportlet-1.0.jar. The library is posted on bluesunrise/maven repository (http://bluesunrise.com/maven/itgroundwork/jars/phpportlet-1.0.jar) Do you have bluesunrise in the maven repository path? Roger Randy Watler wrote: Serge, Known problem. Waiting for a fix from the dev team. Randy Serge Huber wrote: Hi guys, I'm having some trouble compiling the current Jetspeed 2 CVS. I'm getting the following error : java:compile: [echo] Compiling to C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php/target/classes [javac] Compiling 4 source files to C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\target\classes [javac] C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\src\java\org\apache\portals\bridges\php\PHPApplicationPortlet.java:329: cann ot resolve symbol [javac] symbol : method setUseInternalPage () [javac] location: class com.itgroundwork.portlet.php.servlet [javac] phpServletImpl.setUseInternalPage(); [javac] ^ [javac] C:\java\technologies\jakarta-cvs\jakarta-jetspeed-2\portals-bridges\php\src\java\org\apache\portals\bridges\php\PHPApplicationPortlet.java:351: cann ot resolve symbol [javac] symbol : method getSourcePage () [javac] location: class com.itgroundwork.portlet.php.servlet [javac] StringBuffer page = phpServletImpl.getSourcePage(); [javac] ^ [javac] 2 errors Is there something I'm missing ? Regards, Serge Huber. - 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] - 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] - 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]
Re: Compilation problem
Roger: All set. Mischief managed. Thanks, Randy Roger Ruttimann wrote: I committed the updated project.xml for portals-bridges/php Make sure that you have updated portals-bridges and /applications/php (some old files were not removed from CVS I just fixed it) I just got a clean CVS and the build/deploy went fine. Roger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[J2][VOTE] Consistent XML tag style usage for PSML and related documents
J2 Dev Team: As part of adding resource security/permission checks to page and folder access in the PageManager, I am considering adding a new multi-word tag: security-constraint/ to *.psml, *.link, *.ds, and folder.metadata documents. PSML documents typically use the security-constraint/ tag name style, while the other content documents use the securityConstraint/ style. Castor does offer the ability to accept both styles for primitive members, but is not similarly flexible for class mappings. Because Castor cannot uniformly support both styles, I am wondering which option the dev team would like me to follow: 1) Convert all documents to use a consistent style, namely security-constraint/ to match the JSR-168 style. 2) Implement security-constraint/ or securityConstraint/ depending on the prevailing style of the document. 3) Implement only security-constraint/ and ignore resulting mixed styles. Option 1 implies impact for anyone with a running J2 site, but if we are going to change this we need to do it before the M1 release IMO. Option 2 accommodates the existing style differences, but might be more confusing and/or difficult to document. IMO, Option 3 is just plain ugly, albeit easiest on me. I am willing to port the J2 demo site and my own implementation to achieve a consistent XML style, option 1. Opinions? Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[J2][PATCH] AbstractPageManager NPE Patch
Title: [J2][PATCH] AbstractPageManager NPE Patch Gang: Patch for NPE that I encountered in my recent PageManager upgrades when updating our portal. This is likely to show up for any site without a document set, but is a very minor check for null patch. Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [J2][PATCH] AbstractPageManager NPE Patch
WebMail nails me again! Hopefully this time the patch attaches correctly! Randy -Original Message- From: Randy Watler To: 'Jetspeed Developers List ' Sent: 10/31/04 8:51 AM Subject: [J2][PATCH] AbstractPageManager NPE Patch Gang: Patch for NPE that I encountered in my recent PageManager upgrades when updating our portal. This is likely to show up for any site without a document set, but is a very minor check for null patch. Randy ATT254523.txt
RE: [J2][PATCH] AbstractPageManager NPE Patch
Title: RE: [J2][PATCH] AbstractPageManager NPE Patch WebMail nails me again! Hopefully this time the patch attaches correctly! Randy -Original Message- From: Randy Watler To: 'Jetspeed Developers List ' Sent: 10/31/04 8:51 AM Subject: [J2][PATCH] AbstractPageManager NPE Patch Gang: Patch for NPE that I encountered in my recent PageManager upgrades when updating our portal. This is likely to show up for any site without a document set, but is a very minor check for null patch. Randy ATT254523.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [J2][PATCH] AbstractPageManager NPE Patch
One last try from a real email client ...I am feeling particularly stupid this morning, so this had bettter work! Randy Randy Watler wrote: WebMail nails me again! Hopefully this time the patch attaches correctly! Randy -Original Message- From: Randy Watler To: 'Jetspeed Developers List ' Sent: 10/31/04 8:51 AM Subject: [J2][PATCH] AbstractPageManager NPE Patch Gang: Patch for NPE that I encountered in my recent PageManager upgrades when updating our portal. This is likely to show up for any site without a document set, but is a very minor check for null patch. Randy ATT254523.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] AbstractPageManagerNPE.patch.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
guest login user principal: anon - guest?
Ate/David, Am I seeing things right? It appears that the guest login user principal is now guest instead of anon, no? Just checking before I move around my page manager profiler psml login page layouts, (obviously I am updating my portal implementation after it fell behind for 2-3 weeks). Randy
[J2] M1 Release
M1 FINAL [ ] [+1] -- ALL -- Close Open Issues (Bugs) [ ] [ ] -- SS -- Portal CSS [ ] [ ] -- DST -- Cleanup and Reorganize the demo portal SW [ ] [ ] -- SW -- Portlet Selector for the customizer [ ] [ ] -- DLS -- User Admin Portlets (JS2-121) DST [ ] [ ] -- DST -- Site Manager [+1] [ ] -- RW -- Web Content Component DST [ ] [ ] -- RR -- SSO Component [+1] [ ] -- RW -- Secure Access to Site Resources (JS2-111) [ ] [ ] -- RL -- Site Documentation ALL [ ] [ ] -- DST -- Portlets [ ] [ ] -- RR -- Bridges [ ] [ ] -- AD -- Enhanced credential security (JS2-151) [ ] [ ] -- AD -- TCK compliance [ ] [ ] -- AD -- Dhtml horizontal menu with pulldown submenus [ ] [+1] -- RW -- Page decoration configuration defining allowable [ ] [ ] -- SS -- Fixing Portlet info, resourcebundle and LanguageSet [ ] [ ] -- SW -- Declarative TX with Spring DAO [ ] [ ] -- SG -- SVN, mailing lists [ ] [ ] -- -- [ ] [ ] -- -- JCMS Page Manager [ ] [ ] -- -- JMX Component Configurator Portlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 JCMS
Christophe: I am interested in helping you with this project. If you have not noticed, there has been quite a bit of work put into the PageManager to support profiling. While developing the JCMS PageManager implementation, it would be ideal if we can refactor the existing profiling code in CastorXmlPageManager and at least pull it up into AbstractPageManager. Sign me up to help you make that happen! Thanks, Randy Watler LOMBART Christophe wrote: I'm volonteer to integrate JCMS into J2 and makes the JCMS page manager. I propose to send the patchs to David but I think the final release seems a good target for the first JCMS integration step. FYI, I'm plan to start a discussion a presentation on JCMS on this mailing list or on the jetspeed user list (probably at the end of this week). Christophe Message d'origine De: David Sean Taylor [mailto:[EMAIL PROTECTED] Date: mar. 26/10/2004 1:04 : Jetspeed Developers List Cc: Objet: [J2] M1 Release Here is the resulting feature set for the M1 or FINAL release. For those of with your names next to a feature, please +1 the appropriate box as to whether you will finish the feature for either M1 or FINAL. If you have changed your mind, put a -1. Scott, since you weren't at the meeting, I took the liberty to sign you up for a few features. Thought you'd appreciate that ... Next we have to decide on a release date. Alternatively, we could simply not release M1 until all the features below are ready M1 FINAL [ ] [ ] -- ALL -- Close Open Issues (Bugs) [ ] [ ] -- SS -- Portal CSS [ ] [ ] -- DST -- Cleanup and Reorganize the demo portal SW [ ] [ ] -- SW -- Portlet Selector for the customizer [ ] [ ] -- DLS -- User Admin Portlets (JS2-121) DST [ ] [ ] -- DST -- Site Manager [ ] [ ] -- RW -- Web Content Component DST [ ] [ ] -- RR -- SSO Component [ ] [ ] -- RW -- Secure Access to Site Resources (JS2-111) [ ] [ ] -- RL -- Site Documentation ALL [ ] [ ] -- DST -- Portlets [ ] [ ] -- RR -- Bridges [ ] [ ] -- AD -- Enhanced credential security (JS2-151) [ ] [ ] -- AD -- TCK compliance [ ] [ ] -- AD -- Dhtml horizontal menu with pulldown submenus [ ] [ ] -- RW -- Page decoration configuration defining allowable [ ] [ ] -- SS -- Fixing Portlet info, resourcebundle and LanguageSet [ ] [ ] -- SW -- Declarative TX with Spring DAO [ ] [ ] -- SG -- SVN, mailing lists [ ] [ ] -- -- [ ] [ ] -- -- JCMS Page Manager [ ] [ ] -- -- JMX Component Configurator Portlet - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MS SQL Server/JTDS Driver DB Connectivity
Scott, The J2 pool appears to be managed by commons dbcp, configured by JNDI resources in jetspeed.xml. The OJB is configured to use the JNDI connection source in etc/db-obj/repository_database.xml. I am not sure if the OJB configuration attempts to pool the connections again or not. In etc/db-obj/OJB.properties, it enables a pooled connection manager. In addition, etc/db-obj/repository_database.xml also contains a connection pool definition, (it even has an unused validationQuery attribute). I think OJB should be configured to not pool and let the JNDI connection source do it. No need to double pool! Plus, execution of the validationQuery is bad enoough... I do not think it would be efficient to have both pools executing validation queries! Got to figure this stuff out... perhaps DLS could shed some light here? Randy -Original Message- From: Scott T. Weaver To: Randy Watler Sent: 10/22/04 7:45 AM Subject: Re: MS SQL Server/JTDS Driver DB Connectivity Let me check and see if anyone has had these issuses. How is the pool managed? Randy Watler wrote: Scott, I have been reasearching DB connectivity issues we have seen on our production box. The problem is rare, but occasionally the DB simply resets a connection in the pool. The JTDS driver I think we are both using does not seem to have any way to specify autoReconnect, (something that other drivers allow). From what I have gathered today, many seem to use a validationQuery that is run before a connection is handed to the application from the connection pool. For instance, this validation query could be defined in jetspeed.xml for the JNDI connection pool resource configuration: SELECT GETDATE(). Personally, I think this is overkill when a simple retry try/catch could be implemented in the driver, but JTDS's opinion is that it is not their problem. This issue seems to come up only with MS SQL Server and certain drivers, so I was wondering what you were doing, (or planned to do), in your production environment. Thanks in advance for any tips you can provide... Randy
RE: MS SQL Server/JTDS Driver DB Connectivity
Scott, I am not sure what is actually functional. I aim to figure that out. OJB is not configured with a valid validationQuery, it just has an empty attribute placeholder in repository_database.xml. The reason I am digging around in here is that there is a fairly good chance that I'll need to add a validation query. I am not a big fan of using it in principle, but if your reasearch shows that it is needed for MS SQL Server, that will just about make it unanimous... :(. So, I want to enable it in the right place. Also, if we do put them at the JNDI level, OJB cannot pool: obviously, it would defeat the purpose of using a validationQuery if it did not issue the validationQuery again! Randy -Original Message- From: Scott T. Weaver To: Jetspeed Developers List Sent: 10/22/04 8:49 AM Subject: Re: MS SQL Server/JTDS Driver DB Connectivity Randy Watler wrote: Scott, The J2 pool appears to be managed by commons dbcp, configured by JNDI resources in jetspeed.xml. The OJB is configured to use the JNDI connection source in etc/db-obj/repository_database.xml. I am not sure if the OJB configuration attempts to pool the connections again or not. In etc/db-obj/OJB.properties, it enables a pooled connection manager. In addition, etc/db-obj/repository_database.xml also contains a connection pool definition, (it even has an unused validationQuery attribute). I don't think OJB tries to pool JNDI datasources. I am not 100% on that though. I think OJB should be configured to not pool and let the JNDI connection source do it. No need to double pool! Plus, execution of the validationQuery is bad enoough... I do not think it would be efficient to have both pools executing validation queries! Is OJB doing the validation queries? If so, I think that feature can be disabled in OJB.properties. Got to figure this stuff out... perhaps DLS could shed some light here? Randy -Original Message- From: Scott T. Weaver To: Randy Watler Sent: 10/22/04 7:45 AM Subject: Re: MS SQL Server/JTDS Driver DB Connectivity Let me check and see if anyone has had these issuses. How is the pool managed? Randy Watler wrote: Scott, I have been reasearching DB connectivity issues we have seen on our production box. The problem is rare, but occasionally the DB simply resets a connection in the pool. The JTDS driver I think we are both using does not seem to have any way to specify autoReconnect, (something that other drivers allow). From what I have gathered today, many seem to use a validationQuery that is run before a connection is handed to the application from the connection pool. For instance, this validation query could be defined in jetspeed.xml for the JNDI connection pool resource configuration: SELECT GETDATE(). Personally, I think this is overkill when a simple retry try/catch could be implemented in the driver, but JTDS's opinion is that it is not their problem. This issue seems to come up only with MS SQL Server and certain drivers, so I was wondering what you were doing, (or planned to do), in your production environment. Thanks in advance for any tips you can provide... Randy -- Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Admiral Hyman Rickover *** * Scott T. Weaver * * [EMAIL PROTECTED] * * http://www.einnovation.com* * -- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEdit, Website Content Management * * http://www.openedit.org * *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
portlet app deployer/manager app
Scott/all: I believe that something is amiss with my Tomcat4 server.xml configuration. According to the catalina.out startup log files, CatalinaPAM is forced into a file system mode because it cannot ping the manager webapp. Afterward, It does not appear to attempt to reach the manager webapp, (as the error messages at startup would indicate/predict). Everything seems to be OK because the Tomcat deployer is picking up the portlet webapps in my case... but what is the point then of the manager webapp being there? Am I missing something? I am not sure what I should change to get the manager webapp into the act. It is in the same service/server container as jetspeed and will not be available at startup because Tomcat has not enabled services on the HTTP port it is trying to reach. Should the manager app be in the same or a different server.xml Engine or Service as jetspeed? Just throwing it out there. I do not see anything significantly different in my configuration when compared with etc/server.xml in the J2 cvs repositiory. On a related topic, I seem to recall David Taylor and Ate discussing the Host autoDeploy attribute... should it be set to false so the jetspeed and Tomcat deployers are not fighting over the portlet webapps? Sorry guys for the lame questions, I just want to get into an officially correct configuration before I debug further! Randy
Re: [J2] Security enhancements proposal
Ate, +1 from me that will get you to maybe +3.5 then. :) BTW, we do our login from the decorator and do not depend on the login portlet. We do not require password changes and other admin functions from the decorator, (we can certainly put those functions in a real page), but we want to continue to use login/logout from there. Just FYI, Randy Ate Douma wrote: Having received a positive response from Roland S. Ong, a further +3 (mine included) and no other reactions I'll create an new feature issue for this and start working on it right away. Regards, Ate Ate Douma wrote: I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). We already had a first version of the password validation implemented partly *outside* J2 using triggers on the SECURITY_CREDENTIAL table (we are using oracle) and a custom UserManagerImpl. But, since the refactoring of the Security with the new Handlers e.a. our implementation doesn't work anymore anymore. So, I'm faced with fixing our current implementation or writing a new one myself which I then would like to integrate into J2. I think this would be a great (optional) enhancement for most (company) portal implementations. To be able to integrate this into J2 though, I will need a few enhancements to the security object model. Those enhancements won't need to be used by the simple default security handlers but would be available when needed *and* used/enforced when set in a non-default way. The needed enhancements I now foresee are: - boolean enabled attribute for principals and credentials false: principal/credential is *never* used in security checks, meaning: - user cannot log in if its user principal is disabled - user cannot log in if no credential is enabled - disabled groups or roles will not be added to a subject Usage for administrative purposes in *not* to be limited by this: A administrator can still assign disabled groups/roles to a user/group/role or whatever. They just won't have any effect *yet*. Note, I created an issue for this feature (on groups and roles) quite some time ago already: http://issues.apache.org/jira/browse/JS2-27 I just never got around implementing it yet. - int authentication failures attribute on PasswordCredential (0 as default or for other type of credentials): -1 means never tried yet (to indicate enforce change password on first use) 0 means none or last time was successful 0 number of failures (to allow disable after configurable failures) - boolean valid attribute on PasswordCredential (default = true, or only false if null/empty): Allows for password sanity check before even trying to authenticate or set/change a password. A specific PasswordCredential implementation (see next feature) then could check against above mentioned rules like minimum length, number of numeric characters, a regular expression, etc. - Define a PasswordCredentialComponent/Provider/Factory to allow specialized versions of PasswordCredential to be used as describe above, instead of the current implementations which does hardcoded PasswordCredential instantiations. - Date expiration date attribute on PasswordCredential indicating the lifespan of a password, null in the default implementation indicating never - boolean expired attribute indicating on PasswordCredential, default false: true: non-valid PasswordCredential because a newer PasswordCredential is defined or the lifespan had ended. - An enhanced CredentialHandler enforcing most of my above requirements, configurable through the jetspeed-spring.xml with parameters like: password history size, password expiration time and max authentication failures. - A new pipeline security value (in addition to the current one) which checks on a authenticated user (Subject) - if a password change is required: force the user to a change password page/portlet - if a password is about to be expired: inject some sort of warning message into the aggregated output (I don't have clue yet how to do that, probably some kind of javascript message, maybe need an
RE: ProfiledPageContext caching
Scott/David, So I have added the CastorXmlPageManager to the underlying FileCache listeners and have managed some degree of success in reaping the page context caches. However, I am trying to optimize the operation of CastorXmlPageManager cache eviction by using the last accessed time of the FileCacheEntry and comparing that to the page context creation times in the cache. The idea is to eliminate the complete dumping of the cache without performing complex dependency tracking and tests. Anyway, I am not sure if the approach is sound or not yet, but it appears that the last accessed time of the cache elements is not being updated when elements are referenced. Obviously, my algorithm relies on this happening and it would seem that the LRU features of the FileCache require this information as well. I thought I'd check to see if you had any input or insight into this before I went ahead and had the various page manager documents and associated handlers set the last access times. I do not plan to support fine grain access tracking. Instead, I was just going to register PageManager level accesses; in other words, I was not going to consider rendering of a page or navigational document to be an access. Thoughts? Randy
Decorators and Navigation Templates
Gang, As of today, we have rolled a J2 based corporate portal into production and it is live. Due to the demands of our marketing and graphics design folk, I had to generate complete Decorators from the ground up. In the end, I was unable to use the default Navigation Templates due to the highly customized nature of our portal interface. I simply rolled the templates inline into the Decorators instead of customizing the Jetspeed Navigation Templates. I took this route because, as I understand it, Decorators are to be deployable as a unit and I felt that I was better served if I made our custom Decorators stand alone. Additionally, I did not have to solve the locale issues for our portal, so I did not need to consider shifting LeftToRight to TopToBottom dynamically. I spoke with David about this and he urged me to post this to the dev list to open up the discussion of dependencies between Decorators and Navigation Templates. Based only on my limited exposure to J2, I can throw in a few options to start the discussion: 1 - Make Templates and Decorators deployable in the final version of the product. This does not eliminate cross dependencies, but does open up all templates for customization. 2 - Add Navigation Template support within Decorators. This would allow Decorators to stand alone, but might need some kind of fallback mechanism across decorators to promote reuse. 3 - Implement both 1, (to allow deploment of all Templates and provide Navigation Template defaults), and 2, (to allow customization of templates on a per-decorator basis and a stable packaging option for those that require it). However, this might be just too complex to be worth it. Thoughts? Randy
Document Sets, MSSQL populate, and ProfiledPageContext caching.
Scott, David committed my last round of patches last night. There is a prototype implementation of Document Sets that I hope can support your needs for pull down list generation. There are examples checked in, but please feel free to ask questions here whenever you get to looking at it. For now, the Document Sets appear under the Additional Links in the left menu table. The MSSQL populate script now uses 0/1 instead of true/false for BIT data types as we dscussed. Lastly, I have added LRU caching to the ProfiledPageContext generation in CastorXmlPageManager. The cost of generating all of the navigational data is getting significant. The size of the cache is specified in the spring bean configuration for the PageManager. One item is left to do with this: I need to evict/expire/dump cached ProfiledPageContext information whenever a document of folder changes under the pages directory. You mentioned something about a listener I could tap into... what was it again and where are they registered? Randy
J2 Go Live Requirements
J2 Gang, Our release qualification testing went fairly smoothly and J2 performed well. Many thanks to the team! I have some issues external to J2 to resolve immediately, but I thought I'd share the only J2 issues that were raised during the tests: 1 - Loss of current URL in browser on logout. Login preserves the current page navigated to while not logged in. However, logging out seems to always return the user to http://localhost:8080/jetspeed/index.jsp;. Is there redirection support for logout? 2 - Need a way to disable the layout portlet actions, (a.k.a customizer buttons). I am currently manually commenting out code in the columns/layout.vm template, but I'd rather not. Really, that was it! After I address the more pressing needs for this project, I plan on picking these up if you guys have not already addressed them. Thanks again for a great platform, Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: When release is expected
Peter: I'm new to Jetspeed-2 and I'm considering Jetspeed-2 for my development. So I would like to clear out some questions: 1. Is it possible to build an application on the top of the current version of the Letspeed-2 ? How is it stable ? Yes, I just demoed a fully localized reseller portal this week and it went very well. There is a bit of a curve right now to get up to speed with J2. If you have any level of patience you will be fine, plus the list is very responsive to any questions you might have. The support is certainly great thanks to the dev team! We will be going live next week with a corporate portal solution in a limited rollout. I believe J2 should be seriously considered by anyone rolling out a portal solution in the next few months. Randy Watler
p001.psml rendering broken... fixing.
Gang, I am fairly sure I broke the p001.psml rendering when I implemented the nested fragments/layout portlets. I am looking into it now... Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
move minty-blue tab images from portlet to layout decorator
David, I know that we are not updating the metal or minty-blue layout decorators yet, (I assume to let the styles and vm templates stabilize a bit), but the tab*.gif images in .../decorators/portlet/html/minty-blue/images should be moved to the layout decorator in .../decorators/layout/html/minty-blue/images. Obviously, no rush on this but I did not want it forgotten. Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 Page Profiler/Locator Status
David, David/Scott/All, Looking at the Jetspeed2 CVS HEAD, it appears that the profiler/locator system is not active and instead PSML pages are pulled directly from the page-manager. There were also one or two under construction comments that have also supported this conclusion. Assuming I have not missed anything obvious, I am wondering where this support stands? Since we will need group/role profiling at a minimum before we can roll out a production Jetspeed2 implementation, I would certainly be willing to help out in the coding, debugging, or any other capacity if my efforts would be welcome. Right now the simple algorithm is to use the page name to locate the page. Nothing more. I hope to start writing an admin portlet this week to setup profile rules Understood. Our immediate need is to have the system execute on the existing j1, role-fallback, and path role sets. To that end, I have tinkered with some of the under construction code in o/a/j/profiler/impl/ProfilerValveImpl and o/a/j/profiler/impl/JetspeedProfiler. I am considering hacking o/a/j/page/impl/CastorXmlPageManager to support page ids formatted by the existing profiler, (i.e. 'page:/default-page.psml:user:anon:mediatype:html:language:en:country:US'). I envision using a J1 like PSML directory structure under the existing pages directory for this. However, I am not sure this is what is intended! Here are some J2 design questions I have related to these thoughts: - Apparently, the file system arrangement of the PSML resources under the pages directory is currently used to determine navigation and default pages. Ultimately, this information would need to be customized/generated by the profiler in its rule context instead of being read from the file system/database, no? - Given the default values in the path.session and request.session rules, I assume the profiler rules should be determining the default page instead of the default name available in o/a/j/om/folder/FolderImpl. Is this correct? - After adding debug code to loop over the profiler fallback iterator, I am wondering how the group.role.user rule is intended to be iterated over. It seems to be only binding to the user at the moment: page:/test-page.psml:user:manager:mediatype:html:language:en:country:US page:/test-page.psml:user:manger:mediatype:html:language:en page:/test-page.psml:user:manger:mediatype:html page:/test-page.psml:user:manager Would I expect to see something like page:/test-page.psml:role:user:... and page:/test-page.psml:role:manager:... out of this locator or are multiple locators required? Given that the path.session rule is part of the j1 definition, I would also expect the following to be available on the fallback iterator: page:/test-page.psml page:/default-page.psml Would that be a reasonable expectation? - It seems that by enabling the JetspeedProfiler page access, extending the CastorXMLPageManager to map the profiler/locator page urls to the directory structure, and improving the generation of the Folder exported via a request attribute I can bootstrap a rudimentary profiling system for pages. Am I missing something? Finally, I am wondering if this work would conflict with current jetspeed 2 development by commiters... judging by the fact that you are splitting the profiler and page-manager components out now, perhaps you are already at work here. If not, could this kind of effort help at all if contributed? Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] [J2] Page Navigation Tabs Decorators
David, Just discovered during testing that the decorators are not correctly displaying the background in the title bar in maximize mode. Are you seeing that too? I am not seeing any odd behavior in the portlet title bars in maximized mode. Which browser are you using? The only bug I have seen relates to the content search paths that displays jetspeed action icons in the metal and minty-blue portlets. If it persists, I will update from CVS and check it out. Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] [J2] Page Navigation Tabs Decorators
David/Scott: David Sean Taylor wrote: Randy Watler wrote: David, Just discovered during testing that the decorators are not correctly displaying the background in the title bar in maximize mode. Are you seeing that too? I am not seeing any odd behavior in the portlet title bars in maximized mode. Which browser are you using? Mozilla (Firefox) Internet Explorer 6 same behavior on both The title bar background is white, thus you dont really see the title bar Perhaps you forgot to send a patched file, or I missed one? No, neither. This appears to be because the portlet css stylesheet is now not linked into the document in maximized mode. Perhaps this has to do with the recent changes in PageAggregatorImpl/PortletAggregatorImpl that moved the cssUrls setting from a context session to a plain context attribute? I am still trying to track down how the setting makes its way ino the renderRequest object used by the decorator via the JetspeedPowerTool... I am guessing someone more familiar with the core can find the problem more quickly? Still looking anyway, Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] [J2] Page Navigation Tabs Decorators
Randy Watler wrote: This appears to be because the portlet css stylesheet is now not linked into the document in maximized mode. Perhaps this has to do with the recent changes in PageAggregatorImpl/PortletAggregatorImpl that moved the cssUrls setting from a context session to a plain context attribute? I am still trying to track down how the setting makes its way ino the renderRequest object used by the decorator via the JetspeedPowerTool... I am guessing someone more familiar with the core can find the problem more quickly? It seems odd to me that the maximized render case in PageAggregatorImpl.build() does not call addStyle() for the portlet decorator? Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 Page Profiler/Locator Status
David Sean Taylor wrote: Finally, I am wondering if this work would conflict with current jetspeed 2 development by commiters... judging by the fact that you are splitting the profiler and page-manager components out now, perhaps you are already at work here. If not, could this kind of effort help at all if contributed? I don't see how splitting the components will conflict with your work although it might be best for you to base your patches off the split components if you are going to take a few days to write it It would be great to work with you on completing the profiler functionality I look forward to it! Will do. I will go ahead and start this work and keep you appraised. Eventual JCMS integration seems like a good goal... everyone on the list seems to wants one! Thanks for the support, Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] [J2] Page Navigation Tabs Decorators
Sorry about that. Fix is on the way. Jeremy Ford [EMAIL PROTECTED] Thanks Jeremy! WFM. Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] [J2] Page Navigation Tabs Decorators
David/Scott:
Attached are patches to the jetspeed layout decorator to enable tab
navigation for pages, (folder navigation remains as links). This is
based off of a recent CVS HEAD that includes Scott's navigation work. I
tried to follow the usage of CSS styles established with the portlet
decorators. Let me know how it looks!
Steps to patch:
1. move
/portal/src/webapp/WEB-INF/decorations/portlet/html/jetspeed/images/tab*.gif
to /portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/images.
2. apply decorator-top.vm.patch to
/portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/decorator-top.vm
3. apply styles.css.patch to
/portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/css/styles.css
That's it!
Randy Watler
--- decorator-top.vm.orig 2004-08-24 15:33:26.0 -0600
+++ decorator-top.vm2004-09-01 15:12:11.0 -0600
@@ -34,9 +34,11 @@
/ol
*#
+#set($myF = $jetspeed.currentFragment)
!-- BEGIN: layout/html/jetspeed/decorator.vm --
+div id=layout-${myF.id} class=layout-Jetspeed
p
img src=content/images/jetspeed-logo.gif alt=Jetspeed 2 Logo border=0
/p
@@ -55,12 +57,34 @@
#foreach($childFolder in $folder.folders.iterator())
a
href=${appRoot}/portal${childFolder.name}$childFolder.metaData.getTitle($preferedLocal)/a
nbsp;
#end
-
+
+#*
#foreach($childPage in $folder.pages.iterator())
a
href=${appRoot}/portal${childPage.id}$childPage.getTitle($preferedLocal)/a nbsp;
#end
+*#
+p
+table border=0 cellpadding=0 cellspacing=0 width=100%
+tr
+#foreach($childPage in $folder.pages.iterator())
+#set($tabName = $childPage.getTitle($preferedLocal))
+#if($jetspeed.page == $childPage)
+td class=LTabLeft style=font-size:1pt; nowrap=truenbsp;/td
+td class=LTab align=center valign=middle
nowrap=true${tabName}/td
+td class=LTabRight style=font-size:1pt; nowrap=truenbsp;/td
+#else
+td class=LTabLeftLow style=font-size:1pt;
nowrap=truenbsp;/td
+td class=LTabLow align=center valign=middle nowrap=truea
href=${appRoot}/portal${childPage.id}${tabName}/a/td
+td class=LTabRightLow style=font-size:1pt;
nowrap=truenbsp;/td
+#end
+#end
+/tr
+/table
+/p
/p
+/div
+
## $jetspeed.include($jetspeed.currentFragment)
!-- END: layout/html/jetspeed/decorator.vm --
--- styles.css.orig 2004-07-20 15:36:32.0 -0600
+++ styles.css 2004-09-01 14:34:08.0 -0600
@@ -18,3 +18,49 @@
BODY.layout-Jetspeed {
}
+
+.layout-Jetspeed .LTabLeftLow
+{
+ /**
+ Needs to specify the width of image used
+ otherwise it won't show !
+ **/
+ width:10px;
+
+ /** Always use relative path ! **/
+ background:url(content/jetspeed/images/tableft_low.gif);
+}
+
+.layout-Jetspeed .LTabLow
+{
+ /**
+ Specify the height of the image used
+ else it will use the text height
+ **/
+ height:25px;
+ background:url(content/jetspeed/images/tabmiddle_low.gif);
+}
+
+.layout-Jetspeed .LTabRightLow
+{
+ width:10px;
+ background:url(content/jetspeed/images/tabright_low.gif);
+}
+
+.layout-Jetspeed .LTabLeft
+{
+ width:10px;
+ background:url(content/jetspeed/images/tableft.gif);
+}
+
+.layout-Jetspeed .LTab
+{
+ height:25px;
+ background:url(content/jetspeed/images/tabmiddle.gif);
+}
+
+.layout-Jetspeed .LTabRight
+{
+ width:10px;
+ background:url(content/jetspeed/images/tabright.gif);
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] [J2] Page Navigation Tabs Decorators
David,
Oops... attached CVS diff -u patch files... should have done that the
first time!
Randy Watler
Attached are patches to the jetspeed layout decorator to enable tab
navigation for pages, (folder navigation remains as links). This is
based off of a recent CVS HEAD that includes Scott's navigation work.
I tried to follow the usage of CSS styles established with the portlet
decorators. Let me know how it looks!
Steps to patch:
1. move
/portal/src/webapp/WEB-INF/decorations/portlet/html/jetspeed/images/tab*.gif
to /portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/images.
2. apply decorator-top.vm.patch to
/portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/decorator-top.vm
3. apply styles.css.patch to
/portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/css/styles.css
Index: decorator-top.vm
===
RCS file:
/home/cvspublic/jakarta-jetspeed-2/portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/decorator-top.vm,v
retrieving revision 1.10
diff -u -r1.10 decorator-top.vm
--- decorator-top.vm24 Aug 2004 21:33:25 - 1.10
+++ decorator-top.vm1 Sep 2004 23:58:51 -
@@ -34,9 +34,11 @@
/ol
*#
+#set($myF = $jetspeed.currentFragment)
!-- BEGIN: layout/html/jetspeed/decorator.vm --
+div id=layout-${myF.id} class=layout-Jetspeed
p
img src=content/images/jetspeed-logo.gif alt=Jetspeed 2 Logo border=0
/p
@@ -55,12 +57,34 @@
#foreach($childFolder in $folder.folders.iterator())
a
href=${appRoot}/portal${childFolder.name}$childFolder.metaData.getTitle($preferedLocal)/a
nbsp;
#end
-
+
+#*
#foreach($childPage in $folder.pages.iterator())
a
href=${appRoot}/portal${childPage.id}$childPage.getTitle($preferedLocal)/a nbsp;
#end
+*#
+p
+table border=0 cellpadding=0 cellspacing=0 width=100%
+tr
+#foreach($childPage in $folder.pages.iterator())
+#set($tabName = $childPage.getTitle($preferedLocal))
+#if($jetspeed.page == $childPage)
+td class=LTabLeft style=font-size:1pt; nowrap=truenbsp;/td
+td class=LTab align=center valign=middle
nowrap=true${tabName}/td
+td class=LTabRight style=font-size:1pt; nowrap=truenbsp;/td
+#else
+td class=LTabLeftLow style=font-size:1pt;
nowrap=truenbsp;/td
+td class=LTabLow align=center valign=middle nowrap=truea
href=${appRoot}/portal${childPage.id}${tabName}/a/td
+td class=LTabRightLow style=font-size:1pt;
nowrap=truenbsp;/td
+#end
+#end
+/tr
+/table
+/p
/p
+/div
+
## $jetspeed.include($jetspeed.currentFragment)
!-- END: layout/html/jetspeed/decorator.vm --
Index: styles.css
===
RCS file:
/home/cvspublic/jakarta-jetspeed-2/portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/css/styles.css,v
retrieving revision 1.9
diff -u -r1.9 styles.css
--- styles.css 20 Jul 2004 21:36:31 - 1.9
+++ styles.css 1 Sep 2004 23:59:16 -
@@ -18,3 +18,49 @@
BODY.layout-Jetspeed {
}
+
+.layout-Jetspeed .LTabLeftLow
+{
+ /**
+ Needs to specify the width of image used
+ otherwise it won't show !
+ **/
+ width:10px;
+
+ /** Always use relative path ! **/
+ background:url(content/jetspeed/images/tableft_low.gif);
+}
+
+.layout-Jetspeed .LTabLow
+{
+ /**
+ Specify the height of the image used
+ else it will use the text height
+ **/
+ height:25px;
+ background:url(content/jetspeed/images/tabmiddle_low.gif);
+}
+
+.layout-Jetspeed .LTabRightLow
+{
+ width:10px;
+ background:url(content/jetspeed/images/tabright_low.gif);
+}
+
+.layout-Jetspeed .LTabLeft
+{
+ width:10px;
+ background:url(content/jetspeed/images/tableft.gif);
+}
+
+.layout-Jetspeed .LTab
+{
+ height:25px;
+ background:url(content/jetspeed/images/tabmiddle.gif);
+}
+
+.layout-Jetspeed .LTabRight
+{
+ width:10px;
+ background:url(content/jetspeed/images/tabright.gif);
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] [J2] Page Navigation Tabs Decorators
Title: Re: [PATCH] [J2] Page Navigation Tabs Decorators David, Cool. Attached is a further update patch for layout/html/jetspeed/css/styles.css that supresses the link decoration/colors within the buttons. Obviously, we could spend a long time making this stuff perfect, but with this patch I think the basics are in place for now. Thanks for looking at this and committing! Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] [J2] Page Navigation Tabs Decorators
Reattached patch... webmail strikes again!
Randy Watler
David,
Cool. Attached is a further update patch for
layout/html/jetspeed/css/styles.css that supresses the link
decoration/colors within the buttons. Obviously, we could spend a long time
making this stuff perfect, but with this patch I think the basics are in
place for now.
Thanks for looking at this and committing!
Randy Watler
Index: styles.css
===
RCS file:
/home/cvspublic/jakarta-jetspeed-2/portal/src/webapp/WEB-INF/decorations/layout/html/jetspeed/css/styles.css,v
retrieving revision 1.10
diff -u -r1.10 styles.css
--- styles.css 2 Sep 2004 00:42:50 - 1.10
+++ styles.css 2 Sep 2004 04:06:09 -
@@ -38,9 +38,19 @@
else it will use the text height
**/
height:25px;
+ color:black;
background:url(content/jetspeed/images/tabmiddle_low.gif);
}
+.layout-Jetspeed .LTabLow A:link,
+.layout-Jetspeed .LTabLow A:visited,
+.layout-Jetspeed .LTabLow A:hover,
+.layout-Jetspeed .LTabLow A:active
+{
+ color:black;
+ text-decoration: none;
+}
+
.layout-Jetspeed .LTabRightLow
{
width:10px;
@@ -56,6 +66,7 @@
.layout-Jetspeed .LTab
{
height:25px;
+ color:black;
background:url(content/jetspeed/images/tabmiddle.gif);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 PageAggregatorImpl Configuration
...moving thread from user list... David, This content-server/page aggregation issue remains with the latest CVS HEAD version. The problem in a nutshell is that the SESSION_CONTENT_PATH_ATTR value used by the SimpleContentLocator appears to be set once per session by the PageAggregator and contains only the layout decoration paths for the page. Custom portlet decoration paths do not make it into the path. This issue is apparently related to JiRa JS2-24. Instead of updating the paths in the Perhaps the decorator.vm should include its name in the image urls so that the more general default search paths would come into play, (this is already done within the layout css stylesheets). For example, /content/images/maximize.gif could be modified to be /content/my_portlet_decorator_name/images/maximize.gif at a minimum. If done, the hard coded portlet/html/jetspeed path could be removed. Specifying a more unique path, (i.e. with the decorator name in it), would seem to be better than asking the page aggregator and content-server to dynamically manage content search paths as portlets are rendered. Relying on paths also can lead to confusion in the likely event that image file names are the same! Thoughts? Randy Watler Randy Watler wrote: Scott/All, I have successfully added new portlet and layout html decoration directories to jetspeed and so far so good. However, the content for the portlet action icons, (maximize, minimize, etc...), keeps being served from the jetspeed decoration images directories. I enabled debug output for the content-server and verified that it is indeed serving the jetspeed content. With a little digging, it appears that these defaults are comming from the jetspeed-spring.xml configuration for the PageAggregatorImpl. Unfortunately, I am not sure what should be modified and where. As you know, the decorator.vm template uses the current action list urls to generate the html fragments. These look like /content/images/*.gif. Apparently, the PageAggregatorImpl looks only here for the images: layout/html/my layout decoration name portlet/html/jetspeed portlet/html layout/html generic/html html Consequently, it ends up finding the images in the jetspeed decoration directory instead of in portal/html/my portlet decoration name where I would expect it to be looking! It appears that the same thing is happening in the sample default-page.psml HW_App::PreferencePortlet that attempts to use the metal portlet decorations... the action icons are actually the ones from the jetspeed decorations. It appears to me that there is only one workaround: add the new portlet decorations to the jetspeed-spring.xml. Am I on the right track here? BTW, I am working with CVS HEAD as of 8/21 AM. Please let me know if there is a fix, a better workaround, or if I can help fix this in any way. Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jetspeed2 Page Profiler/Locator Status
David/Scott/All, Looking at the Jetspeed2 CVS HEAD, it appears that the profiler/locator system is not active and instead PSML pages are pulled directly from the page-manager. There were also one or two under construction comments that have also supported this conclusion. Assuming I have not missed anything obvious, I am wondering where this support stands? Since we will need group/role profiling at a minimum before we can roll out a production Jetspeed2 implementation, I would certainly be willing to help out in the coding, debugging, or any other capacity if my efforts would be welcome. Let me know what I can do. Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dumb question?
John/Scott:
The patch below for o/a/j/page/impl/CastorXmlPageManager.java worked for
me... it seems that page ids now require an extension so that they can
be cached correctly in the FileCache with a real file name. I am not
sure this is the CORRECT fix. It is certainly not the cleanest or most
efficient possible... perhaps adding an additional name/alias lookup to
the FileCache would be better?
I also had to escape the French LATIN-1 character embedded in the
o/a/j/page/TestCastorXmlPageManager.java source file to make sure it
functioned properly. I seem to recall somewhere that LATIN-1 characters
must be escaped in string literals, (?).
Randy Watler
-
--- CastorXmlPageManager.java.orig2004-08-30 21:37:13.0 -0600
+++ CastorXmlPageManager.java2004-08-30 20:44:43.0 -0600
@@ -194,7 +194,14 @@
Page page = null;
-page = (Page) pages.getDocument(id);
+if (id.endsWith(this.ext))
+{
+page = (Page) pages.getDocument(id);
+}
+else
+{
+page = (Page) pages.getDocument(id + this.ext);
+}
if (page == null)
{
@@ -206,7 +213,14 @@
// watcher
try
{
-pages.put(id, page, this.rootDir);
+if (id.endsWith(this.ext))
+{
+pages.put(id, page, this.rootDir);
+}
+else
+{
+pages.put(id + this.ext, page, this.rootDir);
+}
int lastSlash = id.indexOf(/);
if (lastSlash -1)
{
@@ -385,7 +399,16 @@
}
// marshal page to disk
-File f = new File(this.rootDir, id + this.ext);
+
+File f = null;
+if (id.endsWith(this.ext))
+{
+f = new File(this.rootDir, id);
+}
+else
+{
+f = new File(this.rootDir, id + this.ext);
+}
FileWriter writer = null;
try
@@ -437,7 +460,14 @@
{
try
{
-pages.put(id, page, this.rootDir);
+if (id.endsWith(this.ext))
+{
+pages.put(id, page, this.rootDir);
+}
+else
+{
+pages.put(id + this.ext, page, this.rootDir);
+}
}
catch (IOException e)
{
@@ -467,11 +497,26 @@
return;
}
-File file = new File(this.rootDir, id + this.ext);
+File file = null;
+if (id.endsWith(this.ext))
+{
+file = new File(this.rootDir, id);
+}
+else
+{
+file = new File(this.rootDir, id + this.ext);
+}
synchronized (pages)
{
-pages.remove(id);
+if (id.endsWith(this.ext))
+{
+pages.remove(id);
+}
+else
+{
+pages.remove(id + this.ext);
+}
}
file.delete();
-
--- TestCastorXmlPageManager.java.orig2004-08-30 21:21:44.0
-0600
+++ TestCastorXmlPageManager.java2004-08-30 21:22:26.0 -0600
@@ -346,7 +346,7 @@
Folder folder1French = pageManager.getFolder(folder1);
FolderMetaData metaData = folder1French.getMetaData();
assertNotNull(metaData);
-assertEquals(Titre français pour la chemise 1,
metaData.getTitle(Locale.FRENCH));
+assertEquals(Titre fran\347ais pour la chemise 1,
metaData.getTitle(Locale.FRENCH));
Folder folder1English = pageManager.getFolder(folder1);
metaData = folder1English.getMetaData();
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dumb question?
...same patches attached to avoid line wrapping...
Randy Watler
rwatler wrote:
John/Scott:
The patch below for o/a/j/page/impl/CastorXmlPageManager.java worked
for me... it seems that page ids now require an extension so that they
can be cached correctly in the FileCache with a real file name. I am
not sure this is the CORRECT fix. It is certainly not the cleanest or
most efficient possible... perhaps adding an additional name/alias
lookup to the FileCache would be better?
I also had to escape the French LATIN-1 character embedded in the
o/a/j/page/TestCastorXmlPageManager.java source file to make sure it
functioned properly. I seem to recall somewhere that LATIN-1
characters must be escaped in string literals, (?).
Randy Watler
--- CastorXmlPageManager.java.orig 2004-08-30 21:37:13.0 -0600
+++ CastorXmlPageManager.java 2004-08-30 20:44:43.0 -0600
@@ -194,7 +194,14 @@
Page page = null;
-page = (Page) pages.getDocument(id);
+if (id.endsWith(this.ext))
+{
+page = (Page) pages.getDocument(id);
+}
+else
+{
+page = (Page) pages.getDocument(id + this.ext);
+}
if (page == null)
{
@@ -206,7 +213,14 @@
// watcher
try
{
-pages.put(id, page, this.rootDir);
+if (id.endsWith(this.ext))
+{
+pages.put(id, page, this.rootDir);
+}
+else
+{
+pages.put(id + this.ext, page, this.rootDir);
+}
int lastSlash = id.indexOf(/);
if (lastSlash -1)
{
@@ -385,7 +399,16 @@
}
// marshal page to disk
-File f = new File(this.rootDir, id + this.ext);
+
+File f = null;
+if (id.endsWith(this.ext))
+{
+f = new File(this.rootDir, id);
+}
+else
+{
+f = new File(this.rootDir, id + this.ext);
+}
FileWriter writer = null;
try
@@ -437,7 +460,14 @@
{
try
{
-pages.put(id, page, this.rootDir);
+if (id.endsWith(this.ext))
+{
+pages.put(id, page, this.rootDir);
+}
+else
+{
+pages.put(id + this.ext, page, this.rootDir);
+}
}
catch (IOException e)
{
@@ -467,11 +497,26 @@
return;
}
-File file = new File(this.rootDir, id + this.ext);
+File file = null;
+if (id.endsWith(this.ext))
+{
+file = new File(this.rootDir, id);
+}
+else
+{
+file = new File(this.rootDir, id + this.ext);
+}
synchronized (pages)
{
-pages.remove(id);
+if (id.endsWith(this.ext))
+{
+pages.remove(id);
+}
+else
+{
+pages.remove(id + this.ext);
+}
}
file.delete();
--- TestCastorXmlPageManager.java.orig 2004-08-30 21:21:44.0 -0600
+++ TestCastorXmlPageManager.java 2004-08-30 21:22:26.0 -0600
@@ -346,7 +346,7 @@
Folder folder1French = pageManager.getFolder(folder1);
FolderMetaData metaData = folder1French.getMetaData();
assertNotNull(metaData);
-assertEquals(Titre français pour la chemise 1,
metaData.getTitle(Locale.FRENCH));
+assertEquals(Titre fran\347ais pour la chemise 1,
metaData.getTitle(Locale.FRENCH));
Folder folder1English = pageManager.getFolder(folder1);
metaData = folder1English.getMetaData();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jetspeed2 anon login trap?
Forwarded from jetspeed-user... David Sean Taylor wrote: On Aug 22, 2004, at 9:25 PM, Randy Watler wrote: I have recently pulled Jetspeed2 from CVS HEAD to pick up some of the latest changes. I built it from scratch and installed it normally using MySQL. Afterward, launching the portal default page results in the anon user being logged in. I am unable to logout using the security portlet, (anon remains logged in), or login as a different user using login.jsp, (it results in a Tomcat redirection error; I assume it is not intended to be invoked directly). Anyway, being locked into anon seems odd, but I may not be understanding something that needs to be configured! I am trying to add a login capability to the layout decorations instead of using the security portlet. This seems simple enough, but the above problem has derailed me at the moment. Thoughts? I accidently caused that. We need to decide whether the anonymous (guest) user actually logs in or not. Regardless, if the guest user is logged in, it shouldn't appear that way in the login portlet. Could you start a thread on jetspeed-dev on this subject matter? thanks Randy Watler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
