[Design of OSGi Integration] - Re: BundleActivatorDeployer Questions
by adrian@jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | There just needs to a REAL deployer that invokes the bundle activator.
| I like the current approach better.
| It gives users more flexibility on wiring the activator bean before starting it.
| e.g. they could annotate their activator class with our or custom IoC annotations and MC would configure the instance
|
I thought we were talking about the bundle?
The bundle should just control the deployment controller context.
If you want to create a kernel controller context for the bundle activator
that's a different issue. e.g. in "PRE-REAL" you could create the context
and make the deployment moving to REAL dependent on that "POJO".
But somebody who knows OSGi may get a bit confused
if they do Bundle.start() and it gives them an error saying I'm not
doing it because the IOC injections onto the activator aren't satisfied. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130100#4130100
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130100
18 years, 1 month
[Design of OSGi Integration] - Re: BundleActivatorDeployer Questions
by adrian@jboss.org
"johnbailey" wrote :
| In the BundleActivatorDeploymentVisitor a BundleContext is created, which will lazily create the Bundle. BeanMeteData for the BundleActivator is then installed into the controller with start and stop parameters of the BundleContext.
|
| | public void deploy(DeploymentUnit unit, OSGiMetaData deployment) throws DeploymentException
| | {
| | String bundleActivator = deployment.getBundleActivator();
| | if (bundleActivator != null)
| | {
| | String name = createBundleActivatorBeanName(deployment);
| | // todo - get deployment context in non-depricated way
| | BundleContext bundleContext = new BundleContextImpl(unit);
| | BeanMetaDataBuilder builder =
| | BeanMetaDataBuilderFactory.createBuilder(name, bundleActivator)
| | .addStartParameter(BundleContext.class.getName(), bundleContext)
| | .addStopParameter(BundleContext.class.getName(), bundleContext);
| | BeanMetaData beanMetaData = builder.getBeanMetaData();
| | try
| | {
| | controller.install(beanMetaData);
| | }
| | catch (Throwable throwable)
| | {
| | throw DeploymentException.rethrowAsDeploymentException("Unable to install BundleActivator.", throwable);
| | }
| | }
| | }
| |
|
I don't see why we need to create a seperate kernel controller context for the bundle?
The deployment is the context.
There just needs to a REAL deployer that invokes the bundle activator.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130079#4130079
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130079
18 years, 1 month
[Design of JCA on JBoss] - Re: JBAS-1808 - MCF MBeans
by adrian@jboss.org
Vicky, for such trivial changes in general you should just do it.
Silence means approval. :-)
However in this case, you've got a thread safety issue.
If the cels really are an ArrayList then not accessing it in a synchronized block
will produce a ConcurrentModificationException when the pool changes.
Exposing an AarrayList isn't very good api anyway.
The method in InternalManagedConnectionPool should look something like this:
| // The method should be package protected and just specify a Set
| Set<ConnectionListener> getConnectionListeners()
| {
| // Avoid concurrency issues with the rest of the pool
| synchronized (cls)
| {
| // "Clone" the internal collections inside the synchronized block to avoid concurrency issues
| Set<ConnectionListener result = new HashSet<ConnectionListener>();
| result.addAll(cls); // The connections in the pool
| result.addAll(checkedOut); // The connections being used by applications
| return result;
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130069#4130069
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130069
18 years, 1 month