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

[Design of JBoss Portal] - Re: Portlet module generification

by chris.laprun＠jboss.com

I caught one such bug as well while generifying WSRP (not finished). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117744#4117744 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117744

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by jason.greene＠jboss.com

"bstansberry(a)jboss.com" wrote : | With Hibernate entity caching there's no second node, as the value is a single Object[] representing the entity fields. | Even better, so in that case, you can just set the value to be Object[]. anonymous wrote : | Some problems with this: | | 1) Can lead to deadlocks: node A updates entity 1, node B updates entity 2; they resolve to the same hashcode. Even with your UUID approach you can have that problem if A and B are inserting. | Thats not a deadlock, the updates would be serialized though. For a deadlock to occur, you have to update multiple entities in the same cache transaction in a different order, and even in that condition it would just be a timeout. The locking granularity is only as good as the hashcode algorithm, but I think that is reasonable. We would also need to detect the lack of a hashcode function, and provide our own (since the default is based off of identity, which does not work in a cluster). anonymous wrote : | 2) If you don't have two nodes per entity, putForExternalRead no longer works properly, since it uses the presence of the node to decide to quickly abort. That may be trivial to solve; I don't know. | I believe this can be solved by modifying putForExternalRead to not only check for node existence, but also key existence. anonymous wrote : | 3) With the 2 node solution, where does the UUID come from? These aren't sessions; each node in the cluster would need to come up with the same UUID for a given key. | In the 2 node solution, which does not seem necessary, the UUID does not need to be known by all nodes. It is generated once, for the entire lifespan of the second node. After that point all gets use the entity key, which is known, to retrieve the UUID that is stored as the value of the key on the first node. That UUID is then used to construct the FQN to the node containing the data. anonymous wrote : | Sorry, still jet-lagged; I can only raise problems today; no solutions :( Keep them coming! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117743#4117743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117743

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by alesj

"alesj" wrote : | I think it's missing the features of MetaDataVisitorNode. ;-) Or not. :-) | public List<BeanMetaData> getBeans() | { | AbstractBeanMetaData gbf = new AbstractBeanMetaData(); | gbf.setName(name); | gbf.setAliases(aliases); | gbf.setBean(GenericBeanFactory.class.getName()); | gbf.setMode(mode); | Set<PropertyMetaData> properties = new HashSet<PropertyMetaData>(); | gbf.setProperties(properties); | properties.add(createProperty("bean", bean)); | properties.add(createProperty("classLoader", classLoader)); | properties.add(createProperty("constructor", constructor)); | properties.add(createMapProperty("properties", properties)); | properties.add(createProperty("start", start)); | properties.add(createProperty("create", create)); | gbf.setDemands(demands); | gbf.setDepends(depends); | gbf.setSupplies(supplies); | gbf.setInstalls(installs); | gbf.setUninstalls(uninstalls); | gbf.setInstallCallbacks(installCallbacks); | gbf.setUninstallCallbacks(uninstallCallbacks); | return Collections.singletonList((BeanMetaData) gbf); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117725#4117725 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117725

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by alesj

"adrian(a)jboss.org" wrote : | I fixed this by using my new improved version of the GenericBeanFactoryMetaData, | I called it GenericBeanFactoryMetaData2. | I think it's missing the features of MetaDataVisitorNode. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117724#4117724 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117724

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by alesj

"adrian(a)jboss.org" wrote : | But this implementation is incomplete, it needs to add the install callbacks "etc." into the constructed BeanMetaData: | Is install callbacks even legit for beanfactory? Since once the bean is created, we have no control. So, only the callbacks at the time of creation would be applied - meaning that the order of creation would be important. e.g. getting different behavior if something changes the order, a new dependency ... And no way of applying uninstalls. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117718#4117718 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117718

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by bstansberry＠jboss.com

"jason.greene(a)jboss.com" wrote : | This is an example of how it could possibly work with entity caching: | | | /entities/[TYPE]/[HASHCODE] | | KEY1 -> UUID1 | | KEY2 -> UUID2 | | KEY3 -> UUID3 | | /entities/[TYPE]/[HASHCODE]/[UUID1] | | [FIELD_NAME] -> [FIELD_VALUE] | | ... | | /entities/[TYPE]/[HASHCODE]/[UUID2] | | [FIELD_NAME] -> [FIELD_VALUE] | | ... | | /entities/[TYPE]/[HASHCODE]/[UUID3] | | [FIELD_NAME] -> [FIELD_VALUE] | | ... | | | | So a given entity requires 2 node lookups, no matter the number of collisions. There will, of course, be contention on the hashcode, but this is expected. With Hibernate entity caching there's no second node, as the value is a single Object[] representing the entity fields. Some problems with this: 1) Can lead to deadlocks: node A updates entity 1, node B updates entity 2; they resolve to the same hashcode. Even with your UUID approach you can have that problem if A and B are inserting. 2) If you don't have two nodes per entity, putForExternalRead no longer works properly, since it uses the presence of the node to decide to quickly abort. That may be trivial to solve; I don't know. 3) With the 2 node solution, where does the UUID come from? These aren't sessions; each node in the cluster would need to come up with the same UUID for a given key. Sorry, still jet-lagged; I can only raise problems today; no solutions :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117717#4117717 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117717

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by adrian＠jboss.org

So once the Map issue is resolved, the remaining work is to do the same for the aop-mc-int deployment stuff then we can ditch all the schema binding initializer code. That will make the MC jar a lot smaller. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117710#4117710 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117710

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | 3) The remaining issues are the BeanFactory tests are all failing. | I fixed this by using my new improved version of the GenericBeanFactoryMetaData, I called it GenericBeanFactoryMetaData2. But this implementation is incomplete, it needs to add the install callbacks "etc." into the constructed BeanMetaData: | | public List<BeanMetaData> getBeans() | { | AbstractBeanMetaData gbf = new AbstractBeanMetaData(); | gbf.setName(name); | gbf.setAliases(aliases); | gbf.setBean(GenericBeanFactory.class.getName()); | gbf.setMode(mode); | Set<PropertyMetaData> properties = new HashSet<PropertyMetaData>(); | gbf.setProperties(properties); | properties.add(createProperty("bean", bean)); | properties.add(createProperty("classLoader", classLoader)); | properties.add(createProperty("constructor", constructor)); | properties.add(createMapProperty("properties", properties)); | properties.add(createProperty("start", start)); | properties.add(createProperty("create", create)); | // etc. | return Collections.singletonList((BeanMetaData) gbf); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117709#4117709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117709

18 years, 3 months

1
0
0 / 0

[Design of JBoss Portal] - Portlet module generification

by julien＠jboss.com

I have started to generify the portlet module stuff. So far so good, it helped me to catch one (minor) bug thanks to the type safety introduced. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117706#4117706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117706

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by jason.greene＠jboss.com

The serialization format uses the class desc followed by the value. We could do this as well, using an illegal identifier symbol for a delimiter (;) so your example would become: foo.package.Type1;A The classloading problems can be easily handled by lazily loading the type when that portion of the fqn is accessed as an object. When accessed as a string, the above form is returned. However, there is nothing stopping the developer from doing this themself. So after thinking about it. It is not worth the effort. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117694#4117694 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117694

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