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

by ALRubinger

I think the merits of adding the metadata abstractions to the Containers are pretty apparent, but I'm concerned with the amount of plumbing code this introduces. For every annotation or XML node, we'll have to make corresponding methods which either delegate back to the metadata object model or redirect to our own instance members. What are the arguments against bypassing the abstractions and accessing this information directly in the container like: container.getJBossAssemblyDescriptorMetaData().getJndiName() instead of: container.getJndiName() Sure, 2) is more elegant, but 1) requires no plumbing/abstractions. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113534#4113534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113534

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Serialization, NoSuchMethodException in ProfileServiceUn

by scott.stark＠jboss.org

OK. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113532#4113532 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113532

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: New state transfer in JBoss Cache

by bstansberry＠jboss.com

anonymous wrote : D doesn't care about conflicting remote prepares since at least someone else in the cluster would have detected this and the prepare would roll back anyway. | Here's the specific scenario I was thinking about when I mentioned "one concern is D receives things in different order than A did due to message retransmission." You've got {A, B, C} with new joiner D. Messages as seen by {A, B, C} 1) B:PREPARE-TX1 2) B:COMMIT-TX1 3) C:PREPARE-TX2 4) C:COMMIT-TX2 TX1 and TX2 have a locking conflict, but there is no issue due to above ordering. But, D has a hiccup and drops message 2, requiring JGroups retransmission. Our JGroups stacks don't provide total ordering, just ordering from the same sender. So, now D sees and queues the sequence as: 1) B:PREPARE-TX1 2) C:PREPARE-TX2 -- oops blocks!! 3) B:COMMIT-TX1 -- doesn't get taken off queue due to block 4) C:COMMIT-TX2 When D drains the queue, message #2 will block due to lock conflict, preventing the needed message #3. JGroups' concurrent stack avoids that kind of problem during normal operation by allowing the B and C messages to be processed in parallel. :-) But, as soon as you introduce a single queue, you can get the problem back again. (The message reordering thing I mentioned was meant to help deal with that by scanning the queue and trying to handle B:COMMIT-TX1 before C:PREPARE-TX2.) This is kind of an edge case, but it's there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113531#4113531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113531

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Serialization, NoSuchMethodException in ProfileServiceUn

by alesj

OK, I'll fix this. But you'll have to do the release - in this case of commons as well. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113521#4113521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113521

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Serialization, NoSuchMethodException in ProfileServiceUn

by scott.stark＠jboss.org

Ok, I see. The initial implementation getGenericArrayType that should be simple is to handle primitive arrays. The problem is that the getGenericArrayType does not belong in the WeakTypeClass as a private method as it cannot be override to return an ArrayInfo. The implementation should simply be the following in IntrospectionTypeInfoFactoryImpl: | protected ArrayInfo getGenericArrayType(GenericArrayType type) | { | Type compType = type.getGenericComponentType(); | TypeInfo componentType = getTypeInfo(compType); | ArrayInfoImpl result = new ArrayInfoImpl(componentType); | return result; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113515#4113515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113515

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Serialization, NoSuchMethodException in ProfileServiceUn

by alesj

Yes. This is when you are trying to transform runtime type instance - which is generics unaware. If you did something like this: | public class MyClass | { | public byte[] someBytes(); | } | And then (pseudo) MyClass.getMethod("someBytes").getGenericReturnType(). Then it would fail. In this code | public T get(Type type) | { | if (type == null) | throw new IllegalArgumentException("Null type"); | | if (type instanceof ParameterizedType) | return getParameterizedType((ParameterizedType) type); | else if (type instanceof Class) | return getClass((Class<?>) type); | else if (type instanceof TypeVariable) | // TODO Figure out why we need this cast with the Sun compiler? | return (T) getTypeVariable((TypeVariable) type); | else if (type instanceof GenericArrayType) | return getGenericArrayType((GenericArrayType) type); | else if (type instanceof WildcardType) | return getWildcardType((WildcardType) type); | else | throw new UnsupportedOperationException("Unknown type: " + type + " class=" + type.getClass()); | } | The first example is picked up by (instance of Class), where the 2nd one is by the method I mentioned before. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113512#4113512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113512

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Serialization, NoSuchMethodException in ProfileServiceUn

by scott.stark＠jboss.org

Its already there in some form as this test produces the correct primitive ArrayInfo: | public void testByteArrayInfo() | { | TypeInfoFactory factory = getTypeInfoFactory(); | byte[] x = {}; | TypeInfo xinfo = factory.getTypeInfo(x.getClass()); | getLog().debug(xinfo); | assertTrue(xinfo instanceof ArrayInfo); | ArrayInfo ainfo = (ArrayInfo) xinfo; | } | | 28 DEBUG [ByteArrayUnitTestCase] ArrayInfoImpl@3148aa23{name=[B} | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113507#4113507 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113507

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Serialization, NoSuchMethodException in ProfileServiceUn

by alesj

Found it. :-) >From WeakTypeCache: | private T getGenericArrayType(GenericArrayType type) | { | // TODO JBMICROCONT-131 this needs implementing properly | return get(Object[].class); | } | Adrian? :-) Or what to do? Since if implementing this was trivial, it would have been already done. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113503#4113503 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113503

18 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Problems with aspects configured in jboss-aop-jboss5.dep

by flavia.rainone＠jboss.com

Adrian, Kabir, who usually works on this part of the project, is on vacation. Let me know if this is something that must be solved before he comes back (beginning of January). In this case, I can take a look at this racing issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113488#4113488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113488

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Serialization, NoSuchMethodException in ProfileServiceUn

by alesj

You're right. :-( This test shows it: | public class Test | { | public static void main(String[] args) | { | try | { | Configuration configuration = new PropertyConfiguration(); | BeanInfo beanInfo = configuration.getBeanInfo(ClassLoader.class); | Set<MethodInfo> methods = beanInfo.getMethods(); | for(MethodInfo mi : methods) | { | byte[] bytes = serialize((Serializable)mi); | Object o = deserialize(bytes); | System.out.println("o = " + o); | } | } | catch (Exception e) | { | e.printStackTrace(); | } | } | | protected static byte[] serialize(Serializable object) throws Exception | { | ByteArrayOutputStream baos = new ByteArrayOutputStream(); | ObjectOutputStream oos = new ObjectOutputStream(baos); | oos.writeObject(object); | oos.close(); | return baos.toByteArray(); | } | | protected static Object deserialize(byte[] bytes) throws Exception | { | ByteArrayInputStream bais = new ByteArrayInputStream(bytes); | ObjectInputStream ois = new ObjectInputStream(bais); | return ois.readObject(); | } | } | Any ideas? I'll have a look at it. Trying to fix it, and commit together with all the changes needed for Alexey. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113487#4113487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113487

18 years, 3 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 December 2007