Re:esup-portal-ws Project

[Pascal Aubry-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

uPortal developers,
Though esup-portal-ws (see http://www.ja-sig.org/wiki/x/sQGF) is a quick-and-dirty implementation, it is now used by all the French community (embedded into the French uportal-esup distribution) and I also had feedback from some American universities, Belgium and Canada. Chris Doyle recently did some job on the project (see below) and I feel it would be nice if this project was hosted by jasig (it is currently hosted by the French CRU, see http://www.cru.fr/en) as a contribution. Moving to the jasig svn repository and putting the issues into the kasgi jira would ease the maintenance (by Chris and I) and give it a better visibility as well.
You opinion?
Best,
PA

Chris Doyle a écrit :

Pascal,

 

I am definitely available to help transition this project over to the JA-SIG infrastructure, pending the okay from the community as Jonathan mentioned.  In the meantime, might you be able to grant me svnadmin access to the esup-portal-ws project in the subversion.cru.fr repository?  I'd like to capture a complete SVN dump of the project for import into the JA-SIG repository as a starting point.

 

Thanks,

 

--Chris

 

 

From: Jonathan Markow [jjmarkow@...]
Sent: Monday, July 07, 2008 9:27 PM
To: Pascal Aubry
Cc: Chris Doyle; fabrice.jammes@...; Raymond.Bourges@...
Subject: Re: esup-portal-ws Project

 

Hi Pascal-

It sounds very desirable to me for JA-SIG to host the project--and Chris's improvements.  Why don't you begin by making a proposal to uportal-dev?

Thanks very much,
Jonathan

On Mon, Jul 7, 2008 at 7:08 PM, Pascal Aubry <pascal.aubry@...> wrote:

Hi Chris,
To tell the truth, I am not very proud of this code, written in a few hours... Anyway it is used in production by all our French partners (it is now part of the uPortal-esup distribution) and I also received feedback from Canada, Belgium and a few American universities.
Nice to see esup-portal-ws is useful also to you, and of course your work is worth being shared!
As the project is used quite widely now, I think it is time to rename it uportal-ws and move it to jasig in order to give it a better visibility. Currently, the docs are already hosted by the jasig wiki (http://www.ja-sig.org/wiki/x/sQGF), the source code and the downloads are still hosted by the French CRU (http://www.cru.fr/en).
Jonathan, what do you think about it? Who should I ask?
Chris, would you be ok to do the job (move the project to the jasig repository)? Are you a jasig committer already?
Thanks,
PA

Chris Doyle a écrit :

Greetings,

 
We are currently using the esup-portal-ws project in our uPortal 2.6.1+ instance here at Johns Hopkins.  We are amidst a major uPortal upgrade to version 3.0.0, and during the process I was able to fully mavenize the esup-portal-ws project from the most recent checkout from your SVN trunk (Revision 26).  I would very much like to contribute this work back to you, and ultimately to share it with the JA-SIG and ESUP-Portail communities at-large with your blessings.  I also ended up having to apply a patch to the axistools-maven-plugin mojo in order it to build properly, but I can send over that work as well.

 
Are you interested, and if so how should I ship you my code?

 
Many thanks!

 
--Chris

 
--

[ c h r i s d o y l e ]

Johns Hopkins University

Sr. System Software Engineer, IT@JH

410.735.4127

cdoyle@...

 
"Eleven. Exactly. One louder."

 

--
http://perso.univ-rennes1.fr/pascal.aubry

 

-- 

You are currently subscribed to uportal-dev@... as: lists@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[Drew Wills]

+1 for this move.

Pascal Aubry wrote:

> uPortal developers,
> Though esup-portal-ws (see http://www.ja-sig.org/wiki/x/sQGF) is a
> quick-and-dirty implementation, it is now used by all the French
> community (embedded into the French uportal-esup distribution) and I
> also had feedback from some American universities, Belgium and Canada.
> Chris Doyle recently did some job on the project (see below) and I feel
> it would be nice if this project was hosted by jasig (it is currently
> hosted by the French CRU, see http://www.cru.fr/en) as a contribution.
> Moving to the jasig svn repository and putting the issues into the kasgi
> jira would ease the maintenance (by Chris and I) and give it a better
> visibility as well.
> You opinion?
> Best,
> PA
>
> Chris Doyle a écrit :
>>
>> Pascal,
>>
>>  
>>
>> I am definitely available to help transition this project over to the
>> JA-SIG infrastructure, pending the okay from the community as Jonathan
>> mentioned.  In the meantime, might you be able to grant me svnadmin
>> access to the esup-portal-ws project in the subversion.cru.fr
>> repository?  I'd like to capture a complete SVN dump of the project
>> for import into the JA-SIG repository as a starting point.
>>
>>  
>>
>> Thanks,
>>
>>  
>>
>> --Chris
>>
>>  
>>
>>  
>>
>> *From:* Jonathan Markow [mailto:jjmarkow@...]
>> *Sent:* Monday, July 07, 2008 9:27 PM
>> *To:* Pascal Aubry
>> *Cc:* Chris Doyle; fabrice.jammes@...;
>> Raymond.Bourges@...
>> *Subject:* Re: esup-portal-ws Project
>>
>>  
>>
>> Hi Pascal-
>>
>> It sounds very desirable to me for JA-SIG to host the project--and
>> Chris's improvements.  Why don't you begin by making a proposal to
>> uportal-dev?
>>
>> Thanks very much,
>> Jonathan
>>
>> On Mon, Jul 7, 2008 at 7:08 PM, Pascal Aubry
>> <pascal.aubry@... <mailto:pascal.aubry@...>>
>> wrote:
>>
>> Hi Chris,
>> To tell the truth, I am not very proud of this code, written in a few
>> hours... Anyway it is used in production by all our French partners
>> (it is now part of the uPortal-esup distribution) and I also received
>> feedback from Canada, Belgium and a few American universities.
>> Nice to see esup-portal-ws is useful also to you, and of course your
>> work is worth being shared!
>> As the project is used quite widely now, I think it is time to rename
>> it uportal-ws and move it to jasig in order to give it a better
>> visibility. Currently, the docs are already hosted by the jasig wiki
>> (http://www.ja-sig.org/wiki/x/sQGF), the source code and the downloads
>> are still hosted by the French CRU (http://www.cru.fr/en).
>> Jonathan, what do you think about it? Who should I ask?
>> Chris, would you be ok to do the job (move the project to the jasig
>> repository)? Are you a jasig committer already?
>> Thanks,
>> PA
>>
>> Chris Doyle a écrit :
>>
>>
>> Greetings,
>>
>>  
>> We are currently using the esup-portal-ws project in our uPortal
>> 2.6.1+ instance here at Johns Hopkins.  We are amidst a major uPortal
>> upgrade to version 3.0.0, and during the process I was able to fully
>> mavenize the esup-portal-ws project from the most recent checkout from
>> your SVN trunk (Revision 26).  I would very much like to contribute
>> this work back to you, and ultimately to share it with the JA-SIG and
>> ESUP-Portail communities at-large with your blessings.  I also ended
>> up having to apply a patch to the axistools-maven-plugin mojo in order
>> it to build properly, but I can send over that work as well.
>>
>>  
>> Are you interested, and if so how should I ship you my code?
>>
>>  
>> Many thanks!
>>
>>  
>> --Chris
>>
>>  
>> --
>>
>> [ c h r i s d o y l e ]
>>
>> Johns Hopkins University
>>
>> Sr. System Software Engineer, IT@JH
>>
>> 410.735.4127
>>
>> cdoyle@... <mailto:cdoyle@...>
>>
>>  
>> "Eleven. Exactly. One louder."
>>
>>  
>>
>>
>>
>> --
>> http://perso.univ-rennes1.fr/pascal.aubry
>>
>>  
>>
>
>
> --
> http://perso.univ-rennes1.fr/pascal.aubry
>
>
> --
>
> You are currently subscribed to uportal-dev@... as: awills@...
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>

--
You are currently subscribed to uportal-dev@... as: lists@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[Drew Wills]

Hey folks,

I'm working at JHU, and we've put together an enhancement to DLM:  the
ability to store users' layouts in a standard, portal managed cache.
Currently users' layouts are stored (at least in DLM) as a member
variable on each user's LayoutManager instance.

This situation means that:
   - User layouts never change until (1) the user makes a manual change,
or (2) the user logs in again
   - There's no way to manage in-memory layout data administratively

With this enhancement, you'd be able to:
   - specify that user layouts should expire and be rebuilt, say, 15 min
after creation or after 10 min of "idle" time (i.e. not used for 10 min)
   - specify that no more than, say, 500 layouts should be held in
memory at one time
   - use JMX to "clear" (drop) all the layouts in a running instance of
uPortal
   - write Java tools that intelligently invalidate individual layouts
(or all layouts) when certain portal events happen

The changes are relatively small & encapsulated, so they're unlikely to
"break" existing features or even custom Java tech that integrates with DLM.

I'm attaching a .patch that shows the delta.

Please share thoughts on whether this enhancement is desirable or even
acceptable.  If there's interest, I'll create the JIRA etc.

drew wills



--
You are currently subscribed to uportal-dev@... as: lists@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Index: uportal-impl/src/main/java/org/jasig/portal/layout/dlm/DistributedLayoutManager.java
===================================================================
--- uportal-impl/src/main/java/org/jasig/portal/layout/dlm/DistributedLayoutManager.java (revision 6156)
+++ uportal-impl/src/main/java/org/jasig/portal/layout/dlm/DistributedLayoutManager.java (working copy)
@@ -90,7 +90,7 @@
      */
     static final String FOLDER_LABEL_POLICY = "FolderLabelPolicy";
     
-    protected Document userLayoutDocument=null;
+    private final Map<String,Document> layoutCache = LayoutCachingService.getInstance().getLayoutCache();
     
     protected static Random rnd=new Random();
     protected String cacheKey="initialKey";
@@ -226,7 +226,8 @@
     }
 
     private void setUserLayoutDOM(Document doc) {
-        this.userLayoutDocument = doc;
+
+     layoutCache.put(owner.getUserName(), doc);
         this.updateCacheKey();
 
         // determine if this is a layout fragment by looking at the root node
@@ -243,6 +244,7 @@
         if (labelPolicy != null) {
             labelPolicy.coordinateFolderLabels(owner.getID(), isFragmentOwner, doc);
         }
+        
     }
     private int domRequests = 0;
 
@@ -261,7 +263,7 @@
             {
                 LOG.debug("domRequest: " + (domRequests++));
             }
-            Document userLayoutDocument = this.userLayoutDocument;
+            Document userLayoutDocument = layoutCache.get(owner.getUserName());
             if ( null == userLayoutDocument )
             {
                 IUserLayoutStore layoutStore = getLayoutStore();
@@ -407,7 +409,7 @@
         try {
             //Clear the loaded document first if this is a forced reload
             if (reload) {
-                this.userLayoutDocument = null;
+             layoutCache.remove(owner.getUserName());
             }
             
             uli=getUserLayoutDOM();
@@ -1507,7 +1509,7 @@
         }
         //this.markedUserLayout=null;
         this.updateCacheKey();
-        this.userLayoutDocument=doc;
+        layoutCache.put(owner.getUserName(), doc);
     }
 
     /* Returns the ID attribute of the root folder of the layout. This folder
@@ -1689,7 +1691,7 @@
             // so we need to refresh our local copy of their layout
             if (person == owner)
             {
-                this.userLayoutDocument = null;
+             layoutCache.remove(owner.getUserName());
                 updateCacheKey();
                 getUserLayoutDOM();
             }
Index: uportal-impl/src/main/java/org/jasig/portal/layout/dlm/LayoutCachingService.java
===================================================================
--- uportal-impl/src/main/java/org/jasig/portal/layout/dlm/LayoutCachingService.java (revision 0)
+++ uportal-impl/src/main/java/org/jasig/portal/layout/dlm/LayoutCachingService.java (revision 0)
@@ -0,0 +1,120 @@
+/**
+ * Copyright 2008 The JA-SIG Collaborative.  All rights reserved.
+ * See license distributed with this file and
+ * available online at http://www.uportal.org/license.html
+ */
+
+package org.jasig.portal.layout.dlm;
+
+import java.util.Map;
+import org.w3c.dom.Document;
+
+import org.springframework.beans.factory.annotation.Required;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.jasig.portal.utils.cache.CacheFactory;
+
+/**
+ * Provides caching services for layouts contained in
+ * <code>DistributedLayoutManager</code> instances.  This class is an old-school
+ * singleton whose backing-map is "injected" by a spring context at startup.
+ */
+public final class LayoutCachingService {
+
+ /**
+ * The name of the cache used by <code>LayoutCachingService</code>.  A cache
+ * of this name must be defined within uPortal's <code>'cacheFactory'</code>
+ * bean.
+ */
+ private static final String CACHE_NAME = "org.jasig.portal.layout.dlm.LAYOUT_CACHE";
+
+ /**
+ * Single(ton) instance of this class.
+ */
+ private static LayoutCachingService instance = null;
+
+ /**
+ * "Injected" at startup by the bean container.  This object is typically
+ * defined as the bean with id='cacheFactory' in cacheContext.xml.
+ */
+ private CacheFactory cacheFactory = null;
+
+    private final Log log = LogFactory.getLog(LayoutCachingService.class);
+
+ /*
+ * Public API.
+ */
+    
+    /**
+     * Accessor method or the single(ton) instance of this class.
+     */
+    public static LayoutCachingService getInstance() {
+
+ if (instance == null) {
+ init();
+ }
+
+ return instance;
+
+ }
+
+    /**
+     * Called by the spring IoC container at startup.
+     *
+     * @param cf Ordinarily 'cacheFactory' bean defined in cacheContext.xml
+     */
+ @Required
+ public void setCacheFactory(CacheFactory cf) {
+
+ // Assertions.
+ if (cf == null) {
+ String msg = "Argument 'cpf [CacheFactory]' cannot be null.";
+ throw new IllegalArgumentException(msg);
+ }
+
+ log.debug("INITIALIZING:  Setting cacheFactory.");
+
+ this.cacheFactory = cf;
+
+ }
+
+ /**
+ * Provides clients of <code>LayoutCachingService</code> with access to the
+ * layout cache.
+ *
+ * @return A <code>Map</code> of cached layouts.
+ */
+ public Map<String,Document> getLayoutCache() {
+ return cacheFactory.getCache(CACHE_NAME);
+ }
+
+ /*
+ * Implementation.
+ */
+
+ /**
+ * Private as per classic Singleton pattern.
+ */
+ private LayoutCachingService() {
+ log.debug("INITIALIZING:  Constructing.");
+ }
+
+ /**
+ * Method that creates the single(ton) instance of
+ * <code>LayoutCachingService</code>, synchronized to be sure it only
+ * happens once.
+ */
+ private static synchronized void init() {
+
+ // Make sure we only create one instance...
+ if (instance != null) {
+ // Must have invoked getInstance() w/ 2 threads.
+ return;
+ }
+
+ instance = new LayoutCachingService();
+
+ }
+
+}
Index: uportal-impl/src/main/resources/properties/contexts/cacheContext.xml
===================================================================
--- uportal-impl/src/main/resources/properties/contexts/cacheContext.xml (revision 6156)
+++ uportal-impl/src/main/resources/properties/contexts/cacheContext.xml (working copy)
@@ -43,4 +43,22 @@
         <property name="cacheManagerName" value="uPortal.cacheManager" />
         <property name="configLocation" value="classpath:/properties/ehcache.xml" />
     </bean>
-</beans>
\ No newline at end of file
+    
+    <!--
+     | Service used by DLM to cache Layouts.
+     +-->
+    <bean id="layoutCachingService" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
+        <property name="targetClass" value="org.jasig.portal.layout.dlm.LayoutCachingService" />
+        <property name="targetMethod" value="getInstance" />
+    </bean>
+    <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
+        <property name="targetObject" ref="layoutCachingService" />
+        <property name="targetMethod" value="setCacheFactory" />
+        <property name="arguments">
+            <list>
+                <ref bean="cacheFactory"/>
+            </list>
+        </property>
+    </bean>
+
+</beans>
Index: uportal-impl/src/main/resources/properties/ehcache.xml
===================================================================
--- uportal-impl/src/main/resources/properties/ehcache.xml (revision 6156)
+++ uportal-impl/src/main/resources/properties/ehcache.xml (working copy)
@@ -81,6 +81,10 @@
                 replicateRemovals=true "/>
     </cache>
 
+    <cache name="org.jasig.portal.layout.dlm.LAYOUT_CACHE"
+        eternal="false" maxElementsInMemory="250" overflowToDisk="false" diskPersistent="false"
+        timeToIdleSeconds="0" timeToLiveSeconds="0" memoryStoreEvictionPolicy="LRU" />
+
     <!-- uPortal IBasicEntity Caches -->
 
     <cache name="org.jasig.portal.ChannelDefinition"

[Dustin S.]

This sounds really useful.

Definitely a +1

On Tue, Jul 8, 2008 at 11:32 AM, Drew Wills <awills@...> wrote:

Hey folks,

I'm working at JHU, and we've put together an enhancement to DLM:  the
ability to store users' layouts in a standard, portal managed cache.
Currently users' layouts are stored (at least in DLM) as a member
variable on each user's LayoutManager instance.

This situation means that:
  - User layouts never change until (1) the user makes a manual change,
or (2) the user logs in again
  - There's no way to manage in-memory layout data administratively

With this enhancement, you'd be able to:
  - specify that user layouts should expire and be rebuilt, say, 15 min
after creation or after 10 min of "idle" time (i.e. not used for 10 min)
  - specify that no more than, say, 500 layouts should be held in
memory at one time
  - use JMX to "clear" (drop) all the layouts in a running instance of
uPortal
  - write Java tools that intelligently invalidate individual layouts
(or all layouts) when certain portal events happen

The changes are relatively small & encapsulated, so they're unlikely to
"break" existing features or even custom Java tech that integrates with DLM.

I'm attaching a .patch that shows the delta.

Please share thoughts on whether this enhancement is desirable or even
acceptable.  If there's interest, I'll create the JIRA etc.

drew wills



--
You are currently subscribed to uportal-dev@... as: IcedOut3E@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Index: uportal-impl/src/main/java/org/jasig/portal/layout/dlm/DistributedLayoutManager.java
===================================================================
--- uportal-impl/src/main/java/org/jasig/portal/layout/dlm/DistributedLayoutManager.java        (revision 6156)
+++ uportal-impl/src/main/java/org/jasig/portal/layout/dlm/DistributedLayoutManager.java        (working copy)
@@ -90,7 +90,7 @@
     */
    static final String FOLDER_LABEL_POLICY = "FolderLabelPolicy";

-    protected Document userLayoutDocument=null;
+    private final Map<String,Document> layoutCache = LayoutCachingService.getInstance().getLayoutCache();

    protected static Random rnd=new Random();
    protected String cacheKey="initialKey";
@@ -226,7 +226,8 @@
    }

    private void setUserLayoutDOM(Document doc) {
-        this.userLayoutDocument = doc;
+
+       layoutCache.put(owner.getUserName(), doc);
        this.updateCacheKey();

        // determine if this is a layout fragment by looking at the root node
@@ -243,6 +244,7 @@
        if (labelPolicy != null) {
            labelPolicy.coordinateFolderLabels(owner.getID(), isFragmentOwner, doc);
        }
+
    }
    private int domRequests = 0;

@@ -261,7 +263,7 @@
            {
                LOG.debug("domRequest: " + (domRequests++));
            }
-            Document userLayoutDocument = this.userLayoutDocument;
+            Document userLayoutDocument = layoutCache.get(owner.getUserName());
            if ( null == userLayoutDocument )
            {
                IUserLayoutStore layoutStore = getLayoutStore();
@@ -407,7 +409,7 @@
        try {
            //Clear the loaded document first if this is a forced reload
            if (reload) {
-                this.userLayoutDocument = null;
+               layoutCache.remove(owner.getUserName());
            }

            uli=getUserLayoutDOM();
@@ -1507,7 +1509,7 @@
        }
        //this.markedUserLayout=null;
        this.updateCacheKey();
-        this.userLayoutDocument=doc;
+        layoutCache.put(owner.getUserName(), doc);
    }

    /* Returns the ID attribute of the root folder of the layout. This folder
@@ -1689,7 +1691,7 @@
            // so we need to refresh our local copy of their layout
            if (person == owner)
            {
-                this.userLayoutDocument = null;
+               layoutCache.remove(owner.getUserName());
                updateCacheKey();
                getUserLayoutDOM();
            }
Index: uportal-impl/src/main/java/org/jasig/portal/layout/dlm/LayoutCachingService.java
===================================================================
--- uportal-impl/src/main/java/org/jasig/portal/layout/dlm/LayoutCachingService.java    (revision 0)
+++ uportal-impl/src/main/java/org/jasig/portal/layout/dlm/LayoutCachingService.java    (revision 0)
@@ -0,0 +1,120 @@
+/**
+ * Copyright 2008 The JA-SIG Collaborative.  All rights reserved.
+ * See license distributed with this file and
+ * available online at http://www.uportal.org/license.html
+ */
+
+package org.jasig.portal.layout.dlm;
+
+import java.util.Map;
+import org.w3c.dom.Document;
+
+import org.springframework.beans.factory.annotation.Required;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.jasig.portal.utils.cache.CacheFactory;
+
+/**
+ * Provides caching services for layouts contained in
+ * <code>DistributedLayoutManager</code> instances.  This class is an old-school
+ * singleton whose backing-map is "injected" by a spring context at startup.
+ */
+public final class LayoutCachingService {
+
+       /**
+        * The name of the cache used by <code>LayoutCachingService</code>.  A cache
+        * of this name must be defined within uPortal's <code>'cacheFactory'</code>
+        * bean.
+        */
+       private static final String CACHE_NAME = "org.jasig.portal.layout.dlm.LAYOUT_CACHE";
+
+       /**
+        * Single(ton) instance of this class.
+        */
+       private static LayoutCachingService instance = null;
+
+       /**
+        * "Injected" at startup by the bean container.  This object is typically
+        * defined as the bean with id='cacheFactory' in cacheContext.xml.
+        */
+       private CacheFactory cacheFactory = null;
+
+    private final Log log = LogFactory.getLog(LayoutCachingService.class);
+
+       /*
+        * Public API.
+        */
+
+    /**
+     * Accessor method or the single(ton) instance of this class.
+     */
+    public static LayoutCachingService getInstance() {
+
+               if (instance == null) {
+                       init();
+               }
+
+               return instance;
+
+       }
+
+    /**
+     * Called by the spring IoC container at startup.
+     *
+     * @param cf Ordinarily 'cacheFactory' bean defined in cacheContext.xml
+     */
+       @Required
+       public void setCacheFactory(CacheFactory cf) {
+
+               // Assertions.
+               if (cf == null) {
+                       String msg = "Argument 'cpf [CacheFactory]' cannot be null.";
+                       throw new IllegalArgumentException(msg);
+               }
+
+               log.debug("INITIALIZING:  Setting cacheFactory.");
+
+               this.cacheFactory = cf;
+
+       }
+
+       /**
+        * Provides clients of <code>LayoutCachingService</code> with access to the
+        * layout cache.
+        *
+        * @return A <code>Map</code> of cached layouts.
+        */
+       public Map<String,Document> getLayoutCache() {
+               return cacheFactory.getCache(CACHE_NAME);
+       }
+
+       /*
+        * Implementation.
+        */
+
+       /**
+        * Private as per classic Singleton pattern.
+        */
+       private LayoutCachingService() {
+               log.debug("INITIALIZING:  Constructing.");
+       }
+
+       /**
+        * Method that creates the single(ton) instance of
+        * <code>LayoutCachingService</code>, synchronized to be sure it only
+        * happens once.
+        */
+       private static synchronized void init() {
+
+               // Make sure we only create one instance...
+               if (instance != null) {
+                       // Must have invoked getInstance() w/ 2 threads.
+                       return;
+               }
+
+               instance = new LayoutCachingService();
+
+       }
+
+}
Index: uportal-impl/src/main/resources/properties/contexts/cacheContext.xml
===================================================================
--- uportal-impl/src/main/resources/properties/contexts/cacheContext.xml        (revision 6156)
+++ uportal-impl/src/main/resources/properties/contexts/cacheContext.xml        (working copy)
@@ -43,4 +43,22 @@
        <property name="cacheManagerName" value="uPortal.cacheManager" />
        <property name="configLocation" value="classpath:/properties/ehcache.xml" />
    </bean>
-</beans>
\ No newline at end of file
+
+    <!--
+     | Service used by DLM to cache Layouts.
+     +-->
+    <bean id="layoutCachingService" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
+        <property name="targetClass" value="org.jasig.portal.layout.dlm.LayoutCachingService" />
+        <property name="targetMethod" value="getInstance" />
+    </bean>
+    <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
+        <property name="targetObject" ref="layoutCachingService" />
+        <property name="targetMethod" value="setCacheFactory" />
+        <property name="arguments">
+            <list>
+                <ref bean="cacheFactory"/>
+            </list>
+        </property>
+    </bean>
+
+</beans>
Index: uportal-impl/src/main/resources/properties/ehcache.xml
===================================================================
--- uportal-impl/src/main/resources/properties/ehcache.xml      (revision 6156)
+++ uportal-impl/src/main/resources/properties/ehcache.xml      (working copy)
@@ -81,6 +81,10 @@
                replicateRemovals=true "/>
    </cache>

+    <cache name="org.jasig.portal.layout.dlm.LAYOUT_CACHE"
+        eternal="false" maxElementsInMemory="250" overflowToDisk="false" diskPersistent="false"
+        timeToIdleSeconds="0" timeToLiveSeconds="0" memoryStoreEvictionPolicy="LRU" />
+
    <!-- uPortal IBasicEntity Caches -->

    <cache name="org.jasig.portal.ChannelDefinition"

-- 

You are currently subscribed to uportal-dev@... as: lists@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[Christopher Doyle]

Cache-backed layouts = happy JHU folks, for all of the benefits outlined
by Drew and more...
+1


-----Original Message-----
From: bounce-6010370-5712674@...
[mailto:bounce-6010370-5712674@...] On Behalf Of Drew Wills
Sent: Tuesday, July 08, 2008 11:32 AM
To: uportal-dev@...
Subject: [uportal-dev] LAYOUT_CACHE: Is this an interesting enhancement?

Hey folks,

I'm working at JHU, and we've put together an enhancement to DLM:  the
ability to store users' layouts in a standard, portal managed cache.
Currently users' layouts are stored (at least in DLM) as a member
variable on each user's LayoutManager instance.

This situation means that:
   - User layouts never change until (1) the user makes a manual change,
or (2) the user logs in again
   - There's no way to manage in-memory layout data administratively

With this enhancement, you'd be able to:
   - specify that user layouts should expire and be rebuilt, say, 15 min
after creation or after 10 min of "idle" time (i.e. not used for 10 min)
   - specify that no more than, say, 500 layouts should be held in
memory at one time
   - use JMX to "clear" (drop) all the layouts in a running instance of
uPortal
   - write Java tools that intelligently invalidate individual layouts
(or all layouts) when certain portal events happen

The changes are relatively small & encapsulated, so they're unlikely to
"break" existing features or even custom Java tech that integrates with
DLM.

I'm attaching a .patch that shows the delta.

Please share thoughts on whether this enhancement is desirable or even
acceptable.  If there's interest, I'll create the JIRA etc.

drew wills



--
You are currently subscribed to uportal-dev@... as:
cdoyle@... To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

--
You are currently subscribed to uportal-dev@... as: lists@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[Eric Dalquist]

Some parts of this message have been removed. Learn more about Nabble's security policy.

So this looks like WS interfaces for Person Directory and Groups & Permissions? Would the work be to add these features to the stand-alone projects then?

-Eric

Pascal Aubry wrote:

uPortal developers,
Though esup-portal-ws (see http://www.ja-sig.org/wiki/x/sQGF) is a quick-and-dirty implementation, it is now used by all the French community (embedded into the French uportal-esup distribution) and I also had feedback from some American universities, Belgium and Canada. Chris Doyle recently did some job on the project (see below) and I feel it would be nice if this project was hosted by jasig (it is currently hosted by the French CRU, see http://www.cru.fr/en) as a contribution. Moving to the jasig svn repository and putting the issues into the kasgi jira would ease the maintenance (by Chris and I) and give it a better visibility as well.
You opinion?
Best,
PA

Chris Doyle a écrit :

Pascal,

 

I am definitely available to help transition this project over to the JA-SIG infrastructure, pending the okay from the community as Jonathan mentioned.  In the meantime, might you be able to grant me svnadmin access to the esup-portal-ws project in the subversion.cru.fr repository?  I'd like to capture a complete SVN dump of the project for import into the JA-SIG repository as a starting point.

 

Thanks,

 

--Chris

 

 

From: Jonathan Markow [jjmarkow@...]
Sent: Monday, July 07, 2008 9:27 PM
To: Pascal Aubry
Cc: Chris Doyle; fabrice.jammes@...; Raymond.Bourges@...
Subject: Re: esup-portal-ws Project

 

Hi Pascal-

It sounds very desirable to me for JA-SIG to host the project--and Chris's improvements.  Why don't you begin by making a proposal to uportal-dev?

Thanks very much,
Jonathan

On Mon, Jul 7, 2008 at 7:08 PM, Pascal Aubry <pascal.aubry@...> wrote:

Hi Chris,
To tell the truth, I am not very proud of this code, written in a few hours... Anyway it is used in production by all our French partners (it is now part of the uPortal-esup distribution) and I also received feedback from Canada, Belgium and a few American universities.
Nice to see esup-portal-ws is useful also to you, and of course your work is worth being shared!
As the project is used quite widely now, I think it is time to rename it uportal-ws and move it to jasig in order to give it a better visibility. Currently, the docs are already hosted by the jasig wiki (http://www.ja-sig.org/wiki/x/sQGF), the source code and the downloads are still hosted by the French CRU (http://www.cru.fr/en).
Jonathan, what do you think about it? Who should I ask?
Chris, would you be ok to do the job (move the project to the jasig repository)? Are you a jasig committer already?
Thanks,
PA

Chris Doyle a écrit :

Greetings,

 
We are currently using the esup-portal-ws project in our uPortal 2.6.1+ instance here at Johns Hopkins.  We are amidst a major uPortal upgrade to version 3.0.0, and during the process I was able to fully mavenize the esup-portal-ws project from the most recent checkout from your SVN trunk (Revision 26).  I would very much like to contribute this work back to you, and ultimately to share it with the JA-SIG and ESUP-Portail communities at-large with your blessings.  I also ended up having to apply a patch to the axistools-maven-plugin mojo in order it to build properly, but I can send over that work as well.

 
Are you interested, and if so how should I ship you my code?

 
Many thanks!

 
--Chris

 
--

[ c h r i s d o y l e ]

Johns Hopkins University

Sr. System Software Engineer, IT@JH

410.735.4127

cdoyle@...

 
"Eleven. Exactly. One louder."

 

--
http://perso.univ-rennes1.fr/pascal.aubry

 

-- 

You are currently subscribed to uportal-dev@... as: eric.dalquist@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[Eric Dalquist]

This sounds great, just the sort of thing I was hoping for with the
better caching backend.

A few questions:
1. How are the cache entries keyed?
2. Does this change the cached entry invalidation logic at all from the
existing code?
3. Does this also move the DLM fragment cache into a managed cache as well?

-Eric

Drew Wills wrote:

> Hey folks,
>
> I'm working at JHU, and we've put together an enhancement to DLM:  the
> ability to store users' layouts in a standard, portal managed cache.
> Currently users' layouts are stored (at least in DLM) as a member
> variable on each user's LayoutManager instance.
>
> This situation means that:
>    - User layouts never change until (1) the user makes a manual change,
> or (2) the user logs in again
>    - There's no way to manage in-memory layout data administratively
>
> With this enhancement, you'd be able to:
>    - specify that user layouts should expire and be rebuilt, say, 15 min
> after creation or after 10 min of "idle" time (i.e. not used for 10 min)
>    - specify that no more than, say, 500 layouts should be held in
> memory at one time
>    - use JMX to "clear" (drop) all the layouts in a running instance of
> uPortal
>    - write Java tools that intelligently invalidate individual layouts
> (or all layouts) when certain portal events happen
>
> The changes are relatively small & encapsulated, so they're unlikely to
> "break" existing features or even custom Java tech that integrates with DLM.
>
> I'm attaching a .patch that shows the delta.
>
> Please share thoughts on whether this enhancement is desirable or even
> acceptable.  If there's interest, I'll create the JIRA etc.
>
> drew wills
>
>
>
>  

[Christopher Doyle]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Actually, that’s a great point.  Perhaps the project should be broken up into two pieces – and thus two independent services – one for each standalone project (gap and person-directory).  Good call...shall we proceed forth, then?

 

--Chris

 

 

From: bounce-6013530-5712674@... [mailto:bounce-6013530-5712674@...] On Behalf Of Eric Dalquist
Sent: Wednesday, July 09, 2008 11:37 AM
To: uportal-dev@...
Subject: Re: [uportal-dev] esup-portal-ws Project

 

So this looks like WS interfaces for Person Directory and Groups & Permissions? Would the work be to add these features to the stand-alone projects then?

-Eric

Pascal Aubry wrote:

uPortal developers,
Though esup-portal-ws (see http://www.ja-sig.org/wiki/x/sQGF) is a quick-and-dirty implementation, it is now used by all the French community (embedded into the French uportal-esup distribution) and I also had feedback from some American universities, Belgium and Canada. Chris Doyle recently did some job on the project (see below) and I feel it would be nice if this project was hosted by jasig (it is currently hosted by the French CRU, see http://www.cru.fr/en) as a contribution. Moving to the jasig svn repository and putting the issues into the kasgi jira would ease the maintenance (by Chris and I) and give it a better visibility as well.
You opinion?
Best,
PA

Chris Doyle a écrit :

Pascal,

 

I am definitely available to help transition this project over to the JA-SIG infrastructure, pending the okay from the community as Jonathan mentioned.  In the meantime, might you be able to grant me svnadmin access to the esup-portal-ws project in the subversion.cru.fr repository?  I'd like to capture a complete SVN dump of the project for import into the JA-SIG repository as a starting point.

 

Thanks,

 

--Chris

 

 

From: Jonathan Markow [jjmarkow@...]
Sent: Monday, July 07, 2008 9:27 PM
To: Pascal Aubry
Cc: Chris Doyle; fabrice.jammes@...; Raymond.Bourges@...
Subject: Re: esup-portal-ws Project

 

Hi Pascal-

It sounds very desirable to me for JA-SIG to host the project--and Chris's improvements.  Why don't you begin by making a proposal to uportal-dev?

Thanks very much,
Jonathan

On Mon, Jul 7, 2008 at 7:08 PM, Pascal Aubry <pascal.aubry@...> wrote:

Hi Chris,
To tell the truth, I am not very proud of this code, written in a few hours... Anyway it is used in production by all our French partners (it is now part of the uPortal-esup distribution) and I also received feedback from Canada, Belgium and a few American universities.
Nice to see esup-portal-ws is useful also to you, and of course your work is worth being shared!
As the project is used quite widely now, I think it is time to rename it uportal-ws and move it to jasig in order to give it a better visibility. Currently, the docs are already hosted by the jasig wiki (http://www.ja-sig.org/wiki/x/sQGF), the source code and the downloads are still hosted by the French CRU (http://www.cru.fr/en).
Jonathan, what do you think about it? Who should I ask?
Chris, would you be ok to do the job (move the project to the jasig repository)? Are you a jasig committer already?
Thanks,
PA

Chris Doyle a écrit :

Greetings,

 
We are currently using the esup-portal-ws project in our uPortal 2.6.1+ instance here at Johns Hopkins.  We are amidst a major uPortal upgrade to version 3.0.0, and during the process I was able to fully mavenize the esup-portal-ws project from the most recent checkout from your SVN trunk (Revision 26).  I would very much like to contribute this work back to you, and ultimately to share it with the JA-SIG and ESUP-Portail communities at-large with your blessings.  I also ended up having to apply a patch to the axistools-maven-plugin mojo in order it to build properly, but I can send over that work as well.

 
Are you interested, and if so how should I ship you my code?

 
Many thanks!

 
--Chris

 
--

[ c h r i s d o y l e ]

Johns Hopkins University

Sr. System Software Engineer, IT@JH

410.735.4127

cdoyle@...

 
"Eleven. Exactly. One louder."

 

--
http://perso.univ-rennes1.fr/pascal.aubry

 

-- 

http://perso.univ-rennes1.fr/pascal.aubry

 

-- 

You are currently subscribed to uportal-dev@... as: eric.dalquist@...

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

-- 

You are currently subscribed to uportal-dev@... as: lists@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[Drew Wills]

Eric,

Good questions...

Eric Dalquist wrote:
> This sounds great, just the sort of thing I was hoping for with the
> better caching backend.
>
> A few questions:
> 1. How are the cache entries keyed?

By username, as it stands.  I'm not aware of (1) a way that a single
user can have more than one layout loaded in memory, nor (2) a way that
multiple people can have the same username (in fact this situation would
wreak havoc).

> 2. Does this change the cached entry invalidation logic at all from the
> existing code?

I don't think so, but perhaps I don't understand the question.

We're talking about caching the user's layout DOM, not a theme transform
or any rendered content.

The cache just replaces a private member variable, such that...
   - any calls to getLayout() check the cache, but get it from the
layoutStore if it's not found
   - any calls to setLayout() place a new copy in the cache
   - any methods that previously set the layout to null would now call
cache.remove(username), which clears the way for getLayout() to pull
from the layoutStore on the next call the getLayout()

It *does* change the behavior of the portal in one, uncommon scenario:
it's possible that your layout can change while you're logged in
(without your direct manipulation), based on a fragment layout changing
or somesuch.

This possibility is considered desirable by some;  those who consider it
undesirable would be able to configure the LAYOUT_CACHE in a manner that
would prevent it.

> 3. Does this also move the DLM fragment cache into a managed cache as well?
>

I wish.

The layouts of the actual user accounts that own the fragments would be
cached, but DLM uses a different data structure to store the
"fragmentized" layout objects it use to build composite layouts.

drew wills


--
You are currently subscribed to uportal-dev@... as: lists@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev