April 2007 - jboss-dev-forums - Jboss List Archives

[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

18 years, 11 months

1
0
0 / 0

[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

18 years, 11 months

1
0
0 / 0

[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

18 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Finding the EPR for a provider from a notifier

by burrsutter

And this would solve the problem that Derek was asking for, being able to dynamically deploy/undeploy transport providers (both in/out) on the fly. If someone undeployed the provider we'd need to alert all the active listeners. >From my perspective, this capability isn't has important has making sure we can achieve clustering on the current architecture or "federation" (multiple ESBs running different services) all sharing the same registry. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038299#4038299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038299

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Install Items

by adrian＠jboss.org

No. The whole point of making the InstallItem seperate on the DependencyInfo is that it will hold just that callback information. Internally, the controller will pull out that information and index it by interface (in a similar way to the @Inject was done). It will pull out that information at the "required state" specified on the InstallItem (default INSTALLED). It is then just a case of iterating over all the callbacks by looking up that index as new contexts reach the relevant state. NOTE: There are two states in the above. 1) At what state we inject into the context 2) At what state the injectee must be before we add it View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038297#4038297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038297

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Install Items

by alesj

"adrian(a)jboss.org" wrote : I don't understand any of your comment. e.g. | Yes, I expected this. :-) Let me try to put it better. I don't see any other place to hold the information about callback - e.g. (2) in JBMICROCONT-165 - than the KernelController. I need something like Class --> CallbackItems. Since when a new bean is instantiated - its classes, interfaces are resolved - I don't want to go over all already installed beans and 'ask' them if they need this new bean. I have already hacked something in this direction, I can put it in after I have tests done. Or how/where do you see the point of integration of this Class --> CallbackItems mapping? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038292#4038292 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038292

18 years, 11 months

1
0
0 / 0

[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

18 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Finding the EPR for a provider from a notifier

by weston.price＠jboss.com

anonymous wrote : | And for the inbound ones, where do we get them and/or how hard is it to re-write them? | Same as the outbound: you either build them, or you buy them. Just because we can do outbound JDBC doesn't mean this comes out of the box. This had to be buillt. Inbound follows the same premise. Currently we support JMS (generic) and POP/IMAP for inbound connectivity. The other types could simply be written as necessary. In some cases this often means wrapping an existing module to conform to the JCA SPI. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038219#4038219 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038219

18 years, 11 months

1
0
0 / 0

[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

18 years, 11 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Need Help on Mac OS X

by techtime

Hello, We are experiencing a problem starting JBoss on Mac OS X with Java 1.6, namely the "Trace/BPT trap" one. Would it be possible to share the "fixes for MacOS" if he has ever shared them with you? Sincerely, Ed Letifov View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038189#4038189 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038189

18 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2007