Santiago Gala wrote:
>
> We are developing a extension of the new profiler (in fact, it is
> already here, we are just testing) to cache the generated portletset in
> the session, to avoid recomputing the portletset for each request.
>
Excellent. (I am very happy to hear that)
Shouldn't this be the default behavior?
> This has a heavy impact on performance, as we skip lots of getPortlet()
> calls and lots of memory allocations when the psml descriptions are wide
> and deep (as it is our case).
>
> I wanted to comment that, to develop this simple extension, I had to
> create two classes:
>
> - a new Profile class (inheriting from BaseProfile)
> - a new Service (there is no factory to plug new classes there).
>
To switch profiler services in the JetspeedResources:
# The Profile Manager Service is implemented as a Turbine service.
services.ProfileManager.classname=org.apache.jetspeed.services.profiler.Jets
peedProfileManagerService
But yes, there needs to be a ProfileFactory to plug in different Profile
classes.
I can do that if you already haven't?
> I think that the implementation should be in a way that one does not
> need to modify the service, but only the Profile class, to extend it.
>
>
> Also, I wanted to ask if we are switching profiles soon. I have noticed
> very little activity in this area recently.
>
Sorry, Im still working on it, but I haven't committed. Been rather busy ...
I've been using the new profiler a lot here, and it works well.
In fact I am very dependent on using this new service api for multiple psml
resources per user/group.
I now have the new profiler working with the new Persistence Service.
The next part was to get it working with the new Customizer, which is where
I stopped since Im not sure if the new Customizer will be around long.
>
> Of course, I will commit the changes as an alternative profile if nobody
> oposes. The changes could even be integrated in the default profile,
> maybe as a configurable feature.
>
>
> Also, I wanted to note that the default configuration for the new
> Profiler does not work. The anon.dir cannot be empty with the current
> implementation, because of "/" trimming and other issues.
>
I haven't seen this problem.
Perhaps I need to get the latest build, which I haven't refreshed for 3-4
days.
>
> The only problem of using cached PortletSets (and Controls and
> Controllers) is that, as the Control/lers store state information (which
> they should not), the default session gets recovered in whatever state
> WRT cards selected that was left by the previous request. This will stop
> happening when we clean this part of the API and we recover state from
> the Request only.
>
Look at the new Persistence Service. I believe it solves this problem.
>
> Comments?
>
I will try to commit this week so you can see the persistence + profiler
services working together.
Im travelling today, just to remind you that I won't be able to respond to
email until tomorrow
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
