Re: [jboss-dev-forums] [JBoss ESB Development] - Problem in retrieving WSDL from remote endpoint
by David Ward
David Ward [http://community.jboss.org/people/dward] replied to the discussion
"Problem in retrieving WSDL from remote endpoint"
To view the discussion, visit: http://community.jboss.org/message/539893#539893
--------------------------------------------------------------
The problem is more pervasive than I realized, but I do have a fix. There are a couple issues that need to be discussed, however, so in the end it is a good thing that this is in the developer forum. ;)
First, the fix:
1. StreamUtils.readStreamString(stream, charset):String was incorrectly implemented. It just read in the bytes and created a new String object with the bytes and the specified charset. This will +not+ convert the bytes into the specified charset. So, if the bytes you are reading in are character encoded with KOI8-R instead of UTF-8, for example, then when you output that String, the characters will be garbled. (For example, in Firefox, they will become question marks.) Unfortunately, there is +nothing+ in the JDK that can determine what character encoding a set of bytes or stream is, and this is paramount to creating a String that can be outputted correctly. There is InputStreamReader, but you have to know the encoding of the stream first. :( Luckily, there is a utility out there we can use: http://site.icu-project.org/ ICU4J. What I did to fix the method was call upon a http://icu-project.org/apiref/icu4j/com/ibm/icu/text/CharsetDetector.html..., java.lang.String) helper method in CharsetDetector.
2. Next, the HttpGatewayServlet (which is sometimes used for exposing WSDL via <http-gateway/>, for example, for SOAPProxy) had to be changed to get the now UTF-8 encoded bytes, and output that, making sure to set the Content-Length response header to the length of the byte array, +not+ the length of the String: http://mark.koli.ch/2009/09/remember-kids-an-http-content-length-is-the-n... http://mark.koli.ch/2009/09/remember-kids-an-http-content-length-is-the-n...
3. Finally, the contract.jsp page (which is sometimes used for exposing WSDL via <jbr-provider/>) had to be changed to declare <%@page contentType="text/xml; charset=UTF-8"%> at the top of the page, so that <%=contractData=> would be outputted correctly. See notes on JSP page directive and its effect here: http://www.w3.org/International/O-HTTP-charset http://www.w3.org/International/O-HTTP-charset
After making the changes above, I tested successfully using both JDK 5 + ESB in AS4, and JDK 6 + ESB in AS 5. I also ran a clean integration build.
Next, the two issues that have to be discussed:
1. Are we allowed to add icu4j-4_4.jar and icu4j-charsets-4_4.jar as project dependencies, and ship them with both our community ESB and supported SOA Platform? I can't seem to find out what the ICU4J license is...
2. While correcting the implementation of StreamUtils.readStreamString(stream, charset):String, any code that called that method will now be guaranteed correct character encoding. +However+, any code which calls the underlying StreamUtils.readStream(stream):byte[] method, and decides to create it's +own+ String from the returned byte array (instead of just using readStreamString) could have a misinterpretted character encoding problem. This is all over the place in our code, and I'm a bit hesitant to go change all of it. Maybe for the purpose of this bug, we just stick to fixing the WSDL encoding problem? Luckily, this problem only rears its head if the stream being read contains an extended character set and not UTF-8 (like KOI8-R or cp1251, for example).
Feedback appreciated. Thanks!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539893#539893]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539885#539885
--------------------------------------------------------------
> I have tried turning off caching for these parameterized ClassInfos, which causes some of the tests to fail. From what I can see fixing them means having to adjust some of the tests to use assertEquals() instead of assertSame() for parameterized ClassInfos. I think this is necessary, and that the idea of enforcing object equality for parameterized ClassInfos is a misunderstanding :-)
Apart from this local fix in BeanInfoCacheTestCase, all the other places that test object equality for parameterized class infos are in tests written by me as part of JBREFLECT-5, so I think I am safe to readjust the tests
[kabir ~/sourcecontrol/jboss-reflect/trunk/jboss-reflect]
$svn diff src/test/
Index: src/test/java/org/jboss/test/beaninfo/test/BeanInfoCacheTestCase.java
===================================================================
--- src/test/java/org/jboss/test/beaninfo/test/BeanInfoCacheTestCase.java (revision 104118)
+++ src/test/java/org/jboss/test/beaninfo/test/BeanInfoCacheTestCase.java (working copy)
@@ -125,16 +125,45 @@
{
BeanInfo beanInfo = getConfiguration().getBeanInfo(typeInfo);
ClassInfo typeInfo2 = beanInfo.getClassInfo();
- assertSame(typeInfo, typeInfo2);
+ assertClassInfos(typeInfo, typeInfo2);
}
-
+
private void assertClassInfo(ClassInfo typeInfo, String className, ClassLoader cl) throws Exception
{
BeanInfo beanInfo = getConfiguration().getBeanInfo(className, cl);
ClassInfo typeInfo2 = beanInfo.getClassInfo();
- assertSame(typeInfo, typeInfo2);
+ assertClassInfos(typeInfo, typeInfo2);
}
+ private void assertClassInfos(TypeInfo typeA, TypeInfo typeB)
+ {
+ ClassInfo classA = assertInstanceOf(typeA, ClassInfo.class);
+ ClassInfo classB = assertInstanceOf(typeB, ClassInfo.class);
+
+ if (classA.getRawType() == classA)
+ assertSame(classA, classB);
+ else
+ {
+ assertEquals(classA, classB);
+ TypeInfo[] argsA = classA.getActualTypeArguments();
+ TypeInfo[] argsB = classB.getActualTypeArguments();
+
+ if (argsA != null)
+ assertNotNull(argsB);
+ if (argsB != null)
+ assertNotNull(argsA);
+ if (argsA == null)
+ {
+ assertNull(argsB);
+ return;
+ }
+
+ assertEquals(argsA.length, argsB.length);
+ for (int i = 0 ; i < argsA.length ; i++)
+ assertClassInfos(argsA[i], argsB[i]);
+ }
+ }
+
@SuppressWarnings("unchecked")
protected Type getType(String type, Class<?> clazz) throws Exception
{
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539885#539885]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss Microcontainer Development] - Deployments in error guzzles up the exception cause
by Carlo de Wolf
Carlo de Wolf [http://community.jboss.org/people/wolfc] created the discussion
"Deployments in error guzzles up the exception cause"
To view the discussion, visit: http://community.jboss.org/message/539880#539880
--------------------------------------------------------------
I can't see the cause of the NotCompliantMBeanException in this output. :((
java.lang.Exception: Encountered exception in server startup
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:325)
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:257)
at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381)
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: Incompletely deployed:
DEPLOYMENTS IN ERROR:
Deployment "JMXKernel" is in error due to: javax.management.NotCompliantMBeanException: Cannot register MBean: jboss.system:type=ServerInfo
DEPLOYMENTS MISSING DEPENDENCIES:
Deployment "JMXRegistrationAdvice" is missing the following dependencies:
Dependency "JMXKernel" (should be in state "Installed", but is actually in state "**ERROR**")
Deployment "ServiceDeployer" is missing the following dependencies:
Dependency "JMXKernel" (should be in state "Installed", but is actually in state "**ERROR**")
Deployment "AspectManagerJMXRegistrar" is missing the following dependencies:
Dependency "JMXKernel" (should be in state "Installed", but is actually in state "**ERROR**")
Deployment "ServiceMetaDataICF" is missing the following dependencies:
Dependency "JMXKernel" (should be in state "Installed", but is actually in state "**ERROR**")
Dependency "JMXKernel" (should be in state "Installed", but is actually in state "**ERROR**")
Deployment "JMXStartStopAdvice" is missing the following dependencies:
Dependency "JMXKernel" (should be in state "Installed", but is actually in state "**ERROR**")
Deployment "JMXCreateDestroyAdvice" is missing the following dependencies:
Dependency "JMXKernel" (should be in state "Installed", but is actually in state "**ERROR**")
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:314)
... 4 more
It must output the message of the cause as well.
I caused it by having the wrong version jboss-logging on the CL.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539880#539880]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539875#539875
--------------------------------------------------------------
> Kabir Khan wrote:
>
> One way around this would be in mi.getReturnType() when looking up/creating/caching the parameterized class info to use the classloader of mi.getDeclaringClass().getClassLoader(), which should be able to see all the classes involved. However, I am still stuck on which classloader to use for my previous post.
This works, however for "1 - other problem" I don't really see a way to determine the classloader. It could be the classloader of the raw type, or the loader of any of the class infos. It might be possible to determine which of the classloaders can see all the generic bounds by brute force, but that will probably
a) Be slow
b) Might not be possible, i.e. maybe none of the classloaders for any of the bounds are able to load everything.
I have tried turning off caching for these parameterized ClassInfos, which causes some of the tests to fail. From what I can see fixing them means having to adjust some of the tests to use assertEquals() instead of assertSame() for parameterized ClassInfos. I think this is necessary, and that the idea of enforcing object equality for parameterized ClassInfos is a misunderstanding :-)
Java itself does not seem to reuse the ParameterizedTypes, as shown by this simple passing test:
public class DeleteMe extends ContainerTest
{
public DeleteMe(String name)
{
super(name);
}
public Set<String> m1(){return null;}
public Set<String> m2(){return null;}
public void testType() throws Exception
{
Type t1 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType();
Type t2 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType();
ParameterizedType p1 = assertInstanceOf(t1, ParameterizedType.class);
ParameterizedType p2 = assertInstanceOf(t2, ParameterizedType.class);
//The param are equal, but not the same
assertEquals(p1, p2);
assertNotSame(p1, p2);
//The raw types are the same
assertSame(p1.getRawType(), p2.getRawType());
assertEquals(1, p1.getActualTypeArguments().length);
assertEquals(1, p2.getActualTypeArguments().length);
Class<?> clazz1 = assertInstanceOf(p1.getActualTypeArguments()[0], Class.class);
Class<?> clazz2 = assertInstanceOf(p2.getActualTypeArguments()[0], Class.class);
assertSame(clazz1, clazz2);
}
}
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539875#539875]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years