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

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

by adrian＠jboss.org

"alesj" wrote : | | IntrospectionTypeInfoFactory currently only knows about TypeInfoFactory. | | So no ClassInfoHelper from there. ;-) | | Exposing IntrospectionTypeInfoFactory as other helpers? Why? The helpers are implementation details for lazy loading of information. Javassist doesn't need that since it already implements it internally. In fact, a lot of the reflection classes do as well already in recent versions of the JDK. That's one of the reasons why reflection has gotten much faster over the years, but it still isn't as fast as the javassist version in my testing. ;-) Also we can make the javassist stuff even faster if we can come up with an api that links the classloading, aop (javassist) and classinfo byte code loading together. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063251#4063251 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063251

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: MetaBridge

by thomas.heute＠jboss.com

Just so you know, the management portlet and wsrp management portlet are now using myFaces, they are 2 sar files isolated in their own classoader and both bundles the myFaces libraries. So at least now, there can be no conflict with any other webapp. So anyone can ditch/upgrade/change the jsf-libs without affecting our two portlets. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063250#4063250 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063250

18 years, 9 months

1
0
0 / 0

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

by alesj

| public void readObject(...) | { | super.readObject(...); | typeInfoFactory = new IntrospectionTypeInfoFactory(...); | classInfoHelper = typeInfoFactory.getClassInfoHelper(); | // etc. | } | "alesj" wrote : | What about non-serializable references to ClassInfoHelper and AnnotationHelper? | How do you (de)serialize those? | IntrospectionTypeInfoFactory currently only knows about TypeInfoFactory. So no ClassInfoHelper from there. ;-) Exposing IntrospectionTypeInfoFactory as other helpers? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063247#4063247 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063247

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: MetaBridge

by julien＠jboss.com

So faces parse web.xml to find out stuff about how it is mapped since no such meta data is available from the servlet context ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063244#4063244 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063244

18 years, 9 months

1
0
0 / 0

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

by alesj

"adrian(a)jboss.org" wrote : You should probably also include a static reference for a singleton TypeInfoFactory | somewhere to avoid the continous object construction for lots of serialization. Making IntrospectionTypeInfoFactory and JavassistTypeInfoFactory also available as singletons? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063242#4063242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063242

18 years, 9 months

1
0
0 / 0

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

by alesj

I guess we are talking about ClassInfoImpl. anonymous wrote : I don't understand this new helper? | | All you need to do is rehook into the typeinfo factory using some package | protected method and recreate the other state during deserialization | (most of it can be left to be initialized lazily?) | What about non-serializable references to ClassInfoHelper and AnnotationHelper? How do you (de)serialize those? anonymous wrote : | | | | Object readResolve() | | { | | IntrospectionTypeInfoFactory factory = new IntrospectionTypeInfoFactory(); | | return factory.getTypeInfo(annotatedElement); | | } | | | | Then you aren't creating multiple ClassInfo objects during deserialization, | especially if they are already present in the cache. This looks like an optimal solution. If you are in the same Classloader then there is no new ClassInfo instance creation, since _we_ been serialized, so _we_ exist in cache. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063240#4063240 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063240

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMSHeader fields

by beve

anonymous wrote : | What's the problem specifically? | Well, this is how I'm currently doing it: | if (jmsMsg.getJMSReplyTo()!=null) | { | Destination replyToDestination = jmsMsg.getJMSReplyTo(); | String destType = null; | String destName = null; | String connection = "ConnectionFactory"; | if ( replyToDestination instanceof Queue ) | { | Queue queue = ( Queue ) replyToDestination; | destName = queue.getQueueName(); | destType = JMSEpr.QUEUE_TYPE; | } | else | { | Topic topic = ( Topic ) replyToDestination; | destName = topic.getTopicName(); | destType = JMSEpr.TOPIC_TYPE; | } | message.getHeader().getCall().setReplyTo( new JMSEpr( destType , destName, connection ); | I'm a bit concerned about the connection variable. I looks like this should be a connection factory, but should it be normal one or a clustered connection factory. Maybe I should get this from the configuration file? /Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063228#4063228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063228

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: jboss-head build testsuite action plan

by rrajesh

This algorithm would work fine for build breakages. However one issue when we rollback the commits to a previous working version, we might lose the commits that were done after the build started; which would have ideally been included in the next build. In that case, can we rollback to the previous working version and then apply the commits that were done after this build started? For testsuite regressions, * We need to get in place a notion of known failures, to actually track the regressions. And, is rolling back the commits, a right option for testsuite regressions as well? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063227#4063227 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063227

18 years, 9 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Optional input for AbstractSimpleVFSRealDeployer

by adrian＠jboss.org

Is there a reason why didn't commit your AbstractOptionalVFSRealDeployer to the deployers project so that others don't have to "reinvent the wheel"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063224#4063224 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063224

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: jboss-head build testsuite action plan

by scott.stark＠jboss.org

If we are rolling back changes that break the build, then yes, that seems like the algorithm. I would like the build to be triggered by an N minute quiescent period with a one minute resolution rather than 15 though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063218#4063218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063218

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