I mentioned this in a comment on the other question, but the whole idea of Inversion of Control is to have none of your classes know or care how they get the objects they depend on. This makes it easy to change what type of implementation of a given dependency you use at any time. It also makes the classes easy to test, as you can provide mock implementations of dependencies. Finally, it makes the classes simpler and more focused on their core responsibility.
Calling ApplicationContext.getBean() is not Inversion of Control! While it's still easy to change what implemenation is configured for the given bean name, the class now relies directly on Spring to provide that dependency and can't get it any other way. You can't just make your own mock implementation in a test class and pass that to it yourself. This basically defeats Spring's purpose as a dependency injection container.
Everywhere you want to say:
MyClass myClass = applicationContext.getBean("myClass");
you should instead, for example, declare a method:
public void setMyClass(MyClass myClass) {
this.myClass = myClass;
}
And then in your configuration:
<bean id="myClass" class="MyClass">...</bean>
<bean id="myOtherClass" class="MyOtherClass">
<property name="myClass" ref="myClass"/>
</bean>
Spring will then automatically inject myClass into myOtherClass.
Declare everything in this way, and at the root of it all have something like:
<bean id="myApplication" class="MyApplication">
<property name="myCentralClass" ref="myCentralClass"/>
<property name="myOtherCentralClass" ref="myOtherCentralClass"/>
</bean>
MyApplication is the most central class, and depends at least indirectly on every other service in your program. When bootstrapping, in your main method, you can call applicationContext.getBean("myApplication") but you should not need to call getBean() anywhere else!
This happens because Weblogic is looking for an interface that Authenticator implements.
Change to:
@Stateless
@Name("authenticator")
public class Authenticator implements AuthenticatorLocal {
@Override
public void oneMethod()
{
//enter code here
}
}
@Local
public interface AuthenticatorLocal {
void oneMethod();
}
Note: the interface must have at least one overridden method, otherwise you'll get the same error again.
Best Answer
There may be a couple of issues at work here. I'm getting a very similar error in just a straight servlet that is trying to load an ejb that isn't packaged in the same ear, I'm still trying to track that down. I also know that there is a difficulty when loading EJB v2.x that is supposed to be fixed in Weblogic 10.3.3. If you find anything please let me know, and I'll do the same. One thing I have noticed is that if I load the EJB via initialContext.lookup, it works fine.
YMMV