[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme
by alesj
OK, I wrapped ManagedPropertys + Fields.
This in what I currently get:
| java.lang.ClassNotFoundException: AOPContainerProxy$26
| at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:82)
| at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:76)
| at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
| at java.lang.Class.forName0(Native Method)
| at java.lang.Class.forName(Class.java:242)
| at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:174)
| at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
| at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
| at java.util.HashMap.readObject(HashMap.java:1067)
| at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
| at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
| at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
| at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
| at java.util.HashSet.readObject(HashSet.java:278)
| at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
| at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
| at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
| at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
| at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
| at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:239)
| at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)
| at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120)
| at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:943)
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:584)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
| at org.jboss.remoting.Client.invoke(Client.java:1550)
| at org.jboss.remoting.Client.invoke(Client.java:530)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at AOPProxy$1.getComponentsForType(AOPProxy$1.java)
| at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.getManagedComponent(ProfileServiceUnitTestCase.java:424)
| at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testUpdateDefaultDS(ProfileServiceUnitTestCase.java:305)
|
Guess this is because we don't proxy the properties in ManagedViewImpl:
| protected void mergeRuntimeMO(ManagedObject mo, ManagedObject runtimeMO)
| throws Exception
| {
| Map<String, ManagedProperty> moProps = mo.getProperties();
| Set<ManagedOperation> moOps = mo.getOperations();
| HashMap<String, ManagedProperty> props = new HashMap<String, ManagedProperty>(moProps);
| HashSet<ManagedOperation> ops = new HashSet<ManagedOperation>(moOps);
|
| Map<String, ManagedProperty> runtimeProps = runtimeMO.getProperties();
| Set<ManagedOperation> runtimeOps = runtimeMO.getOperations();
|
| if (runtimeProps != null)
| props.putAll(runtimeProps);
| if (runtimeOps != null)
| {
| runtimeOps = createOperationProxies(runtimeMO, runtimeOps);
| ops.addAll(runtimeOps);
| }
|
| ManagedObjectImpl moi = (ManagedObjectImpl) mo;
| moi.setProperties(props);
| moi.setOperations(ops);
| }
|
And the server proxy cannot be resolved on client side. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090712#4090712
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090712
16 years, 7 months
[Design of EJB 3.0] - Re: EJBTHREE-786
by ALRubinger
So to sum up a couple possible solutions and their drawbacks:
1) Have Proxy implement EJBObject/EJBLocalObject only if designated by the bean provider, ie:
@Remote
| public interface MyBusiness extends EJBObject
This allows us to avoid signature collisions, but doesn't give us EJB2.1 Remote Interface views (EJB3 Spec 3.6.4) by default, and puts the onus on the bean provider to explicity designate EJBObject. Also makes it impossible to have both 2.1 Remote/Local interfaces "AND" methods defined by EJBObject at the same time. Looks like we also have to look into whether this is valid for TCK.
2) Create multiple Proxies, one for EJB3.0 Business Interface, one for EJB2.1 Remote Interface (EJBObject).
Drawback here is the number of changes we'd have to make, and the confusion to our user base by adding another Proxy into JNDI. I can imagine we'd get lots of requests on the user forum asking "when to use which/what's the differrence"? Also, we'd have to determine a default JNDI binding for the new Proxy as well as mechanism to override that (analagous to @RemoteBinding and its XML equivalent). Benefit is that we'd definitely be avoiding method collision, satifying 786, and not interfering w/ the TCK.
3) I don't believe we can simply tell Seam (or any other EJB3.0 Clients) that they can't use "remove" in their Business Interface:
Spec 3.4:
The business interface of an EJB 3.0 session bean is an ordinary Java
| interface, regardless of whether local or remote access is provided for the bean. In particular, the EJB 3.0 session bean business interface is not one of the interface types required by earlier versions of the EJB specification (i.e., EJBObject or EJBLocalObject interface
4) Keep implementation as it current stands, but add new metadata (ie. @NoEjb2View) which will designate that we shouldn't have EJBObject be implemented by the Proxy. Benefit here is that we keep support to EJB3.0 and EJB2.1 clients by default, and provide mechanism for Seam to have their "remove" method.
As long as this doesn't violate spec or TCK, and is agreeable to Seam folks, 4 would be my vote.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090676#4090676
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090676
16 years, 7 months
[Design of JBoss Web Services] - Re: Exception propagation for one way messaqges
by jason.greene＠jboss.com
"adinn" wrote :
| CXF notifies the error by returning a 500 code error to the http client. This results in the JaxWS proxy throwing an exception
|
This isn't correct either. A one way message is not guaranteed to be processed when you submit it, so the response just indicates whether or not transmission, not the processing of the message is successful. So it would not be portable to return a 500 as a fault, nor would it be portable to interpret a 500 from a one way service as meaning anything more than a transmission problem.
Relevant sections:
"The HTTP response to a one-way operation indicates the success or failure of the transmission of the message."
"R2727 For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it."
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090660#4090660
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090660
16 years, 7 months
[Design of EJB 3.0] - Re: EJBTHREE-786
by pete.muir＠jboss.org
Coming at this from a Seam (i.e. people using EJB3) perspective:
"bdecoste" wrote : Having our proxies implement EJBObject is to be backwards compatible to EJB2.1 clients - isn't that a major point of the spec? I know the details aren't there, but the spirit of the spec is to be 2.1 client compatible.
Actually I thought *the* major point of EJB3 was to remove the arbitrary restrictions on what you can and can't do with your EJBs. Saying 'no, you can't define a method with the signature remove() on your business interface' strikes me as pretty arbitrary (from a user perspective). At the very least the current exception message is rubbish.
anonymous wrote : Again, can't we just tell SEAM to change their method name
You can tell Gavin many things, it doesn't mean he listens ;)
anonymous wrote : and disallow EJBObject methods on Remote interfaces like EJB2.1 does?
Perhaps I misunderstand you, but surely we are talking about Local and Remote interfaces (currently this exception is thrown for both) - if this restriction applies to just Remote interfaces it would be a start ;)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090584#4090584
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090584
16 years, 7 months