RE: A humble request,
Dude, you need to look into your filtering stuff a little further. Don't ask all of us to change because you can't get your email stuff to filter off subject line! I'm filtering this and a zillion others at the same time. -Original Message- From: John Kew [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 21, 2001 1:08 AM To: Jetspeed Subject: A humble request, would it be possible to preface all subjects on the JetSpeed list with [JetSpeed]? This would help filtering, and just general recognition of the emails. -John -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: Portlet security
There was a proposal in the cvs tree at one time, don't know if enough has changed to make it invalid, but integration with turbine's security model was in there... -Original Message- From: Craig Berry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 21, 2001 11:20 AM To: Jetspeed Mailing List (E-mail) Subject: Portlet security The GlueCode team is preparing to pursue portlet-level security for Jetspeed -- that is, the ability to make portlets visible to only certain users. Of course, we want to build this on the existing Turbine group/role/permission scheme. Our initial thought is that adding attributes in jetspeed-config.jcfg of roughly this form viewable-by group="foo" role="bar" perm="baz" / would be a good way to encode the permissions. In the absence of any such attributes, the default would be viewable by all. A reasonable "choke point" at which to limit access to portlets would appear to be PortletConfig.getPortletSet(). The set returned could be filtered to remove portlets for which the user does not have permission. This would suffice to control access both to portlets on the portal page, and listing of portlets on the customization page (which we're working to extend, by the way). Thoughts on this approach, please? -- Craig Berry - (310) 570-4140 VP Technology GlueCode 1452 Second St Santa Monica CA 90401 -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Lock still there on clean checkout from CVS
FYI: Still getting a lock wait message on a clean checkout from cvs... waiting for jon's lock in /products/cvs/jetspeed/jetspeed/webapp/WEB-INF/templates/jsp/screens = Jeffrey D. Brekke Information Systems [EMAIL PROTECTED] Quad/Graphics http://www.qg.com 555 South 108th Street 414-566-3302 West Allis, WI 53214-1145 USA --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: Tracing/Logging in JetSpeed
For concerns about Tracing/Logging I suggest take a look at: http://www.log4j.org./ Josep Vela [EMAIL PROTECTED] RD Manager FIHOCA Avda. Roma, 25 8029 Barcelona (Spain) Thanks for the hint, the API looks quite good, it has the required isEnabledFor(Priority), isInfoEnabled() and isDebugEnabled() methods, also, it has explicit support for assertions which is very nice. However, a colleague just told me that the Turbine community has decided against using Log4J and is now working on improved tracing/logging, I think based on Avalon. I believe the idea was to improve the interface so the logging implementation is pluggable. I don't think anyone has said 'no' to log4j though... --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: WAR support
Why not just check out the sources for turbine from CVS? - Jeffrey D. Brekke Information Systems [EMAIL PROTECTED] Quad/Graphics http://www.qg.com 555 South 108th Street 414-566-3302 West Allis, WI 53214-1145 USA - -Original Message- From: David Sean Taylor [mailto:[EMAIL PROTECTED]] Sent: Monday, December 11, 2000 12:29 PM To: JetSpeed Subject: RE: WAR support Raphael, I noticed that you updated the turbine.jar. Ingo recently zipped up the turbine source into /lib/src/turbine.zip when he checked in turbine.jar. I was hoping that we would continue to provide the current source for turbine with the latest jar if its not too much trouble? Thanks for updating the Hypersonic SQL database with the latest Turbine schema. Its been broken for the last week or so. Did you have trouble getting the turbine-hypersonic.sql script to run? I noticed that you didn't check it in. I had problems with the 'default -1' on the TURBINE_SCHEDULED_JOB table and had to remove the 'default' constraints. (Im not sure how SQL-2 compliant hypersonic is, but regardless Im really beginning to like it.) It now seems obvious to me that jetspeed.script was used to create the database for the WAR distribution. To point out another point that may or may not be obvious, it appears that the 'jetspeed-system' directory will no longer be used. Now the default hypersonic database, cache and logs are all placed under the webapp/WEB-INF directory. -- David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, December 11, 2000 7:00 AM To: JetSpeed Subject: Re: WAR support ingo schuster wrote: At 11:22 2000-12-11, [EMAIL PROTECTED] wrote: I've just committed in the CVS an initial webapp support for jetspeed based on my Turbine resources patches. Their are some known issues yet with the WAR but it builds OK and I should be able to iron out all the small details tonight. In the webapp directory, I tried to reorganize the user documents I welcome any comments, suggestions, etc on the document structure. Raphael, Can you explain the directory structure in more detail? Am I right that "webapp" is the application root and "WEB-INF" is meant to be the document root? No. The "webapp" is bith the application and document root. WEB-INF is the special folder in webapps which is *not* accessible from server and therefore mainly for storing private items of the webapp. How can it then be that the images are not below the document root? What I'd really like to have is a directory structure that separates content (in the docroot) from configuration and application data (below the webapp but not below the docroot). I'd propose a structure like follows (that's quite similar to what I use at the moment): webapp |- WEB-INF |- lib |- portlets |- servlets |- config |- log |- cache |- doc_root |- images |- static |- dynamic |- stylesheets |- ... |- templates | |- jsp | | |- layouts, navigations,screens | |- wm | |- layouts, navigations,screens |- psml |- portlet_resources |- portlet1 |- portlet2 |- portlet3 "WEB-INF" contains only web.xml "lib" contains the portal jars: jetspeed.jar, turbine.jar, xerces.jar,... "portlets" holds jars of portlets "servlets" may contain additional servlets, but is empty (or not present at all) in the standard installation "config"contains all our config (properties) files - (the webapps configuration shouldn't really be exposed in the docroot!) "cache","log" are application folders "lib", "portlets","servlets" would be in the classpath. Below "doc_root" (or whatever you name it) the HTTP accessible files are stored: "images", "stylesheets", etc. - content "templates" - our templates "psml" - the psml files (if stored in the filesystem and not in a DB,LDAP,...) "portlet_resources" - portlet specific resources such as images, stylesheets, sample data, I know that there are some problems to realize this structure (e.g. jetspeed-config.jcfg needs to be below the doc_root at the moment), but as I said, that the kind of structure makes sense to me (and so it's probably worth some effort to achive it). What do you think? Raphael, could you perhaps list and explain your directory
RE: RegistryManager service landed
Kevin, Understood. I don't think there is a need to move these over to scheduled jobs since the daemon factory is now implemented as a service. If in the future there is a need, we can do it then. So I will not look at porting these into scheduled jobs at this time. So there is no overlap, have you considered contrib'ing the daemon service into turbine? Maybe even a special case of the scheduler/scheduled job? - Jeffrey D. Brekke Information Systems [EMAIL PROTECTED] Quad/Graphics http://www.qg.com 555 South 108th Street 414-566-3302 West Allis, WI 53214-1145 USA - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 03, 2000 7:36 PM To: JetSpeed Subject: Re: RegistryManager service landed -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 "Brekke, Jeff" [EMAIL PROTECTED] writes: There's only 1 package to implement as a service before we can remove the JetspeedServlet: the daemon stuff. I've been looking into this. There was talk of converting these to turbine scheduled jobs and using the turbine scheduler. I wouldn't want these ported under the scheduler. They somewhat overlapped but if something is a scheduled task then it is just that... a task... not a daemon. With the daemon package (at least with what I intended) you can start a thread and have it do its own management without having something trigger it. There is a lot of advangate in that. This is great, but will require a database backend to hold the scheduled jobs, which in turn means Jetspeed could not run without a database. John Thorhauer has created a turbine scheduler that initializes from a properties file. We could use his scheduler and implement it in Jetspeed or I was thinking of attempting to merge this with the Turbine scheduler ( if possible ) and contrib back into Turbine. Converting the daemon implementations into scheduled jobs seems straightforward. Any comments? Am I missing something? snip (strong) -0 on this migration. The current impls could run under the scheduler (probably) but if this is decided please tag CVS as I would want to migrate this code into its own package... maybe turbine service. Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 YEAH!!! I'M A MIME! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6KvUTAwM6xb2dfE0RAm06AKCkvJ9GQUyGu6BWmSJH6Rf3izY8CQCffTvy pFx4dmu5Eafp0yNQ6ngEkLw= =TQtO -END PGP SIGNATURE- Uzi Legion of Doom Soviet DES Rule Psix SEAL Team 6 Albanian domestic disruption genetic FBI spy Qaddafi Peking Waco, Texas jihad -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED] This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: RegistryManager service landed
See above. I'm interested in the Scheduler mechanism. Currently, I'm implementing Resources as "implements Runnable", so that they can be used (casted) as parameters for their own update tasks. I will look if it would be simple to change this so that they encapsulate a Turbine Scheduler job, instead. FYI: I've created a TurbineNonPersistentScheduler that will initialize the scheduler with jobs from the properties file and doesn't require a db backend to function. Shortly I'll present the changes on the Turbine list to see if there are any objections to committing it. My quick thoughts were to take the three daemons we have now: Feed, DiskCache, and BadURL, convert them to scheduled jobs using the above scheduler, dumping the daemon facility. Sounds like we'll need something different for what you and Raphael are proposing. --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: RegistryManager service landed
There's only 1 package to implement as a service before we can remove the JetspeedServlet: the daemon stuff. I've been looking into this. There was talk of converting these to turbine scheduled jobs and using the turbine scheduler. This is great, but will require a database backend to hold the scheduled jobs, which in turn means Jetspeed could not run without a database. John Thorhauer has created a turbine scheduler that initializes from a properties file. We could use his scheduler and implement it in Jetspeed or I was thinking of attempting to merge this with the Turbine scheduler ( if possible ) and contrib back into Turbine. Converting the daemon implementations into scheduled jobs seems straightforward. Any comments? Am I missing something? jb --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: [vote] Remove the Turbine subclass
I was working on converting each individually. Putting all the intializations into one service, for now, would allow the checkin to the latest trubine code to proceed. Either way, they will be converted. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, November 17, 2000 10:28 AM To: JetSpeed Subject: Re: [vote] Remove the Turbine subclass on 11/17/2000 2:28 AM, "Raphael Luta" [EMAIL PROTECTED] wrote: If the vote is in favor of moving to a service init I thought that Jeff was already working on this. -jon -- twice of not very much is still a lot more than not very much -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: Caching
[SNIPPED] Never mind if I was harsh. The reason why I think that we should rename JetspeedDiskCache is because of this kind of confusions. It is very easy to forget the distinctions. Also, I think there are more features in it that caching. It acts also as a serializer to external access. The new service we are planning will enable plugging in a more complex content management system instead of it. BTW: The feature of having multiple caches with different policies is already available? [SNIPPED] No. Jason van Zyl and Dave Bryson are planning on enhancing it for use in Velocity and are welcome to suggestions. See his post earlier today on this list. Have a good weekend, jb --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
EngineContextService patch
FYI: I've moved EngineContext over to a Turbine service. It still is not populated properly, but the functionality of the non-turbine service version is the same as the service version. In order to get this to work, I had to update to a newer Turbine jar. This also got the ThreadpoolService working. I've uploaded a large patch and the turbine jar I used to my patch site: http://sites.netscape.net/ekkerbj Below is a summary of the patch: - Created org.apache.jetspeed.services.enginecontext containing the EngineContext as a turbine service - Updated the TR.properties with changes for the updated turbine jar. - Updated the turbine jar to a newer version. This version is right before changes to the User/ACL stuff started taking place. So the new services framework is functional. - Updated JetspeedServlet jar so the old EngineContext stuff is removed - Updated other code that uses EngineContext - Updated the unix starup script for a tomcat-build to initialize the classpath properly Again, I didn't really change the contents of EngineContext ( which is suspect and not populated yet ) yet. I've missed the discussion about how this object will be populated. Let me know of any changes/problems. Feel free to commit or I guess I'll ask for a vote for write access to CVS for myself. I'll hopefully be able to crank out another service before the weekend. jb - Jeffrey D. Brekke Information Systems [EMAIL PROTECTED] Quad/Graphics http://www.qg.com 555 South 108th Street 414-566-3302 West Allis, WI 53214-1145 USA - --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: CVS Clean up, Part 1: Initialization and Properties
-Original Message- From: Raphael Luta [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 6:51 AM To: JetSpeed Subject: Re: CVS Clean up, Part 1: Initialization and Properties "Brekke, Jeff" wrote: [SNIPPED] Most of the initialization work done in the Jetspeed servlet could actually be done by Turbine directly if the daemons, pools, etc... were implemented as TurbineServices. I'm definitely +1 for reimplementing all these packages as Turbine services. [SNIPPED] We should have this reimplemented as turbine services asap. Subclassing the turbine servlet is not recommended. There is an entire services/initable framework in turbine for accomplishing initialzations. I think it would be a bad design decision. Reimplementing the Jetspeed servlert init() code as a JetspeedService would mean both : - that Jetspeed can be described as a Turbine service, which it can't. it's a full web application - that we would have a service which only task is to initialize other components without providing any access to them, ie a useless service, a hack. I think the real fix is to move all the initialized components as real Turbine services so that Turbine can take care of this initialization itself and actually use them ! We can then remove the Jetspeed servlet because it's not required anymore. Understood and I agree. My reply was not clear and you nailed it. Jetspeed is a web application based on the Turbine framework. I've just committed the first such service (Threadpool) and I'd definitely like if some other people could step in and move the deamons, etc as services. BTW, why subclassing Turbine is not recommended ? If there is specialization that is required of the Turbine servlet, then it should be added to Turbine. This is why the entire initable stuff was created and even spec'd out by Kevin Burton as I recall. Thanks again for all your work on Jetspeed. -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Build errors
FYI: Looks like some strange errors on build are ocurring after a cvs update. With regards to ThreadPool. Looks like org/apache/jetspeed/util/threadpool/Runable.java is in a package org.apache.jetspeed.services.threadpool, but the file is in the wrong place and there is no services/threadpool directories in the source tree. diskcache and alike are blowing. - Jeffrey D. Brekke Information Systems [EMAIL PROTECTED] Quad/Graphics http://www.qg.com 555 South 108th Street 414-566-3302 West Allis, WI 53214-1145 USA - This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: CVS Clean up, Part 1: Initialization and Properties
[SNIPPED] Most of the initialization work done in the Jetspeed servlet could actually be done by Turbine directly if the daemons, pools, etc... were implemented as TurbineServices. I'm definitely +1 for reimplementing all these packages as Turbine services. [SNIPPED] We should have this reimplemented as turbine services asap. Subclassing the turbine servlet is not recommended. There is an entire services/initable framework in turbine for accomplishing initialzations. --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: Branch switch
I get the following errors building on a fresh checkout of jetspeed ( cvs co jetspeed ). jetspeed/src/java/org/apache/jetspeed/portal/PortletConfig.java:66: Package org.apache.jetspeed.psml.peer not found in import. [javac] import org.apache.jetspeed.psml.peer.*; [ Other files same error ] jetspeed/src/java/org/apache/jetspeed/turbine/screens/Home.java:76: Package org.apache.jetspeed.psml.factory not found in import. [javac] import org.apache.jetspeed.psml.factory.*; -Original Message- From: Santiago Gala [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 07, 2000 1:40 PM To: JetSpeed Subject: Re: Branch switch Santiago Gala wrote: The HEAD branch should be switched with a new branch, and then it should compile and run. I have to run out of here. I'll report completely later today. Back into my home/office. I have not seen any feedback on the HEAD branch. I hope it is not completely broken :-) A short log of what I did. I tagged the HEAD branch just before the changes as: pre-proposal-0003-branch-switch I tagged the pre-proposal-0003-no-psml branch just before as: pre-proposal-0003-branch-switch-branch I created a new branch out of HEAD, for further development in proposal-0003. It is called proposal-0003-work-01 I checked this branch out and tested that it was the same as before. (To check out a branch, one has to check out HEAD and then update -r branch due to a bug in cvs) I updated -j ... to merge. I noticed after that I could have got a much cleaner process by using two -j, but I had to fight with problems, ... Fix all the conflicts and issues with compilation and commit again. To ensure that it works, clean the bin directory with ./build.sh clean before building. It is possible that you have to delete the Cocoon jsp repository, but I did not need it, XSP is running. Sorry for the delay but yesterday night I got electric power problems due to a wind storm, and this morning my computer froze when I was finishing to write the message and then I had to leave. Tell me please if you find any problem building the tree. Regards... :-) -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: ACL's
There is a proposal for this in the cvs tree. -Original Message- From: Anbunidhi Mahalingam [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 4:46 AM To: [EMAIL PROTECTED] Subject: ACL's ACL's in Jetspeed : I just tried to control the portlet through Jetspeed (like show / hide particular portlet in the portal) based on the ACL stuff. But I got failed because of the following strategies. If I am wrong in doings, please correct me and help me to resolve this issue.(atleast controlling one portlet) using ACL. As Mr. Kevin Burton is pointing out that Jetspeed can access and use ACL's which is in Turbine to control Jetspeed portal. But, as of my knowledge, the ACL's which we are using in Turbine is not sufficient for controlling our portlet. Turbine ACL's just control entire screen/portal not our individual portlet. It is not possibe to control access to a portlet or part of it through Turbine. If we have ACL's in jetspeed we can control our each and every portlet with in the screen/portal. For example, if we want to use Jetspeed in an intranet stuff like, think about a portlet which can show the salary of each employee. In this case we must have the ability to restrict the usage to people of the HR department. On the other hand it is not necessary to enable this restriction mechanism on the user level. In general we would restrict the access to a group of users (for example the members of the HR department). These users will be members of a specific role. As a result we should enable access to portlet functionality depending on their roles. Username may still need to be used in the access/denial specfication. Otherwise, how do you deny access to one user of the HR group, but allow access to all others? We cannot control this through Turbine ACL's. So we need seperate ACL's which should be in a position to control our individual portlet within portal/screen. With Regards, Anbunidhi Mahalingam. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: ACL's
The proposal hasn't been implemented yet. Changes to PSML must take place. Currently there is no way to control portlet display at the layout level. If you are writing your own portlets, you could check the users name or group in the portlet itself and choose to display the content or a message or something. -Original Message- From: Anbunidhi Mahalingam [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 6:34 AM To: JetSpeed Subject: Re: ACL's Is there anyway around to do that with Turbine ACL's ??? - Original Message - From: "Brekke, Jeff" [EMAIL PROTECTED] To: "'JetSpeed'" [EMAIL PROTECTED] Sent: Thursday, October 19, 2000 1:21 PM Subject: RE: ACL's There is a proposal for this in the cvs tree. -Original Message- From: Anbunidhi Mahalingam [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 4:46 AM To: [EMAIL PROTECTED] Subject: ACL's ACL's in Jetspeed : I just tried to control the portlet through Jetspeed (like show / hide particular portlet in the portal) based on the ACL stuff. But I got failed because of the following strategies. If I am wrong in doings, please correct me and help me to resolve this issue.(atleast controlling one portlet) using ACL. As Mr. Kevin Burton is pointing out that Jetspeed can access and use ACL's which is in Turbine to control Jetspeed portal. But, as of my knowledge, the ACL's which we are using in Turbine is not sufficient for controlling our portlet. Turbine ACL's just control entire screen/portal not our individual portlet. It is not possibe to control access to a portlet or part of it through Turbine. If we have ACL's in jetspeed we can control our each and every portlet with in the screen/portal. For example, if we want to use Jetspeed in an intranet stuff like, think about a portlet which can show the salary of each employee. In this case we must have the ability to restrict the usage to people of the HR department. On the other hand it is not necessary to enable this restriction mechanism on the user level. In general we would restrict the access to a group of users (for example the members of the HR department). These users will be members of a specific role. As a result we should enable access to portlet functionality depending on their roles. Username may still need to be used in the access/denial specfication. Otherwise, how do you deny access to one user of the HR group, but allow access to all others? We cannot control this through Turbine ACL's. So we need seperate ACL's which should be in a position to control our individual portlet within portal/screen. With Regards, Anbunidhi Mahalingam. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- - This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: ACL's
Yes, you are correct. I was lumping the portletregistry ( or .jcfg ) under 'PSML' umbrella. During customization the user would only see content they have access to. Individual and default user's psml would not hold information about security, the portlet registry does. It's all in the proposal-004, sorry for the confusion. This proposal will need to be updated when the security refactoring is completed in Turbine ( supposedly very soon ). FYI: I noticed that this proposal (004) is checked into the head, not the branch that compiles. You can view it with cvsweb. http://www.working-dogs.com/jetspeed/cvsweb/index.cgi/jetspeed/docs/proposal s/0004.txt?rev=1.2content-type=text/x-cvsweb-markup -Original Message- From: Thomas F. Boehme [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 8:15 AM To: JetSpeed Subject: Re: ACL's Jeff, I can't see the need to change the PSML structure. A user should see whatever is defined in his/her PSML file. Really, the control mechanism should be in place at the customization level. That is, a user who is not authorized to see certain content should not have the option of choosing that portlet for viewing in his/her page. Therefore, I would place the the authorization at content (-- jetspeed-config.jcfg or similar) rather than the layout. What do you think?` Thomas - Original Message - From: "Brekke, Jeff" [EMAIL PROTECTED] To: "'JetSpeed'" [EMAIL PROTECTED] Sent: Thursday, October 19, 2000 14:20 Subject: RE: ACL's The proposal hasn't been implemented yet. Changes to PSML must take place. Currently there is no way to control portlet display at the layout level. If you are writing your own portlets, you could check the users name or group in the portlet itself and choose to display the content or a message or something. -Original Message- From: Anbunidhi Mahalingam [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 6:34 AM To: JetSpeed Subject: Re: ACL's Is there anyway around to do that with Turbine ACL's ??? - Original Message ----- From: "Brekke, Jeff" [EMAIL PROTECTED] To: "'JetSpeed'" [EMAIL PROTECTED] Sent: Thursday, October 19, 2000 1:21 PM Subject: RE: ACL's There is a proposal for this in the cvs tree. -Original Message- From: Anbunidhi Mahalingam [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 4:46 AM To: [EMAIL PROTECTED] Subject: ACL's ACL's in Jetspeed : I just tried to control the portlet through Jetspeed (like show / hide particular portlet in the portal) based on the ACL stuff. But I got failed because of the following strategies. If I am wrong in doings, please correct me and help me to resolve this issue.(atleast controlling one portlet) using ACL. As Mr. Kevin Burton is pointing out that Jetspeed can access and use ACL's which is in Turbine to control Jetspeed portal. But, as of my knowledge, the ACL's which we are using in Turbine is not sufficient for controlling our portlet. Turbine ACL's just control entire screen/portal not our individual portlet. It is not possibe to control access to a portlet or part of it through Turbine. If we have ACL's in jetspeed we can control our each and every portlet with in the screen/portal. For example, if we want to use Jetspeed in an intranet stuff like, think about a portlet which can show the salary of each employee. In this case we must have the ability to restrict the usage to people of the HR department. On the other hand it is not necessary to enable this restriction mechanism on the user level. In general we would restrict the access to a group of users (for example the members of the HR department). These users will be members of a specific role. As a result we should enable access to portlet functionality depending on their roles. Username may still need to be used in the access/denial specfication. Otherwise, how do you deny access to one user of the HR group, but allow access to all others? We cannot control this through Turbine ACL's. So we need seperate ACL's which should be in a position to control our individual portlet within portal/screen. With Regards, Anbunidhi Mahalingam. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html
RE: Putting another app on Jetspeed
We have the same situation: extended turbine's authentication/authorization and have many Turbine applications ( all ecs based now ). What we did is place all our applications inside the same zone and and have Jetspeed use our auth extensions. This works pretty well for us right now. But we now want to use templates ( WM/Velocity ) for our turbine applications. I can't really see how to integrate jetspeed ( basically an ECS/XML based turbine application ) and a templated application. *) We want to maintain the common look and feel accross our applications also. So using the user settings/prefs from jetspeed sounds great. Again the integration is not clear to us yet. Basically we want to use Jetspeed to allow our users: *) to pull together information from all these different applications *) arrange them how they want: layout *) Set preferences, color, settings, etc. *) Use what ever we want to develop the web application ( Turbine currently ). But also allow other web apps to appear on their portal page also. There was talk a few months back on this list or the Turbine list, about writing an external login server which multiple applications ( read: zones ) could use for authentication/authorization. Effectivly letting multiple turbine apps share login information. It may get into sharing session information accross zones and session failover also. jb -Original Message- From: Diethelm Guallar, Gonzalo To: 'JetSpeed' Sent: 09/15/2000 8:36 PM Subject: Putting another app on Jetspeed Ok, here is the deal. I have developed a web app using Turbine, and it has a user/permission system (it actually extends Turbine's) to ensure each user has access to his/her own stuff and nothing more. What I would like to do is: * Put something in Jetspeed that, once a user logs into Jetspeed, will let them choose to go to a page with links to all the stuff in my Turbine app that user can do. Think "my app = a bank, what the user can do = browse his accounts, credit cards, etc.". * Pass the login information from Jetspeed to my Turbine app, so that the user logs in only once. * Embed my app in Jetspeed (I believe this is already possible and pretty simple, right?). What happens with things such as multiple Turbine jars being loaded (one for Jetspeed, once for my App)? Should I just redirect from Jetspeed to a separate "zone" (I'm using Tomcat, but you get the idea)? If yes, how should I share the login information so that the user logs in only once on Jetspeed and is able to access all the context in my Turbine app? Am I making sense here? Thanks, -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: CVS code has compilation bugs
[SNIPPED] Ok, this would be Jetspeed-1.2b1.zip, size 7338070 bytes, right? Yup. --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
