Hi,
Now, I have CVS HEAD and I am working with it. Reporting bugs as and when I
am finding any...
Got a doubt, related to Profiler and PsmlManager Service. Both these
services are basically hooked into Turbine as they extend
TurbineBaseService. I looked at the code, both these services never
interact with each other directly. Depending upon the logged in user,
particular Profile (for the user) is getting created (from
JetspeedProfilerService) and appropriate PSMLDocument is loaded (from
CastorPsmlManagerService). So my question is how this interaction occurs?
Just to explain my question in detail, assume user "turbine" logs in. Now,
for "turbine" the default.psml file is located under directory
"/WEB-INF/psml/user/turbine". Now, I can figure out that,
JetspeedProfilerService is responsible to create this file path. But who
invokes the JetspeedProfilerService to get this file path and then later
use PsmlManagerService to load the actual document?
Also I would like some detailed information on the "fallback" algorithm
that is used while creating user profile/psml-file path. I tried to look at
the Javadoc for the "fallback" method in
org.apache.jetspeed.services.profiler.JetspeedProfilerService, which helps
a bit but still I would like to have some more informaition on that.
Also there are following methods in interface
org.apache.jetspeed.services.profiler.Profiler, which I'm unable to figure
out what they do:
=====================
public String locateTemplate(RunData data, String resourceType, String
path, String template);
public String locateScreenTemplate(RunData data, String template);
public String locateLayoutTemplate(RunData data, String template);
public String locatePortletTemplate(RunData data, String template);
public String locateControlTemplate(RunData data, String template);
public String locateControllerTemplate(RunData data, String template);
======================
Also I would like to have some guidance on how should we put .psml
information into database, so that once we agree on that, future
integration will be lot easier.
So, as far as putting, the .psml information into database is concerned, I
think, the DatabaseProfilerService has to handle the exact same issues that
are handled by JetspeedProfilerService for creating the resourceURL (that
is file path). Now, when we put the psml information in to the database,
similar to file system where fully qualified path is the identifying key
for the file, we also would need same type of primary key to get the stored
psml info. In simplistic terms, I can actually use, the same file name
(resourceURL) just replace by some character (may be ".") to create a
primary key and dump the psml contents as bytes or string. If we follow
this criteria for the primary key, then we can put all the fallback
algorithm and all the profiling related methods in a super class and
subclass it to get the file resource URLs (in case of
org.apache.jetspeed.services.profiler.JetspeedProfilerService) or database
primary keys (in case of DatabaseProfilerService). That way we would be
still using "Factory" pattern and effectively using "Template Method"
pattern to reuse the critical algorithm related code (which we definitely
don't want to replicate). This way if someone wants to store this psml info
into LDAP then they can also do it much easily. As far as
PsmlManagerService for managing database PSML info (create/update/remove),
is concerned it has to be implemented from ground zero.
While using DatabaseProfilerService/DatabasePsmlManagerService, I think,
there may be few issues related to the Customizer, which currently assumes
only File based PSMLs. I need to investigate that further.
Please, let me know, what do you think on above points and also of any
other clues that may help me in implementing above task.
Thanks,
-Atul
At 11:53 AM 7/3/01 -0700, you wrote:
> > When is 1.3a2 scheduled for? B'cse if we do all those changes
> > in current
> > release (1.3a1) it would have to be redone in 1.3a2. And as
> > release date for
> > 1.3a2 is not yet out, we are in a kind of flux.
> >
>
>The 1.3a2 release will be out soon.
>I think you can safely code to the cvs head, although I'd recommend that we
>first define the standard PSML interfaces before embarking on writing the
>psml service.
>
>We still don't use interfaces for PSML access - everything is accessed thru
>the Castor-XML generated classes.
>Im looking at org.apache.jetspeed.om.newregistry. The next step would be to
>create a similar org.apache.jetspeed.om.psml
>
>It would be great to have a database-based psml implementation.
>I look forward to this one...
>
>-------------------------------------
>David Sean Taylor
>[EMAIL PROTECTED]
>-------------------------------------
>http://jakarta.apache.org/jetspeed
>-------------------------------------
>
>
>
>
> > -----Original Message-----
> > From: Atul Dambalkar [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 03, 2001 10:29 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Putting .psml/markup info into database
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: David Sean Taylor [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, July 02, 2001 10:52 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Putting .psml/markup info into database
> > >
> > >
> > > > Hi,
> > > >
> > > > I'm trying to do certain modifications to Jetspeed. The main
> > > > requirement we
> > > > have is, we want to put .psml/markup information into
> > > > database. We don't
> > > > want all those .psml files lying around in file system. And
> > > > as number of
> > > > users grow, it will just flood the file system.
> > > >
> > > > Here are some of my findings and conclusions:
> > > > 0. Need to define a database schema, which will allow to
> > > > store per group/per
> > > > role/per user specific .psml information in to database.
> > >
> > > There is already a 'schema' for PSML: src/xml/schema/psml.xsd
> > >
> >
> > Huh. That's a good point. Actually, I had looked at the
> > psml.xsd and was
> > about to explore the schema, before creating a new one. Thanks for the
> > pointer though.
> >
> > > This XML Schema is the definitive schema for PSML.
> > > From the xml schema, we use Castor to create the Java object
> > > model for PSML.
> > > I believe the database schema to be an implementation detail for a
> > > relational database implementation.
> > >
> > > > 1. The current Profiler Manager Service
> > > > (org.apache.jetspeed.services.profile.JetspeedProfileManagerSe
> > > > rvice) needs
> > > > to be rewritten.
> > >
> > >
> > > I think you want to look at the
> > > org.apache.jetspeed.services.psmlmanager.PsmlManagerService
> > > interface - this
> > > has more to do with the storage and retrieval of PSML.
> >
> > Well, I guess, you are looking at the current CVS HEAD. I am
> > planning to use
> > the current 1.3a1 release, which doesn't have
> > PsmlManagerService (and as
> > 1.3a2 release date is not yet available).
> >
> > >
> > > For the next release, I'd like to refactor the Profiler
> > > service to better
> > > use the PsmlManagerService to persist and query psml.
> > >
> > > That said, I disagree that the
> > JetspeedProfileManagerService should be
> > > rewritten.
> > > It is a good implementation of a file-system based profiling system.
> >
> > Its a great implementation. I am not saying we should get rid
> > of it, may be
> > I put it wrong.
> >
> > > Wouldn't you prefer to have two implementations: a file-based and
> > > database-based implementation?
> >
> > Yeah, ofcourse. I would prefer that.
> >
> > >
> > > Both would implement the same interface:
> > > org.apache.jetspeed.services.profiler.ProfilerService.
> > > Thus you can plug in the new Service impl. without disrupting
> > > any other code
> > > in the system.
> >
> > That's perfect. "Code to an interface..never to an implementation!"
> >
> > > And for those who chose not to use database storage for their
> > > psml, they are
> > > still free to store it in the file system with the
> > > JetspeedProfileManagerService.
> > >
> >
> > Yep.
> >
> > > This was the design intention from the beginning.
> > >
> > > > 2. The new rewritten class can be plugged into Jetspeed thro'
> > > > properties
> > > > file.
> > > > 3. Also, org.apache.jetspeed.cache.disk package needs to be
> > > > modified. It
> > > > curently handles remote and local urls. It needs handle the
> > > > database storage
> > > > to get the required information if the newly written Profiler
> > > > Manager has to
> > > > use Disk Cache (which it will now, as we don't want to go
> > > to database
> > > > everytime user logs in).
> > >
> > > You shouldn't have to touch the Disk Cache.
> > > The impl. of the new DatabaseProfileManagerService would most
> > > likely use
> > > JDBC, or perhaps Castor JDO...
> > > Take a look at the CastorPsmlManagerService. It already
> > makes use of a
> > > WeakReference memory cache.
> >
> > Huh. That's a good hint.
> >
> > >
> > > >
> > > > Will someone from the Jetspeed development team comment on
> > > > this, please? Or
> > > > is there a plan to incorporate this as a new feature?
> > > >
> > >
> > > Sure. If you write it, we would be glad to incorporate it :)
> > > However, we are not planning on writing this for the 1.3a2 release.
> >
> > When is 1.3a2 scheduled for? B'cse if we do all those changes
> > in current
> > release (1.3a1) it would have to be redone in 1.3a2. And as
> > release date for
> > 1.3a2 is not yet out, we are in a kind of flux.
> >
> > Thanks,
> >
> > -Atul
> >
> > > I think it would be a good candidate for 1.3a3, along with
> > > the refactoring
> > > of the Profiler and PSMLManager, which is already planned.
> > >
> > > > Thanks,
> > > >
> > > > -Atul
> > > >
> > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
