[JBoss AS Development] - Re: Naming over Remoting 3
by ALRubinger
"ron.sigal" wrote : Are you ok with "ejb3" -> "invokable"? Do you still want it in repos/common?
Sure, I hadn't given it much thought. I'd say let's keep it in the same repo for now so that we can "svn mv" without losing version history.
The groupId might change eventually too, who knows? I'd say let's just keep the naming until we know the intent of the project IMO.
"ron.sigal" wrote : I'm curious why org.jboss.ejb3.container.core.MapBasedInvocationContext is a non-public class (which requires the related tests to go in org.jboss.ejb3.container.core instead of org.jboss.test.ejb3.container.core), but the other classes in org.jboss.ejb3.container.core are public.
Because it didn't *need* to be public, so I scoped it down as small as possible. :) By convention lately I've been doing this so that I can have tests in the same packages and get at package-private members.
S,
ALR
PS - Hehe, "package-private members".
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267399#4267399
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267399
16 years, 4 months
[JBoss AS Development] - Re: Graceful Shutdown
by bstansberry＠jboss.com
A semi-nasty wrinkle that occurred to me as I wrote the above:
For a container involving sessions or other long running units of work, we want to allow new requests for that session until it has expired/been removed/been replicated. This is the work of the acceptor, which needs to interact with the container to track the status of sessions.
But actually it's only interested in sessions associated with its endpoint. The fact that calls coming in via some other endpoint are keeping sessions alive shouldn't prevent the acceptor completing its stop method.
Perhaps this isn't a huge issue; e.g. if a SFSB takes requests via a Remoting connector and also via the web tier, there are 2 acceptors involved -- the SFSB's and the web app's. If the shutdown is multithreaded, stop() can proceed on both in parallel. So all sources of new sessions will be cut off and eventually and the SFSB+Remoting acceptor can complete stop().
This requires multithreaded shutdown though.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267394#4267394
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267394
16 years, 4 months
[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC
by kabir.khan＠jboss.com
I am able to add qualifiers to the bean level via xml easily, e.g.:
| <bean xmlns="urn:jboss:bean-deployer:2.0" class="Dummy">
| <qualifier>
| <javabean xmlns="urn:jboss:javabean:1.0" class="java.util.Date"/>
| <javabean xmlns="urn:jboss:javabean:1.0" class="java.lang.String"/>
| </qualifier>
| </bean>
| <bean xmlns="urn:jboss:bean-deployer:2.0" class="Dummy">
| <qualifier type="Wanted">aop</qualifier>
| </bean>
|
This is handled by a sub class of AbstractRelatedClassMetadata which hardcodes the name of the class depending on the qualifier type being Wanted or Supplied (Default).
Now, trying to add this for injection points, I get the following to parse:
| <bean xmlns="urn:jboss:bean-deployer:2.0" class="Dummy">
| <property name="test">
| <inject>
| <qualifier>
| <javabean xmlns="urn:jboss:javabean:1.0" class="java.util.Date"/>
| <javabean xmlns="urn:jboss:javabean:1.0" class="java.lang.String"/>
| </qualifier>
| </inject>
| </property>
| </bean>
|
But since I also want to be able to add these qualifiers directly programatically whereby I have been doing:
| AbstractInjectionValueMetaData inject = new AbstractInjectionValueMetaData();
| inject.setInjectionPointQualifiers(new HashSet<Object>(Arrays.asList(qualifiers)));
|
I end up with two sets of properties in AbstractInjectionValueMetaData for the same thing:
| /**
| * Get the injectionPointQualifiers
| * @return the injectionPointQualifiers
| */
| public Set<Object> getInjectionPointQualifiers()
| {
| return injectionPointQualifiers;
| }
|
| /**
| * Set the injectionPointQualifiers
| * @param injectionPointQualifiers the injectionPointQualifiers to set
| */
| public void setInjectionPointQualifiers(Set<Object> injectionPointQualifiers)
| {
| this.injectionPointQualifiers = injectionPointQualifiers;
| }
|
| /**
| * Get the injectionPointQualifierMetaData
| * @return the injectionPointQualifierMetaData
| */
| public Set<RelatedClassMetaData> getInjectionPointQualifierMetaData()
| {
| return injectionPointQualifierMetaData;
| }
|
| /**
| * Set the injectionPointQualifierMetaData
| * @param injectionPointQualifierMetaData the injectionPointQualifierMetaData to set
| */
| @XmlElement(name="qualifier", type=AbstractQualifierMetaData.class) //Sub-class of AbstractRelatedClassMetaData
| public void setInjectionPointQualifierMetaData(Set<RelatedClassMetaData> injectionPointQualifierMetaData)
| {
| this.injectionPointQualifierMetaData = injectionPointQualifierMetaData;
| }
|
I like the convenience of being able to call setInjectionPointQualifiers() directly when creating this programatically without having to wrap it up in an AbstractQualifierMetaData, but I guess that can be hidden in the BeanMetaDataBuilder. So unless somebody knows how to avoid that, I'll take that route.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267388#4267388
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267388
16 years, 4 months