perfsonar development work

[Stijn Melis <>]

Hi Maciej,


I just checked which Exceptions are used in the implementation of the 
SSH/TelnetMP and I ran into these:

SystemException
RequestException
ResourceException
DataFormatException
PerfSONARException (I only ran into it once)


Regards,

Stijn


Maciej Glowiak wrote:
> Hi Jeff,
>
> Thanks for your response. Read my answer below.
>
> Jeff W. Boote wrote:
> > Maciej Glowiak wrote:
> > > Hi again,
> > >
> > >     after discussion with Roman I realized that perhaps we might get 
> > > rid of other ...Exceptions (SystemException, DataFormatException, 
> > > etc.) than PerfSONARException. All information about the error is now 
> > > inside result code which is a part of PerfSONARException.
> > >
> > > But that small change is in fact serious change that may influent on 
> > > several services, so all service developers based on pS base should 
> > > be aware of that. So the agreement from _Steering Group_ is required.
> >
> > Hi Maciej,
> >
> > Perhaps you could explain what the change would mean for those other 
> > services.
> >
> > I'm not sure I see the advantage/disadvantage of the change. Is it 
> > just code clean-up? If so, couldn't the current Soap Handler catch all 
> > of these exceptions and add generic errors for the ones that do not 
> > have the result code portion? (In fact, doesn't it already?)
> >
> > That would mean a generic error could still be reported to the client, 
> > and individual service developers can be encouraged to change 
> > exceptions to provide more information. But, it would remain a 
> > backwards compatible change then. Right? Or do I misunderstand the issue?
>
>
> There is some inconsistence in our code now. We have our own Exceptions 
> such as:
>
>   SystemException
>   DataFormatException
>   AuthenticationException
>   RequestException
>   ResourceException
>   (maybe I missed one or two)
>
> all of them are sub-classes of PerfSONARException which contains all the 
> "logic" for result codes. Other, mentioned before, exceptions contain 
> only constructors with invocation of PerfSONARException constructors.
>
> So there is a question whether we still need all of these Exceptions if 
> PerfSONARException handles result codes? It is sufficent.
>
> 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 :(
>
> I'd like to change this situation and replace all Exceptions by just 
> PerfSONARException or do it at least in two mentioned methods:
>
> MessageHandler.execute(...)
> ServiceEngine.takeAction(...)
>
>
>
> > Also, I'm not convinced this is an issue for the Steering Group. I 
> > would hope that things at this low of a technical level could be 
> > decided among the developers. If we can't agree, then of course we can 
> > push it up. But, we should at least try to figure it out. It is a 
> > technical issue specifically with the Java implementation, not an 
> > interoperability question - or a matter of resources or politics, right?
>
> 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...
>
> Maciej