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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MDB's and batching transactions

by clebert.suconic＠jboss.com

anonymous wrote : Specifying only 1 session would solve this but would slow things down under heavy load. | Can't you do something like... when batching... the MDB instance would be always fixed to the same Session? Maybe that would require some support from the MDB team? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247607#4247607 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247607

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Should Touching / changing timestamp of exploded folder

by jaikiran

In this specific usecase (which i think is probably a rare one), i guess all we should do is just check the last modified timestamp of the root of the deployment. Changes to .class files (or any other files) within the deployment will not change the timestamp of the root folder, so we will be safe. As for how the last modified timestamp of the root directory is changed - it would probably be irrelevant. It would be upto the user to do whatever is necessary to change that timestamp. We just provide a feature which picks up that change. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247605#4247605 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247605

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Should Touching / changing timestamp of exploded folder

by max.andersen＠jboss.com

"alesj" wrote : | But instead of this touch hack, we could provide a different StructureModificationChecker, | for those who rely on .class changes. | It would check classes as well as metadata locations. | I don't see any usecase for automatic restarting deployment on class changes. That would trigger it too often. Of course unless ejb3 and others have implemented incrememently deployment updates recently ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247602#4247602 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247602

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploding jar libraries in deployments

by ALRubinger

Jaikiran's opened: https://jira.jboss.org/jira/browse/JBAS-7148 S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247597#4247597 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247597

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploding jar libraries in deployments

by ALRubinger

"alesj" wrote : What about if you just extracted that line, | and then override it in your custom EmbInMemWarDeployer? That violates a design goal of Embedded. Embedded is a combination of projects which launch AS inside an existing process. Any time AS itself cannot handle being run in a fashion other than standalone points to improper assumptions it makes about its environment. I'd instead like to overload AbstractCopyMechanism with a non-recursive explode(), and expose that via VFSUtils. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247596#4247596 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247596

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploding jar libraries in deployments

by alesj

"ALRubinger" wrote : | Any preference Ales? Or you'd prefer we handle it outside of jboss-vfs and hack something together just for Tomcat? | What about if you just extracted that line, and then override it in your custom EmbInMemWarDeployer? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247586#4247586 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247586

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploding jar libraries in deployments

by jaikiran

"ALRubinger" wrote : BTW is there a failing test case for this ATM? | | I'll create a JIRA for this and attach the testcase. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247580#4247580 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247580

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploding jar libraries in deployments

by ALRubinger

BTW is there a failing test case for this ATM? S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247578#4247578 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247578

14 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploding jar libraries in deployments

by ALRubinger

So it looks like we instead need some non-recursive "explode". Or at least a mechanism like "unjar" which will act upon vfsmemory. Any preference Ales? Or you'd prefer we handle it outside of jboss-vfs and hack something together just for Tomcat? S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247577#4247577 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247577

14 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - New ClassPool sub-project; structure

by alesj

I did a quick look at the jboss-classpool. - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-classpool/ It looks like a big mess. :-) I don't know enough about how it's actually implemented, to properly say what should be spi. But from what I saw, there is a lot of impl details that can be properly moved/hidden. e.g. Lets at least properly expose API - the code the user should touch, everything else should be plugins == impl details, something user can only touch at his own risk. If there is some spi, I guess you can re-factor that as well, but I must say I don't see a lot of interfaces that would be really intended to help the dev change the behavior. They are mostly there to have good abstraction over the impl. Perhaps you could also join in together the code for 4.x and 5.x: * jboss4, ucl --> jboss4/pool, jboss4/cl * jboss5, jbosscl --> jboss5/pool, jboss5/cl Or whatever you feel fits pool and cl better. e.g. cl could be called structure And I guess we can do some simple "cleanup" of root org.jboss.classpool package. e.g. some split into pool, resource-plugins, strategy, ... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247575#4247575 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247575

14 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2009