[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC
by kabir.khan＠jboss.com
I already changed the names you complain about here:
"alesj" wrote :
| btw: I don't like type="default" as it doesn't say/explain anything
|
"alesj" wrote : "kabir.khan(a)jboss.com" wrote :
| | This looks wrong or at least not the Guice/Weld concept like.
| |
| Sorry, there was a problem with the example. Here is an updated one with the new names.
|
| This will not resolve as you say:
|
| | <bean name="bean1" class="SomeBean">
| | <!-- type='Supplied' by default on bean level -->
| | <qualifier>a</qualifier>
| | </bean>
| | <bean name="bean2"class="SomeBean">
| | <qualifier>a</qualifier>
| | </qualifier>b</qualifier>
| | </bean>
| | <bean name="bean3" class="OtherBean">
| | <qualifier type="Wanted">a</qualifier>
| | </bean>
| |
|
| This will inject bean2:
|
| | <bean name="bean1" class="SomeBean">
| | <!-- type='Supplied' by default on bean level -->
| | <qualifier>a</qualifier>
| | </bean>
| | <bean name="bean2"class="SomeBean">
| | <qualifier>a</qualifier>
| | </qualifier>b</qualifier>
| | </bean>
| | <bean name="bean3" class="OtherBean">
| | <qualifier type="Wanted">a</qualifier>
| | <qualifier type="Wanted">b</qualifier>
| | </bean>
| |
|
| The 'relaxed' matching if only Wanted bean level qualifiers is shown here, and will inject bean1 in both cases.
|
| | <bean name="bean1" class="SomeBean">
| | <!-- type='Supplied' by default on bean level -->
| | <qualifier>a</qualifier>
| | </bean>
| | <bean name="bean2"class="SomeBean">
| | </qualifier>b</qualifier>
| | </bean>
| | <bean name="bean3" class="OtherBean">
| | <qualifier type="Wanted">a</qualifier>
| | <qualifier type="Wanted">c</qualifier>
| | </bean>
| |
|
|
| | <bean name="bean1" class="SomeBean">
| | <!-- type='Supplied' by default on bean level -->
| | <qualifier>a</qualifier>
| | </bean>
| | <bean name="bean2"class="SomeBean">
| | </qualifier>a</qualifier>
| | </qualifier>b</qualifier>
| | </bean>
| | <bean name="bean3" class="OtherBean">
| | <qualifier type="Wanted">a</qualifier>
| | <qualifier type="Wanted">b</qualifier>
| | <qualifier type="Wanted">c</qualifier>
| | </bean>
| |
|
| Maybe I should change 'Wanted' to 'Required'? We could add 'Optional' etc.
|
| "alesj" wrote :
| | The default qualifier on the bean/class shouldn't imply exact matching,
| | it should just imply that we always need that qualifier for all (non-explicit?) injection points.
| |
|
| I am not sure if you are saying you think I should turn off the 'relaxed' stuff shown above requiring exact matches?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267643#4267643
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267643
14 years, 5 months
[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC
by alesj
"kabir.khan(a)jboss.com" wrote :
| I forgot to mention that in the case of qualifier metadata existing at a higher level in MDR than instance level, the search takes that into account and merges whatever it can find at all levels. e.g., if ["a", "b"] exists at JVM level and ["c", "d"] at INSTANCE level, when doing the lookup for an instance ["a", "b", "c", "d"] is returned.
|
I would hide the search behind some registry / cache / "database'.
By default we would have the same simple algorithm as we have now,
but we could/should turn it into smarter/faster one.
e.g. merge qualifiers only once, match on set intersection not being empty
In this case we would have to check if MDR can be changed in such a way that our data wouldn't be stale / invalid.
e.g. something would pull the X level MDR "rug" under our feet / "database"
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267634#4267634
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267634
14 years, 5 months
[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC
by alesj
"kabir.khan(a)jboss.com" wrote :
| 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.
This looks wrong or at least not the Guice/Weld concept like.
Afair Guice/Weld usage goes like this:
@Blue @Red class FooX implements Foo
@Blue class FooY implements Foo
@Inject @Blue Foo foo
it would throw an exception not knowing which one to choose, as both are supplying @Blue.
You would have to be more precise, having both @Red and @Blue on injection point.
The default qualifier on the bean/class shouldn't imply exact matching,
it should just imply that we always need that qualifier for all (non-explicit?) injection points.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267632#4267632
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267632
14 years, 5 months
[JBoss AS Development] - Re: Graceful Shutdown
by jason.greene＠jboss.com
"bstansberry(a)jboss.com" wrote :
|
| Jason, are you concerned about solving this case (eventually), or are you just using it to make a point about dependencies? Segregating internal calls from those coming via remote endpoints, and then closing off the remote endpoints before stopping/undeploying anything will handle most such cases. The only ones it won't are where Service B makes a remote call to non-HA Service A, even though both are deployed locally. Which case is IMHO out of scope. :-)
I was just making a point about static dependencies not being a catch-all. The remote shut-off would totally do the trick, which is why I liked your earlier suggestion about starting with just a simple solution for the web tier.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267568#4267568
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267568
14 years, 5 months
[JBoss OSGi Development] - Service mix part deux (II.)
by alesj
Starting a new fresh thread, as the old one is pretty much tangled up
with a bunch of useless tracking-impl info.
* http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160504
OK, I have cleaned up OSGi MC Facade to work directly off ContextTracker and ContextQueries:
* OSGiManager registeredServices --> controller/context queries
* AbstractBundleState servicesInUse --> context tracker getUsedContexts
* OSGiServiceState usedBundles --> context tracker getUsers(this)
I currently just imitated previous behavior,
explicitly using just OSGi notions - no non-OSGi+MC context usage yet.
So my question is:
(a) how do we handle non-OSGi context in OSGi Facade
(b) how do we handle OSGi services with additional properties in non-OSGi
I guess (b) should be simple.
e.g. as we already discussed, put service's properties into MDR/Instance
and allow for context filtering based on those properties.
But otherwise the plain usage should be type matching, on exposed service's classes.
What about (a)?
What is MC POJO's bundle?
I guess this is why every deployment has OSGiBundleState, which is what we should return / use?
And I guess this - JBDEPLOY-65 - is needed to make a mapping from context to deployment unit --> OSGiBundleState?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267566#4267566
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267566
14 years, 5 months
[JBoss AS Development] - Re: Graceful Shutdown
by bstansberry＠jboss.com
"emuckenhuber" wrote : "bstansberry(a)jboss.com" wrote : Could the deployment of the acceptor be part of the deployment of the service? It's just a separate MC bean that depends on the core service.
| |
| | That eliminates the issue of deployment phases.
|
| Yeah i thought it's just a MC bean with an install callback :) It's just a question when this bean gets deployed. Basically there is no way we can eliminate deployment phases - where at the moment each Profile represents a deployment phase (mainDeployer.process()).
| Just think what would happen if you move the "TomcatService" into the 'web.deployer'. This would start the connectors/acceptors/endpoints before even looking at what's in 'deploy'. Which means that the acceptor would be available, but without any web app installed. The same would happen if we have multiple smaller profile description.
|
| Although this is not specific to graceful shutdown it could affect it depending on the way you signal the acceptors to gracefully stop. If the "central management bean" is called to signal the shutdown, before we actually stop AS then it could work. Otherwise the same would happen - we undeploy all user applications, before undeploying the acceptor deployment.
I agree with your conclusion "if the "central management bean" is called to signal the shutdown, before we actually stop AS then it could work." But I want to clarify some re: my understanding of the acceptor and how it ties in to deployment stages.
AIUI, an acceptor is not scoped to a connector. It's scoped to the thing that handles requests for a particular component (a webapp, and EJB). In Tomcat terms, it would be the first thing in the webapp-specific Pipeline that results in a call on the servlet.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267562#4267562
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267562
14 years, 5 months