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

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by alesj

"adrian(a)jboss.org" wrote : | Anyway, like you say, this is a trivial feature, its the serialization and alias stuff that I was more referring to. The alias feature was there long ago, even introduced at R&D presentation. ;-) But it was done wrong. The idea stayed the same. Only the impl improved. It improved on your comment of being a full dependency. :-) The current impl is good - it does exactly what we want. I think it will be useful, once people have a lot of beans to handle. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063898#4063898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063898

18 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Listen address of JBossTS ports not configurable

by mark.little＠jboss.com

Yes, that's pretty much what I had in mind last night when I was looking at this from a stand-alone perspective. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063896#4063896 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063896

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassInfo being serializable

by alesj

"adrian(a)jboss.org" wrote : | But you'll probably need to introduce a Reflection* subclass for | each to make the serialization work, | I did a quick change - moved readResolve() from ClassInfoImpl to ReflectClassInfoImpl. How come all the tests still work? Not covering all the corner cases? "adrian(a)jboss.org" wrote : | i.e. add readResolve() into the introspection factory. | What about if I add a super class for all Reflection* subclases with readResolve there? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063892#4063892 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063892

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by adrian＠jboss.org

"alesjSilence means approval? :-)[/quote wrote : | | Only when you've given people chance to respond. :-) | Anyway, like you say, this is a trivial feature, its the serialization and alias stuff | that I was more referring to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063888#4063888 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063888

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassInfo being serializable

by adrian＠jboss.org

None of them makes any direct use of reflection, so a reflection specific subclass has never been necessary before. But you'll probably need to introduce a Reflection* subclass for each to make the serialization work, i.e. add readResolve() into the introspection factory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063886#4063886 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063886

18 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Listen address of JBossTS ports not configurable

by adrian＠jboss.org

"mark.little(a)jboss.com" wrote : [ | Presumably you'd want this capability even if you were running JBossTS stand-alone, i.e., outside of JBossAS? If that's the case, any way we attempt to address this should work with the JBossAS approach, but not be dependant on it. | The JBossAS approach is to inject a bind address: //@Inject setBindAddress(String address); and then the configuration is usually done form a system property | <attribute name="BindAddress">${jboss.bind.address}</attribute> | But IMHO this is a bad way to do it. There should really be a way to inject a ServerSocketFactory which allows a lot more configuration of what the properties are and what protocol, e.g. ssl In fact, my real opinion is that you should do the reverse and provide an implementation of an interface like the following: void run(InputStream is, OutputStream os) throws IOException {} a bit like a servlet container or IIOP and then the host (e.g. JBoss) decides how those streams are constructed and invokes your interface to handle it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063880#4063880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063880

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Consolidate delegating cache loader classes [JBCACHE-1134]

by galder.zamarreno＠jboss.com

This thread is to discuss http://jira.jboss.com/jira/browse/JBCACHE-1134. Here's a summary of my thoughts taken from JIRA: In the org.jboss.cache.loader package, we have: o.j.c.l.DelegatingCacheLoader and o.j.c.l.AbstractDelegatingCacheLoader The second one was created by me when I first created SingletonStoreCL (doh!). I refactored common code from AsyncCL to AbstractDelegatingCL and made AsyncCL and SingletonStoreCL extend it. I have just spotted DelegatingCacheLoader which is extended by LocalDelegatingCacheLoader and TcpDelegatingCacheLoader. The difference between the classes extending DelegatingCacheLoader and the classes extending AbstractDelegatingCacheLoader is: Classes extending DelegatingCacheLoader (LocalDelegatingCacheLoader/TcpDelegatingCacheLoader) are standalone classloaders that delegate to other cache instances. ClusteredCacheLoader could be defined as a refined delegating cache loader in comparison to LDCL and TDCL, in the sense that they delegate get() calls, but don't delegate put() calls because replication takes care of it. Classes extending AbstractDelegatingCacheLoader are decorators of other class loaders that delegate to cache loaders instead of other caches. As such, AbstractDelegatingCacheLoader adds getCacheLoader()/setCacheLoader() methods that help the interaction between the decorator cache loader and the real cache loader. So, this is what I'm proposing: - two interfaces, one for CLs that delegate to caches and one for CLs that delegate to CLs. - provide abstract implementations for these interfaces with common functionality. - refactor CL implementations to adhere to this hierarchy. This should include making ClusteredCacheLoader implement the interface or extend the abstract implementation, of a CL that delegates to another cache taking in account that it only delegates get() operations. Thoughts? p.s. interfaces need a bit more baking to define the names and the contract...etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063877#4063877 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063877

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by alesj

"adrian(a)jboss.org" wrote : | This is most important so you don't have to unpick everything and redo it | like you had to do with the ClassInfo serialization. :-( That's was me getting my feet wet with whole container java.lang abstraction and its serialization. An educational feedback. And I still don't understand why it works by only adding deserialization detail on ReflectClassInfoImpl. But this is not the post to discuss that. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063875#4063875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063875

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by alesj

"adrian(a)jboss.org" wrote : | I'm not saying you'll get answers (if you do it will most likely be after you | commit anyway ;-) but at least you gives others the option to comment | and review. | I agree. That's why I posted the initial forum post yesterday around noon. And created JIRA issue. And linked starting Thomas's post will all new posts. Since this is not really a huge feature, and _nobody_ commented on either posts, I went ahead and did it. Silence means approval? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063873#4063873 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063873

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassInfo being serializable

by alesj

"adrian(a)jboss.org" wrote : What does ClassInfoImpl have to do with it? | You do it in the subclass ReflectClassInfoImpl. Yup, that would work. :-) How come this doesn't effect other subclasses of ClassInfoImpl - ArrayInfoImpl, EnumInfoImpl, InterfaceInfoImpl, AnnotationInfoImpl? They don't need typeInfoFactory, classInfoHelper, annotationHelper after deserialization? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063871#4063871 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063871

18 years, 9 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 July 2007