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

[JBoss OSGi Development] - Re: How does bundle resolution work

by adrian＠jboss.org

Discussion and update on missing features in jboss-cl http://www.jboss.org/index.html?module=bb&op=viewtopic&t=163957 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266368#4266368 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266368

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

Of course, if you are already in the uninstall lifecycle like the uninstalls or stop/destroy then you effectively do: | Object parameter = dependency.getTarget(me); | try | { | invokeStop(parameter); | } | finally | { | dependency.ungetTarget(me); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266354#4266354 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266354

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: JBoss OSGi logging policy

by adrian＠jboss.org

There is more to it than just setting system properties, and I don't start eclipse from the command line anyway. I also want to be able run tests and see the logging in the console. It's inefficient in my opinion to have to shell out to a file to inspect the logging. e.g. can't click on a stacktrace and go straight to the line of code that caused the problem. As I've said, it should be Hudson or Maven that redirects logging to a file using the log4j.configuration system property. It shouldn't automatically go there using hardwired rules embedded in the change log that are not suitable for everybody's working practices. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266351#4266351 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266351

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"adrian(a)jboss.org" wrote : | Anything you getTarget() during the install() phase should have | a corresponding ungetTarget() during the uninstall() of the lifecycle. | Sure, that's what I'm doing, for symmetric usage that's trivial/natural to support. But that's not the case with our installs, actually uninstalls. e.g. my install - someXInstall(Foo foo, Bar bar, int x) "matching" uninstall undoXInstall(Baz baz, double y) Where we inject this Baz instance. And since this is the last time we actually know something about this injection, we need to clean it up right after the invocation. Or how else? See doUninstalls: * http://anonsvn.jboss.org/repos/jbossas/projects/kernel/trunk/kernel/src/m... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266348#4266348 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266348

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

On the blueprint stuff, I'll repeat from an earlier thread. This should just be another facade on the MC like the spring-int project is. There is no reason to re-implement it when we already know there is a mapping from the spring-int example. Its just a change of namespace and some xml element/attribute names. :-) Any missing features/metadata should be implemented in the MC. In fact, from my (incomplete ;-) understanding of blueprint, its basically two different injection mechanisms in one xml file. One using a "Spring" type api and one using an "OSGi" type for the two different mechanisms. When Ales has this working, you should able to use either type to inject any service within JBoss. Just choose your poison. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266347#4266347 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266347

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

I'm not following what you are talking about? Anything you getTarget() during the install() phase should have a corresponding ungetTarget() during the uninstall() of the lifecycle. If somebody is using the api manually (either the MC api directly or the OSGi api) then it is up to them to make sure they don't have stale references. With OSGi the references can go stale at anytime anyway, which is why the service notification mechanism exists (in principle we should automatically respond those if IOC is used and "redeploy" whatever it was injected into?) Even if they do, they will/should be tidied up at Deployment/Bundle.stop() when the ServiceTracking for that context should be disabled/cleaned up. The ServiceFactory is just a lazy version of the service. i.e. you only construct it if somebody wants to use it. Its still a singleton. It only controls when the object is constructed (first access instead of upfront). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266345#4266345 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266345

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"alesj" wrote : | But that still leaves the problem of actual service usage at undeploy: | "alesj" wrote : | | whereas service could still hold onto the ref - which might be an issue if that ref is ServiceFactory, | | as ServiceFactory::unget could modify the actual created service. | | Actually SF::unget is called at service unregister, so this is a bit different, but doesn't change the problem that much. We could still end up with "illegal" service, but that's also the case right now - any install/uninstall that keeps injected service ref, would be unwinded to appropriate state, but the ref would still be there, once it's re-winded. e.g. | public someInstall(@Inject Foo bar) | { | if (this.bar != null) // which is true after unwind/re-wind | ... // do some crazy stuff on it | | this.bar = bar; | } | But I guess that's the problem of encapsulation, where we go beyond plain java beans. So, the problem just remains with the ugliness, but I guess we can cope with that. | try | { | // do some uninstall on CC:getTarget | } | finally | { | // invoke CC:ungetTarget | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266340#4266340 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266340

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: No explicit control over bundle.start()

by adrian＠jboss.org

"alesj" wrote : "thomas.diesler(a)jboss.com" wrote : | | The MC Framework incorrectly uninstalls the bundle if there is a failure in bundle.start() | | | No, that is / should be the right behavior, as you don't wanna have broken service stuck in some middle state. | | The is a notion of ErrorHandler in Controller, which might be useful, | if we decide to go down this path. | That is the correct way to handle it. As we discussed when designing the ErrorHandler, the default behaviour is to assume an error during the lifecycle is fatal. We don't know whether the object that threw the exception is still in a consistent state, so we throw it away. This rule comes from the EJB spec and it is a very safe assumption. The OSGi spec takes a different (and probably incorrect :-) view. anonymous wrote : | Imho, the real problem is how we handle this Bundle::start. | | "thomas.diesler(a)jboss.com" wrote : | | The controller context reached its required stage DESCRIBED after bundle install. A subsequent call to bundle.start() is supposed to transition to stages CLASSLOADER and then INSTALLED, which corresponds to the Bundle states RESOLVED and ACTIVE respectively. | | | Bundle::start should only be called after we're past CLASSLOADER stage. | At least in automated mode. If the user wants to do this before, it's his choice and potential fault. | No bundle.start() is no different to change(deploymentContext, ControllerState.INSTALLED); If the deployment was only in the DESCRIBE state, it should transistion through all the intermediate states. Of course, it might not be able to do it if there are missing classloading dependencies meaning the bundle cannot be resolved. So the solution is to add an ErrorHandler to the DeploymentControllerContext if it is an OSGi deployment, although I'd prefer it if this was an api on the DeploymentUnit using DeploymentStages rather than working against the implementation details. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266338#4266338 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266338

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Goals of OSGi integration - Using a Standard spi for deploym

by adrian＠jboss.org

Beyond the obvious goal of implementing the OSGi spec the other part to having the OSGi framework implemented on top of the MC/Deployers is so you can control other types of deployments using the Bundle/Service api. This is a standardised api. Which means some people are much more confortable writing to it than for example the JBoss MainDeployer api. There's also the reverse requirement that the OSGi components should work properly from the MC/Deployers. Some typical use cases: 1 ) INSTALLATION I want to deploy a webapp. I do: Bundle myWar = someBundle.installBundle(myWarURL); Since this is not an OSGi bundle it will automatically move to the ACTIVE state (unlike normal bundles which which require a bundle.start() unless there is some other rule to do it, e.g. start level service or persistent state, etc). This worked until the latest changes. 1a) It should be possible to deploy OSGi bundles using the MainDeployer, e.g. via hot deployment. AFAIK this works? 2) CONTROLLING LIFECYCLE I can use the OSGi api to control the lifecycle of non-osgi deployments. e.g. Bundle tomcat = ...; tomcat.stop(); // do stuff tomcat.start(); This also worked until the latest changes. 2a) In reverse you should be able to control the OSGi bundles and services using the MC/Deployers api. This works for deployments, but it isn't going to understand things like the AUTO_START_PROPERTY which is unknown to the MC code. 3) ACCESSING SERVICES I should be able to use the OSGi api to access jboss services, e.g. ServiceReference[] dataSources = bundleContext.getServiceReferences(javax.sql.DataSource.class.getName(), null); Those services should look like they are associated with a Bundle (the BundleState associated with the DeploymentUnit that created the datasource) and do all the notifications, security checks etc. that OSGi requires. This doesn't work. See the "ServiceTracking" thread where Ales and I discussed how to implement this. 3a) In reverse, OSGi deployed services should be available to the MC for use in dependency injection. 4) INTEGRATED CLASSLOADING I should be able to import classes from JBoss deployments. e.g. ImportPackage: javax.ejb;version=3.0 This doesn't work for the reasons described on the "resolver is wrong" thread. 4a) In reverse OSGi bundle classes should be available to non-osgi deployments. This works, but the rules will likely be inconsistent to what the ResolverPlugin is doing, leading to classloading problems? 5) MANAGEMENT Other deployments and services that are not OSGI deployments should still appear in things like the package admin. 5a) In reverse, OSGi bundles and services should be available to JBoss management tools, e.g. the management console 6) OTHER OSGI FEATURES Other OSGi features, like lazy start should work for other non-osgi deployments. Or you should be able to add a war to an osgi start level. etc. 6a) You can use JBoss specific features to augment/change the standard behaviour of an osgi-bundle. e.g. adding a META-INF/jboss-classloading.xml to change the classloading requirements without touching the manifest. (This would be essentially what the management console will do if you modify the classloading rules there). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266334#4266334 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266334

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: PROPERTY_AUTO_START

by adrian＠jboss.org

I'll repeat. This should be a feature at the deployer's level. If it is not implemented properly, then you should fix it there. 1) You can't expect other parts of the MC/deployers to look at OSGi specific properties and understand what is going on. 2) The feature should be available to all deployments. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266326#4266326 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266326

15 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev November 2009