From ccunningham@example.org Thu Mar 1 06:55:30 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 10231 invoked from network); 1 Mar 2001 06:55:30 -0000 Received: from bluesunrise.com (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 06:55:30 -0000 Received: from MANU [83.161.120.155] by bluesunrise.com [63.197.2239130] with SMTP (MDaemon.v3.0.0.R) for <ccunningham@example.org>; Wed, 28 Feb 2001 23:10:56 -0800 Reply-To: <ccunningham@example.org> From: "David Sean Taylor" <ccunningham@example.org> To: <ccunningham@example.org> Subject: RE: NLS in Jetspeed Date: Wed, 28 Feb 2001 22:56:12 -0800 Message-ID: <004101c0a21c$b53a1340$83e5c53f@MANU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <ccunningham@example.org> X-MDaemon-Deliver-To: ccunningham@example.org X-Return-Path: ccunningham@example.org X-MDRcpt-To: ccunningham@example.org X-MDRemoteIP: 83.161.120.155 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hope this finds its way to the right list, and I hope everyone finds the new list! Im continuing Ingo's and Santiago's discussion 'RE: NLS in Jetspeed' from a few days ago on the old list: > > I'd like to improve the national language support in Jetspeed. I never finished the language code for the profiler, but it shouldn't take too long, although Im not as fast as Ingo, but who is! :)) > > * The templates are moved into respective subdirectories (e.g. > > templates/jsp/en/{layouts,navigations,screens} for JSP The profiler proposal specified that the implementation use file names, not directories, for language specific resources The directories are broken down by mediatype Since I haven't yet completed writing the language support, Im open to arguments for a different impl. > (I think subclassing he TurbineTemplateService is the easiest way of doing this) You could also add the code to the TurbineTemplateService. As Ingo and I are aware, it already has a fallback algorithm. Its just a matter of deciding whether NLS should go into Turbine. If it doesn't, it will still be difficult to separate the fallback algorithm, and you end up completely rewriting it anyway. BTW - Ingo - that reminds me - did our fix ever get committed on the default name bug? > > Also, don't forget it is lang_COUNTRY, as in de, de_AT, de_CH, de_DE > (jre even has a de_DE_EURO). > > I think the approach should be having > > default > (files here) > lang > (files here maybe) > COUNTRY > (files here maybe) > ... > This differs from the proposal. See jetspeed/proposals/0005.txt > The schema for psml is user/mime_type or group/mime_type or > default/mime_type > Our schema for skins is lang/mime_type/browser/version/theme > > I think we should unify this code under the Profiler Service, > to have a > method that, > given a CapabilityMap/RunData, a "kind_of_resource" and a > name, returns > the resource going to > the leaves and falling back if it does not exist. > Yes, when you say 'kind_of_resource' you mean: - markup (psml) - template - skins ? - ... So this profiling service will find any resource, not just psml markup. +1 on that The JetspeedProfileManagerService is actually undergoing some changes, most of the implementation will remain, but Raphael has refactored the profiler into two services under the new customization package (see the 'psml_02-branch' branch): 1. ConfigStoreService 2. ProfileService I will look into factoring out the resource fallback algorithm into a generic fallback service, and also consider directories to delineate NLS resources -- david From ccunningham@example.org Thu Mar 1 07:06:20 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 13774 invoked from network); 1 Mar 2001 07:06:20 -0000 Received: from bluesunrise.com (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 07:06:20 -0000 Received: from MANU [83.161.120.155] by bluesunrise.com [63.197.2239130] with SMTP (MDaemon.v3.0.0.R) for <ccunningham@example.org>; Wed, 28 Feb 2001 23:21:28 -0800 Reply-To: <ccunningham@example.org> From: "David Sean Taylor" <ccunningham@example.org> To: <ccunningham@example.org> Subject: RE: [VOTE] Portlet API, Results of the Chat Date: Wed, 28 Feb 2001 23:06:45 -0800 Message-ID: <004301c0a21e$2d965780$83e5c53f@MANU> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <ccunningham@example.org> X-MDaemon-Deliver-To: ccunningham@example.org X-Return-Path: ccunningham@example.org X-MDRcpt-To: ccunningham@example.org X-MDRemoteIP: 83.161.120.155 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > Point 1 (output model): > The API will have streams in the base response API, SAX support in a > sub-interface; compliant portals must implement both interfaces. > +1 > Point 2 (content model): > Fragments are the prefered output model for portlets but the > portal must > implement full documents support as the default. > The content model used by a portlet is defined in its portlet > descriptor. +1 -- david From ccunningham@example.org Thu Mar 1 13:10:18 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 35398 invoked from network); 1 Mar 2001 13:10:18 -0000 Received: from hisitech.com (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 13:10:18 -0000 Received: from hisitech.com (sgala@[83.161.120.155]) by hisitech.com (8.8.8) id GAA11326; Thu, 1 Mar 2001 06:14:57 -0700 (MST) Message-ID: <ccunningham@example.org> Date: Thu, 01 Mar 2001 14:11:09 +0100 From: Santiago Gala <ccunningham@example.org> Organization: High Sierra Technology, S.L. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8) Gecko/20010215 X-Accept-Language: en MIME-Version: 1.0 To: ccunningham@example.org Subject: Re: NLS in Jetspeed References: <004101c0a21c$b53a1340$83e5c53f@MANU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N David Sean Taylor wrote: > Hope this finds its way to the right list, and I hope everyone finds the new > list! > It did! Amazingly, it also arrived to the proper filtered box in my mail! >> Also, don't forget it is lang_COUNTRY, as in de, de_AT, de_CH, de_DE >> (jre even has a de_DE_EURO). >> >> I think the approach should be having >> >> default >> (files here) >> lang >> (files here maybe) >> COUNTRY >> (files here maybe) >> ... >> > > > This differs from the proposal. > See jetspeed/proposals/0005.txt > OK. I don't have any problems with the proposal. I was just pointing the fact that there are also geographical variations. color <--> colour, USD <--> UKP, quatre vingt <--> huitante (spell?) The _EURO stuff looks pathological to me, and transient in any case, (as my elder daughter reminds me, I have to carry her to the bank january next year, to change all her valuable pesetas into euros :-) > > Yes, when you say 'kind_of_resource' you mean: > - markup (psml) > - template > - skins ? > - ... > > So this profiling service will find any resource, not just psml markup. > +1 on that Yes, that is the idea. I'm seeing that we have very similar features for the three problems: - getting a resource dependent on user/request/session info - specialized resources with a given search order - fallback algorithm to a root. > > The JetspeedProfileManagerService is actually undergoing some changes, most > of the implementation will remain, but Raphael has refactored the profiler > into two services under the new customization package (see the > 'psml_02-branch' branch): > > 1. ConfigStoreService > 2. ProfileService > > I will look into factoring out the resource fallback algorithm into a > generic fallback service, and also consider directories to delineate NLS > resources If we go for a common "resource" solution, it will actually be simpler, as we would use the same pattern. I'm 0 on that. BTW, regarding the proposals, I'm lazy, and I would like the proposals to be visible from the web site. When I clean my working copy mess of the new server/permissions, etc. I think I will put them under xdocs/proposals (wrapped in <pre></pre> ). What do you think? From ccunningham@example.org Thu Mar 1 13:34:37 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 52509 invoked from network); 1 Mar 2001 13:34:37 -0000 Received: from fwns1d.raleigh.ibm.com (HELO fwns1.raleigh.ibm.com) (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 13:34:37 -0000 Received: from rtpmail03.raleigh.ibm.com ([83.161.120.155]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA23728 for <ccunningham@example.org>; Thu, 1 Mar 2001 08:34:07 -0500 Received: from shesmer (shesmer.boeblingen.de.ibm.com [83.161.120.155]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA35690 for <ccunningham@example.org>; Thu, 1 Mar 2001 08:16:18 -0500 Message-ID: <ccunningham@example.org> From: "Stephan Hesmer" <ccunningham@example.org> To: "Jetspeed Development" <ccunningham@example.org> References: <ccunningham@example.org> <ccunningham@example.org> Subject: Re: Synchronized and PortletConfig Date: Thu, 1 Mar 2001 14:15:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Santiago Gala wrote: > I agree in whole. This work is needed. We have been delaying this effort, due to the new > PortletAPI, but I think the changes go in the right direction. > > I tested having PortletSets cached in the session. This brought the problem that portlets > were not being correctly expired during the session, as expiration happens in getPortlet() > during creation of the PortletSet. > > I suggest taking out setPortletConfig() from the Portlet API and changing to init(config), > so that there is no reasonable way to spoil the config again. > > > We could do the following: > > - Maybe you could want to have commit rights, or will the changes be commited by Ingo? > - You post the changes' description for discussion, but I think the best communication > would be in the following points... > - take 24-48 hours for people to commit other "minor" changes in the main branch > (I will commit the JAXP/TRAX changes, don't think they interfere) > - open a branch for this work. > - apply your patches in this branch > - test a little bit > - have a IRC meeting to discuss about any pending problems or unforessen implications > (maybe we understand things in different ways, and this can lead to divergent work). > Also, if the main developers understand the changes,and the reasons, it is less > likely that incompatible changes that spoil the model appear later. > - test more :) (don't forget the jsp classes, that don't get compiled during ./build) > - merge the patches into the main branch > > > The reasons is that I have also some changes in related classes, and while I don't think I have problems, > maybe I have seen things that you forgot, or the other way round. I prefer having a branch, so that we > can take time to think if something breaks (conflicts) without being pressed by Sam Ruby's GUMP :) > I would suggest not to apply the changes in the current jetspeed, but that I implement the changes directly with the new Portlet API. I will implement the new API for Jetspeed ccunningham@example.org. Therefore, I ask you all to have commit rights, so that we have two committers ccunningham@example.org. I will mostly use it for the Portlet API (I think a new branch is the best) and Ingo will do all other stuff from IBM, so that the commits are consolidated. Look in my other mail for an explanation of the sync and PortletConfig. Stephan From ccunningham@example.org Thu Mar 1 14:24:47 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 5303 invoked from network); 1 Mar 2001 14:24:47 -0000 Received: from fwns2d.raleigh.ibm.com (HELO fwns2.raleigh.ibm.com) (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 14:24:47 -0000 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [83.161.120.155]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA20316 for <ccunningham@example.org>; Thu, 1 Mar 2001 09:24:17 -0500 Received: from shesmer (shesmer.boeblingen.de.ibm.com [83.161.120.155]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA25856 for <ccunningham@example.org>; Thu, 1 Mar 2001 09:24:17 -0500 Message-ID: <ccunningham@example.org> From: "Stephan Hesmer" <ccunningham@example.org> To: "Jetspeed Development" <ccunningham@example.org> Subject: Synchronized and PortletConfig (long) Date: Thu, 1 Mar 2001 15:23:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N The basic problem is that we store per-user variables in the PortletConfig. These are: * Dictionary layoutConstraints * int layoutPosition * Dictionary skin * PortletSet currentSet All variables need to be stored in a class that is created for every user. In our case it is created even in every request. What is going on in the current Jetspeed? ---------------------------------------------------- ( Legend: Every function that is synchronized is prefixed with <sync>. Every class that is a singleton per-user is prefixed with <singleton> ) ( Best viewed with a fixed width font) When a user accesses a page (for example the default home page), the PSML file is loaded into a Portlets tree. Next, a new PortletSet tree is created out of the Portlets tree. Now let us have a closer look at how this is going on: -> (1) PortletSetFactory.getPortletSet -> new PortletSet -> PortletSet.setController -> PortletSet.setPortletConfig -> PortletConfig is returned from PortletConfigFactory. Note: PortletConfigFactory in every function call creates a new PortletConfig object. PortletConfig should only exist once per portlet, but here it is misused to save per-user data. -> for each subtree in Portlets do -> <sync>PortletSet.addPortlet( child_PortletSet ) (2) child_PortletSet is created recursively with calling again (see 1) -> for each portlet in Portlets do -> <singleton>PortletFactory.getPortlet( portlet ) (3) (2) <sync>PortletSet.addPortlet( child ) -> add( child ) -> child.getPortletConfig -> <sync>PortletConfig.setPortletSet( this ) -> <sync>PortletConfig.setLayout -> <sync>PortletConfig.setPosition (3) <singleton>PortletFactory.getPortlet( portlet ) -> PortletConfigFactory.getPortletConfig( portlet ) Note: PortletConfigFactory creates in every function call a new PortletConfig object. PortletConfig should only exist once per portlet, but here it is misused to save per-user data. -> <sync>PortletSet.addPortlet( portlet ) (see 2) As you can see, the PortletConfig is created every time the factory is called. This leads to NO failure when the PortletConfig is stored in a PortletSet (see 2), because the PortletSet exists per-request (this means, that it is created anew for every request). When a PortletSet subtree is added to the parent PortletSet in (2), the PortletConfig is also initialized with the parent PortletSet, the layout and the position. This leads to no failure because first the PortletSet is created for every request and second the PortletConfig is created every time the factory is called. So, we don't have any failure here. But we would not need the synchronized in (2). But, when a portlet is added to the PortletSet tree in (3), the PortletConfig is assigned to the portlet that exists only once per system. Now imagine, that 3 request at the same time are processed. Then, the PortletConfig is created in every request, but assigned to the very same portlet. Note, the PortletConfig function in the portlet are synchronized (see 2). Here, it is only necessary as the data currently is stored in the wrong object with the wrong scope (singleton per portlet). However, it should be stored in an object with a per-user scope in which case we do not need the synchronized statement. Furthermore, other requests would not override others "skin" or "positions" anymore. Hope this summary is enough for you. Stephan From ccunningham@example.org Thu Mar 1 21:31:00 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 71147 invoked from network); 1 Mar 2001 21:31:00 -0000 Received: from bluesunrise.com (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 21:31:00 -0000 Received: from MANU [83.161.120.155] by bluesunrise.com [63.197.2239130] with SMTP (MDaemon.v3.0.0.R) for <ccunningham@example.org>; Thu, 01 Mar 2001 13:46:29 -0800 Reply-To: <ccunningham@example.org> From: "David Sean Taylor" <ccunningham@example.org> To: <ccunningham@example.org> Subject: RE: NLS in Jetspeed Date: Thu, 1 Mar 2001 13:31:39 -0800 Message-ID: <005701c0a297$0101caf0$83e5c53f@MANU> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <ccunningham@example.org> X-MDaemon-Deliver-To: ccunningham@example.org X-Return-Path: ccunningham@example.org X-MDRcpt-To: ccunningham@example.org X-MDRemoteIP: 83.161.120.155 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > OK. I don't have any problems with the proposal. I was just > pointing the fact that there are also geographical variations. > color <--> colour, USD <--> UKP, quatre vingt <--> huitante (spell?) > Yes, I believe the proposal covers that with examples like fr_FR, fr_BE (Ma femme est belge) quatre vingt dix <--> nonante :) > huitante (spell?) Is that fr_CH? Shouldn't that be 'octante'? > > I will look into factoring out the resource fallback algorithm into a > > generic fallback service, and also consider directories to delineate NLS > > resources > > If we go for a common "resource" solution, it will actually be > simpler, as we would use > the same pattern. I'm 0 on that. > The downside is more subdirectories, which is a pain for site maintenance. Let me revise the proposal considering a common resource-fallback service. > > BTW, regarding the proposals, I'm lazy, and I would like the proposals > to be visible from the web site. > > When I clean my working copy mess of the new server/permissions, etc. I > think I will put them under xdocs/proposals (wrapped in <pre></pre> ). > What do you think? > Im +1 on the relevant proposals, and -1 on any outdated proposals. - david > -----Original Message----- > From: Santiago Gala [mailto:ccunningham@example.org] > Sent: Thursday, March 01, 2001 5:11 AM > To: ccunningham@example.org > Subject: Re: NLS in Jetspeed > > > David Sean Taylor wrote: > > > Hope this finds its way to the right list, and I hope > everyone finds the new > > list! > > > > It did! Amazingly, it also arrived to the proper filtered box > in my mail! > > >> Also, don't forget it is lang_COUNTRY, as in de, de_AT, > de_CH, de_DE > >> (jre even has a de_DE_EURO). > >> > >> I think the approach should be having > >> > >> default > >> (files here) > >> lang > >> (files here maybe) > >> COUNTRY > >> (files here maybe) > >> ... > >> > > > > > > This differs from the proposal. > > See jetspeed/proposals/0005.txt > > > > OK. I don't have any problems with the proposal. I was just > pointing the fact that there are also geographical variations. > color <--> colour, USD <--> UKP, quatre vingt <--> huitante (spell?) > > The _EURO stuff looks pathological to me, and transient in any case, > (as my elder daughter reminds me, I have to carry her to the > bank january > next year, to change all her valuable pesetas into euros :-) > > > > > Yes, when you say 'kind_of_resource' you mean: > > - markup (psml) > > - template > > - skins ? > > - ... > > > > So this profiling service will find any resource, not just > psml markup. > > +1 on that > > Yes, that is the idea. I'm seeing that we have very similar features > for the three problems: > - getting a resource dependent on user/request/session info > - specialized resources with a given search order > - fallback algorithm to a root. > > > > > The JetspeedProfileManagerService is actually undergoing > some changes, most > > of the implementation will remain, but Raphael has > refactored the profiler > > into two services under the new customization package (see the > > 'psml_02-branch' branch): > > > > 1. ConfigStoreService > > 2. ProfileService > > > > I will look into factoring out the resource fallback > algorithm into a > > generic fallback service, and also consider directories to > delineate NLS > > resources > > If we go for a common "resource" solution, it will actually > be simpler, as we would use > the same pattern. I'm 0 on that. > > > BTW, regarding the proposals, I'm lazy, and I would like the > proposals > to be visible from the web site. > > When I clean my working copy mess of the new > server/permissions, etc. I > think I will put them under xdocs/proposals (wrapped in <pre></pre> ). > What do you think? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ccunningham@example.org > For additional commands, e-mail: ccunningham@example.org > > From ccunningham@example.org Thu Mar 1 21:38:33 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 81658 invoked from network); 1 Mar 2001 21:38:33 -0000 Received: from bluesunrise.com (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 21:38:33 -0000 Received: from MANU [83.161.120.155] by bluesunrise.com [63.197.2239130] with SMTP (MDaemon.v3.0.0.R) for <ccunningham@example.org>; Thu, 01 Mar 2001 13:54:05 -0800 Reply-To: <ccunningham@example.org> From: "David Sean Taylor" <ccunningham@example.org> To: <ccunningham@example.org> Subject: RE: Synchronized and PortletConfig Date: Thu, 1 Mar 2001 13:39:13 -0800 Message-ID: <005801c0a298$11243c50$83e5c53f@MANU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <ccunningham@example.org> X-MDaemon-Deliver-To: ccunningham@example.org X-Return-Path: ccunningham@example.org X-MDRcpt-To: ccunningham@example.org X-MDRemoteIP: 83.161.120.155 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > I would suggest not to apply the changes in the current > jetspeed, but that I > implement the changes directly with the new Portlet API. I > will implement > the new API for Jetspeed ccunningham@example.org. > > Therefore, I ask you all to have commit rights, so that we have two > committers ccunningham@example.org. I will mostly use it for the Portlet > API (I think a > new branch is the best) and Ingo will do all other stuff from > IBM, so that > the commits are consolidated. > +1 for Stephan I think this work should be done in a branch and committed frequently so we test it and so others can also commit to the branch Do you plan on implementing the entire API yourself? From ccunningham@example.org Thu Mar 1 22:00:20 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 23470 invoked from network); 1 Mar 2001 22:00:20 -0000 Received: from bluesunrise.com (83.161.120.155) by h31.sny.collab.net with SMTP; 1 Mar 2001 22:00:20 -0000 Received: from MANU [83.161.120.155] by bluesunrise.com [63.197.2239130] with SMTP (MDaemon.v3.0.0.R) for <ccunningham@example.org>; Thu, 01 Mar 2001 14:15:15 -0800 Reply-To: <ccunningham@example.org> From: "David Sean Taylor" <ccunningham@example.org> To: <ccunningham@example.org> Subject: RE: Synchronized and PortletConfig (long) Date: Thu, 1 Mar 2001 14:00:26 -0800 Message-ID: <005901c0a29b$05f81970$83e5c53f@MANU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <ccunningham@example.org> X-MDaemon-Deliver-To: ccunningham@example.org X-Return-Path: ccunningham@example.org X-MDRcpt-To: ccunningham@example.org X-MDRemoteIP: 83.161.120.155 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N This problem you described was very confusing for me as a new Jetspeed user, as Im sure others have experienced. Its about time that it is fixed, and I believe this is the right time with the new Portlet API. Concerning performance, the current code, as you have pointed out, creates a lot of new instances with each request. Do you plan to cache and re-use portlet sets on a per user or session basis? Also, currently, having the same portlet ref'd twice on the same psml page is a problem. If its not too much trouble, I'd like to briefly understand your new implementation. How much of this will you rewrite? - david > -----Original Message----- > From: Stephan Hesmer [mailto:ccunningham@example.org] > Sent: Thursday, March 01, 2001 6:24 AM > To: Jetspeed Development > Subject: Synchronized and PortletConfig (long) > > > The basic problem is that we store per-user variables in the > PortletConfig. > These are: > * Dictionary layoutConstraints > * int layoutPosition > * Dictionary skin > * PortletSet currentSet > > All variables need to be stored in a class that is created > for every user. > In our case it is created even in every request. > > What is going on in the current Jetspeed? > ---------------------------------------------------- > ( Legend: Every function that is synchronized is prefixed > with <sync>. Every > class that is a singleton per-user is prefixed with <singleton> ) > ( Best viewed with a fixed width font) > > When a user accesses a page (for example the default home > page), the PSML > file is loaded into a Portlets tree. Next, a new PortletSet > tree is created > out of the Portlets tree. Now let us have a closer look at > how this is going > on: > -> (1) PortletSetFactory.getPortletSet > -> new PortletSet > -> PortletSet.setController > -> PortletSet.setPortletConfig > -> PortletConfig is returned from PortletConfigFactory. > Note: PortletConfigFactory in every function call creates a new > PortletConfig object. PortletConfig should only exist once > per portlet, but here it is misused to save per-user data. > -> for each subtree in Portlets do > -> <sync>PortletSet.addPortlet( child_PortletSet ) (2) > child_PortletSet is created recursively with calling > again (see 1) > -> for each portlet in Portlets do > -> <singleton>PortletFactory.getPortlet( portlet ) (3) > > > (2) <sync>PortletSet.addPortlet( child ) > -> add( child ) > -> child.getPortletConfig > -> <sync>PortletConfig.setPortletSet( this ) > -> <sync>PortletConfig.setLayout > -> <sync>PortletConfig.setPosition > > > (3) <singleton>PortletFactory.getPortlet( portlet ) > -> PortletConfigFactory.getPortletConfig( portlet ) > Note: PortletConfigFactory creates in every function call a new > PortletConfig object. PortletConfig should only exist once > per portlet, but here it is misused to save per-user data. > -> <sync>PortletSet.addPortlet( portlet ) (see 2) > > > As you can see, the PortletConfig is created every time the factory is > called. This leads to NO failure when the PortletConfig is stored in a > PortletSet (see 2), because the PortletSet exists per-request > (this means, > that it is created anew for every request). > When a PortletSet subtree is added to the parent PortletSet > in (2), the > PortletConfig is also initialized with the parent PortletSet, > the layout and > the position. This leads to no failure because first the PortletSet is > created for every request and second the PortletConfig is > created every time > the factory is called. So, we don't have any failure here. > But we would not > need the synchronized in (2). > But, when a portlet is added to the PortletSet tree in (3), the > PortletConfig is assigned to the portlet that exists only > once per system. > Now imagine, that 3 request at the same time are processed. Then, the > PortletConfig is created in every request, but assigned to > the very same > portlet. Note, the PortletConfig function in the portlet are > synchronized > (see 2). Here, it is only necessary as the data currently is > stored in the > wrong object with the wrong scope (singleton per portlet). However, it > should be stored in an object with a per-user scope in which > case we do not > need the synchronized statement. Furthermore, other requests would not > override others "skin" or "positions" anymore. > > Hope this summary is enough for you. > > Stephan > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ccunningham@example.org > For additional commands, e-mail: ccunningham@example.org > > From ccunningham@example.org Fri Mar 2 00:47:55 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 86758 invoked from network); 2 Mar 2001 00:47:55 -0000 Received: from hisitech.com (83.161.120.155) by h31.sny.collab.net with SMTP; 2 Mar 2001 00:47:55 -0000 Received: from hisitech.com (sgala@[83.161.120.155]) by hisitech.com (8.8.8) id RAA56972; Thu, 1 Mar 2001 17:52:41 -0700 (MST) Message-ID: <ccunningham@example.org> Date: Fri, 02 Mar 2001 01:48:46 +0100 From: Santiago Gala <ccunningham@example.org> Organization: High Sierra Technology, S.L. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8) Gecko/20010215 X-Accept-Language: en MIME-Version: 1.0 To: ccunningham@example.org Subject: Re: Synchronized and PortletConfig References: <005801c0a298$11243c50$83e5c53f@MANU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N David Sean Taylor wrote: >> I would suggest not to apply the changes in the current >> jetspeed, but that I >> implement the changes directly with the new Portlet API. I >> will implement >> the new API for Jetspeed ccunningham@example.org. >> >> Therefore, I ask you all to have commit rights, so that we have two >> committers ccunningham@example.org. I will mostly use it for the Portlet >> API (I think a >> new branch is the best) and Ingo will do all other stuff from >> IBM, so that >> the commits are consolidated. >> > > > +1 for Stephan > I think this work should be done in a branch and committed frequently so we > test it and so others can also commit to the branch > Do you plan on implementing the entire API yourself? > +1, obviously. Sorry for the delay. From ccunningham@example.org Fri Mar 2 18:21:42 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 67029 invoked from network); 2 Mar 2001 18:21:42 -0000 Received: from hisitech.com (83.161.120.155) by h31.sny.collab.net with SMTP; 2 Mar 2001 18:21:42 -0000 Received: from hisitech.com (sgala@[83.161.120.155]) by hisitech.com (8.8.8) id LAA07540; Fri, 2 Mar 2001 11:26:40 -0700 (MST) Message-ID: <ccunningham@example.org> Date: Fri, 02 Mar 2001 19:22:35 +0100 From: Santiago Gala <ccunningham@example.org> Organization: High Sierra Technology, S.L. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8) Gecko/20010215 X-Accept-Language: en MIME-Version: 1.0 To: ccunningham@example.org Subject: Re: Synchronized and PortletConfig References: <ccunningham@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Raphaël Luta wrote: > The current portlet architecture will be kept for backward compability > for will should be phased out in favor of the new portlet container system. > Does it mean that you think we should go on with these patches? I'm +1, just to play with the issues and be more prepared to spot any remaining problem in the new implementation you're working on. > The new implementation is still very much in flux but you can see the > work done > about it in the 'psml_02-branch' branch or by monitoring the CVS commits... > > I will take a look ASAP (in a separate working copy). I just noticed it when you said (I should be subscribed to the jserv-dev list...) (Resent. I sent it to the wrong list) From ccunningham@example.org Fri Mar 2 18:22:10 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 67620 invoked from network); 2 Mar 2001 18:22:10 -0000 Received: from hisitech.com (83.161.120.155) by h31.sny.collab.net with SMTP; 2 Mar 2001 18:22:10 -0000 Received: from hisitech.com (sgala@[83.161.120.155]) by hisitech.com (8.8.8) id LAA07607; Fri, 2 Mar 2001 11:27:08 -0700 (MST) Message-ID: <ccunningham@example.org> Date: Fri, 02 Mar 2001 19:23:04 +0100 From: Santiago Gala <ccunningham@example.org> Organization: High Sierra Technology, S.L. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8) Gecko/20010215 X-Accept-Language: en MIME-Version: 1.0 To: jetspeed-dev <ccunningham@example.org> Subject: Re: [VOTE] Portlet API, Results of the Chat References: <ccunningham@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N ingo schuster wrote: > Hi, > > I posted the log of the PortletAPI chat some days ago. As there where no > responses, I assume that nothing is left to discuss with regard to the > issues we talked about in this chat. As we (at IBM) a very keen to start > implementing the new API, I'd like to vote about the point that we seem > to agree upon. We will of course have to vote on more details, however > as soon as the core design decisions are clear, we can at least start > with the implementation. > > So I ask you to vote about following points: > Sorry for the delay. > Point 1 (output model): > The API will have streams in the base response API, SAX support in a > sub-interface; compliant portals must implement both interfaces. +1. All I care about is that somebody is able to build a portlet engine that can take care of SAX event stream so that it does not need reparsing until the final "serialization/rendering". > > Point 2 (content model): > Fragments are the prefered output model for portlets but the portal must > implement full documents support as the default. > The content model used by a portlet is defined in its portlet descriptor. +1, I understand the issues brought by Raphaël. For completeness, we should stick to this model, so that we can survive new formats/markups without having to rush defining fragments model for each one. (...) > > 1. Should PortletRequest/PortletResponse have methods to access > ServletRequest/ServletResponse? I would ask it as: should PortletRequest/PortletResponse IMPLEMENT ServletRequest/ServletResponse? I think we should not give the "true" objects to the portlet, just a facade. > 2. Should the session object be passed as separate object of the > Portlet.service() method? -0. I think we should either go with a service(request, response) model ---> Portlet implements servlet, PortletRequest implements ServletRequest so that a servlet can be used as a portlet by the container, or a getContent(data) model ---> RunData encapsulates all objects > 3. Should attributes in PortletRequest and PortletSession be prefixed by > the portlet container to separate portlet namespaces? +1. A portlet should only view its own attributes. A portlet should not know anything about the surrounding portlets. > 4. Should we stick with the attribute getters/setters from the Servlet > API or use the DynamicData object consistently across the relevant > objects (request, session, configuration, user, page)? This goes up to my comment to (2). I think the crucial item is deciding if we go for a overloaded (and with further semantics) "standard" servlet call, or if we have a request model similar to the one in Turbine. Once we have this top level idea clear, we can proceed. Mixing both in the model will be a mess. I don't have a clear position on this one. Having the first model allows for straight integration of existing servlets (at the cost of more processing, cause they would deliver full documents). Having the second model means a new API to define (based on the one in Turbine), and maybe a cleaner interface. > 5. Do we want to stick with a pre-defined set of capabilities. > Preferably not, but if the names of capabilities are standardized, how > is the portlet going to find out whether a particular capability is > present? We can have a mechanism similar to the one in TRAX: the portlet can ask for an Iterator on capability names. the portlet can ask for the value of a capability. the container can throw an exception if it ignores the capability name. This allows for futurer extensibililty. We define a minimum set of required and optional capabilities supported in the version 1.0 of the spec. > 6. What should be the interface of the user? I don't understand the question here. Which interface? who is the user? From ccunningham@example.org Fri Mar 2 18:55:44 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 6446 invoked from network); 2 Mar 2001 18:55:44 -0000 Received: from d12lmsgate.de.ibm.com (83.161.120.155) by h31.sny.collab.net with SMTP; 2 Mar 2001 18:55:44 -0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [83.161.120.155]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id TAA193876 for <ccunningham@example.org>; Fri, 2 Mar 2001 19:55:17 +0100 From: ccunningham@example.org Received: from d12mta09.de.ibm.com (d12mta10_cs0 [83.161.120.155]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id TAA105378 for <ccunningham@example.org>; Fri, 2 Mar 2001 19:53:54 +0100 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A03.0067EFF9 ; Fri, 2 Mar 2001 19:55:16 +0100 X-Lotus-FromDomain: IBMDE To: ccunningham@example.org Message-ID: <ccunningham@example.org> Date: Fri, 2 Mar 2001 19:55:11 +0100 Subject: Is the jetspeed-dev Mailing list already active ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N (Sorry for the test, I just wonder why I only get mail from the jetspeed-user list) Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: {{PHONE+SOCIAL_SECURITY_NUMBER}} Mobile: 902.663.4679 e-mail: ccunningham@example.org Fax: {{PHONE+SOCIAL_SECURITY_NUMBER}} Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany From ccunningham@example.org Sat Mar 3 08:40:03 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 43509 invoked from network); 3 Mar 2001 08:40:03 -0000 Received: from ldap.whichever.com (HELO takahe.whichever.com) (83.161.120.155) by h31.sny.collab.net with SMTP; 3 Mar 2001 08:40:03 -0000 Received: from [83.161.120.155] (jonmac.whichever.com [83.161.120.155]) by takahe.whichever.com (Postfix) with ESMTP id 7A90F3CA10; Sat, 3 Mar 2001 00:40:09 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 03 Mar 2001 00:40:07 -0800 Subject: You make the decision. From: Jon Stevens <ccunningham@example.org> Message-ID: <ccunningham@example.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit To: undisclosed-recipients:; X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N After a few weeks of working on this in my off hour not-so-spare time, I present, for your enjoyment and pleasure, an essay titled: You make the decision. <http://jakarta.apache.org/velocity/ymtd/ymtd.html> Love and Kisses, -jon From ccunningham@example.org Sat Mar 3 10:37:23 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 1324 invoked from network); 3 Mar 2001 10:37:23 -0000 Received: from d12lmsgate.de.ibm.com (83.161.120.155) by h31.sny.collab.net with SMTP; 3 Mar 2001 10:37:23 -0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [83.161.120.155]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA208650 for <ccunningham@example.org>; Sat, 3 Mar 2001 11:37:02 +0100 From: ccunningham@example.org Received: from d12mta09.de.ibm.com (d12mta10_cs0 [83.161.120.155]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id LAA53378 for <ccunningham@example.org>; Sat, 3 Mar 2001 11:35:38 +0100 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A04.003A4F80 ; Sat, 3 Mar 2001 11:36:54 +0100 X-Lotus-FromDomain: IBMDE To: ccunningham@example.org Message-ID: <ccunningham@example.org> Date: Sat, 3 Mar 2001 11:36:46 +0100 Subject: Re: [VOTE] Portlet API, Results of the Chat Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Some additional info on two of the questions. Santiago Gala wrote: > > 2. Should the session object be passed as separate object of the > > Portlet.service() method? > > -0. I think we should either go with a > service(request, response) model ---> Portlet implements servlet, > PortletRequest implements ServletRequest > so that a servlet can be used as a portlet by the container, or a > getContent(data) model ---> RunData encapsulates all objects The question should be: "Should the service method be similar to the Servlet API's, service method i.e. service(PortletRequest req, PortletResponse rsp) or should we deviate by providing the session as a third parameter ?". As one fundamental concept behind the new Portlet API to be as similar as possible to the Servlet API, the IBM position is of course that the service method definitively should *not* have the session as a third parameter, the session should be obtained from the request just similarly to the Servlet API. (By the way, this avoids problems when running on a cluster using sessions that are persisted to a database - creating the session object in this case would mean to get the serialized session object from the database, deserialize it and instantiate the session object. Obviously, it is advantageaous and simple to only do this when the portlet calls portletRequest.getSession(), i.e. when it is really needed rather than getting the PortletSession object from the HttpSession object in the session persistence database and passing it through the third parameter for each request. One might think it may be possible to use a lazy PortletSession object that only does the database object when e.g. it's getAttribute methods are invoked, but even to only determine whether a PortletSession object or a null pointer should be passed through the service method would require to access the persistent session DB, deserialize the HttpSession object, look into the HttpSession object whether there is a PortletSession object prefixed with the portlet's ID. From this perspective, it does not even seem feasible to explicitly provide the session as a third parameter of the service method.) > > 4. Should we stick with the attribute getters/setters from the > > Servlet API or use the DynamicData object consistently across the > > relevant objects (request, session, configuration, user, page)? > > This goes up to my comment to (2). I think the crucial item is > deciding if we go for a overloaded (and with further semantics) > "standard" servlet call, or if we have a request model similar to > the one in Turbine. Once we have this top level idea clear, we can > proceed. Mixing both in the model will be a mess. > > I don't have a clear position on this one. Having the first model > allows for straight integration of existing servlets (at the cost > of more processing, cause they would deliver full documents). Having > the second model means a new API to define (based on the one in Turbine), > and maybe a cleaner interface. You've exactly got a good point here. (As the guiding principle for the design of the Portlet API was to be very close to the Servlet API, the IBM position is to stick with the getters/setters.) > > > 5. Do we want to stick with a pre-defined set of capabilities. > > Preferably not, but if the names of capabilities are standardized, > > how is the portlet going to find out whether a particular capability > > is present? > > We can have a mechanism similar to the one in TRAX: > the portlet can ask for an Iterator on capability names. > the portlet can ask for the value of a capability. > the container can throw an exception if it ignores the capability name. > > This allows for futurer extensibililty. We define a minimum set of > required and optional capabilities supported in the version 1.0 of > the spec. > > > 6. What should be the interface of the user? > > I don't understand the question here. Which interface? who is the user? > Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: {{PHONE+SOCIAL_SECURITY_NUMBER}} e-mail: ccunningham@example.org Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany From ccunningham@example.org Tue Mar 6 20:56:17 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 52551 invoked from network); 6 Mar 2001 20:56:17 -0000 Received: from ldap.whichever.com (HELO takahe.whichever.com) (83.161.120.155) by h31.sny.collab.net with SMTP; 6 Mar 2001 20:56:17 -0000 Received: from [83.161.120.155] (gate.sp.collab.net [83.161.120.155]) by takahe.whichever.com (Postfix) with ESMTP id 2BD013E03B; Tue, 6 Mar 2001 12:56:17 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 06 Mar 2001 12:56:04 -0800 Subject: License Update From: Jon Stevens <ccunningham@example.org> To: jetspeed-dev <ccunningham@example.org> Cc: <ccunningham@example.org> Message-ID: <ccunningham@example.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Could someone please immediately update the license on all of the Jetspeed source code and website documentation to be this one below (the reason is that I'm getting questions about the older one that don't apply in the newer one). The only changes that I made are in clauses 4 and 5 to add "Apache Jetspeed". thanks, -jon /* ==================================================================== * The Apache Software License, Version 1.1 * * Copyright (c) 2000-2001 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. The end-user documentation included with the redistribution, * if any, must include the following acknowledgment: * "This product includes software developed by the * Apache Software Foundation (http://www.apache.org/)." * Alternately, this acknowledgment may appear in the software itself, * if and wherever such third-party acknowledgments normally appear. * * 4. The names "Apache" and "Apache Software Foundation" and * "Apache Jetspeed" must not be used to endorse or promote products * derived from this software without prior written permission. For * written permission, please contact ccunningham@example.org. * * 5. Products derived from this software may not be called "Apache" or * "Apache Jetspeed", nor may "Apache" appear in their name, without * prior written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * ==================================================================== * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * <http://www.apache.org/>. */ From ccunningham@example.org Tue Mar 6 21:01:01 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 60803 invoked from network); 6 Mar 2001 21:01:01 -0000 Received: from hisitech.com (83.161.120.155) by h31.sny.collab.net with SMTP; 6 Mar 2001 21:01:01 -0000 Received: from hisitech.com ({{EMAIL+PHONE}} [83.161.120.155]) by hisitech.com (8.8.8) id OAA49588; Tue, 6 Mar 2001 14:06:51 -0700 (MST) Message-ID: <ccunningham@example.org> Date: Tue, 06 Mar 2001 22:01:49 +0100 From: Santiago Gala <ccunningham@example.org> Organization: High Sierra Technology, S.L. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdksmp i686; en-US; 0.8) Gecko/20010215 X-Accept-Language: en MIME-Version: 1.0 To: ccunningham@example.org Subject: Re: License Update References: <ccunningham@example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Jon Stevens wrote: > Could someone please immediately update the license on all of the Jetspeed > source code and website documentation to be this one below (the reason is > that I'm getting questions about the older one that don't apply in the newer > one). > > The only changes that I made are in clauses 4 and 5 to add "Apache > Jetspeed". > Could it be done by adding the license file in the top level of the distribution and having a smaller comment pointing to the license file? This kind of refactoring is simpler, and it will allow for simpler updates in the future. From ccunningham@example.org Tue Mar 6 21:26:37 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 99304 invoked from network); 6 Mar 2001 21:26:37 -0000 Received: from ldap.whichever.com (HELO takahe.whichever.com) (83.161.120.155) by h31.sny.collab.net with SMTP; 6 Mar 2001 21:26:37 -0000 Received: from [83.161.120.155] (gate.sp.collab.net [83.161.120.155]) by takahe.whichever.com (Postfix) with ESMTP id 667B93E082 for <ccunningham@example.org>; Tue, 6 Mar 2001 13:26:35 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 06 Mar 2001 13:26:13 -0800 Subject: Re: License Update From: Jon Stevens <ccunningham@example.org> To: <ccunningham@example.org> Message-ID: <ccunningham@example.org> In-Reply-To: <ccunningham@example.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N on 3/6/01 1:01 PM, "Santiago Gala" <ccunningham@example.org> wrote: > Could it be done by adding the license file in the top level of the > distribution > and having a smaller comment pointing to the license file? > > > This kind of refactoring is simpler, and it will allow for simpler updates in > the future. At this time, the answer is no. Legality != simplicity. thanks -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous <http://jakarta.apache.org/velocity/ymtd/ymtd.html> From ccunningham@example.org Tue Mar 6 21:35:27 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 11441 invoked from network); 6 Mar 2001 21:35:27 -0000 Received: from hisitech.com (83.161.120.155) by h31.sny.collab.net with SMTP; 6 Mar 2001 21:35:27 -0000 Received: from hisitech.com ({{EMAIL+PHONE}} [83.161.120.155]) by hisitech.com (8.8.8) id OAA52186; Tue, 6 Mar 2001 14:41:20 -0700 (MST) Message-ID: <ccunningham@example.org> Date: Tue, 06 Mar 2001 22:36:23 +0100 From: Santiago Gala <ccunningham@example.org> Organization: High Sierra Technology, S.L. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdksmp i686; en-US; 0.8) Gecko/20010215 X-Accept-Language: en MIME-Version: 1.0 To: ccunningham@example.org Subject: Re: License Update References: <ccunningham@example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Jon Stevens wrote: > on 3/6/01 1:01 PM, "Santiago Gala" <ccunningham@example.org> wrote: > > >> Could it be done by adding the license file in the top level of the >> distribution >> and having a smaller comment pointing to the license file? >> >> >> This kind of refactoring is simpler, and it will allow for simpler updates in >> the future. > > > At this time, the answer is no. > > Legality != simplicity. > > thanks > > -jon Then, my problem is that I have plenty of changes, that I must commit carefully to avoid running into problems WRT xalan version or turbine version. I will try to put the changed license in all the files that I commit. But I think this effort should be done over a clean copy. From ccunningham@example.org Tue Mar 6 23:00:14 2001 Return-Path: <ccunningham@example.org> Mailing-List: contact ccunningham@example.org; run by ezmlm Delivered-To: mailing list ccunningham@example.org Received: (qmail 27402 invoked from network); 6 Mar 2001 23:00:14 -0000 Received: from ldap.whichever.com (HELO takahe.whichever.com) (83.161.120.155) by h31.sny.collab.net with SMTP; 6 Mar 2001 23:00:14 -0000 Received: from [83.161.120.155] (gate.sp.collab.net [83.161.120.155]) by takahe.whichever.com (Postfix) with ESMTP id 5C9293E108
{'source': 'Apache Software Foundation Public Mail Archives'}