Thanks for the update Matt. I have some changes I'm working on to remedy this for easier XSL/CSS editing. I'll post here when they are committed but it should be within a few hours.

-Eric

On 09/21/2010 10:44 AM, Matt Polizzotti wrote:
I briefly spoke to Eric about this issue yesterday in the uportal irc channel 
and I wanted to post what I am seeing to the developer list. I am currently 
working on UP-2789, implementing a new tab management interface, and since 
updating yesterday, I have experienced issues with uPortal caching xsl, 
javascript and css resources. In short, changes to these resources do not seem 
to render to the portal in a predictable way when the browser is refreshed.

I typically run uPortal in developer mode:
1] I comment out the JavaScript and CSS pageCachingFilter located in the 
web.xml file, which is housed under trunk/uportal-war/src/main/webapp/WEB-INF

2] I toggle xslt caching from on to off in the portal.properties file, which is 
housed under trunk/uportal-war/src/main/resources/properties

3] I disable CSS and JavaScript aggregation with the Toggle Resources 
Aggregation portlet.

Thank you and please let me know if I need to provide additional information.
-Matthew Polizzotti


----- Original Message -----
From: "Eric Dalquist"<[email protected]>
To: [email protected]
Sent: Friday, September 17, 2010 10:24:36 PM
Subject: [uportal-dev] New rendering pipeline in trunk

   I just finished merging the new StAX based rendering pipeline into
trunk. Instead of SAX ContentHandlers StAX XMLEventReaders and custom
CharacterEventReaders are used to pass data starting at the user's
layout through the transforms and eventually to the browser. It also
switched to the standard StAX XMLOutputFactory for serialization so no
more custom HTML/XHTML serializer code in uPortal. To make this all work
xalan, xerces, xml-apis, and xml-resolver have all been removed from the
project. Developers will need to take care when adding a new dependency
that one of these isn't accidentally added back in as a transitive
dependency. They auto-register with the JVM and all have old versions of
the JAXP APIs which don't work right.

The new pipeline is broken up into components and configured via Spring.
An overview of the guiding design is in the wiki:
https://wiki.jasig.org/display/UPC/Rendering+Pipeline+Refactoring That
page will be updated and renamed to reflect the actual design in the
next week or so.

Caching of pipeline events has also been revamped. Each component in the
pipeline can contribute to a compound cache key that is built up.
Caching components use this information to determine if a cache of event
data can be replayed. As the new pipeline is tuned this should allow the
caching of rendering data to be much more responsive to user requests.
Also the caches are in Ehcache which allows for further configuration
and management of behavior.

The XSL loading code is now modification aware. The XSL templates are
cached but periodically the files are checked for modifications and
reloaded if there are any. For those working on XSL development this
should make your lives easier as things will update live for you but
still perform well in a production environment.


This commit also removes the PortalSessionManager servlet and replaces
it with a Spring DispatcherPortlet that delegates all portal and portlet
requests to an annotated controller. Several of the functions of
PortalSessionManager have been broken out into Interceptors to simplify
the classes.


URL Canonicalization is also included, there is a servlet filter that
will enforce the correct URL in the new syntax for any view of the portal.


This is a big change set. If you run into any problems please report
them on the list and we can figure out a solution.
-Eric


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to