March 2008 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: Compatibility of JBoss 5 / migration of applications

by ALRubinger

"ALRubinger" wrote : Also good news for this type of scenario is that we'll soon be allowing existing AS installations to upgrade EJB3 without the entirety of the AS This should read: "...existing AS 5.x installations ...". S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134407#4134407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134407

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: aop-mc-int tests failing on annotation parsing

by kabir.khan＠jboss.com

http://jira.jboss.com/jira/browse/JBMICROCONT-250 is in now View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134406#4134406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134406

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: Compatibility of JBoss 5 / migration of applications

by ALRubinger

>From an EJB3 perspective, AS 4.2.2.GA and AS 5.0.0.Beta4 are closely-aligned. When making the jump to the 5-series, most of my previous applications' migration issues centered around packaging and declaration of dependencies (as the underlying container, MC, has changed, along with many core services and ObjectNames). If I were them, I'd try deploying their existing EARs/JARs on each platform and see where the differences lie. Given that they've got some time before their deliverables, I'd try to get on the AS5 train early as possible. 4.2.2 is certainly more stable, but they want to be developing alongside our own releases to stay in line incrementally instead of worrying about a large migration later. Also good news for this type of scenario is that we'll soon be allowing existing AS installations to upgrade EJB3 without the entirety of the AS (via our new/reinstated Plugin Installer). Where are you giving the training? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134404#4134404 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134404

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: Compatibility of JBoss 5 / migration of applications

by bdecoste

EJB3 applications developed on 4.x will require some minimal modifications for deployment on 5.0, which is targeted for release late spring. The modifications will be concerning the jboss extensions to the spec, such as package names of jboss extension annotations. There will also likely be configuration changes required (e.g. ejb3-interceptors-aop.xml). In a nutshell, the spec based implementations should port fine - it's the extensions that could require some work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134403#4134403 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134403

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBVFS 2.0.0.Beta10/2.0.0.CR1 releases

by scott.stark＠jboss.org

I fixed the writing of the more deeply nested jars, but this fails to deserialize because the underlying sun.net.www.protocol.jar.JarURLConnection does not understand nested jars: | java.io.FileNotFoundException: JAR entry level2.zip!/level3.zip not found in C:\home\svn\JBossMC\VFS\trunk\target\classes\vfs\test\level1.zip | at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:114) | at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:69) | at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.readObject(AbstractJarHandler.java:213) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | 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 org.jboss.test.AbstractTestCase.deserialize(AbstractTestCase.java:352) | at org.jboss.test.AbstractTestCase.serializeDeserialize(AbstractTestCase.java:367) | at org.jboss.test.virtual.test.NoCopyJarsUnitTestCase.testLevelZips(NoCopyJarsUnitTestCase.java:179) | To properly serialize jar files we have to provide our own jar: protocol implementation, or not rely on the jar file JarURLConnection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134400#4134400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134400

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Compatibility of JBoss 5 / migration of applications

by camunda

Hi! I deliver a JB161-Training for JBoss next week and the customer had one question in advance which I want to forward to this forum, hopefully somebody has an answer to that? The question is, if EJB3 applications developed today with maybe JBoss 4.2 can be easily deployed on JBoss AS 5 (because the production release of the application will be next year)? Or should they be patient with some features? Or other recommendations? Since Java EE is a standard, there shouldn't be too big differences, I think. But some stuff isn't standardized. So I am not sure here and an answer would be great since ... Thanks a lot Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134397#4134397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134397

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Using a CompositeMetaType for a Map with String keys?

by mark.spritzler

I think the tests should change. Here is why, I think, and I am assuming here, that TableMetaTypes were originally designed for "Maps" However, their actual implementations ended up being a hodgepodge MetaType. Each row in the TableMetaType can have its own structure. So one row might have 5 columns and the next row might have 10 columns. TableMetaType is now a very powerful MetaType, but I think overkill for Maps. Personally, while I see the power of TableMetaTypes, I think we should try to avoid using them. Anything we have, can be created combining the Map, List and Simple/Generic types to match our needs. I will also add that my opinion is coming from how JON types are designed, and we just have Map, List and Simple properties and have yet to come across anything that we couldn't handle. like creating List of Maps with Simples for security domains in JMS and config properties for Connection Factories. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134394#4134394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134394

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: aop-mc-int tests failing on annotation parsing

by kabir.khan＠jboss.com

