perfsonar development work

[Michael Bischoff <>]

Guilherme Fernandes wrote:
> This happened when we needed the LSRegistrationComponent for the MPs. 
> At that time we only had the 
> org.perfsonar.service.measurementArchive.register one, which was used 
> for the registration of RRD-MA and SQL-MA (the other services didn't 
> register on the LS at that time).
>
> Since the MA's LSRegistrationComponent had ma's specific variables 
> (service.ma.conf_file, component.ma-registrator.scheduler_component, 
> etc), I changed the MA's component to make it generic and put it in 
> base. I know RRD-MA and SQL-MA use the one at 
> measurementArchive.register and I guess the other MA's do too. MP's 
> should be using the one at base.registration, but I'm not sure this is 
> consistent across all.
> > Perhaps one should inherit from the other or should both inherit a 
> > new abstract class, fixes
> > now have to be done in two places. I also believe that difference 
> > isn't documented atm. Also
> > are MA only using ServiceContent's?
> >   
> I agree that there shouldn't be different classes for LSRegistration. 
> The main differences AFAIK are that the one at base can register only 
> the "service.r.*" variables in service.properties, without the need of 
> using file or xmldb, and that the MA's component can update using 
> xmldb (the generic one doesn't support this functionality).
>
> Since the functionality of having xmldb based registration is also 
> useful for some MP services as well, I don't see why both components 
> shouldn't be merged in base. Between, it seems that SSH/Telnet MP also 
> uses eXist for keeping metadata configuration, I don't know which 
> LSRegistrationComponent it is using right now, maybe someone can 
> comment on this?
One seems to use the service.ma.conf_file.store_type the other 
service.ls.registration_file while they both use the 
InformationXMLFileServiceContent. I suggest we can merge the xmldb 
functionality into the base.registration and deprecate the 
measurementArchive one.

> > The reason that I'm working on it is because the current support for 
> > ServiceContent's doesn't
> > fit our needs as a xmldb is overkill and file approach is impractical 
> > so I was coding
> > additional support for a new ServiceContent that takes it's 
> > information from the servlet
> > context.
> >   
> Are you sure the one in base.registration doesn't suffice your needs?
The issue is that the file needs to be updated as the user changes the 
configuration of the service. There are two options, either the service 
administrator has to specify the exact same configuration twice, because 
inconsistencies between the two would lead to obscure bugs and this 
approach is tedious to begin with. That approach isn't really an option. 
The other is to write code that detect changes, compares data in the 
file with the configuration, and writes the file that's in a relative 
path. Which is hack-o-ry and error prone. This could be less painfully 
by calling a servlet of file in memory but there is no absolute path to 
either. which  requires changing  the way the current  
InformationXMLFileServiceContent. (Ok, that wasn't a very clear 
explanation and I probably lost everyone along the way) In short; no it 
doesn't really. On second thought using the ServletContext doesn't 
really fit the perfsonar framework neither, working out a more elegant 
solution, I'll probably get back on that at a later date.

Best regards,

Michael Bischoff