I'm building multiple DAO's that consists of two other DAO's. I have made a generic class to handle invocations on the sub-dao's, since this is always the same.
My problem is that for this to work, i had to put an interface containing only methods (not marked local or remote!) on the sub-dao's. All dao's are stateless beans.
When i try to #EJB the dao's however, i get:
com.dao.EJSLocal0SLSomeDao_85a3a0b7 cannot be cast to com.dao.SomeDao
Is there any way to tweak this so i can use an interface not related to Local or Remote?
Kind Regards
Tom
If you need to cast the bean implementation class, then you need to use no-interview view (that is, annotate the EJB with #LocalBean). If you look up an unrelated interface, you can the proxy that is returned can only be cast to that specific interface.
Related
The big picture: I would ultimately like the ability, given just an EJB name, to be able to look up a business interface view of that EJB, in an .ear file, without knowing its module name—regardless, in other words, of what .jar file it might be packaged in, or what module-name it might have been given in a deployment descriptor somewhere. (Currently, java:app JNDI names require you to know what EJB module the EJB name is relative to; this is a non-starter for me.)
With portable JNDI names not solving my problem, I turned to CDI.
It seems to me that if I can Get To A Place Where I can ask a BeanManager for a CDI bean of a particular type and with a particular name (no, I can't use #Named for this; I don't control the authoring of the EJBs in question), then I can effectively get what I want, provided that all such beans are obviously deployed in bean archives. Fine.
To get here, I can use a CDI portable extension to observe the container's lifecycle. I get that.
There are two interesting events, then, that I wish to observe, and I'm interested in what I can change, when, during observation. One is ProcessAnnotatedType and the other is ProcessSessionBean.
The catch is that during ProcessAnnotatedType I'd like to add a home-grown annotation (EJBNamed or some such; haven't written it yet) that captures the EJB's "official" ejb-name. This name of course can come from at least three different metadata sources with the EJB and Java EE 6 specifications dictating exactly which overrides what. But at ProcessAnnotatedType-time, that information is not yet available.
During ProcessSessionBean, I can of course get the bean name, but it is my understanding that by that point it is too late—since my ProcessAnnotatedType phase already went by, it seems that my chance at modifying things has come and gone.
First, is that correct? Suppose at ProcessAnnotatedType time I decorate the AnnotatedType with a qualifier of my own that is mutable. Suppose further, then, at ProcessSessionBean time I get that annotated type and add my #EJBNamed annotation.
It seems to me this should be legal, as long as I don't expect the container to actually do anything with that annotation, which I don't. I do expect to be able—later—to ask for a Bean with that qualifier of a given type.
So: is it possible for subsequent CDI portable extension observer methods to muck with annotations and such installed during previous portable extension observer method executions?
I am working on a very large game project in Symfony, and keep running into variations of the same problem.
I have a service that I need to separate into multiple "sub-services" because there is too much code to be contained within one class. For instance, a custom JSON serializer handler that needs a separate handler service for each method of serialization.
I'm having trouble working out the best practice for passing dependencies between "families of services." I would preferably like to keep all the definitions within services.yml just so things don't break in the future, but am assuming that may not be achievable.
Here's a better example - I have an "ActionQueueService" which takes a rather lengthy queue of actions from the user. What I would like to do is create a separate class to handle each type of action, so -
ActionQueueService // processes action queue JSON and delegates to sub-services
AbstractAction
PurchaseAction extends AbstractAction
SellAction extends AbstractAction
HarvestAction extends AbstractAction
Now if these three "actions" are defined as services they can have their own dependencies. However, they all have to be injected into the ActionQueueService - what happens if there are 38 of them (which there will be one day).
The next logical step for me was to create ActionFactory. Now I'm only passing in one dependency to ActionQueueService, and it can invoke any action service simply by calling -
$this->actionFactory->get('Harvest');
The problem I have is that each child has it's own separate list of dependencies. A Purchase or Sell action would need the Character service and the ShopStock service, a HarvestAction would need the HarvestService. Because I've decided to use a Factory method, I have to instantiate the sub-service within the factory class. I don't want to pass every dependency into the Factory only to have that either a) inject every dependency into every child or b) handle some crazy child constructor logic.
One solution would be to pass the service container into the factory and come up with a naming convention that allows me to create the service on the fly. I've heard that this is fairly bad practice though. Maybe a wrapper around the service container that limits the amount of bad stuff that could be done with it.
If anybody has any ideas on how this could be solved with Symfony I'd appreciate it. There are similar answers out there but unfortunately I don't know any languages other than PHP/Symfony.
I have an .ear file with dozens of EJB jar files in it.
Each EJB jar file has dozens of EJBs in it.
Each EJB has #EJB references in it with no other information (no name attribute, etc.).
At the moment everything Just Works: it just so happens that for any given #EJB-annotated injection target there is exactly one concrete EJB that is present in the .ear file to fill the slot.
I need for various reasons to introduce a few more EJB jar files that contain EJBs that could also fill some of these slots.
Hence, I need to tell my Java EE container which EJB to inject into which slot where there are conflicts.
I am familiar with the ejb-jar.xml deployment descriptor mechanism for overriding EJB references but if that is my only recourse I'm looking at changing possibly thousands of these entries.
I noticed in the application.xml schema version 6 that there is support for <ejb-local-ref> elements in there, too, which is in some abstract way what I want. But I cannot figure out how to make use of these elements to do what I want.
In some abstract perfect world, I'd like to somehow say, in one place, "Hey, Java EE container, when you see an #EJB-annotated field like this:
#EJB
SomeType bean;
...please inject the EJB whose beanName is fred into it. Everywhere in this application." How do I do that?
There's no standard way to do it and as far as I know, no common vendor-specific way to do it.
This is something i tried to get in in EJB 3.1 for EJB and JPA refs: if an injection point works using the default rules because there's only one SomeType bean, but then some day a second SomeType bean is added... to be blunt, you're hosed :) This problem also exists for #PersistenceContext and #PersistenceUnit refs. The idea was/is to have some "this is the default impl of SomeType option in the standard deployment descriptors and bail people out of these situations.
We should still get this into the specification. If this is your problem, I'll repost that proposal and if you can please follow up with information on how much of a nightmare this is for you, I can almost guarantee we'll get this fixed for EJB.next.
Get your canonical xml
For now, one possible approach is to temporarily deploy this ear in TomEE using the flag openejb.descriptors.output=true. TomEE/OpenEJB will actually give you all the effective deployment descriptors for your application. Could save you several hours or days if your application is as large as you state. Internally we 1) read in the deployment descriptors, 2) use the annotations to "fill out" the deployment descriptors. The result is we have a tree which is the canonical set of "metadata" for each EJB module. With the openejb.descriptors.output=true flag set, we will write each of these ejb-jar.xml files to disk and log the location.
Once you have your ejb-jar.xml files in hand, you can modify at will and go back to GlassFish and perhaps have better luck.
Overriding: Control your reference counts
In terms of how to actually manage this in Java EE, you have to understand how to be successful in overriding references. There's a critical bit of info one needs to know in how annotation references translate to xml. The goal is to have 1 reference and not N.
When your reference is unnamed like so:
package org.some.awesome.code;
public class Foo {
#EJB
SomeType orange;
... there's a fixed rule that the default name of this must be org.some.awesome.code.Foo/orange. The class name and package become part of the name so as to give you the most fine grained control in overriding. The following xml will override this reference:
<ejb-local-ref>
<ejb-ref-name>org.some.awesome.code.Foo/orange</ejb-ref-name>
<local>org.some.awesome.code.SomeType</local>
<ejb-link>Fred</ejb-link>
</ejb-local-ref>
This reference will now link to the EJB of type SomeType with the beanName 'Fred'.
The disadvantage of this is that if you have 100 references like this and you want to change them all, you will need 100 declarations in xml to do so.
There's no way out of this problem that doesn't involve changing your code -- this is where my "use this as the default" proposal has value, it would allow one xml change to handle all 100 cases with no code change. It's as simple as being able to say "when I'm not specific in my code, I really mean use X" via the deployment descriptor.
Perhaps by making it legal to declare overrides in xml using just the type, like so:
<ejb-local-ref>
<local>org.some.awesome.code.SomeType</local>
<ejb-link>Fred</ejb-link>
</ejb-local-ref>
As mentioned, this is currently not legal.
Changing your code
There are a few code change approaches available, but one of them is to give each #EJB ref the same name. Then you will end up with just 1 reference rather than N.
package org.some.awesome.code;
public class Foo {
#EJB(name "purple")
SomeType orange;
Here the name of the reference is explicitly given so overriding it in xml can be done more simply as follows:
<ejb-local-ref>
<ejb-ref-name>purple</ejb-ref-name>
<local>org.some.awesome.code.SomeType</local>
<ejb-link>Fred</ejb-link>
</ejb-local-ref>
If there are 100 #EJB(name="purple") references, all of them would be overridden by the above declaration.
Conclusion
Short answer, there's currently no easy way out. You're looking at either extensive xml or extensive code change.
Long term, we can hopefully improve this part of the specification so people aren't punished when they grow out of the default matching rules.
I am currently solving the same problem. I am investigating possibility of overriding the JNDI context so it provides other instance than the standard ones. You just have to set the system property java.naming.factory.initial (e.g. in jndi.properties) to your implementation and put the implementation on the root classpath. Then in the factory you create your own version of context with overridden lookup method. Sounds simple, but I am figting with this for days.
i am using EF4 and StructureMap in an asp.net web application. I am using the repository/unit of work patterns as detailed in this post. In the code, there is a line that delegates the setup of an ObjectContext in global.asax.
EntityUnitOfWorkFactory.SetObjectContext(() => new MyObjectContext());
On the web page code-behind, you can create a generic repository interface like so ...
IRepository<MyPocoObject> ds = ObjectFactory.GetInstance<IRepository<MyPocoObject>>();
My question is what is a good approach to refactoring this code so that I can use more than one ObjectContext and differentiate between them in the code-behind? Basically i have two databases/entity models in my application and need to query them both on the same page.
The Unit of Work is used to manage persistence across multiple repositories, not multiple object contexts.
You're not going to be able to persist changes across multiple contexts using a unit of work, as the UoW is simply implemented as a wrapper for a ObjectContext. Therefore, you'll need two unit of works.
Overall, things are going to get messy. You're going to have two OCs newed up and disposed each HTTP request, not to mention transaction management is going to be a nightmare.
Must you have two ObjectContexts? What is the reasoning for this? If it's for scalability, don't bother; it's going to be too painful for other things like your repository, unit of work and http scope management.
It's hard to provide good advice without seeing how you have your repositories set up.
Try creating wrapper classes for each object context, each implementing IUnitOfWork and a secondary unique interface (IEfSqlContext1, etc which represents one of your models/contexts).
Then you can inject whichever context you want.
As I said though, try and avoid having two EDMX/Contexts. It's more trouble than it's worth.
Its known that DTO doesnt have methods.
Since the controller uses the DTO objects , there is a dependency . should we set expectaions on the properties of DTO(mock DTO properties) while testing the controllers.?
thanks
Where a DTO is just holding values, there's no point in mocking it. Mock objects should be used to confirm how an object collaborates with its neighbour. If there's no real behaviour, if the DTO is not providing a service, then don't use a mock.
A DTO is so lightweight that the additional cost of stubbing it out just seems silly. Plus now you need an interface for your DTO or everything has to be marked as virtual...
Can you name at least one thing why not?
I can't.
P.s. i mean - why not to use properties. You got 2 controversial questions in your post.
I agree with Arnis L. You just pass your DTO to your controller during your tests (initialized with the values you need) and there's nothing to test in your DTO (unless you have some logic in your getter/setter but it's not really a good practice for DTO).
Are you thinking of the dto going into the action, or the one(s) coming out?
The one going in will be used directly against a repository, a service or some other collaborator. I would mock those instead and place my expectations there.
Your test code will also have full control on creating the ingoing dto.
If you like to use the outgoing dto, I would just grab that one from the ViewResult and verify it is the expected one. How you do that is up to you: You could mock the repository or talk to your persistence storage of choice.
Don't Mock your DTOs. It's simpler just to create your DTO than to create the Mock and in some situation can get you into a bit of trouble if you mutate their state.
I've written about one such experiences at the link below.
Don't Mock DTOs