I have a multi-module project where the EJB BarService in project bar refers to a FooService EJB in foo project. The #EJB annotation is use to inject the EJB.
#EJB
private FooService fooService;
I'm using IntellijIDEA 11, and it complains with
'Ambiguous EJB reference "beanName" or more precise "beanInterface" should be specified'.
This error is only showing up for EJB references in a different module. If I use the beanName as suggested, the error goes away. However I would prefer not to use it, since it would be hard to refactor the component name as it is a string.
Is this a bug in IDEA, or am I trying to do something wrong here?
(Noticed this and this asking the exact same question in the JetBrains forums, but there are no replies sadly).
The javadoc for javax.ejb.EJB is somewhat unclear on this point:
If no explicit linking information is provided and there is only one
session bean within the same application that exposes the matching
client view type, by default the EJB dependency resolves to that
session bean.
It's debatable whether application in this context means "EJB module" or "EAR", so I don't necessarily think IDEA is to blame. I'm not familiar with other vendors, but at least WebSphere Application Server will attempt to disambiguate within the client EJB/WAR module before considering all EJBs in all modules in the EAR.
Related
I added dependencies to my profile class:
public class MyModelMappingProfile : Profile
{
public MyModelMappingProfile(
IDependency1 dependencyOne, IDependencyTwo dependencyTwo)
When I start the service it complains System.MissingMethodException: No parameterless constructor defined for type 'MyModelMappingProfile'.
Found this solution, which solves the problem, but is very manual. Is there something more generic? Haven't found an answer in the docs
https://jimmybogard.com/automapper-usage-guidelines/
X DO NOT inject dependencies into profiles
Profiles are static configuration, and injecting dependencies into them can cause unknown behavior at runtime. If you need to use a dependency, resolve it as part of your mapping operation. You can also have your extension classes (resolvers, type converters, etc.) take dependencies directly.
I wonder if it's possible to get an instance of the JAX-RS Application a resource is attached on. Ideally a way that isn't dependent to a specific implementation. For example using dependency injection...
Thanks very much for your help,
Thierry
As stated in The Spec
5.2.1 Application
The instance of the application-supplied Application subclass can be injected into a class field or method parameter using the #Context annotation. Access to the Application subclass instance allows configuration information to be centralized in that class. Note that this cannot be injected into the Application subclass itself since this would create a circular dependency.
but from I've experienced, it will most likely not be the actual instance, but a proxy. Also if you're looking to alter anything on it, I'm not sure it's possible. It might be read-only.
I am currently experiencing a problem in my RCP application and wanted to ask, if someone stumbled over the same problem and can give me some valuable hints:
My RCP application allows plugins to provide implementations of a specific abstract class of my model (singleton) to extend my model during runtime via the update manager. I instantiate these classes via
extensionPointImplementation.createExecutableExtension(..)
after parsing the Eclipse registry. I can serialize the created instances using the default Java serialization API.
Now to the problem: The plugin trying to deserialize the objects cannot find the class implementations of the model extensions due to the fact, that there is no plugin dependency between the plugins. Nevertheless, it is not possible for me to create such a dependency which would make the idea of extending the model during runtime obsolete.
Is it possible to solve this problem by using the default Java serialization API or do I have to implement my own serialization (which parses the Eclipse registry and creates the instances via the line shown above if all necessary plugins are available, otherwise throw an exception) which might be based on the default Java serialization API (if possible I do not want to create the serialization completely by myself)?
Thanks.
You need to define a so called buddy policy.
In the bundle trying to instantiate the class add
Eclipse-BuddyPolicy: registered
to the manifest.mf.
In the bundle providing the class add
Eclipse-RegisterBuddy: <symbolic name of the bundle instantiating the class>
to the manifest.mf.
My application has this structure: there's a RepositoryFacade (that is a Singleton) that uses many other ObjectRepository that are Singleton (UserRepository, etc).
Now I'd like to test it, mocking the [Objetct]Repositiries. To do that I made the [Objetct]Repositiry implements an interface, and then i tried to:
final IUserRepository mockIUserRepository= context.mock(IUserRepository.class);
RepositoryFacade.getInstance().setUserRepository(mockIUserRepository);
final User testUser = new User("username");
// expectations
context.checking(new Expectations() {{
oneOf (mockIUserRepository).save(testUser);
}});
// execute
RepositoryFacade.getInstance().save(testUser);
And in RepositoryFacade I added:
public IUserRepository userRepository = UserRepository.getInstance();
But if I try to run the test, I obtain:
java.lang.SecurityException: class "org.hamcrest.TypeSafeMatcher"'s signer
information does not match signer information of other classes in the same
package
p.s. Originally my RepositoryFacade had not a IUserRepository variable, I used it asking always UserRepository.getInstance().what_i_want(). I introduced it to try to use JMock, so if not needed I'll be glad to remove that bad use of Singleton.
Thanks,
Andrea
The error you're getting suggests that you have a classloading issue with the org.hamcrest package rather than any issue with your singletons. See this question for more on this exception and this one for the particular problem with hamcrest and potential solutions.
Check your classpath to make sure you're not including conflicting hamcrest code from multiple jars. If you find hamcrest in multiple jars, this may be corrected by something as simple as changing their order in your classpath.
Junit itself comes in two versions - one may include an old version of hamcrest. Switching to the one not including hamcrest may also fix your problem.
If you can find a way to do it, it would be better in the long run to get rid of the singletons altogether and instead do dependency injection using something like Spring or Guice.
But what you're doing should work, once you deal with the classloading, and it's a reasonable approach to dealing with singletons in a testing context.
Now, with EJB 3.1, we can find the javax.ejb.Singleton annocation that can ensure that this bean is going to be singleton.
Is there a way that i can ensure singleton using stateless beans in EJB 3.0 with some modifications in my code (use of the keyword static, or other way to do that....)
If you're able to limit your #Stateless bean pool size to exactly 1, then you can get pretty close to an #Singleton.
The effect would be like having an #Singleton that uses #Lock(WRITE) for all calls (i.e. no concurrency) and does not eagerly startup via #Startup (it will start on first access).
You might still be able to get the effect of #Startup if your platform has the option to eagerly fill #Stateless bean pools.
Is there a way that I can ensure singleton using stateless beans in EJB 3.0 with some modifications in my code (use of the keyword static, or other way to do that....)
No, nothing standard. Your container might provide some specific extensions though (e.g. JBoss has a proprietary #Service annotation).