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

[JBoss AS Development] - Re: Graceful Shutdown

by ALRubinger

"emuckenhuber" wrote : Actually this also brings up the question if we want to have something like a "acceptor" phase in our bootstrap process To highlight DML's suggestion in the long chat, one idea on the table is to pull out "acceptors" and "processors", where acceptors depend on processors. Then there's no additional lifecycle phase, just a typical dependency. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267295#4267295 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267295

14 years, 5 months

1
0
0 / 0

[JBoss AS Development] - Re: Graceful Shutdown

by emuckenhuber

Actually this also brings up the question if we want to have something like a "acceptor" phase in our bootstrap process, which could be part of the Profile definition. This could be interesting in general otherwise we might start the connector before deploying user applications. This does not make it easier for the ProfileService part, but it might help to handle this part better as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267292#4267292 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267292

14 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: iPhone / iPod Touch access to jBPM tasks

by koen.aers＠jboss.com

I need a new phone... Definitely a motivation to get one of those ;-) Cheers, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267289#4267289 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267289

14 years, 5 months

1
0
0 / 0

[JBoss AS Development] - Re: Graceful Shutdown

by emuckenhuber

Hmm graceful shutdown should not be part of the MC bean lifecycle, as it would then always shutdown in a graceful manner. This should be an optional way to shutdown AS - triggered with a different signal or management action. Additionally with the graceful shutdown there will most likely be a timeout which then is going just stop AS. This does not seem to fit very well with MC lifecycle actions, since we would basically need to interrupt a action during a state transition (pre_stop -> stop). I see the problem with the order of calling the graceful shutdown and agree that we should try to leverage existing dependencies. Thinking about that i'm not really sure if using bean dependencies would make sense though. Using MC bean dependencies would mean that the jboss.web somehow needs to have a dependency on EJB3, which does not really make sense - since the bean itself does not need this dependency. Maybe one thing which might be worth looking at is if we can use Profile dependencies for that. Since we are going to have something like optional dependencies as well, to better control the boot sequence. At least at the point where a profile would describe something like a service/container - this set of dependencies could make more sense. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267282#4267282 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267282

14 years, 5 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

It's really not such a big deal if you understand the difference between reactor and standalone project. If framework would have started in the reactor (as it should have) than this would be the first move. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267278#4267278 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267278

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC

by kabir.khan＠jboss.com

Following Ales's suggestions what I now have is: Qualifier metadata is implemented as RelatedClassMetaData, where the qualifier objects are stored in RCMD.getEnabled(). To pick out the RCMDs that specify qualifiers I use 'RCMB#SUPPLIED_QUALIFIER' as the classname, and 'RCMB#WANTED_QUALIFIER' as the classname for wanted qualifiers specified at bean level. Following the population of the metadata and beaninfo in PreInstallAction (and in InstallAction if beaninfo was null) I populate the MDR with sets of qualifiers from the metadata. These are stored in the INSTANCE level metadata under 'RCMB#SUPPLIED_QUALIFIER' and 'RCMB#WANTED_QUALIFIER' respectively. The search algorithm works much the same as before. ClassAndQualifierKey queries for all the beans implementing a class, and then narrows it down depending on the wanted qualifiers and the required qualifiers. Before I commit, I want to add some xml configuration of qualifiers. I propose | <bean name="bean1" class="SomeBean"> | <qualifier>a</qualifier> | </bean> | <bean name="bean2"class="SomeBean"> | <qualifier>a</qualifier> | </qualifier>b</qualifier> | </bean> | <bean name="bean3" class="OtherBean"> | <qualifier type="default">a</qualifier> | </bean> | Meaning that the bean1 supplies qualifier 'a', bean2 supplies qualifiers 'a', 'b' and bean3 uses 'a' by default when looking for other beans to inject into it. So when injecting SomeBean instances into bean3, bean1 will be chosen. Next, I want to look at somehow supporting fine-grained qualifiers injection. If we have two instances of | class Bean{} | where instance 1 supplies qualifier 'A' and instance 2 supplies qualifier 'B' and we have | class Target | { | Bean a; | | Bean b; | | @Constructor | Target(@Inject Bean a) | { | this.a = a; | } | | @Inject | void setB() | { | this.b = b; | } | } | It should be possible to specify qualifiers for injected parameters and properties, so that in this example we can say the constructor wants the Bean with qualifier 'A' while the setter wants the Bean with the qualifier 'B'. I'll see if I can use/expand AbstractInjectionValueMetaData to use qualifiers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267275#4267275 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267275

14 years, 5 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by alesj

"thomas.diesler(a)jboss.com" wrote : | As a consequence, I suggest to move framework to its natural location again (i.e. projects/runtime/framework/trunk) since its life as reactor project has ended. | Argh, not the moving again. I'm for it if Adrian also agrees, and you 110% promise you will never ever move it again. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267264#4267264 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267264

14 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: jBPM 4.1 takeTask() race condition

by jbarrez

Should be easy to do by just writing a service method that does a query/assignment with the jBPM API. If you then get a staleObjectException, you know someone else has taken the task just before you. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267261#4267261 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267261

14 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: iPhone / iPod Touch access to jBPM tasks

by jbarrez

Wow, supercool! Too bad I haven't got an iPhone (yet) ... or I would definitely give it a go! What about writing a blog about it? Looks like a cool thing to write about! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267260#4267260 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267260

14 years, 5 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

After a long discussion with Ales, we decided to cut the Beta5 release from a framework branch that uses compatible dependencies The location of that branch is as you might guess https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/... This effectively renders the reactor/framework stale with respect to the overall jbosgi/trunk build. Perhaps, at this point I should explain again what a "reactor project" is ... It is the home of fast moving jbosgi projects that want to participate in the overall jbosgi build and be part of the framework and container independent test matrix. Reactor projects are part of the installer and are QAed by the Hudson environment on different frameworks and target containers. Reactor projects cannot introduce dependencies that are not available in the supported target containers. Eventually, every reactor project will start its own lifecycle in jboss-osgi/projects when it becomes stable enough. Every project you see in jboss-osgi/projects (there are currently a little under 20 of them) has once started in the reactor and was an integral part of the jbosgi build. It seems that framework has crossed that bridge of introducing incompatible dependencies and needs to have a trunk version which is independent of the overall jbosgi build. A framework/trunk version also seems to be needed to make fast progress. The situation now is that framework still uses the reactor svn location, but is not part of the reactor build. As a consequence, I suggest to move framework to its natural location again (i.e. projects/runtime/framework/trunk) since its life as reactor project has ended. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267255#4267255 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267255

14 years, 5 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 November 2009