> The trick with the code below is essentially, beans are not available for > business method invocations until after they are constructed (i.e. > PostConstruct is finished). > > So basically your construction code is waiting for your construction code to > finish.
This is exactly what I was thinking caused it. In fact, I was suspecting something bad might happen when I was writing it exactly because I'm trying to use it before construction. > You could cheat as Richard suggests and launch a thread to call your init() > method over your business interface. You're technically not allowed to do > that, but in this case it's actually pretty safe. It'd be identical to > having the init() method annotated with @Asynchronous -- once we get that > support in. It doesn't feel right. I was doing this in hope of getting past the 2 beans for startup. But I eventually got everything going with your first suggestion of having an EntityManager injected and passing in it's reference to the data initialization bean, together with the spring XML resource details. > Having a public init() method is really the big PITA here. As soon as we > get the tx support in for singleton callbacks, you'll want to go straight in > and remove that method. Luckily I don't even need it with the method I'm using now. I wasn't sure how transactions worked and until I ran into the problem thought it was linked to the injected instance, where it's actually in the ThreadContext. So injecting the bean and then passing it into the Local business bean works just as well. Thanks for brilliant software. I honestly can't think of a single situation in OpenEJB where I had to settle for second best - this would have been the first, but ended up being done in the same way I would have done it anyway. Do you smell that? I smell signs of well designed software. Q
