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

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

"galder.zamarreno(a)jboss.com" wrote : Hey David, I've started to look into how to integrate JBoss Marshalling into JBoss Cache. Here's a list of things I wanted to ask you about: | | 1.- Would it be possible to upload source jars to the maven repo for next release? | Will do. If I don't, feel free to yell at me. :-) "galder.zamarreno(a)jboss.com" wrote : 2.- Looking at JBoss Marshalling, I saw that you're considering primitive arrays as known classes but primitive object arrays are not. Is this an oversight or on purpose? i.e. | | map.put(Byte[].class, Protocol.ID_BYTE_ARRAY_CLASS); | | map.put(Boolean[].class, Protocol.ID_BOOLEAN_ARRAY_CLASS); | | map.put(Character[].class, Protocol.ID_CHAR_ARRAY_CLASS); | | ... | The reason for this is that primitive array classes do not extend the object array class. Since all object arrays are represented by a single byte plus the component type information, there should be one byte to signify the array plus one byte for the primitive wrapper, which is two bytes (not too bad). Likewise, e.g. Byte[][].class would be three bytes, etc. If the length is still unacceptably long, a ClassTable can be used to reduce it down to a single byte. "galder.zamarreno(a)jboss.com" wrote : 3.- Looks like collections like ArrayList, LinkedList, Hashmap, TreeMap...etc are treated as Serializable objects whereas JBoss Cache treats them differently. Instead, we look through the collection and see if it's an object we might want to marshall it in a diferent way to standard Serialization, i.e. a list of ReplicableCommand (ReplicableCommand does not implement Serializable). How would we deal with this? That can depend. You can always use an Externalizer for those types to override how the serialization occurs. Another option is to use an ObjectTable, which lets you customize the serialization process to a slightly higher degree (at the cost that both the reader and the writer need to have matching ObjectTable specifications; Externalizers do not have this restriction as the writer's Externalizer is itself serialized). "galder.zamarreno(a)jboss.com" wrote : 4.- Also, JBC treats SingletonList instances separately by just copying the single object within them. Any plans to add this to JBoss Marshalling as well? This could also be easily handled with an Externalizer. "galder.zamarreno(a)jboss.com" wrote : Other than this, JBoss Marshalling seems to contain the rest of optimisation JBC did for known type arrays, repeated objects, null values...etc. So, in spite of agreeing with Jason's statement in https://jira.jboss.org/jira/browse/JBCACHE-1336 earlier today: | | anonymous wrote : It might be more useful to define type marshallers outside of the type since most of our magic numbers apply to types not under our control (JDK types). | | I don't think this might apply any longer if the above points can be resolved. IOW, all types that are not under our control would already be handled by JBoss Marshalling which means that we can concentrate on our types and we could then use @Marshallable annotations. Yeah, I think that between ClassTable, ObjectTable and ClassExternalizerFactory you can implement all the customizations you need. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220413#4220413 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220413

17 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Transaction Status.STATUS_ROLLEDBACK

by jfrantzius

"mark.little(a)jboss.com" wrote : Well like I said, in the current code you can call rollback and it won't throw an exception if the transaction has already rolled back. | | I'm not sure which version of TS is in 4.2.1GA though. Maybe Jonathan can answer? I'm seeing the exact same problem with JBoss AS 4.2.3.GA, i.e. I cannot rollback the UserTransaction once its status has become STATUS_ROLLEDBACK (after a timeout). So that would be a bug then? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220398#4220398 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220398

17 years

1
0
0 / 0

[Design of Management Features on JBoss] - Re: ManagedObjects for MBeans

by ips

I'm glad you agree :) The jboss.web ManagedComponents are not the only place such lumping together is done. For example, the ComponentType{type=MCBean, subtype=*} component type is used as the type for a bunch of different types of underlying MBeans. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220396#4220396 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220396

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remaining EasyMock tests

by clebert.suconic＠jboss.com

