perfsonar development work

[Maciej Glowiak <>]

Maciej Glowiak wrote:
> Jeff W. Boote wrote:
> > Maciej Glowiak wrote:
> > > But that's the minor problem. The major one is that in our classes 
> > > PerfSONARException is not handled!
> > >
> > > See two main interfaces:
> > >
> > >
> > > a) MessageHandler
> > >
> > >        public Message execute(Message reqMessage)
> > >            throws SystemException,ResourceException,
> > >                   DataFormatException,RequestException;
> > >
> > > b) ServiceEngine
> > >
> > >     public Message takeAction(String actionType, Message request)
> > >         throws SystemException, ResourceException,
> > >                DataFormatException, RequestException;
> > >
> > > Both do not support PerfSONARException, so if I get 
> > > PerfSONARException inside my XmlLSServiceEngine I need to catch it 
> > > and convert to for instance SystemException. That doesn't make sense :(
> >
> > Ok, Now I understand the issue. It was not clear for me before. Thank 
> > you for explaining it.
> >
> > I agree that it makes sense to changes these methods to throw the 
> > PerfSONARException exception (and leave the sub-classes out of it).
> >
> > I also would not be against deprecating the sub-classes to encourage 
> > developers to stop using them. (I agree that sub-classes with no 
> > additional functionality don't make sense.) I would not be in favor of 
> > just removing them without a transition period.
> >
> > The only reason I can see to perhaps keep them, is if we plan on 
> > adding functionality to any of them. For example, it is possible the 
> > AuthenticationException could be extended to access some of the Auth 
> > headers - and specific functionality could be added there to decode 
> > the auth headers and report a more specific error message. (User-id - 
> > any other fields from the cert...)
> >
> > But, it probably makes sense to not use these sub-classes unless/until 
> > they have been extended.
> >
> > > Neither am I, but it'll need cooperation from other developers. I can 
> > > change interfaces and their implementations of SVN, but developers 
> > > should be aware of potential problems (shouldn't be any in fact) and 
> > > check their services. Until now I haven't get any response from 
> > > developers' side (except Roman), so...
> >
> > I would suggest announcing a time in the future that you intend to 
> > make the change unless there are dissenting opinions raised. (I 
> > recommend at least a week to give people enough time to respond. With 
> > time-zone issues and travel schedules less time than that can be a 
> > problem.)
> >
> > As long as you make the change such that it does not 'break' code (by 
> > deprecating instead of removing for example), I think this is totally 
> > reasonable.
> >
> > jeff
>
>
> Hi Jeff,
>
> Deprecating those classes is great idea, I don't know why I haven't 
> thought about it before :)
>
> Surely I don't want to 'break' the code, so I will mark all those 
> classes as "deprecated" and then just change interfaces and their 
> implementations. Then we may consider removing some Exceptions after 
> some time.
>
> I think the deadline for comments, suggestions etc. could be 6th of May. 
> After this date I'll make changes.
>
> Best regards
> Maciej

Hi All,

As agreed on the mailing list and Salvador meeting I will be proceeding 
changes in interfaces (as described above) today (and next days). I'll 
try not to break the code by marking old exceptions as "deprecated", but 
you should be aware that the functionality of some of your services 
should be upgraded.

Best regards

Maciej


--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024          -- skype_id: maciej_psnc   GG: 4526858 ||
 ====================================================================