April 2010 - jboss-dev-forums - Jboss List Archives

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/539894#539894 -------------------------------------------------------------- Okay, duh. The license was staring me right in the face on their homepage. Here it is: http://source.icu-project.org/repos/icu/icu/trunk/license.html http://source.icu-project.org/repos/icu/icu/trunk/license.html Are we okay with that? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/539894#539894] Start a new discussion in JBoss ESB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

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...]

15 years, 11 months

1
0
0 / 0

[JBoss XML Binding Development] - JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData

by Scott Marlow

Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] created the discussion "JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData" To view the discussion, visit: http://community.jboss.org/message/539886#539886 -------------------------------------------------------------- I'm trying to add a getPersistenceMetaData() to PersistenceUnitMetaData, so that code that has access to the PersistenceUnitMetaData can also get the PersistenceMetaData. This will help resolve JBJPA-27. Attached to JBJPA-27 is a JBJPA-27.patch ( https://jira.jboss.org/jira/secure/attachment/12333993/JBJPA-27.patch https://jira.jboss.org/jira/secure/attachment/12333993/JBJPA-27.patch) that is written for https://svn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk https://svn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk. The patch changes PersistenceMetaData.setPersistenceUnits(List persistenceUnits) but unit testing is showing an empty List is passed in. This isn't a surprise but I am wondering if there is a way to handle linking the classes via some other XML binding magic? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/539886#539886] Start a new discussion in JBoss XML Binding Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

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...]

15 years, 11 months

1
0
0 / 0

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/539884#539884 -------------------------------------------------------------- Some information from Andrew Haley to a mail where I asked him about the class loaders of parameterized types: > I don't think that it makes any sense even to talk about the class > loader that was used to create a ParameterizedType. Clearly there was > a class loader used to resolve the class names that are passed when a > ParameterizedType is created, but I don't think the information is > recorded anywhere. > > > > The core bug here seems to be that cacheing is being done > inappropriately. > > > > Can you write a test case, please? One that demonstrates the bug in > > > > //Fails - loader is loaderA > assertEquals(loaderB, infoB.getActualTypeArguments[0].getClassLoader()); > > > > It has to be complete and runnable as a standalone program. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/539884#539884] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

[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...]

15 years, 11 months

1
0
0 / 0

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/539876#539876 -------------------------------------------------------------- > > Type t1 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType(); > Type t2 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType(); > Should be Type t1 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType(); Type t2 = DeleteMe.class.getDeclaredMethod("m2").getGenericReturnType(); but the result is the same -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/539876#539876] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

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...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/539866#539866 -------------------------------------------------------------- As a follow-up to our discussions last week, I've created a wiki page that incorporates many of the concepts we discussed. Comments/edits are very much appreciated. Next I'll get Jason's requirements document page updated to reflect the additional requirements we discussed. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/539866#539866] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Tools Development] - Remote Debugging for Eclipse Test Plug-in Running by Tycho

by Denis Golovin

Denis Golovin [http://community.jboss.org/people/dgolovin] commented on the document "Remote Debugging for Eclipse Test Plug-in Running by Tycho" To view all comments on this document, visit: http://community.jboss.org/docs/DOC-15209#comment-3233 -------------------------------------------------- It should, but I was looking for possibility to debug errors in JUnit tests for jsf.core not for right way to configure it :) That I think is a next step. I'm not sure but it might be possible to start it as maven build from eclipse in debug mode. I tried to use remote debugging because I was running maven3 from console. --------------------------------------------------

15 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2010