Paging & Journal tests will require UnitTests also. There are a few races that I tested using Unittests that would be easier to reproduce them as UnitTests. In the past we would consider anything using RealFile as an integration test, and that's why we had some common classes between Unit and integration. I will place those PagingTest and JournalTests as UnitTests. For the easyMock tests: PagingImplTest: usage is minimal, just creating a NiceMock that I could create an implemented Mock if you really want to get rid of EasyMock. (I'm not doing the upside-down programming style on some of these tests). Journal: There are a few tests using EasyMock to validate the encoding. I will get rid of those. I will still keep the FakeJournalUnitTests for now, as they are really easy to debug when things are going wrong during development on the journal. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220389#4220389 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220389

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: mailing list test

by blake.bowers＠jboss.com

another test for dev list. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220385#4220385 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220385

17 years

1
0
0 / 0

[Design of Management Features on JBoss] - Re: ManagedObjects for MBeans

by alesj

"ips" wrote : Otherwise, we would have to parse the component names to figure out which type of jboss.web MBean we are dealing with. | This is definitely how it should _not_ be done. ;-) Depending on the name is just bad contract. e.g. we might drop the names in MC, just have aliases for some beans View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220350#4220350 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220350

17 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing AspectManager/Domains to understand jboss

by jason.greene＠jboss.com

I agree with Adrian's position regarding classloading. We should never violate the classloading configuration. That leads to unexpected and unpredicted behavior. If we feel the urge to add "magic" here, then we are probably doing something wrong. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220344#4220344 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220344

17 years

1
0
0 / 0

[Design of Management Features on JBoss] - ManagedObjects for MBeans

by ips

I noticed that the variouus types of jboss.web MBeans are all exposed as ManagedComponents with type ComponentType{type=MBean, subtype=Web}. For example, my AS5 instance has the following ManagedComponents: org.jboss.managed.plugins.ManagedComponentImpl@17498cb{name=jboss.web:host=127.0.0.1,type=Host, type=ComponentType{type=MBean, subtype=Web}, owner=ManagedDeployment@23354564} org.jboss.managed.plugins.ManagedComponentImpl@ca251{name=jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor, type=ComponentType{type=MBean, subtype=Web}, owner=ManagedDeployment@23354564} org.jboss.managed.plugins.ManagedComponentImpl@1babf49{name=jboss.web:name=http-127.0.0.1-8080,type=ThreadPool, type=ComponentType{type=MBean, subtype=Web}, owner=ManagedDeployment@23354564} It would be more intuitive if each of the different types of jboss.web MBeans were exposed as a different type of ManagedComponent, e.g.: ComponentType{type=MBean, subtype=Web:Host} ComponentType{type=MBean, subtype=Web:GlobalRequestProcessor} ComponentType{type=MBean, subtype=Web:ThreadPool} That way, in the Jopr jboss-as-5 plugin, each component type can be mapped one-to-one to an RHQ ResourceType. Otherwise, we would have to parse the component names to figure out which type of jboss.web MBean we are dealing with. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220340#4220340 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220340

17 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing AspectManager/Domains to understand jboss

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : Probably the easiest compromise is just log a warning, e.g. | Agreed "adrian(a)jboss.org" wrote : | But some might think that is serious problem if is B is really the security aspect | and b.BInterceptor is really the Authentication interceptor. :-) | i.e. "Blah" would not have the intended security aspect. At least we are logging it, and they can fix it by adding an import to the affected target archive. Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220331#4220331 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220331

17 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing AspectManager/Domains to understand jboss

by adrian＠jboss.org

Probably the easiest compromise is just log a warning, e.g. WARN Not apply aspect B to com.acme.Blah because b.BInterceptor cannot be loaded from classloader A.jar But some might think that is serious problem if is B is really the security aspect and b.BInterceptor is really the Authentication interceptor. :-) i.e. "Blah" would not have the intended security aspect. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220324#4220324 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220324

17 years

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 2009