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

[Design the new POJO MicroContainer] - Re: Naming, @JNDI and OnDemand

by alesj

"alesj" wrote : | What to do? :-) | (a) have OnDemand stay in Pre_Install | (b) add extra Not_Installed AOP lifecycle hook | As seen, none of these two will work. Only moving On_Demand to Describe will work, but that defeats the purpose of On_Demand. The only solution I can think of right now are explicit instructions to put On_Demand bean into JNDI. e.g. | <jndi-on-demand bean="some-existing-bean" ... | with a programmatic/api support as well. For non On_Demand beans the @JNDI will work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230317#4230317 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230317

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JmsConnectionPool: Allowing control over the number of S

by Kevin.Conner＠jboss.com

Oops, didn't mean to sign twice :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230316#4230316 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230316

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JmsConnectionPool: Allowing control over the number of S

by Kevin.Conner＠jboss.com

Perhaps I have misunderstood what you are proposing in that case :) The pool, as far as the client is concerned, should be a single entity but the internals are currently such that there is a single association between the connection and the sessions, whether XA or non XA. This client view should be retained but it would be better for the internals of the pool to manage the associations between the connections and their sessions independently, both for non-XA and XA resources. The 'client pool' would therefore contain a number of internal pools. Your second option sounds as if you intended to keep a single internal pool of the sessions but this would complicate the tracking of the relationships. Of course this may not be what you had intended. Perhaps you can give an expanded description of your options so that we can get a better understanding of what you are proposing. Kev Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230315#4230315 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230315

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: An oddity in the configuration

by jmesnil

the settings content is the same either in jbm-configuration.xml or in jbm-queue.xml (i.e. there is only 1 settings schema type which is included in both XML files) In addition to be defined in the settings element, the queues can also be defined with other related resources (diverts, bridges, etc.) in the configuration element of jbm-configuration.xml View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230307#4230307 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230307

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans

by alesj

"alesj" wrote : | I'm thinking in the lines of putting DependencyBuilder into per bean instance scope in MetaData. | If there is one present, use it, otherwise fall to default - from KernelConfig. I've added this: | protected DependencyBuilder getDependencyBuilder(MetaData md, Kernel kernel) throws Throwable | { | DependencyBuilder dependencyBuilder = md.getMetaData(DependencyBuilder.class); | if (dependencyBuilder == null) | { | KernelConfig config = kernel.getConfig(); | dependencyBuilder = config.getDependencyBuilder(); | } | return dependencyBuilder; | } | | @SuppressWarnings("unchecked") | protected void installActionInternal(KernelControllerContext context) throws Throwable | { | BeanInfo info = context.getBeanInfo(); | if (info != null) | { | KernelController controller = (KernelController)context.getController(); | Kernel kernel = controller.getKernel(); | KernelMetaDataRepository repository = kernel.getMetaDataRepository(); | MetaData md = repository.getMetaData(context); | DependencyBuilder dependencyBuilder = getDependencyBuilder(md, kernel); | // add custom dependencies (e.g. AOP layer). | List<DependencyBuilderListItem> dependencies = dependencyBuilder.getDependencies(info, md); | can you try it out? You will need to take an existing KernelControllerContext and add DependencyBuilder metadata for its ScopeInfo's scope. (see BasicKernelMetaDataRepository for actual usage) This will (mostly) even add more penalty to the performance, as we have to check MetaData for DependencyBuilder instance. Although it shouldn't be much, as it's only a few Map entry checks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230304#4230304 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230304

16 years, 11 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Default JGroups Configs

by jaikiran

This gave some clue http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Cl... Turns out, this configuration comes from a xml file JBOSS_HOME/server/all/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml : | <UDP | singleton_name="udp-async" | mcast_port="${jboss.jgroups.udp_async.mcast_port:45689}" | mcast_addr="${jboss.partition.udpGroup:228.11.11.11}" So based on this syntax, if the jboss.partition.udpGroup property is not set, then it defaults to 228.11.11.11. I guess, the code parsing this xml file should have taken care of setting this mcast_addr correctly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230302#4230302 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230302

16 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM4 postgres support

by tom.baeyens＠jboss.com

Beta2 will include postgresql scripts View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230301#4230301 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230301

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans

by alesj

"jaikiran" wrote : | 1) Can the AOPDependencyBuilder be removed as the default | No, as this would break all the @JMX definitions. Plus probably a ton of other stuff. ;-) "jaikiran" wrote : | 2) Currently this is a kernel level property. Can this be made per bean/context level property (by default set to org.jboss.kernel.spi.dependency.helpers.AbstractDependencyBuilder) so that each MC bean context can override this if required? Whichever MC beans need this AOPDependencyBuilder currently in the AS can then be switched appropriately. | I'll see what we can do. I'm thinking in the lines of putting DependencyBuilder into per bean instance scope in MetaData. If there is one present, use it, otherwise fall to default - from KernelConfig. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230293#4230293 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230293

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Potential Netty problem with synchronously closing conne

by trustin

Related Netty forum thread: http://n2.nabble.com/Pruning-the-accepted-connections-at-the-earliest-sta... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230278#4230278 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230278

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Potential Netty problem with synchronously closing conne

by trustin

I have made the proof-of-concept modification on Netty that suspends ServerSocket.accept() when the number of connections reaches a certain threshold, and it seems to make the ConnectionTest.testManyConnections() pass according to Tim. I'm currently designing more generic interface that allows you to: * suspend / resume ServerSocket.accept() * close the accepted connection immediately * close the accepted connection immediately with a good bye (e.g. 'server busy', 'go away') message The point of this modification is to prune malicious connections as early as possible so that the server does not run out of file descriptors and to temporarily suspend ServerSocket.accept() if necessary. Therefore, a time-consuming tasks cannot be executed in this context. Please let me know if you like it or not. If not, let me know what features are missing. Thanks in advance! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230272#4230272 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230272

16 years, 11 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 May 2009