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

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by emuckenhuber

"bstansberry(a)jboss.com" wrote : "emuckenhuber" wrote : I've put an example (untested) of an ImmutableProfile in org.jboss.system.server.profile.repository in case you are interested... | | So i basically created basic abstraction on top of the deploymentRepository, so that it can be used by those two. | | I'm not seeing it??? | https://svn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/syste... "bstansberry(a)jboss.com" wrote : | anonymous wrote : So what i would like to do is that only for MutableProfiles a deploymenRepository is required (because of the DeploymentManager). For an immutable profile this is therefore not needed. So we would also have some different implementations of a Profile then. | | But i'm not really sure how this would affect your work? | | Could be trouble. What "mutable" means is still pretty unclear. But a twist a clustered repository is adding is the fact that a profile that doesn't change after the server starts can still change as part of the startup process. That is, a node that's been offline synchronizes its content with the cluster as part of startup. True, mutable is not really clear. But basically it's the ability to add and remove contents. Furthermore it implies that hot-deployment could be possible. But i don't think a deploymentRepository is required for all profiles (e.g. the bootstrap profile, or in future most of the xml defined profiles). Also the root profile basically just has some dependencies. Most probably the ImmutableDeploymentRepository should be renamed to NoHotDeploymentRepository and the MutableRepository to HotDeploymentRepository :) Both should somehow support addDeploymentContent, as you might want to add a deployer - although there is no hot-deployment scanning. I mean in the end it's then depending on your implementation what it should support and if it uses a deploymentRepository. Just that the isMutable() is used by the DeploymentManager to determine which profiles are a possible target to deploy content to. But i don't think i have time to do that for 'Beta1', but most probably for CR1. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214248#4214248 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214248

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by bstansberry＠jboss.com

"emuckenhuber" wrote : I've put an example (untested) of an ImmutableProfile in org.jboss.system.server.profile.repository in case you are interested... | So i basically created basic abstraction on top of the deploymentRepository, so that it can be used by those two. I'm not seeing it??? anonymous wrote : So what i would like to do is that only for MutableProfiles a deploymenRepository is required (because of the DeploymentManager). For an immutable profile this is therefore not needed. So we would also have some different implementations of a Profile then. | But i'm not really sure how this would affect your work? Could be trouble. What "mutable" means is still pretty unclear. But a twist a clustered repository is adding is the fact that a profile that doesn't change after the server starts can still change as part of the startup process. That is, a node that's been offline synchronizes its content with the cluster as part of startup. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214244#4214244 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214244

16 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Contributing back to the jBPM community - business calen

by baobab

Guys, any reply? Need urgent!!! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214225#4214225 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214225

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by emuckenhuber

I've put an example (untested) of an ImmutableProfile in org.jboss.system.server.profile.repository in case you are interested... So i basically created basic abstraction on top of the deploymentRepository, so that it can be used by those two. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214195#4214195 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214195

16 years, 7 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Runtime and bundle lifecycle/dependency resolution

by alesj

"thomas.diesler(a)jboss.com" wrote : | I'd suggest the BundleStartStopDeployer maintains a list of unresolved bundles and tries to resolve them before bundle.start() is attempted. | MC already does this. Bundle == DeploymentControllerContext. You're missing my point. We should make sure the Bundle only gets to BSSD if it's properly resolved. Any other hacking/duplicating is a step in the wrong direction. "thomas.diesler(a)jboss.com" wrote : | We could make PackageAdmin a required service without which BundleStartStopDeployer cannot start bundles automatically. | I wouldn't be that strict. Having PackageAdmin means having few more jars/bundles. If it's there, great, if not fallback to (2) or in the worst case (3). "thomas.diesler(a)jboss.com" wrote : | Only if this approach fails I'd investigate (2) or (3) Fine by me. As long as you make it behind under nice spi/api. e.g. BundleClassLoaderDependencyDeployer::createResolveDependencyItem() could return diff DI instance based on what is available View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214193#4214193 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214193

16 years, 7 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Runtime and bundle lifecycle/dependency resolution

by thomas.diesler＠jboss.com

The PackageAdmin seems to be one of the core services provided by felix | [tdiesler@tddell default]$ find . -name *.jar | xargs grep PackageAdmin | Binary file ./deployers/osgi.deployer/org.apache.felix.framework.jar matches | Binary file ./deployers/osgi.deployer/org.osgi.core.jar matches | I'd suggest the BundleStartStopDeployer maintains a list of unresolved bundles and tries to resolve them before bundle.start() is attempted. We could make PackageAdmin a required service without which BundleStartStopDeployer cannot start bundles automatically. Only if this approach fails I'd investigate (2) or (3) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214185#4214185 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214185

16 years, 7 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Runtime and bundle lifecycle/dependency resolution

by alesj

"thomas.diesler(a)jboss.com" wrote : | I'll have a look at Felix hot deployment - they must have the same problem. | You're not reading my posts. ;-) They are using PackageAdmin for that. So, to simplify things, let's go with this order: (1) try to locate PackageAdmin, and use it to chech if the bundle is resolved (2) provide a spi, so we can implement this on per framework impl details * we try to provide this - if we find the appropriate info easily * 'force' the users to provide this, if they didn't provide the PackageAdmin in the first place (3) implement this ugly hack via start() check * make it such, that it's not part of default usage - as a separate addon View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214170#4214170 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214170

16 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: oryx and jbpm

by heiko.braun＠jboss.com

OK, I've setup a doodle. Please take your pick: http://doodle.com/eichevkdygcxpp7f View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214157#4214157 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214157

16 years, 7 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Runtime and bundle lifecycle/dependency resolution

by thomas.diesler＠jboss.com

The fundamental problem is that a BundleContext.installBundle() does not attempt to resolve the just installed bundle. The information of whether a bundle can be resolved is therefore not available when BundleContext.installBundle() returns. Triggering the resolve process varies from framework to framework and in the simplest case will probably boil down to | | boolean startResolve() | { | try | { | bundle.start() | return true; | } | catch (BundleException ex) | { | return false; | } | The above is no good however because it unintentionally starts the bundle. I'll have a look at Felix hot deployment - they must have the same problem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214153#4214153 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214153

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - JBOSGI-38 and bundle deployment order

by alesj

"thomas.diesler" wrote : | A bundle deployer can therefore not easily start a bundle, because it does not know if all dependencies can be resolved already. | What do you mean under "easily" here? It's the job of our ResolvedBundleDependencyItem to handle this properly. And that's what I meant under providing proper spi here: - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151223 And since we only start/stop bundle after ClassLoading stage, we should be fine, as we know all its dependencies are resolved - that's the purpose of ResolvedBundleDependencyItem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214148#4214148 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214148

16 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2009