I have working app1.ear, containing:
JPA entity, MyObjectImpl, implementing interface MyObject from api.jar
api.jar with MyObject interface and EJB Remote interface
ejb.jar with EJBs providing methods to access and modify JPA Entities
Second app2.ear is supposed to communicate with app1.ear using ONLY interfaces in api.jar. Everything works fine when passing Java basic types between ears.
But when app2.ear tries to retrieve from app1.ear instance of MyObject - CORBA MARSHAL exception is raised, saying that MyObjectImpl class can not be found:
"IOP00810257: (MARSHAL) Could not load class com.zzz.MyObjectImpl"
Placing MyObjectImpl in app2.ear solves the issue, but I don't want to expose JPA implementation to other ear applications.
Am I missing something or my approach is wrong? Please advise what to do or where to dig.
Many thanks in advance!
PS: Server GF 3.0.1, no GF-specific deployment descriptors, both ears running on the same JVM
The impl classes are required during deserialization. Another approach would be to use XML or JSON or protobuff, if you doesn't want to expose the impl classes.
Related
I'd like to know what the best practices are for Eclipse 4 dependency injection.
After reading about this subject on the internet, I came up with the following strategy.
requirements
Share the data model of the application (e.g. company, employee, customer, ...) so that framework objects (view parts, handlers, listeners, ...) can access it with as little coupling as possible.
proposed strategy
I've used the lifeCycleURI plugin property to register a handler which is triggered at application startup. Such handler creates an "empty" top-level data model container object and place it into the EclipseContext. It is also discarded when application stops.
All Eclipse framework classes (view parts, handlers) use the classic DI to get such data model object injected.
Button listeners created with the class constructor can't have the data model object injected in them. So I thought they could be created with ContextInjectionFactory.make() to have injection performed. This would couple the class which creates the listener with CIF, but the great advantage is that injection works out of the box.
This is the best solution I've found yet to leverage E4 DI with as little coupling as possible. The weak spot is in my opinion this coupling with CIF. My question would be whether any strategy exist to remove even this coupling, or alternate solutions for the same requirements.
You can create a service class in your project, let's say ModelService.
Add #creatable and #singleton annotations to that class :
#creatable
#singleton
class ModelService{
}
And let DI do its job using following syntax in your parts/handlers/etc ..
#Inject ModelService modelService;
Then you can implement methods in your service like 'createBaseModel()', updateModel() and so on.
This creates a low coupling solution : you can also implement ModelService in a separate plugin and define it as a OSGi service.
for that solution, you can read this Lars Vogel article.
I'm building an extension in Extbase (latest version, latest typo3) and am having repositories injected into my models.
This simply does not work. No errors, no clues, nothing. The inject* Method simply does not get called. The exact same Injection works in the controller.
Is it possible to inject Repositories into models in Extbase? In general, injection to models is possible since 1.4.
How can I debug this? Where do I have to look?
This is a common misconception:
Not every class you use in TYPO3 CMS uses dependency injection by default - and it's a good thing.
What is true, is that every object that has been instantiated by the ObjectManager can benefit from it.
In short: if you new Thing() some object, it won't benefit from dependency injection. If you use the ObjectManager to get an instance of something, the whole dependency injection gallore will rain down on your new instance:
constructor injection [Example: How can I use an injected object in the constructor?
annotations are read and field injections are done
setter injection was done in the past (Remark: I think it's deprecated)
public method (if existent) initializeObject is called
Note that injected objects are being instantiated by the objectManager as well-so recursion is possible if injected ServiceA needs an injected ServiceB.
Singletons are possible as well if you implement the marker interface SingletonInterface.
Dependency injection only works if you get an instance of the object via the ObjectManager. If you are using the good ol'
t3lib_div::makeInstance('Tx_yourextension_domain_model_thing')
inject* methods are not being called.
There is a german blog entry explaining how it works.
Could someone help me understand the use of beanInterface parameter of #EJB annotation in JavaEE 6?
I have a situation in which I have an EJB and I want it to be accessed locally and remotely as well.
I have a MyBaseInterface and then both MyEJBLocalInterface and MyEJBRemoteInterface extending MyBaseInterface. Now I have MyEJB which is implementing both MyEJBLocalInterface and MyEJBRemoteInterface.
Now I have a situation in which I want only to access MyEJB locally.
Could I achieve the same with the following?
#EJB(beanInterface=MyEJBLocalInterface.class)
private MyBaseInterface instanceOfLocallyAccessedMyEJB;
Could someone help me understand the use of beanInterface parameter of #EJB attribute?
Thanks.
the beanInterface attribute of the #EJB annotation is used for different purposes depending on the EJB version you are using:
In EJB 3.X you can use it to specify whether you want to use the remote of local reference of the EJB you are referring to, which is your case.
In EJB 2.X it is used to specify the Home/LocalHome interface of the session/entity bean
To sum up, yes. You should be able to use it to inject the desired interface.
This might not be supported in older versions of JBoss though.
I'm experiencing some problems with GWT and Gilead/Hibernate
I did my code according to the tutorial but it fails with
com.google.gwt.user.client.rpc.SerializationException: Type 'ru.atamur.entity.UserEntity_gilead_15' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized.: instance = ru.atamur.entity.UserEntity_gilead_15#133fa82
Looking at the source code I can see that Gilead transformed my UserEntity into UserEntity_gilead_15 inside GileadRPCHelper.parseReturnValue(returnValue, _beanManager)
I can see that this was deliberately done by ProxyClassMapper (I'm trying to use proxy mode), so I was wondering where Gilead was expecting to tell GWT Serilization mechanism about this new proxy class it introduced ...
Can you share your code ?
before that I want to say that SerializationException is thrown when your class doesn't implement isSerializable interface that you send it to the server.
Every class that you send to the server should implement isSerializable interface
I would like to have the following kind of resource class work when deployed under RestEasy in JBoss 6:
#Path("Something")
public class Foo {
#EJB
private SomeService service
#GET
public Object frobnicate() {
assert service != null;
// JBoss blows up here
return result;
}
}
Two questions:
It is a limitation of RestEasy, not of the Java EE specification, right, that RestEasy can't inject anything annotated with #EJB?
What have people done to work around this limitation?
My developers are about to surge forward with hard-coded JNDI lookups (e.g. context.lookup(someHardCodedNameHere)) because no one can find a workaround to this specification violation at the present time. I really want to avoid this.
Lastly, I've looked at using CDI, but the story here isn't much better as RestEasy and CDI still aren't talking to each other.
Thanks in advance for any pointers.
The JBoss guys tell me this is being worked on on the trunk. So as of JBoss 6 milestone 3 this is impossible.