I have a problem declaring a Constant inside a Remote-Interface (using Orion-Application-Server) :
If I declare a Constant like
public static final int MAX = 30;
inside a Remote-Interface in order to let the Client of the EJB use this Constant, I get in trouble ...
When I do so, the Client throws this Exception:
java.lang.ClassFormatError: __Proxy2 (Repeative method name/signature)
This Exception is only thrown, when I declare the Constant in the Remote-Interface. If I remove the Constant out of the Remote-Interface (the Client will not use the Constant in this case), everything works fine.
My Question is now: Does the EJB-Specification (and if so, which Version) prohibites the Declaring of Constants in a Remote-Interface or is it maybe a specific Problem of the Application-Server or do I disregard anything else ...
Any answer is appreciated :-) Thank you in advance ...
upto my knowledge, remote interface only defines the bean methods which are accessible to the clients. And if you want a variable to be set, you can also set it in the bean and put some getter/setter methods in the remote and bean to access from the remote interface to tackle the problem.
first of all thank you for your prompt answer !
Maybe I should explain a little bit more about the Context, in which a Client has access to that Bean:
Let's say you have defined an Interface, which provides Clients with Data. This interface is not only planned to be implemented by EJBs but also by normal Classes / JavaBeans.
The Interface could look like this:
public interface Provider
// Do a Search and deliver the SearchResult by an
public Iterator getHits( Hashtable searchProps )
// Define the allowed searchProperties
public static final int SEARCH_CRITERIAS = 1;
public static final int SEARCH_ORDERING = 2;
As you can see, I want to have a generic Signature of the Argues, but also constrict the possible Argues,
which can be delivered to the Method getHits().
This is done by defining some Constants, which can by used as Keys for setting the allowed Arguments. You will find this idea on many Classes of Sun's APIs (for example like java.awt.Color)
For the Client it should be transparent, wether he works with an EJB (which has to implement the Interface) or with a normal Class (which implements the Interface as well). The strategy of which type of Provider the Client currently works is encapsulated in a Factory. The Factory can be configured wether he (the Factory) delivers normal Classes or EJBs. For the Client this is totally transparent - he only works against the Interface.
This Design makes it possible to simply switch the Type of Provider (maybe a Class that is hosted on the same VM or an EJB hosted on a remote Server) by configuring the Factory. For example you could set up to local Classes when in test-mode (dummies) and set up to EJBs when in production-mode.
The dilemma is, that all Types of Implementations should behave the same. When using local Classes, it is no Problem to declare the Constants within the Interface. ... and this is how it should work !!!
But when realising a Provider with the EJB-Technologie, the Remote-Interface is done by simply extending the 'Business-Interface' Provider:
public EJBProvider extends EJBObject, Provider
That's all !!!
All relevant Methods (and Constants ;-) ) are allready defined in the Interface Provider ! And this is the only way to let local classes implemet this interface too, having also the Constants in their Context (I dont want to define the same Constants on different places - only once !!!)
And now I have the problem mentioned in my original Posting ... :~(
On the one Hand, everything works fine, when implementing the Interface Provider by local classes - on the other Hand I get this Exception (please see original Posting), when implementing by EJBs.
(Normally it should be no Problem declaring Constants within Interfaces and refer to this public Constants)
I don't want to split into differnet Interfaces (one for local Classes and one for EJBs) because of the transparency for the Client (therefore I do the whole spectacle ;-) ).
I don't want to add a new getter-method for each new Constant, because this would destroy the original idea (again I want to refer to java.awt.Color - adding a new Color should be easy by simply adding a new Constant - unregarded of the implementation).
Now you know my dilemma ...
Maybe there are some additional ideas to solve this (Design-)problem ...
... any suggestion might help - thanks again in advance !!!