Modifying methodHasAnnotations to this solves the problem. | private boolean methodHasAnnotations(MetaData metaData, MethodInfo mi) | { | MethodSignature sig = new MethodSignature(mi); | MetaData methodMD = metaData.getComponentMetaData(sig); | | if (hasMetaDataAtInstanceLevel(methodMD)) | { | return true; | } | return false; | } | | private boolean hasMetaDataAtInstanceLevel(MetaData metaData) | { | if (metaData != null) | { | MetaData instanceMetaData = metaData.getScopeMetaData(CommonLevels.INSTANCE); | if (instanceMetaData != null && instanceMetaData.isEmpty() == false) | { | return true; | } | } | return false; | } | I will run the aop-mc-int tests before commiting View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134392#4134392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134392

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: aop-mc-int tests failing on annotation parsing

by kabir.khan＠jboss.com

For http://jira.jboss.com/jira/browse/JBMICROCONT-250 the problem is that we are getting a proxy created although there are no aspects. Proxies cannot have their fields set. The reason the proxy is created is that the bean used in MapAnnotationTestCase.testCustomMapPreInstantiated() has method level annotations on the bean class | public class FromPreinstMapSimpleBean extends SimpleBean | { | /** The serialVersionUID */ | private static final long serialVersionUID = 1L; | | @MapValue( | value = { | @EntryValue( | key=@Value(string = @StringValue("string1")), | value=@Value(string = @StringValue("string2")) | ), | @EntryValue( | key=@Value(string = @StringValue("string2")), | value=@Value(string = @StringValue("string1")) | ) | }, | keyClass = "java.lang.String", | valueClass = "java.lang.String" | ) | public void setPreInstantiatedMap(CustomMap preInstantiatedMap) | { | super.setPreInstantiatedMap(preInstantiatedMap); | } | ... | } | When AOPConstructorJoinPoint does its check to see if instance-level metadata exists | private boolean hasMethodMetaData(MetaData metaData) | { | //Check for method annotations | ClassInfo info = constructorInfo.getDeclaringClass(); | while (info != null) | { | MethodInfo[] methods = info.getDeclaredMethods(); | if (methods != null) | { | for (MethodInfo mi : methods) | { | if (methodHasAnnotations(metaData, mi)) | { | return true; | } | } | } | info = info.getSuperclass(); | } | | return false; | } | | private boolean methodHasAnnotations(MetaData metaData, MethodInfo mi) | { | MethodSignature sig = new MethodSignature(mi); | MetaData methodMD = metaData.getComponentMetaData(sig); | if (methodMD != null) | { | return methodMD.getAnnotations() != MetaData.NO_ANNOTATIONS; | } | return false; | } | methodHasAnnotations returns true. The methodMD contains only one retrieval, of type AnnotatedElementMetaDataLoader, which has annotations since they exist in the class itself. It should only return true if these annotations exist at instance level or lower View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134391#4134391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134391

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Using a CompositeMetaType for a Map with String keys?

by scott.stark＠jboss.org

I update the DefaultMetaTypeFactory.generate(TypeInfo typeInfo) handling of map types to create a MapCompositeMetaType for String,? parameterized maps: | if (typeInfo.isMap()) | { | // See if this is a Map<String,?> type | ClassInfo classInfo = (ClassInfo) typeInfo; | TypeInfo[] types = classInfo.getActualTypeArguments(); | if (types != null) | { | TypeInfo keyType = types[0]; | TypeInfo valueType = types[1]; | if(keyType.getName().equals(String.class.getName())) | { | // Use MapCompositeMetaType | MetaType valueMetaType = resolve(valueType); | return new MapCompositeMetaType(valueMetaType); | } | } | // No, return the general map type | return generateMap(classInfo); | } | but the following 4 tests fail because they all use types that fall into the Map(String, ?) pattern, and they are expecting TableMetaType/TableValues: | Failed tests: | testSimpleMap(org.jboss.test.metatype.values.factory.test.MapValueFactoryUnitT | estCase) | testCompositeValueMap(org.jboss.test.metatype.values.factory.test.MapValueFact | oryUnitTestCase) | testSimpleMap(org.jboss.test.metatype.types.factory.test.MapMetaTypeFactoryUni | tTestCase) | testCompositeValueMap(org.jboss.test.metatype.types.factory.test.MapMetaTypeFa | ctoryUnitTestCase) | What do we want to change, tests or how the factory gets configured for MapCompositeMetaType? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134388#4134388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134388

18 years, 1 month

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 March 2008