[Design the new POJO MicroContainer] - Re: Install Items
by adrian＠jboss.org
You still don't understand.
The callback is a generic thing.
It's also an implementation detail handled internally by the controller,
so you don't need anything on the controller itself.
e.g. something like
| public interface InstallItem<T>
| {
| ControllerState whenRequired();
| ControllerState requiredState();
| int getCardinality();
| Class<T> getItemType();
| }
|
| public interface SingleInstallItem<T> extends InstallItem<T>
| {
| add(T item);
| remove(T item);
| }
|
|
| public interface CollectionInstallItem<T> extends InstallItem<T>
| {
| set(Collection<? extends T> items);
| }
|
And then in the controller (pseudo code):
| protected void install(ControllerContext context, ControllerState toState)
| {
| // do it (what it does now)
|
| Collection<InstallItem> installs = context.getDependencyInfo().getInstallItems();
| if (installs != null && installs.isEmpty() == false)
| {
| for (InstallItem install : installs)
| {
| if (install.getWhenRequired().equals(toState)
| {
| addToIndex(install.getItemItype(), install);
| // also install what already exists
| }
| }
| }
|
| Collection<Class<?> implements = getClassesImplemented(context.getTarget());
| if (implements != null && implements.isEmpty() == false)
| {
| for (Class implement : implements)
| {
| Set<InstallItem> installs = getFromIndex(implement);
| // Do the installs if we are at the required state
| {
| // eventually leading to something like
| InstallItem install = // from installs
| if (toState.equals(install.getRequiredState))
| install.add(context.getTarget());
| }
| }
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038323#4038323
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038323
19 years, 1 month
[Design of JBossCache] - Re: JBCACHE-1025: JBossCache mbean registration fails on Web
by JerryGauth
When a TreeCache instance is registered in JMX, the "cluster name" is used as the registration name. If the TreeCache has no cluster name (i.e., it's not clustered and the cluster name hasn't been explicitly set), a default name of TreeCache-Group is used.
Because of this, it appears that a best practice is to always provide a unique cluster name for a cache where statistics will be exposed. Otherwise the first cache instance to register itself with the default name will be the only one to have its statistics accessible via JMX.
If the cache has a "service name", then the service name is used for registration. If there is no service name, we concatenate the "jboss.cache:service=" prefix with the cache's cluster name.
I haven't looked closely at the origin of the service name but it seems likely that this name isn't available when running in non-JBoss environments. It's also presumably not available when running on JBoss without a service configuration file (e.g., when creating the cache in application code).
I'm not familiar with the preRegister process. Perhaps we should be using it when registering mbeans for which no service name has been provided?
I'll have to look closer at how the service name is provided for TreeCache.
re: the interceptors, my observation was essentially that it wouldn't be sufficient to store the cache's WAS registration suffix and simply append it to the interceptor registration names. It would be necessary to store the WAS registration names for each interceptor as well as for the cache itself. So it seems like we would need to maintain a map of registration names rather than simply a single variable. At least that's what seems necessary at first glance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038321#4038321
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038321
19 years, 1 month
[Design the new POJO MicroContainer] - Re: Install Items
by alesj
Where to put such code:
| /**
| * Add callback context.
| *
| * @param name the depend on name
| * @param context context interested in name
| */
| void addCallbackContext(Object name, ControllerContext context);
|
| /**
| * Remove callback context.
| *
| * @param name the depend on name
| * @param context context interested in name
| */
| void removeCallbackContext(Object name, ControllerContext context);
|
| /**
| * Get interested contexts.
| *
| * @param name dependent name
| * @return set of contexts interested in name or null if none such exists
| */
| Set<ControllerContext> getCallbackContexts(Object name);
|
|
Best place would be Controller, but this is too specific for state machine.
Should I create a middle interface, between Controller and KernelController?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038313#4038313
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038313
19 years, 1 month
[Design the new POJO MicroContainer] - Re: Install Items
by adrian＠jboss.org
I don't understand any of your comment. e.g.
"alesj" wrote : Why should InstallItem be referenced by DependencyInfo?
|
Because that is where cross context dependency info is stored
and where the real implementation of the dependency resolution is done.
| I need to register a 'callback / install' item directly into the controller - holding the information of requested class, cardinality, target context, target method/property.
|
The only thing registered directly in the controller are the contexts.
These have DependencyInfo, i.e. what is required before the context can
change state.
| Since with Controller.resolveContexts() I never iterate over already installed context's.
| And even if I did, I should only iterate over those who actually hold any install item.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038284#4038284
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038284
19 years, 1 month
[Design of JBoss ESB] - Re: Finding the EPR for a provider from a notifier
by burrsutter
JCA inbound or outbound in 4.2?
Assuming outbound means that the ESB can use the JCA container/adapter to then make connections to the outside world (e.g. database, SAP, whatever) then the new 4.2 ESB Server should be capable.
However, if inbound means something akin to the current/planned listeners/gateways (FTP, JMS, SOAP, HTTP(S), RMI, File, Hibernate, etc) then I'm not so sure about that item.
Do I have the correct understanding of inbound vs outbound? And for the inbound ones, where do we get them and/or how hard is it to re-write them?
Burr
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038211#4038211
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038211
19 years, 1 month