August 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossXB] - xsd:attribute ref unsupported in unmarshaller

by anil.saldhana＠jboss.com

with a generic value container? | <xsd:attribute name="flag"> | <xsd:simpleType> | <xsd:restriction base="xsd:string"> | <xsd:enumeration value="required"/> | <xsd:enumeration value="requisite"/> | <xsd:enumeration value="sufficient"/> | <xsd:enumeration value="optional"/> | </xsd:restriction> | </xsd:simpleType> | </xsd:attribute> | | <xsd:element name="login-module" type="jbsx:loginModuleInfo"/> | <xsd:complexType name="loginModuleInfo"> | <xsd:annotation> | <xsd:appinfo> | <jbxb:class impl="org.jboss.security.auth.login.AppConfigurationEntryHolder"/> | </xsd:appinfo> | </xsd:annotation> | <xsd:sequence> | <xsd:element ref="jbsx:module-option" minOccurs="0" maxOccurs="unbounded"/> | </xsd:sequence> | <xsd:attribute name="code" type="xsd:string" use="required"/> | <xsd:attribute ref="jbsx:flag" use="required"/> | </xsd:complexType> | | I do not have the test case for this. But I saw that an addChild call never happened for "flag" in AppConfigurationEntryHolder (a GenericValueContainer). Alex, you may be faster in churning out a test case and fixing this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071822#4071822 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071822

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassCastException for char[] MetaValue creation

by adrian＠jboss.org

There was some work done on this for OpenMBeans in Java6 http://java.sun.com/javase/6/docs/technotes/guides/jmx/enhancements.html#... I haven't looked at the details. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071816#4071816 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071816

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassCastException for char[] MetaValue creation

by scott.stark＠jboss.org

I created JBMICROCONT-202 for these issues and have checked in some changes for these that has the tests passing. There is a real mismatch in the type system for primitive arrays vs the object forms of such arrays. I played around with a few different things to try to better preserve the primitive arrays, but since you can't create generic arrays, the ArrayMetaValue always has to be the Object form (Character[] instead of char[]). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071814#4071814 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071814

18 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP asintegration WITHOUT the integration :-)

by adrian＠jboss.org

So, once this change (use the correct classloader instead of guessing the TCL) is done throughout AOP there will be no need for ScopedClassLoaderDomains or any other integration code beyond the javassist ScopedClassPool. With just the few changes I've done already, all the tests I've written pass including the ones that have unexported classes and multiple versions of the classes which are some of the more complicated OSGi use cases. There's one caveat which is that to make the multiple version test work, I had to make the interceptor PER_CLASS scope. The notion of PER_VM needs redefining such that it takes into account multiple versions of the advice in different classloaders, but it should have to do complicated things like the ScopedClassLoaderDomain to do that. The PER_VM advices should just indexed by the classloader of the advice class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071812#4071812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071812

18 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - AOP asintegration WITHOUT the integration :-)

by adrian＠jboss.org

Related to these threads: New classloader tests - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114427 Refactoring ASIntegration for new classloader - [url] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112771[/url] AOP Scoping is WRONG! http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112736 I think I've found a way to make this work without having to any integration. The basic problem is the one I found with the TCL usage. When this is fixed (and some other things), we don't need any integration code. The new tests I wrote now all work with the following two changes: 1) In JoinPointGenerator I now always use the classloader of the pool where the advice lives, not the TCL. 2) I've added a new option "pushClassLoader" to the AspectManager which says that when generating advices it should be done under the classloader of the **Advised** class Obviously these changes are incomplete: a) Part (2) above should be using the classloader of the **Advice** class b) I'm only doing (2) for PER_VM and PER_CLASS since that's all I've tested so far c) There are other places besides the Advisor that generate advices d) There are a number of other places that use the TCL that need fixing in a similar way. There's one other fix that needs doing which is in (I haven't made this change) AspectManager.findClassPool() The use of Translatable is obsolete. It should really be doing something like: | if (cl == null) | cl = ClassLoader.getSystemClassLoader(); // Using SecurityActions; | return registerClassLoader(cl); | For now, I've made RealClassLoader (which is what both the new and old classloaders extend) implement Translatable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071811#4071811 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071811

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassCastException for char[] MetaValue creation

by scott.stark＠jboss.org

So the testCharArray failure comes down to this conflict mentioned in the org.jboss.metadata.spi.signature.Signature.stringsToClasses comment | //For arrays we will want to load the class, the ArrayInfoImpl generates names in an invalid format, resolve this here | String primitiveCandidate = param.substring(index + 1); | String componentType = primitiveArrayTypes.get(primitiveCandidate); | | The same encoded names as found in primitiveArrayTypes should be going into the ArrayInfoImpl name when a primative type is the element type: | public ArrayInfoImpl(TypeInfo componentType) | { | this.componentType = componentType; | StringBuilder builder = new StringBuilder(); | builder.append("["); | TypeInfo temp = componentType; | while (temp.isArray()) | { | builder.append("["); | temp = ((ArrayInfo) temp).getComponentType(); | } | if (temp.getClass().equals(PrimitiveInfo.class)) | { | //builder.append(temp.getName()); | // Use the signature encoded name for the primitive element type | String encodedName = Signature.getPrimativeArrayType(temp.getName()); | builder.append(encodedName); | } | else | { | builder.append("L").append(temp.getName()).append(";"); | } | name = builder.toString(); | calculateHash(); | } | with that change, the IntrospectionArrayUnitTestCase.testCharArray passes, but the JavassistArrayUnitTestCase.testCharArray fails with the following. The JavassistArrayInfoImpl also needs to be updated. If I do that all container unit tests are passing. | junit.framework.AssertionFailedError: expected:<JavassistArrayInfoImpl@75843a75{name=[Lchar;}> but was:<ArrayInfoImpl@3c1a1399{name=[C}> | at junit.framework.Assert.fail(Assert.java:47) | at junit.framework.Assert.failNotEquals(Assert.java:282) | at junit.framework.Assert.assertEquals(Assert.java:64) | at junit.framework.Assert.assertEquals(Assert.java:71) | at org.jboss.test.classinfo.test.AbstractClassInfoTest.testBasics(AbstractClassInfoTest.java:74) | at org.jboss.test.classinfo.test.ClassInfoArrayTest.testArray(ClassInfoArrayTest.java:96) | at org.jboss.test.classinfo.test.ClassInfoArrayTest.testCharArray(ClassInfoArrayTest.java:52) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071748#4071748 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071748

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassCastException for char[] MetaValue creation

