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

[Design of POJO Server] - Re: JMS Topics/Queues in ProfileService

by scott.stark＠jboss.org

The population of the stats is broken. I have updated the testDefaultDSStats to validate that the stats values are non-null. http://jira.jboss.com/jira/browse/JBAS-5247 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131564#4131564 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131564

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Barrier service, event oriented depdencies for AS5

by scott.stark＠jboss.org

So the embedded management console itself being an application needs to know when the server has completed its startup processing. Simple enough to introduce yet another barrier type of service. Perhaps a better approach is to add a kernel event injection dependency item that would allow a component to have an event broadcast inject the KernelEvent, or deliver it to its KernelEventListener method. If it does, what would be the syntax/naming convention for describing this dependency? Does something already exist that would allow one to be notifed of the ProfileService.application-start event? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131522#4131522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131522

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Concurrent deployments

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | If all the deployments specified their classloading dependencies | (osgi style) the problem would go away. | The proposed mavenisation of the JBossAS build might help in determining what these dependencies really are. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131495#4131495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131495

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Concurrent deployments

by adrian＠jboss.org

"david.lloyd(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : * Not all services define their dependencies properly. It's only the implicit sequential order that makes them work correctly. | | If they don't define their dependencies properly, what guarantee is there that they will even work at all? | They use the "deterministic" implicit rules, which means you can test it works for single bootstrap, but if you try to redeploy something that only has implicit dependencies, you'll find it doesn't understand what is going on :-). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131494#4131494 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131494

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Concurrent deployments

by adrian＠jboss.org

"david.lloyd(a)jboss.com" wrote : | I don't really understand the hairy details behind some of the classloader problems, but surely they could be worked around by imposing some reliance on the dependency system for them as well? | If all the deployments specified their classloading dependencies (osgi style) the problem would go away. This also means automagically adding javaee (and the relevant container) classloading dependencies into ejb/war deployments etc. since we can't expect users to do this for themselves. It's doable, but I doubt it is going to happen soon? Another side affect of this, is that those deployments that explictly list their package exports wouldn't have to go through the scan of the filesystem/jars to determine what packages they export. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131493#4131493 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131493

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Concurrent deployments

by david.lloyd＠jboss.com

"adrian(a)jboss.org" wrote : * Not all services define their dependencies properly. It's only the implicit sequential order that makes them work correctly. If they don't define their dependencies properly, what guarantee is there that they will even work at all? "adrian(a)jboss.org" wrote : * Finally, less of a practical issue, but more a generic note. Using mulitple threads for startup will only work if there are multiple cpus/cores. In non SMP environments the bootstrap could be slower with multiple competing threads, although it may be able to take advantage of times during disk I/O waits | to do some processing on other threads? Two things - first, I don't even know where I'd be able to buy a server-class system (heck even a desktop-class system come to think of it) that didn't have at least two cores (if not two or more multi-core CPUs). But that issue aside, any service that has non-CPU bound tasks (which includes not just disk I/O but network I/O) could possibly see a performance benefit from concurrent startup, even on a single-core system. And in any case we're talking about service deployment - I doubt the additional overhead of context switching between multiple threads could possibly make a measurable impact on performance. Especially in comparison to examples like Bela's 5-second timeout. Also one could reasonably expect that rather than firing off a thread for every task, there would be a thread pool Executor of some sort. The thread pool could be sized in proportion to the number of cores available, or in some configurable fashion. Then the simple rule would be, any deployment task with no remaining dependencies gets put into the queue for execution. I don't really understand the hairy details behind some of the classloader problems, but surely they could be worked around by imposing some reliance on the dependency system for them as well? I agree with Bela - a concurrent startup would be hugely beneficial for startup time, not to mention just being cool. In fact when first learning about the MC and its dependency system, I had simply assumed that dependencies were resolved concurrently and never gave it a moment's thought. It wasn't until I spoke with Bela at JBW that I learned otherwise. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131491#4131491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131491

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : | | I suppose I could validate the capabilities that say they "ExportPackages" | | by running the ExportALL processing even if you explicitly list the package capabilities, | | but I'm not sure it really buys much? | | You'll still get a ClassNotFoundException on javax.jms.Queue | | if you export the package, include it in your filesystem but don't have that class. ;-) | Right, but what we want to be able to debug is the question about why javax.jms.Queue is not found when it sitting in my-jms.jar of classloader x. Its going to be common to have classes from the server domain hidden from the application deployment class loader, so why the hidden class is not seen in the question. | The management interface of the classloader will show the package is not exported, but you'd need to see the filter(s) and decode them to understand why. I guess I could always add some more trace logging to say which filter excludes a package? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131488#4131488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131488

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by anil.saldhana＠jboss.com

"scott.stark(a)jboss.org" wrote : The problem is the use of metaData.getClass().getName() as this returns the implementation class. You need to use JBossAppMetaData.class.getName() since that is the signature. Its the metaData instance that has to be an implementation of this. The ctor parameters also look incorrect that it should be metaData rather than deployment: | | | | ServiceConstructorMetaData serviceConstructor = new ServiceConstructorMetaData(); | | serviceConstructor.setSignature(new String[] { String.class.getName(), | | JBossAppMetaData.class.getName(),Boolean.class.getName()}); | | serviceConstructor.setParameters(new Object[] {contextId, metaData, Boolean.TRUE}); | | createJaccPolicyBean(serviceConstructor, unit); | | | That is the change I am doing now. Rather than the use of metaData.getClass().getName(), I am doing getMetaDataClassType() which is an overridden method in the sub-deployers (EarSecurityDeployer will pass JBossAppMetaData as the meta data class type). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131485#4131485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131485

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JMS Topics/Queues in ProfileService

by adrian＠jboss.org

Prefill doesn't work if you specify a security-domain like the DefaultDS does. Weston only implemented it for the basic pool. Yes, the jboss-messaging use of the datasource should create the pool, so I'd guess it is broken? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131484#4131484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131484

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JMS Topics/Queues in ProfileService

by scott.stark＠jboss.org

yes, that is true. I'll look into why the stats are showing up. Probably a bug and the test should be validating that there are non-null values. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131483#4131483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131483

18 years, 1 month

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