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

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

by adrian＠jboss.org

Ales, you really need to discuss things in the forums before you do stuff. That way you can get input on whether: * it is a good idea * your proposed solution should be done a different way * it is a part of something more generic, e.g. Bill's name<->ObjectName feature request was really done by implementing aliases e.g. This is where I described what I proposed to do to the deployers in April http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106213 here is where I warned that I was going to commit those changes http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112071 and this is where I described what I had done when I had committed http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181 with a number of other discussions in between. :-) 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. This is most important so you don't have to unpick everything and redo it like you had to do with the ClassInfo serialization. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063870#4063870 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063870

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 : Why the name of the method? It should be a property name. | Is this a spring thing again? :-) | Not that I would know. I think they have a interface you need to implement to get your name injected - BeanNameAware. I thought it is more flexible to have a method, not just setter - three more chars to write. ;-) And I always liked applyName. :-) "adrian(a)jboss.org" wrote : | And do you support something like? | | | | @InjectContextName | | public void setName(Stinrg name) {} | | or | | @Inject(fromContext="name") | | public void setName(String name) {} | | Support it in what way? This should be a part of our annotation support if that's what you mean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063865#4063865 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063865

18 years, 9 months

1
0
0 / 0

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

by adrian＠jboss.org

Why the name of the method? It should be a property name. Is this a spring thing again? :-) And do you support something like? | @InjectContextName | public void setName(Stinrg name) {} | or | @Inject(fromContext="name") | public void setName(String name) {} | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063862#4063862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063862

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMSRouter refactoring

by mark.little＠jboss.com

Yes, I agree with Tom. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063861#4063861 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063861

18 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Client view of the VFSDeployment more restricted for pro

by adrian＠jboss.org

Perhaps it would be easier if the parent Deployment interface had a setAttachments() instead of implementing Attachments? That way you use the same implementation and choose how you want to pass your attachments. The default should still be a HashMap. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063860#4063860 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063860

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

"huuskart" wrote : See JBTM-253. | | JBossTS opens a bunch of network ports (three, I think, but debug output only mentions two) it listens on, but JBossTS does not give me the option to specify at which address it listens for connections. | Correct. These are for the per-node recovery manager. anonymous wrote : | As such, this is not a bug or error. However, standard practice in practically every single network listening software is to give the option for the administrator to specify at which address the software listens on. JBoss AS also gives this option, it even has a global system property jboss.bind.address, and every single service except JBossTS can be separately configured to listen on a particular address, and by default the services usually are configured to listen on ${jboss.bind.address}. | | I want to see JBossTS also support this. | | My ultimate reason for this is simply the fact that I hate to have services listening globally on ports they have no business or need listening on. Of course my servers are firewalled, so there's no problem of getting rogue connections, but even so, if I'm running a simple single JBoss AS instance, nothing will ever need to connect to JBossTS services from outside of the localhost, then I want to configure JBossTS so that it listens only on localhost. | 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. anonymous wrote : | But really, for complex installations there may be even real reasons why this needs to be configured. The server could have multiple IP addresses, run several JBoss instances, and would need to configure JBossTS in each instance to listen on different IP. | Agreed. However, we need to be careful about giving too many configuration options in this area or crash recovery could be impacted to the point of not working. anonymous wrote : | From another point of view, I could ask that if JBossTS does not need to support this configuration option, why would any service in JBoss support it, and why does JBossTS support configuring even the port at all, if listen address configuration need not be supported (these two really always go hand in hand). I think we should support this. The reason we don't is because JBossTS pre-dates JBossAS development by many years and also virtual hosting/multiple IP addresses per machine as a typical state of affairs. It may well be that what you're after is still not that widely needed, because yours is the first suggestion around this and TS has been pretty widely deployed. However, that doesn't negate the need for it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063858#4063858 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063858

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMSRouter refactoring

by tfennelly

Dan, it seems to me that the easiest thing to do would be to change the AbstractRouter.process method from being final and then just override all this behavior in the JMSRouter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063856#4063856 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063856

18 years, 9 months

1
0
0 / 0

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

by alesj

This is done. Comment from JIRA task: Support for injecting bean name is added both to plain bean and to beanfactory as well: | <bean name="MyPlainBeanName" class="org.jboss.test.kernel.deployment.support.NameAwareBean" name-method="applyName" /> | <beanfactory name="MyNameAsFactory" class="org.jboss.test.kernel.deployment.support.NameAwareBean" name-method="applyName" /> | You have to specify name of the method that will handle bean name injection - in this case it is applyName method on NameAwareBean class. It's a method support, not a property support, so setters should be fully written. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063855#4063855 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063855

18 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Client view of the VFSDeployment more restricted for pro

by adrian＠jboss.org

VFSDeployment is an interface. You can implement it how you like. The default is predertermined attachments stored in a HashMap. There's nothing to stop you using something else, e.g. deserializing them from the file system (which is what I think you are trying to do)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063854#4063854 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063854

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMSRouter refactoring

by beve

This is from AbstractRouter: | public final Message process(Message message) throws ActionProcessingException { | if(unwrap) { | route(ActionUtils.getTaskObject(message)); | } else { | route(message); | } | | return null; | } | And JMSRouter route method is called with either the complete Message object when unwrap=false, and when unwrap=true with the contents of the Message objects body. Thanks, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063852#4063852 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063852

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