You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@osm.net> on 2001/12/07 16:12:40 UTC
ExcaliburComponentManager
ExcaliburComponentManager - some of the methods don't throw the exception
declared under their respective interfaces.
public void initialize( ) // doesn't throw Exception
public void contextualize( final Context context ) // doesn't throw
ContextException
These two omissions result in compilation errors under JDK1.4b3.
Steve.
Stephen J. McConnell, OSM sarl
digital products for global business
http://www.osm.net
mailto:mcconnell@osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> ExcaliburComponentManager - some of the methods don't throw the exception
> declared under their respective interfaces.
>
> public void initialize( ) // doesn't throw Exception
> public void contextualize( final Context context ) // doesn't throw
> ContextException
>
> These two omissions result in compilation errors under JDK1.4b3.
The ExcaliburComponentManager along with the entire Excalibur tree is
scheduled to be focused on after the Framework release.
Now, I am running JDK 1.4b3, and I am not receiving those errors. Could
you give me the build log?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExcaliburComponentManager
Posted by Stephen McConnell <mc...@osm.net>.
> From: Peter Donald wtote:
On Sat, 8 Dec 2001 09:33, Stephen McConnell wrote:
> > Conclusion ... should ECM throw the classic lifecycle exceptions or
> > not?
>
> +1 for throwing
me too
> > As it stands its easier to work with but its not useful for
> > extension. Its not a big deal because we (OSM) can do what we want
> > with DefaultComponentManager (as distinct from the LifecycleHelper
> > issue that I still need to battle with Pete about and the
> > PhoenixServlet issue which is basically a lack of documentation
> > problem - both of which I'll get to sometime soon).
>
> ;)
What are you smiling about - I'm preparing my case!
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManager
Posted by Peter Donald <pe...@apache.org>.
On Sat, 8 Dec 2001 09:33, Stephen McConnell wrote:
> Conclusion ... should ECM throw the classic lifecycle exceptions or
> not?
+1 for throwing
> As it stands its easier to work with but its not useful for
> extension. Its not a big deal because we (OSM) can do what we want
> with DefaultComponentManager (as distinct from the LifecycleHelper
> issue that I still need to battle with Pete about and the
> PhoenixServlet issue which is basically a lack of documentation
> problem - both of which I'll get to sometime soon).
;)
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExcaliburComponentManager
Posted by Stephen McConnell <mc...@osm.net>.
Berin:
Reply in-line down below somewhere.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
> > Leo:
> >
> > The error occurred when creating a class that extended
> > ExcaliburComponentManager - the derived class contained
> > implementations of the initalize or contextualize methods
> > corresponding to the Initializable and Contextualizable
> > interfaces. The compiler complained because my new
> > class was declaring the exceptions (I was including the
> > respective throws clause). So, to be absolute correct - the
> > compilation error was on my class - not
> > ExcaliburComponentManager. However, the compilation error
> > arrived because ExcaliburComponentManager implementation
> > doesn't declare the respective exceptions.
> >
> > What is interesting here is that ExcaliburComponentManager
> > implements the Initializable and Composable interfaces
> > without declaring the required exceptions and yet this
> > compiles ok (which I confess I don't understand).
>
> This has to do with inheritance. Java allows you to hide exceptions for
>
> inherited methods, but you cannot add them. This is because the
> super class implementation declares the set of exceptions that it
> will allow. You can get more specific--but you cannot go outside
> that set. Once you eliminate the exception in the inheritance
> hierarchy, you have a super class that has a smaller set than the
> base class. Anything that extends this super class
> now must repect *it's* declared set of exceptions.
>
> The comments in the following heirarchy of classes will help you
> understand.
> The question is, is there a *reason* you want to throw an
> exception from the subclasses of ExcaliburComponentManager or
> are you declaring it to be semantically correct?
(a) the initial situation was that the declaration was made to be
semantically correct
(b) this raised the compilation problem because ECM changes the
definition of what is semantically correct as you and Leo have
pointed out
(c) which led us to ignore ECM in favour of DefaultComponentMnager
because we need to be able to throw an exception
[snip OO tutorial (with the comment that I've been dealing with
interface 98% of the time and this one caught me by surprise) :-)]
Conclusion ... should ECM throw the classic lifecycle exceptions or
not? As it stands its easier to work with but its not useful for
extension. Its not a big deal because we (OSM) can do what we want
with DefaultComponentManager (as distinct from the LifecycleHelper
issue that I still need to battle with Pete about and the
PhoenixServlet issue which is basically a lack of documentation
problem - both of which I'll get to sometime soon).
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Leo:
>
> The error occurred when creating a class that extended
> ExcaliburComponentManager - the derived class contained implementations of
> the initalize or contextualize methods corresponding to the Initializable
> and Contextualizable interfaces. The compiler complained because my new
> class was declaring the exceptions (I was including the respective throws
> clause). So, to be absolute correct - the compilation error was on my
> class - not ExcaliburComponentManager. However, the compilation error
> arrived because ExcaliburComponentManager implementation doesn't declare the
> respective exceptions.
>
> What is interesting here is that ExcaliburComponentManager implements the
> Initializable and Composable interfaces without declaring the required
> exceptions and yet this compiles ok (which I confess I don't understand).
This has to do with inheritance. Java allows you to hide exceptions for
inherited methods, but you cannot add them. This is because the super class
implementation declares the set of exceptions that it will allow. You can
get more specific--but you cannot go outside that set. Once you eliminate
the exception in the inheritance hierarchy, you have a super class that has
a smaller set than the base class. Anything that extends this super class
now must repect *it's* declared set of exceptions.
The comments in the following heirarchy of classes will help you understand.
The question is, is there a *reason* you want to throw an exception from the
subclasses of ExcaliburComponentManager or are you declaring it to be
semantically correct?
class BaseClass
{
/**
* Specifies that it *can* throw an exception. It does not mean that
* it *has* to.
*/
abstract void method() throws Exception;
}
class SuperClass extends BaseClass
{
/**
* This is legal because it is more specific, and does not violate the
* contract specified by BaseClass.
*/
void method() throws IOException;
}
class IllegalClass extends SuperClass
{
/**
* This is not legal because it violates the contract specified in SuperClass
*/
void method() throws SocketException;
}
class NoExceptionClass extends SuperClass
{
/**
* This is legal because exceptions do not need to be thrown, but now no
* other exceptions are allowed to be thrown.
*/
void method();
}
class SecondIllegalClass extends NoExceptionClass
{
/**
* This is not legal because the super class narrowed the contract on
* thrown exceptions to none. If a class was cast as the NoExceptionClass,
* then tried to throw an exception, it would violate the NoExceptionClass
* contract.
*/
void method() throws Exception;
}
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExcaliburComponentManager
Posted by Stephen McConnell <mc...@osm.net>.
From: Leo Sutic wrote:
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> > What is interesting here is that ExcaliburComponentManager
> > implements the
> > Initializable and Composable interfaces without declaring the required
> > exceptions and yet this compiles ok (which I confess I don't
> > understand).
>
> Stephen,
>
> it is a basic thing about OO programming - a subclass should be able to
> stand in for a superclass anywhere. That is, if SuperClass is a superclass
> to SubClass, then:
>
> void myMethod (SuperClass sc) { ... }
>
> ...
>
> myMethod (new SubClass ());
>
> should be valid, as the contract for SuperClass is inherited down to
> SubClass. That is, SubClass must deliver at least as much as SuperClass.
>
> Proceeding with the notion of contracts - each class requires
> something and delivers something. This contract is inherited down the
> hierarchy, and a subclass must not require more and must not deliver
> less than a superclass.
>
> Thus, since Initializable can be seen as a superclass of
> ExcaliburComponentManager, ECM must not require more and must not deliver
> less than Initializable.
>
> Initializable has a method initialize () throws Exception.
>
> Requires: No parameters, ability for caller to handle Exception.
> Delivers: Initializes the class.
>
> Now, when ECM does *not* throw Exception:
>
> Requires: No parameters.
> Delivers: Initializes the class.
>
> So ECM actually requires *less* than Initializable. This is perfectly
> valid - the contract is upheld by the subclass. You class, however, does
> throw an Exception and thus requires *more* than its superclass (ECM).
Leo:
Your quite right - the distinction here is that ECM does not need to throw
an exception relative to its own implementation characteristics. However,
this limits the potential for supertypes because a supertype cannot
introduce anything that would potential raise an exception during initalize.
Conclusion - there isn't a fault in ECM in terms of its own internal
implementation - but elimination of the throws Exception delcaration
effectively eliminates the possibility for supertypes that need this (which
was my case).
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExcaliburComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> What is interesting here is that ExcaliburComponentManager implements the
> Initializable and Composable interfaces without declaring the required
> exceptions and yet this compiles ok (which I confess I don't understand).
Stephen,
it is a basic thing about OO programming - a subclass should be able to
stand in for a superclass anywhere. That is, if SuperClass is a superclass
to SubClass, then:
void myMethod (SuperClass sc) { ... }
...
myMethod (new SubClass ());
should be valid, as the contract for SuperClass is inherited down to
SubClass. That is, SubClass must deliver at least as much as SuperClass.
Proceeding with the notion of contracts - each class requires something and
delivers something. This contract is inherited down the hierarchy, and a
subclass must not require more and must not deliver less than a superclass.
Thus, since Initializable can be seen as a superclass of
ExcaliburComponentManager, ECM must not require more and must not deliver
less than Initializable.
Initializable has a method initialize () throws Exception.
Requires: No parameters, ability for caller to handle Exception.
Delivers: Initializes the class.
Now, when ECM does *not* throw Exception:
Requires: No parameters.
Delivers: Initializes the class.
So ECM actually requires *less* than Initializable. This is perfectly
valid - the contract is upheld by the subclass. You class, however, does
throw an Exception and thus requires *more* than its superclass (ECM).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExcaliburComponentManager
Posted by Stephen McConnell <mc...@osm.net>.
Leo:
The error occurred when creating a class that extended
ExcaliburComponentManager - the derived class contained implementations of
the initalize or contextualize methods corresponding to the Initializable
and Contextualizable interfaces. The compiler complained because my new
class was declaring the exceptions (I was including the respective throws
clause). So, to be absolute correct - the compilation error was on my
class - not ExcaliburComponentManager. However, the compilation error
arrived because ExcaliburComponentManager implementation doesn't declare the
respective exceptions.
What is interesting here is that ExcaliburComponentManager implements the
Initializable and Composable interfaces without declaring the required
exceptions and yet this compiles ok (which I confess I don't understand).
Cheers, Steve.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Friday, 07 December, 2001 16:25
> To: Avalon Developers List
> Subject: RE: ExcaliburComponentManager
>
>
>
>
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> > ExcaliburComponentManager - some of the methods don't throw the
> exception
> > declared under their respective interfaces.
> >
> > public void initialize( ) // doesn't throw Exception
> > public void contextualize( final Context context ) // doesn't throw
> > ContextException
> >
> > These two omissions result in compilation errors under JDK1.4b3.
>
> Interesting. The Java Language Specification 8.4.4 specifies that a method
> that overrides an inherited method may not throw an exception that the
> overridden method does not throw, but does not require it to specify the
> same throws clause. Could you include the compilation errors?
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExcaliburComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> ExcaliburComponentManager - some of the methods don't throw the exception
> declared under their respective interfaces.
>
> public void initialize( ) // doesn't throw Exception
> public void contextualize( final Context context ) // doesn't throw
> ContextException
>
> These two omissions result in compilation errors under JDK1.4b3.
Interesting. The Java Language Specification 8.4.4 specifies that a method
that overrides an inherited method may not throw an exception that the
overridden method does not throw, but does not require it to specify the
same throws clause. Could you include the compilation errors?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>