perfsonar development work

["Jeff W. Boote" <>]

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