You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Atul Dambalkar <ad...@cisco.com> on 2001/07/06 19:18:29 UTC
Fwd: RE: Putting .psml/markup info into database
Forwarded from jetspeed-user list...
More below...
>Atul Dambalkar wrote:
>
> > Now, I have CVS HEAD and I am working with it. Reporting bugs
> > as and when I
> > am finding any...
> >
>
>Yes, Thanks!
>
> > 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?
>
>Look at org.apache.jetspeed.util.template.JetspeedTool.java
>This is a good example of invoking the profiler and psml-manager.
Sure. Thanks.
> >
> > 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.
> >
>
>see /jakarta-jetspeed/proposals/0005.txt
Oh..right..I need to go thro' 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);
> > ======================
> >
>
>These methods need to be moved out of the Profiler interface.
>I put them there to reuse some code, and wasn't quite sure where to put them
>since I'd prefer they we're implemented in Turbine anyway.
>You should not have to implement them for your service.
>
Okay, great.
> > 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
>
>So you are suggesting storing the entire profile information in one big blob
>(or string)?
That would be most simplistic approach, but I totally agree with what you
are saying.
>That will probably be best for speed. Im just wondering if we should be
>leveraging the sql engine more.
We should leverage SQL engine more.
>Like if you needed to search psml content.
>
>Yes, the primary key must be unique, but it would be nice if it were
>possibly segmented i.e.
>
>type (user/role/group) + entity (username/rolename/groupname) + mediatype +
>language + resourcename
>
>This will be much more useful for searching on secondary indices, such as
>SELECT * FROM PSML WHERE MEDIATYPE = 'WML'
>
True.
> > 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
>
>that would be nice (LDAP)! ....are you volunteering for that one too ;-)
Well, why not...if there is someone to use it :)
BTW, what is your opinion on, moving the "fallback" algorithm specific code
to some super class and reusing it in the respective sub classes
(FileSystemProfilerService/DatabaseProfilerService...)? Or another approach
would as I am outlining below that, to create method signatures in such a
way that the current ResourceURL/file paths get entirely eliminated and
then the PSML location (file system/database/ldap) will be totally
transparent to PsmlManagerService.
> > 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.
>
>I hope not....I thought I removed that stuff
Nope, its still there in CVS HEAD which I extracted on Jul-3, 14.53 PST.
> >
> > 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.
>
>I will add some new methods to the Profiler interface for listing profiles
>(there can be more than one profile per user...)
>This shouldn't be too much work, but they will necessary in order to
>customize all profiles.
>Will also move out the template location methods -- perhaps into a
>TemplateLocator service.
What is the time line that you are looking for this, to commit?
>Im wondering if there is a need for two Profiler services. Perhaps much of
>the Profiler functionality, such as searching thru directories, should be
>moved down into the CastorPsmlManagerService (and
>DatabasePsmlManagerService). The Profiler should not be aware of the file
>system.
That's perfect. In that case, we need to modify PsmlManagerService for
method signatures to handle extracting the PSML information independent of
any location...file system/database/ldap.. something like..
PSMLDocument getDocument(type (user/role/group), entity
(username/rolename/groupname), mediatype, language, resourcename) which can
also adequately handle Database queries..
and so CastorPsmlManagerService also has to be modified to handle these new
methods. Similarly DatabasePsmlManagerService will implement those methods
to query the database.
>Perhaps we should move this discussion to jetspeed-dev@jakarta-apache.org
Sure, now it is.
-Atul
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Putting .psml/markup info into database
Posted by Atul Dambalkar <ad...@cisco.com>.
At 04:21 PM 7/9/01 -0700, you wrote:
>Hi Atul,
>
>Im travelling today, and Im having trouble getting my usual email, so Im on
>a different account today...
No problem..David.
Great that, you could reply back. Thanks.
> >
> > Please, educate me here. What are Castor mapping files? Where are they
> > located and how they are used?
> >
> > >
> > >interface Profile
> > >{
> > > PSMLDocument getDocument()
> > > ProfileLocator getLocator()
> > >}
> > >
> > >or like this
> > >
> > >interface Profile extends ProfileLocator
> > >{
> > > PSMLDocument getDocument()
> > >}
> > >
> > >I like the second solution best, it's not as clean as the first
> > but easier
> > >to use...
> >
> > I also like the second approach.
> >
>
>Done, its in the cvs.
Yeah, I saw that. Cool stuff.
> >
> > >The Profiler would still have to code the fallback algorithm but instead
> > >of actually
> > >looking for the resource it would just build an ordered list of Locator
> > >objects which
> >
> > That's what I meant in my previous emails, not exactly though...about
> > separating "Fallback Algorithm" in one (may not be super) class and
> > everyone will just use the same ProfilerService... We don't want to
> > replicate "Fallback Algorithm"
> >
> > Here is what I feel: (Feel free to correct me or fill in any
> > missing bit of
> > information as you guys definitely know the exact flow and the
> > side effects..)
> > 0. Turbine invokes SessionValidator object in Jetspeed.
> > 1. Profiler(Service) gets invoked from the
> > org.apache.jetspeed.modules.actions.JetspeedSessionValidator
> > 2. Profiler creates the ordered list of ProfileLocator objets (as
> > you said)
> > 3. Turbine invokes the profile from the RunData object, and
> > renders the page...
> > 4. In this case the implementation of the method "PSMLDocument
> > getDocument()" in class
> > org.apache.jetspeed.om.profile.BaseProfile needs to
> > be changed or overridden to the one which uses,
> > PsmlManager.fallback(Locators)..
> > 5. Modify couple of methods in CastorPsmlManagerService viz.
> > getDocument(String url) to handle Locator objects.
> > 6. Implement DatabasePsmlManagerService or LDAPPsmlManagerService,
> > transperant to ProfilerService
> >
> > I just did a CVS update, looked at the updated code, cool stuff, looks
> > perfect to me and think we are on right track, except the
> > JetspeedProfilerService, which I think, needs modification.
>
>Im in the middle of working on it. I tried to commit the interfaces so that
>you could see them first.
>The code that is specific to the file system still needs to be migrated out
>of the JetspeedProfiler and over into the CastorPsmlManagerServer.
>Or perhaps it should be called the FilePsmlManagerService, since for the
>DatabasePsmlManagerService, you may also choose to impl it with Castor...
Perfect!!
> >
> > >should be used for finding documents, from the most preferred to
> > the least
> > >preferred
> >
> > If we implement the ProfilerSerivce this way, then there can be only one
> > ProfilerService. Of-course JetspeedProfilerService needs to be
> > modified to
> > handle this functionality (basically, File-System/Resource-URL specific
> > code from JetspeedProfilerService will just go into
> > CastorPsmlManagerService) and then we can live with only one
> > ProfilerService...(no separate DatabaseProfilerService or
> > LDAPProfilerService)...., we don't have to code "Fallback
> > algorithm" in all
> > different Profiler Services, only Persistence will change...File
> > system/Database/LDAP. And then we just use any PsmlManagerService as we
> > want which can be CastorPsmlManagerService or
> > DatabasePsmlManagerService or
> > LDAPPsmlManagerService.
>
>
>Yes, like that.
>Hope to commit the profiler/psmlmanager mods in the next day or so.
>Please take a look at the new interfaces in the PSMLManager, and let me know
>if you think they will work for you.
The interfaces look perfect. But got a doubt about the "FallBack Algo." How
are you handling it for FilePsmlManagerService? Can we have a generic fall
back algorithm? New ProfileLocator object has made it a lot simpler..
Here is what I feel:
public class GenericPsmlManagerService implements PsmlManagerService {
// Uses Template Method pattern.
public PSMLDocument fallback(List locators) {
// implementation
Algo {
// Will invoke public PSMLDocument getDocument(
ProfileLocator locator ) method from sub-class.
}
}
}
public class DatabasePsmlManagerService extends GenericPsmlManagerService {
// impl.
}
public class FilePsmlManagerService extends GenericPsmlManagerService {
// impl.
}
It will be great, if you can please, comment on above..
>There is no reason why you can't start writing the
Yes, and we are now working on that right away. We are trying to leverage
Turbine DB Schema for the Database service. I will keep you posted on our
development here...
>DatabasePsmlManagerService, although it will be dependent on my changes to
>the JetspeedProfilerService for fully integrated testing.
Sounds great and looking forward to it..
-Atul
>-David
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Putting .psml/markup info into database
Posted by Atul Dambalkar <ad...@cisco.com>.
Hi Raphael,
At 09:44 AM 7/11/01 +0200, you wrote:
>Atul Dambalkar wrote:
>
>>At 10:50 AM 7/10/01 +0200, you wrote:
>>
>>>
>>>Check these:
>>>
>>>http://castor.exolab.org/xml-mapping.html
>>>
>>>http://castor.exolab.org/jdo.html
>>
>>Sure...Thanks for the pointers.
>>They have really a good example code.
>>Are those Castor Mapping files ready yet? When I looked at the
>>CastorPsmlManager it does use the Castor Unmarshelling..but doesn't use
>>any mapping file... If those mapping files are ready, can you point me to
>>that..we can directly start using that.
>
>
>There's no mapping file for PSML now but there is one for the Registry
>/WEB-INF/conf/registry.xml
okay.
>>>I globally agree except than I *do* think that some users may need alternate
>>>
>>>Profiler implementation if they want to implement advanced adaptative
>>>profiling
>>
>>Okay, but then in that case, they definitely need to implement there own
>>ProfilerService..and also the PsmlManager has to be implmented for any
>>additional things.
>
>
>I don't think PsmlManager and Profiler should tied directly. The coupling
>between the 2 services is done through the Profile interface and Profile
>implementation. If you don't change the Profile interface there's no reason
>to update PsmlManager when you update Profiler.
I guess, one may or may not have to implement PsmlManager. Of-course we
would prefer "not".
-Atul
>--
>Raphael Luta - raphael.luta@networks.groupvu.com
>Vivendi Universal Networks - Paris
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Putting .psml/markup info into database
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Atul Dambalkar wrote:
>
> At 10:50 AM 7/10/01 +0200, you wrote:
>
>>
>> Check these:
>>
>> http://castor.exolab.org/xml-mapping.html
>>
>> http://castor.exolab.org/jdo.html
>
>
> Sure...Thanks for the pointers.
>
> They have really a good example code.
>
> Are those Castor Mapping files ready yet? When I looked at the
> CastorPsmlManager it does use the Castor Unmarshelling..but doesn't use
> any mapping file... If those mapping files are ready, can you point me
> to that..we can directly start using that.
>
There's no mapping file for PSML now but there is one for the Registry
/WEB-INF/conf/registry.xml
>>
>> I globally agree except than I *do* think that some users may need
>> alternate
>>
>> Profiler implementation if they want to implement advanced adaptative
>> profiling
>
>
> Okay, but then in that case, they definitely need to implement there own
> ProfilerService..and also the PsmlManager has to be implmented for any
> additional things.
>
I don't think PsmlManager and Profiler should tied directly. The coupling
between the 2 services is done through the Profile interface and Profile
implementation. If you don't change the Profile interface there's no reason
to update PsmlManager when you update Profiler.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Putting .psml/markup info into database
Posted by Atul Dambalkar <ad...@cisco.com>.
At 10:50 AM 7/10/01 +0200, you wrote:
>Atul Dambalkar wrote:
>
>>At 06:36 PM 7/7/01 +0200, you wrote:
>>
>>>Atul Dambalkar wrote:
>>> >
>>> > At 02:22 PM 7/6/01 -0700, you wrote:
>>> > >Ive started working on this today.
>>> > >Hopefully I can refactor this pretty quickly, by the weekend.
>>> >
>>> > That would be fabulous..and then we can start here on the implementation
>>> > for the DatabasePsmlManagerService. Hopefully, I will have to just follow
>>> > the "config" object (which you are referring below under PsmlManager) to
>>> > handle the database interactions.
>>> >
>>>
>>>Yes, the intitial idea is also to rewrite the CastorPsmlManager
>>>implementation
>>>to use the Castor mapping files rather than a generated API (just like
>>>the registry
>>>does). The same Castor mapping file can be used to describe both the xml
>>>persistence
>>>schema and the DBMS or LDAP persistence schema and if the DBMS, LDAP and
>>>XML impl are
>>>all based on Castor, it's very easy to provide upgrade paths from XML ->
>>>DBMS/LDAP.
>>
>>Please, educate me here. What are Castor mapping files? Where are they
>>located and how they are used?
>
>
>Check these:
>
>http://castor.exolab.org/xml-mapping.html
>
>http://castor.exolab.org/jdo.html
Sure...Thanks for the pointers.
They have really a good example code.
Are those Castor Mapping files ready yet? When I looked at the
CastorPsmlManager it does use the Castor Unmarshelling..but doesn't use any
mapping file... If those mapping files are ready, can you point me to
that..we can directly start using that.
>>Here is what I feel: (Feel free to correct me or fill in any missing bit
>>of information as you guys definitely know the exact flow and the side
>>effects..)
>>0. Turbine invokes SessionValidator object in Jetspeed.
>>1. Profiler(Service) gets invoked from the
>>org.apache.jetspeed.modules.actions.JetspeedSessionValidator
>>2. Profiler creates the ordered list of ProfileLocator objets (as you said)
>>3. Turbine invokes the profile from the RunData object, and renders the
>>page...
>
>
>Not exactly, Turbine invokes the screenTemplate selected by the request. If no
>screen is selected, the default template is used. This template uses the
>JetspeedTool to load and render a pane resource defined in a PSMLDOcument
>which
>is referenced by the Profile object.
Okay, great. That definitely helps me understand the flow.
>>4. In this case the implementation of the method "PSMLDocument
>>getDocument()" in class org.apache.jetspeed.om.profile.BaseProfile needs
>>to be changed or overridden to the one which uses,
>>PsmlManager.fallback(Locators)..
>>5. Modify couple of methods in CastorPsmlManagerService viz.
>>getDocument(String url) to handle Locator objects.
>>6. Implement DatabasePsmlManagerService or LDAPPsmlManagerService,
>>transperant to ProfilerService
>
>
>Yes, that's the way it should work.
>
>
>>I just did a CVS update, looked at the updated code, cool stuff, looks
>>perfect to me and think we are on right track, except the
>>JetspeedProfilerService, which I think, needs modification.
>>
>>>should be used for finding documents, from the most preferred to the
>>>least preferred
>>
>>If we implement the ProfilerSerivce this way, then there can be only one
>>ProfilerService. Of-course JetspeedProfilerService needs to be modified
>>to handle this functionality (basically, File-System/Resource-URL
>>specific code from JetspeedProfilerService will just go into
>>CastorPsmlManagerService) and then we can live with only one
>>ProfilerService...(no separate DatabaseProfilerService or
>>LDAPProfilerService)...., we don't have to code "Fallback algorithm" in
>>all different Profiler Services, only Persistence will change...File
>>system/Database/LDAP. And then we just use any PsmlManagerService as we
>>want which can be CastorPsmlManagerService or DatabasePsmlManagerService
>>or LDAPPsmlManagerService.
>>What do you guys think on this?
>
>
>I globally agree except than I *do* think that some users may need alternate
>
>Profiler implementation if they want to implement advanced adaptative
>profiling
Okay, but then in that case, they definitely need to implement there own
ProfilerService..and also the PsmlManager has to be implmented for any
additional things.
-Atul
>systems.
>
>--
>Raphael Luta - raphael.luta@networks.groupvu.com
>Vivendi Universal Networks - Paris
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Putting .psml/markup info into database
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Atul Dambalkar wrote:
> At 06:36 PM 7/7/01 +0200, you wrote:
>
>> Atul Dambalkar wrote:
>> >
>> > At 02:22 PM 7/6/01 -0700, you wrote:
>> > >Ive started working on this today.
>> > >Hopefully I can refactor this pretty quickly, by the weekend.
>> >
>> > That would be fabulous..and then we can start here on the
>> implementation
>> > for the DatabasePsmlManagerService. Hopefully, I will have to just
>> follow
>> > the "config" object (which you are referring below under
>> PsmlManager) to
>> > handle the database interactions.
>> >
>>
>> Yes, the intitial idea is also to rewrite the CastorPsmlManager
>> implementation
>> to use the Castor mapping files rather than a generated API (just like
>> the registry
>> does). The same Castor mapping file can be used to describe both the
>> xml persistence
>> schema and the DBMS or LDAP persistence schema and if the DBMS, LDAP
>> and XML impl are
>> all based on Castor, it's very easy to provide upgrade paths from XML
>> -> DBMS/LDAP.
>
>
> Please, educate me here. What are Castor mapping files? Where are they
> located and how they are used?
>
Check these:
http://castor.exolab.org/xml-mapping.html
http://castor.exolab.org/jdo.html
> Here is what I feel: (Feel free to correct me or fill in any missing bit
> of information as you guys definitely know the exact flow and the side
> effects..)
> 0. Turbine invokes SessionValidator object in Jetspeed.
> 1. Profiler(Service) gets invoked from the
> org.apache.jetspeed.modules.actions.JetspeedSessionValidator
> 2. Profiler creates the ordered list of ProfileLocator objets (as you said)
> 3. Turbine invokes the profile from the RunData object, and renders the
> page...
Not exactly, Turbine invokes the screenTemplate selected by the request. If no
screen is selected, the default template is used. This template uses the
JetspeedTool to load and render a pane resource defined in a PSMLDOcument which
is referenced by the Profile object.
> 4. In this case the implementation of the method "PSMLDocument
> getDocument()" in class org.apache.jetspeed.om.profile.BaseProfile needs
> to be changed or overridden to the one which uses,
> PsmlManager.fallback(Locators)..
> 5. Modify couple of methods in CastorPsmlManagerService viz.
> getDocument(String url) to handle Locator objects.
> 6. Implement DatabasePsmlManagerService or LDAPPsmlManagerService,
> transperant to ProfilerService
>
Yes, that's the way it should work.
> I just did a CVS update, looked at the updated code, cool stuff, looks
> perfect to me and think we are on right track, except the
> JetspeedProfilerService, which I think, needs modification.
>
>> should be used for finding documents, from the most preferred to the
>> least preferred
>
>
> If we implement the ProfilerSerivce this way, then there can be only one
> ProfilerService. Of-course JetspeedProfilerService needs to be modified
> to handle this functionality (basically, File-System/Resource-URL
> specific code from JetspeedProfilerService will just go into
> CastorPsmlManagerService) and then we can live with only one
> ProfilerService...(no separate DatabaseProfilerService or
> LDAPProfilerService)...., we don't have to code "Fallback algorithm" in
> all different Profiler Services, only Persistence will change...File
> system/Database/LDAP. And then we just use any PsmlManagerService as we
> want which can be CastorPsmlManagerService or DatabasePsmlManagerService
> or LDAPPsmlManagerService.
>
> What do you guys think on this?
>
I globally agree except than I *do* think that some users may need alternate
Profiler implementation if they want to implement advanced adaptative profiling
systems.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Putting .psml/markup info into database
Posted by David Sean Taylor <da...@b3interactive.com>.
Hi Atul,
Im travelling today, and Im having trouble getting my usual email, so Im on
a different account today...
>
> Please, educate me here. What are Castor mapping files? Where are they
> located and how they are used?
>
> >
> >interface Profile
> >{
> > PSMLDocument getDocument()
> > ProfileLocator getLocator()
> >}
> >
> >or like this
> >
> >interface Profile extends ProfileLocator
> >{
> > PSMLDocument getDocument()
> >}
> >
> >I like the second solution best, it's not as clean as the first
> but easier
> >to use...
>
> I also like the second approach.
>
Done, its in the cvs.
>
> >The Profiler would still have to code the fallback algorithm but instead
> >of actually
> >looking for the resource it would just build an ordered list of Locator
> >objects which
>
> That's what I meant in my previous emails, not exactly though...about
> separating "Fallback Algorithm" in one (may not be super) class and
> everyone will just use the same ProfilerService... We don't want to
> replicate "Fallback Algorithm"
>
> Here is what I feel: (Feel free to correct me or fill in any
> missing bit of
> information as you guys definitely know the exact flow and the
> side effects..)
> 0. Turbine invokes SessionValidator object in Jetspeed.
> 1. Profiler(Service) gets invoked from the
> org.apache.jetspeed.modules.actions.JetspeedSessionValidator
> 2. Profiler creates the ordered list of ProfileLocator objets (as
> you said)
> 3. Turbine invokes the profile from the RunData object, and
> renders the page...
> 4. In this case the implementation of the method "PSMLDocument
> getDocument()" in class
> org.apache.jetspeed.om.profile.BaseProfile needs to
> be changed or overridden to the one which uses,
> PsmlManager.fallback(Locators)..
> 5. Modify couple of methods in CastorPsmlManagerService viz.
> getDocument(String url) to handle Locator objects.
> 6. Implement DatabasePsmlManagerService or LDAPPsmlManagerService,
> transperant to ProfilerService
>
> I just did a CVS update, looked at the updated code, cool stuff, looks
> perfect to me and think we are on right track, except the
> JetspeedProfilerService, which I think, needs modification.
Im in the middle of working on it. I tried to commit the interfaces so that
you could see them first.
The code that is specific to the file system still needs to be migrated out
of the JetspeedProfiler and over into the CastorPsmlManagerServer.
Or perhaps it should be called the FilePsmlManagerService, since for the
DatabasePsmlManagerService, you may also choose to impl it with Castor...
>
> >should be used for finding documents, from the most preferred to
> the least
> >preferred
>
> If we implement the ProfilerSerivce this way, then there can be only one
> ProfilerService. Of-course JetspeedProfilerService needs to be
> modified to
> handle this functionality (basically, File-System/Resource-URL specific
> code from JetspeedProfilerService will just go into
> CastorPsmlManagerService) and then we can live with only one
> ProfilerService...(no separate DatabaseProfilerService or
> LDAPProfilerService)...., we don't have to code "Fallback
> algorithm" in all
> different Profiler Services, only Persistence will change...File
> system/Database/LDAP. And then we just use any PsmlManagerService as we
> want which can be CastorPsmlManagerService or
> DatabasePsmlManagerService or
> LDAPPsmlManagerService.
Yes, like that.
Hope to commit the profiler/psmlmanager mods in the next day or so.
Please take a look at the new interfaces in the PSMLManager, and let me know
if you think they will work for you.
There is no reason why you can't start writing the
DatabasePsmlManagerService, although it will be dependent on my changes to
the JetspeedProfilerService for fully integrated testing.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Putting .psml/markup info into database
Posted by Atul Dambalkar <ad...@cisco.com>.
At 06:36 PM 7/7/01 +0200, you wrote:
>Atul Dambalkar wrote:
> >
> > At 02:22 PM 7/6/01 -0700, you wrote:
> > >Ive started working on this today.
> > >Hopefully I can refactor this pretty quickly, by the weekend.
> >
> > That would be fabulous..and then we can start here on the implementation
> > for the DatabasePsmlManagerService. Hopefully, I will have to just follow
> > the "config" object (which you are referring below under PsmlManager) to
> > handle the database interactions.
> >
>
>Yes, the intitial idea is also to rewrite the CastorPsmlManager implementation
>to use the Castor mapping files rather than a generated API (just like the
>registry
>does). The same Castor mapping file can be used to describe both the xml
>persistence
>schema and the DBMS or LDAP persistence schema and if the DBMS, LDAP and
>XML impl are
>all based on Castor, it's very easy to provide upgrade paths from XML ->
>DBMS/LDAP.
Please, educate me here. What are Castor mapping files? Where are they
located and how they are used?
> >
> > Yep, that's what we need. This is now really getting interesting. I am
> > looking forward to the new ProfileLocator interface ..
> >
>
>
>Well, the new ProfileLocator interface would be trivial:
>
>interface ProfileLocator
>{
> get/setMediaType()
> get/setLanguage()
> get/setRole()
> get/setUser()
> get/setName()
>}
>
>basically it's just a transport for all the possible PSML search criteria
>
>A complete Profile object would associate a Locator with a document, either
>like this
>
>interface Profile
>{
> PSMLDocument getDocument()
> ProfileLocator getLocator()
>}
>
>or like this
>
>interface Profile extends ProfileLocator
>{
> PSMLDocument getDocument()
>}
>
>I like the second solution best, it's not as clean as the first but easier
>to use...
I also like the second approach.
>The Profiler would still have to code the fallback algorithm but instead
>of actually
>looking for the resource it would just build an ordered list of Locator
>objects which
That's what I meant in my previous emails, not exactly though...about
separating "Fallback Algorithm" in one (may not be super) class and
everyone will just use the same ProfilerService... We don't want to
replicate "Fallback Algorithm"
Here is what I feel: (Feel free to correct me or fill in any missing bit of
information as you guys definitely know the exact flow and the side effects..)
0. Turbine invokes SessionValidator object in Jetspeed.
1. Profiler(Service) gets invoked from the
org.apache.jetspeed.modules.actions.JetspeedSessionValidator
2. Profiler creates the ordered list of ProfileLocator objets (as you said)
3. Turbine invokes the profile from the RunData object, and renders the page...
4. In this case the implementation of the method "PSMLDocument
getDocument()" in class org.apache.jetspeed.om.profile.BaseProfile needs to
be changed or overridden to the one which uses,
PsmlManager.fallback(Locators)..
5. Modify couple of methods in CastorPsmlManagerService viz.
getDocument(String url) to handle Locator objects.
6. Implement DatabasePsmlManagerService or LDAPPsmlManagerService,
transperant to ProfilerService
I just did a CVS update, looked at the updated code, cool stuff, looks
perfect to me and think we are on right track, except the
JetspeedProfilerService, which I think, needs modification.
>should be used for finding documents, from the most preferred to the least
>preferred
If we implement the ProfilerSerivce this way, then there can be only one
ProfilerService. Of-course JetspeedProfilerService needs to be modified to
handle this functionality (basically, File-System/Resource-URL specific
code from JetspeedProfilerService will just go into
CastorPsmlManagerService) and then we can live with only one
ProfilerService...(no separate DatabaseProfilerService or
LDAPProfilerService)...., we don't have to code "Fallback algorithm" in all
different Profiler Services, only Persistence will change...File
system/Database/LDAP. And then we just use any PsmlManagerService as we
want which can be CastorPsmlManagerService or DatabasePsmlManagerService or
LDAPPsmlManagerService.
What do you guys think on this?
-Atul
>and the PsmlManager implementation will check and return the first
>document available.
>
>--
>Raphaël Luta - luta.raphael@networks.vivendi.net
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Putting .psml/markup info into database
Posted by ra...@networks.groupvu.com.
Atul Dambalkar wrote:
>
> At 02:22 PM 7/6/01 -0700, you wrote:
> >Ive started working on this today.
> >Hopefully I can refactor this pretty quickly, by the weekend.
>
> That would be fabulous..and then we can start here on the implementation
> for the DatabasePsmlManagerService. Hopefully, I will have to just follow
> the "config" object (which you are referring below under PsmlManager) to
> handle the database interactions.
>
Yes, the intitial idea is also to rewrite the CastorPsmlManager implementation
to use the Castor mapping files rather than a generated API (just like the registry
does). The same Castor mapping file can be used to describe both the xml persistence
schema and the DBMS or LDAP persistence schema and if the DBMS, LDAP and XML impl are
all based on Castor, it's very easy to provide upgrade paths from XML -> DBMS/LDAP.
>
> Yep, that's what we need. This is now really getting interesting. I am
> looking forward to the new ProfileLocator interface ..
>
Well, the new ProfileLocator interface would be trivial:
interface ProfileLocator
{
get/setMediaType()
get/setLanguage()
get/setRole()
get/setUser()
get/setName()
}
basically it's just a transport for all the possible PSML search criteria
A complete Profile object would associate a Locator with a document, either
like this
interface Profile
{
PSMLDocument getDocument()
ProfileLocator getLocator()
}
or like this
interface Profile extends ProfileLocator
{
PSMLDocument getDocument()
}
I like the second solution best, it's not as clean as the first but easier to use...
The Profiler would still have to code the fallback algorithm but instead of actually
looking for the resource it would just build an ordered list of Locator objects which
should be used for finding documents, from the most preferred to the least preferred
and the PsmlManager implementation will check and return the first document available.
--
Raphaël Luta - luta.raphael@networks.vivendi.net
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Build broken...
Posted by Meik Arends <me...@arends-online.de>.
Atul Dambalkar wrote:
> I just now updated CVS HEAD. Build is broken...
>
> ========================================
> [javac]
> /home/adambalk/jakarta-jetspeed/src/java/org/apache/jetspeed/modules/actions/portlets/security/UserRoleUpdateAction.java:244:
> cannot resolve symbol
> [javac] symbol : variable JETSPEED_GROUP
> [javac] location: class org.apache.jetspeed.services.JetspeedSecurity
> [javac] JetspeedSecurity.getGroup(JetspeedSecurity.JETSPEED_GROUP),
> [javac] ^
I got the same errors ..
--
----------------------------------------------------------------
Meik Arends
meik@arends-online.de
WAP-Mail: wap@arends-online.de ( für wirklich dringendes ;-)
Email-Zertifikat unter http://trust.web.de/root.sql
ICQ: 42486557
----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Build broken...
Posted by David Sean Taylor <da...@bluesunrise.com>.
> I just now updated CVS HEAD. Build is broken...
Its updated, missing 2 files from last night's commits. Please try again.
services/JetspeedSecurity.java,
services/security/JetspeedDBSecurityService.java
-david
> -----Original Message-----
> From: Atul Dambalkar [mailto:adambalk@cisco.com]
> Sent: Friday, July 06, 2001 3:01 PM
> To: jetspeed-dev@jakarta.apache.org
> Subject: Build broken...
>
>
> I just now updated CVS HEAD. Build is broken...
>
> ========================================
> [javac]
> /home/adambalk/jakarta-jetspeed/src/java/org/apache/jetspeed/m
> odules/actions/portlets/security/UserRoleUpdateAction.java:244:
> cannot resolve symbol
> [javac] symbol : variable JETSPEED_GROUP
> [javac] location: class
> org.apache.jetspeed.services.JetspeedSecurity
> [javac]
> JetspeedSecurity.getGroup(JetspeedSecurity.JETSPEED_GROUP),
> [javac]
> ^
> [javac]
> /home/adambalk/jakarta-jetspeed/src/java/org/apache/jetspeed/m
> odules/actions/portlets/security/UserRoleUpdateAction.java:251:
> cannot resolve symbol
> [javac] symbol : variable JETSPEED_GROUP
> [javac] location: class
> org.apache.jetspeed.services.JetspeedSecurity
> [javac]
> JetspeedSecurity.getGroup(JetspeedSecurity.JETSPEED_GROUP),
> [javac]
> ^
> [javac]
> /home/adambalk/jakarta-jetspeed/src/java/org/apache/jetspeed/m
> odules/actions/portlets/security/UserRoleUpdateAction.java:322:
> cannot resolve symbol
> [javac] symbol : variable JETSPEED_GROUP
> [javac] location: class
> org.apache.jetspeed.services.JetspeedSecurity
> [javac] Group jetGroup =
> JetspeedSecurity.getGroup(JetspeedSecurity.JETSPEED_GROUP);
> [javac]
> ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -deprecation for details.
> [javac] 3 errors
>
> BUILD FAILED
>
> /home/adambalk/jakarta-jetspeed/build/build.xml:175: Compile failed,
> messages should have been provided.
> =====================================================
>
> -Atul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Build broken...
Posted by Atul Dambalkar <ad...@cisco.com>.
I just now updated CVS HEAD. Build is broken...
========================================
[javac]
/home/adambalk/jakarta-jetspeed/src/java/org/apache/jetspeed/modules/actions/portlets/security/UserRoleUpdateAction.java:244:
cannot resolve symbol
[javac] symbol : variable JETSPEED_GROUP
[javac] location: class org.apache.jetspeed.services.JetspeedSecurity
[javac]
JetspeedSecurity.getGroup(JetspeedSecurity.JETSPEED_GROUP),
[javac]
^
[javac]
/home/adambalk/jakarta-jetspeed/src/java/org/apache/jetspeed/modules/actions/portlets/security/UserRoleUpdateAction.java:251:
cannot resolve symbol
[javac] symbol : variable JETSPEED_GROUP
[javac] location: class org.apache.jetspeed.services.JetspeedSecurity
[javac]
JetspeedSecurity.getGroup(JetspeedSecurity.JETSPEED_GROUP),
[javac]
^
[javac]
/home/adambalk/jakarta-jetspeed/src/java/org/apache/jetspeed/modules/actions/portlets/security/UserRoleUpdateAction.java:322:
cannot resolve symbol
[javac] symbol : variable JETSPEED_GROUP
[javac] location: class org.apache.jetspeed.services.JetspeedSecurity
[javac] Group jetGroup =
JetspeedSecurity.getGroup(JetspeedSecurity.JETSPEED_GROUP);
[javac]
^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 3 errors
BUILD FAILED
/home/adambalk/jakarta-jetspeed/build/build.xml:175: Compile failed,
messages should have been provided.
=====================================================
-Atul
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: RE: Putting .psml/markup info into database
Posted by Atul Dambalkar <ad...@cisco.com>.
At 02:22 PM 7/6/01 -0700, you wrote:
>Atul Dambalkar wrote:
> > BTW, what is your opinion on, moving the "fallback" algorithm
> > specific code
> > to some super class and reusing it in the respective sub classes
> > (FileSystemProfilerService/DatabaseProfilerService...)? Or
> > another approach
> > would as I am outlining below that, to create method
> > signatures in such a
> > way that the current ResourceURL/file paths get entirely
> > eliminated and
> > then the PSML location (file system/database/ldap) will be totally
> > transparent to PsmlManagerService.
>
>Yes, that is the plan.
>I am now looking at either enhancing the Profile object or creating a new
>ProfileLocator object for setting criteria for searching
Great!
>I originally thought the fallback algorithm would be generic, but in
>practice Im finding out that it can differ for different impls.
That is quite possible.
>The ResourceURL/file paths should not surface in the interfaces.
Perfect.
>We are moving towards that with the Profile and the new ProfileLocator
>interfaces
>
> >
> >
> > > > 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.
> > >
> > >I hope not....I thought I removed that stuff
> >
> > Nope, its still there in CVS HEAD which I extracted on Jul-3,
> > 14.53 PST.
> >
>
>The customizer is a candidate for complete rewrite ...
>I'd like to see a new customizer written with velocity and pull tools.
>This should be possible soon but we still have some work to complete first,
>such as interfaces (OM API) for PSML.
> >
> > > >
> > > > 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.
> > >
> > >I will add some new methods to the Profiler interface for
> > listing profiles
> > >(there can be more than one profile per user...)
> > >This shouldn't be too much work, but they will necessary in order to
> > >customize all profiles.
> > >Will also move out the template location methods -- perhaps into a
> > >TemplateLocator service.
> >
> > What is the time line that you are looking for this, to commit?
> >
>
>Ive started working on this today.
>Hopefully I can refactor this pretty quickly, by the weekend.
That would be fabulous..and then we can start here on the implementation
for the DatabasePsmlManagerService. Hopefully, I will have to just follow
the "config" object (which you are referring below under PsmlManager) to
handle the database interactions.
> >
> > >Im wondering if there is a need for two Profiler services.
> > Perhaps much of
> > >the Profiler functionality, such as searching thru
> > directories, should be
> > >moved down into the CastorPsmlManagerService (and
> > >DatabasePsmlManagerService). The Profiler should not be
> > aware of the file
> > >system.
> >
> > That's perfect. In that case, we need to modify
> > PsmlManagerService for
> > method signatures to handle extracting the PSML information
> > independent of
> > any location...file system/database/ldap.. something like..
> > PSMLDocument getDocument(type (user/role/group), entity
> > (username/rolename/groupname), mediatype, language,
> > resourcename) which can
>
>Yes, this is from a discussion with Raphael a while back:
>
> Profiler
> request parameters ---------------+---------------> Profile (config
>locator)
>
> PsmlManager
>
> Profile ----------------+-------------------------> PSMLDocument (config)
Yep, that's what we need. This is now really getting interesting. I am
looking forward to the new ProfileLocator interface ..
-Atul
> > also adequately handle Database queries..
> > and so CastorPsmlManagerService also has to be modified to
> > handle these new
> > methods. Similarly DatabasePsmlManagerService will implement
> > those methods
> > to query the database.
> >
> >
> > >Perhaps we should move this discussion to
> > jetspeed-dev@jakarta-apache.org
> >
> > Sure, now it is.
> >
> > -Atul
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: RE: Putting .psml/markup info into database
Posted by David Sean Taylor <da...@bluesunrise.com>.
Atul Dambalkar wrote:
> BTW, what is your opinion on, moving the "fallback" algorithm
> specific code
> to some super class and reusing it in the respective sub classes
> (FileSystemProfilerService/DatabaseProfilerService...)? Or
> another approach
> would as I am outlining below that, to create method
> signatures in such a
> way that the current ResourceURL/file paths get entirely
> eliminated and
> then the PSML location (file system/database/ldap) will be totally
> transparent to PsmlManagerService.
Yes, that is the plan.
I am now looking at either enhancing the Profile object or creating a new
ProfileLocator object for setting criteria for searching
I originally thought the fallback algorithm would be generic, but in
practice Im finding out that it can differ for different impls.
The ResourceURL/file paths should not surface in the interfaces.
We are moving towards that with the Profile and the new ProfileLocator
interfaces
>
>
> > > 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.
> >
> >I hope not....I thought I removed that stuff
>
> Nope, its still there in CVS HEAD which I extracted on Jul-3,
> 14.53 PST.
>
The customizer is a candidate for complete rewrite ...
I'd like to see a new customizer written with velocity and pull tools.
This should be possible soon but we still have some work to complete first,
such as interfaces (OM API) for PSML.
>
> > >
> > > 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.
> >
> >I will add some new methods to the Profiler interface for
> listing profiles
> >(there can be more than one profile per user...)
> >This shouldn't be too much work, but they will necessary in order to
> >customize all profiles.
> >Will also move out the template location methods -- perhaps into a
> >TemplateLocator service.
>
> What is the time line that you are looking for this, to commit?
>
Ive started working on this today.
Hopefully I can refactor this pretty quickly, by the weekend.
>
> >Im wondering if there is a need for two Profiler services.
> Perhaps much of
> >the Profiler functionality, such as searching thru
> directories, should be
> >moved down into the CastorPsmlManagerService (and
> >DatabasePsmlManagerService). The Profiler should not be
> aware of the file
> >system.
>
> That's perfect. In that case, we need to modify
> PsmlManagerService for
> method signatures to handle extracting the PSML information
> independent of
> any location...file system/database/ldap.. something like..
> PSMLDocument getDocument(type (user/role/group), entity
> (username/rolename/groupname), mediatype, language,
> resourcename) which can
Yes, this is from a discussion with Raphael a while back:
Profiler
request parameters ---------------+---------------> Profile (config
locator)
PsmlManager
Profile ----------------+-------------------------> PSMLDocument (config)
> also adequately handle Database queries..
> and so CastorPsmlManagerService also has to be modified to
> handle these new
> methods. Similarly DatabasePsmlManagerService will implement
> those methods
> to query the database.
>
>
> >Perhaps we should move this discussion to
> jetspeed-dev@jakarta-apache.org
>
> Sure, now it is.
>
> -Atul
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org