The enum would not restrict the allowed types as that would continue to be whatever deployers decide to add. It would be a separate enum from the ComponentType interface that had a ComponentType accessor, for example:
| public interface KnownComponentTypes
| {
| public enum DataSourceTypes
| {
| XA("DataSource", "XA"), LocalTx("DataSource", "LocalTx"), NoTX("DataSource", "NoTX");
|
| private final String type;
| private final String subtype;
| private DataSourceTypes(String type, String subtype)
| {
| this.type = type;
| this.subtype = subtype;
| }
|
| public ComponentType getType()
| {
| return new ComponentType(type, subtype);
| }
| };
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038179#4038179
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038179
Is there an Enum or some other place to find the different possible values you can set for ComponentType, so when you call getComponentsForType(ComponentType type) it will return stuff? :)
Or is it possible to keep the ComponentType set to an empty String and therefore the ManagementView call to get components returns all Components?
Is this something that should be thought about in the design, or am I just wasting your time because I should have posted this in a different forum. :)
Thanks
Mark Spritzler
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038175#4038175
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038175
Where does ""jboss.cache:service=TreeCache-Group" come from? AFAICT the only place the serviceName field is set is in preRegister, and that should be the value WAS is passing in.
Or is WAS passing in "jboss.cache:service=TreeCache-Group" to preRegister but actually registering it under something else? And then createService tries to register it as "jboss.cache:service=TreeCache-Group" and WAS barfs because the same object is registered under a different name?
Re: the interceptors, the order of the attributes is not important; it's OK to mix them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038152#4038152
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038152
It looks like WebSphere really mangles the registration names of interceptors by wrapping the interceptor name attribute within the WebSphere attributes.
For example, when I register the TxInterceptor using the object name jboss.cache:service=TreeCache-Group,treecache-interceptor=TxInterceptor,
the registration name in WebSphere becomes jboss.cache:service=TreeCache-Group,cell=citgoNode01Cell,treecache-interceptor=TxInterceptor,node=citgoNode01,process=server1
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038134#4038134
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038134
MBeanConfigurator is registering the cache's mbean using the object name that it retrieves as you noted. By default (e.g., no config file, no cluster), this name will be "jboss.cache:service=TreeCache-Group." If you retrieve the name of the registered object instance after registration, the returned name (on my server) is "jboss.cache:service=TreeCache-Group,cell=citgoNode01Cell,node=citgoNode01,process=server1"
WebSphere appends the cell name, node name and server name to the object's registration name. It seems likely that you subsequently need to use this name if you want to determine whether an mbean has already been registered.
The same issue applies to registration of the individual interceptors.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038127#4038127
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038127