by scott.stark＠jboss.org

Based on other tests like org.jboss.test.classinfo.test.AbstractClassInfoTest.testArray: | protected void testArray(Class<?> clazz, TypeInfo info) throws Throwable | { | TypeInfo arrayType = info.getArrayType(1); | getLog().debug("ArrayType(1): " + arrayType); | assertTrue(arrayType.isArray()); | Class<?> arrayClass = Array.newInstance(clazz, 1).getClass(); | assertEquals(arrayClass, arrayType.getType()); | | arrayType = info.getArrayType(5); | getLog().debug("ArrayType(5): " + arrayType); | assertTrue(arrayType.isArray()); | arrayClass = Array.newInstance(clazz, 5).getClass(); | assertEquals(arrayClass, arrayType.getType()); | } | the getArrayType is supposed to return a TypeInfo for a TypeInfo that corresponds to TypeInfo[depth]? I thought this was returning the TypeInfo for the given dimension of the array. | /** | * Whether this type is an array | * | * @param depth the array depth | * @return the array type | */ | TypeInfo getArrayType(int depth); | This needs to be clarified. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071727#4071727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071727

18 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - "admin" portlet mode

by julien＠jboss.com

I have implemented the "admin" portlet mode which allow to garantee some security constraint to be honoured when the mode is called. The security constraint is that the permission action "admin" is granted for the user. I have updated the documentation for it and I have added the "admin" permission to the set of available permission actions in the administration tool. I have also put a simple example (ModePortlet) in the basic samples. What is missing today are the different icons for the themes that represent the "admin" action. They have been jiraised and are a dependency of the global admin mode task. This feature will allow us to remove the isUserInRole usage in our various portlets and instead implement the functionalities based on the check of the current mode being "admin". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071722#4071722 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071722

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassCastException for char[] MetaValue creation

by scott.stark＠jboss.org

In looking into this the type info subsystem in the container module also looks broken for primitive array types. I added a primitive char[] test and its failing due to char vs Character mismatches: | public void testCharArray() | throws Throwable | { | char[] array = {'h', 'e', 'l', 'l', 'o'}; | testArray(array); | } | | ... | | junit.framework.ComparisonFailure: expected:<...C> but was:<...char> | at junit.framework.Assert.assertEquals(Assert.java:81) | at junit.framework.Assert.assertEquals(Assert.java:87) | at org.jboss.test.classinfo.test.AbstractClassInfoTest.testBasics(AbstractClassInfoTest.java:83) | at org.jboss.test.classinfo.test.ClassInfoArrayTest.testArray(ClassInfoArrayTest.java:94) | at org.jboss.test.classinfo.test.ClassInfoArrayTest.testCharArray(ClassInfoArrayTest.java:52) | I also ran across JBMICROCONT-123 which is about improving the implementation, but this is actually a bug as this method does not work at all. The depth argument to Array.newInstance is the array length, not a depth for the array dimension. | public static Class getArrayClass(Class clazz, int depth) | { | return Array.newInstance(clazz, depth).getClass(); | } | This simple test in org.jboss.test.classinfo.test.ClassInfoArrayTest of getArrayClass fails because getArrayClass is returning an array of the input type, not selecting the type of the indicated array dimension: | public void testArrayType() | { | String[] array = {"hello", "world"}; | TypeInfoFactory factory = getTypeInfoFactory(); | TypeInfo info = factory.getTypeInfo(array.getClass()); | | TypeInfo info0 = info.getArrayType(0); | assertEquals(info0.getName(), "[java.lang.String;", info0.getName()); | } | | ... | junit.framework.ComparisonFailure: [[Ljava.lang.String; expected:<......> but was:<...[L...> | at junit.framework.Assert.assertEquals(Assert.java:81) | at org.jboss.test.classinfo.test.ClassInfoArrayTest.testArrayType(ClassInfoArrayTest.java:61) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071717#4071717 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071717

18 years, 8 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Metadata Support for Transactional Web Services

by mark.little＠jboss.com

"bill.burke(a)jboss.com" wrote : Yes, this stuff is great. If we market it right, should be an interesting value-add for our customers and users. | Absolutely. Only Microsoft has anything comparable and they're still behind the curve. anonymous wrote : | Lol, Mark, cracking the whip....Right, get your damn paper done! Yee-Haw ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071582#4071582 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4071582

18 years, 8 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 August 2007