[Design the new POJO MicroContainer] - Registering listener on KernelEventManager
by scott.stark＠jboss.org
I'm looking at providing a better startup notification as the current one from the ServerImpl occurs just at the end of the bootstrap phase. I'm trying to test out an example listener, but the following
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <bean name="StartupMonitor"
| class="org.jboss.test.profileservice.lib.startup.StartupMonitor">
| <install bean="jboss.kernel:service=KernelEventManager" method="registerListener">
| <!-- registerListener(Object name, KernelEventListener listener, KernelEventFilter filter, Object handback) -->
| <parameter>jboss.kernel:service=KernelEventManager</parameter>
| <parameter><this/></parameter>
| <parameter><null/></parameter>
| <parameter><null/></parameter>
| </install>
| </bean>
| </deployment>
|
fails with an error like:
| 15:38:32,904 ERROR [AbstractKernelController] Error installing to Installed: name=StartupMonitor state=Start
| java.lang.IllegalArgumentException: Cannot install, context BeanKernelRegistryEntry@56d0a8c{target=org.jboss.kernel.plugins.event.AbstractEventManager(a)39cf701c} does not implement InvokeDispatchContext
| at org.jboss.kernel.plugins.dependency.InstallAction.installActionInternal(InstallAction.java:79)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:135)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:46)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:574)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:398)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69)
| at org.jboss.system.deployers.TempBeanMetaDataDeployer.deploy(TempBeanMetaDataDeployer.java:48)
| at org.jboss.system.deployers.TempBeanMetaDataDeployer.deploy(TempBeanMetaDataDeployer.java:35)
|
Why wouldn't the event mgr have an InvokeDispatchContext implementation?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137236#4137236
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137236
18 years
[Design of POJO Server] - Re: JBAS-5259, JMS Destination Names is showing as QueueServ
by mark.spritzler
Not sure what I can really add.
Here is the code that runs while discovering the resource.
First at the AS discovery level we run
|
| ProfileServiceFactory.refreshCurrentProfileView();
|
| which looks like this.
|
| try
| {
| Profile activeProfile = getProfileService().getActiveProfile();
| ProfileKey activeKey = activeProfile.getKey();
| getCurrentProfileView().loadProfile(activeKey);
| }
| catch (Exception e)
| {
| LOG.error("Could not find default Profile in Current Profile View", e);
| }
|
|
| The following is the getProfileService() method call in the first line
|
| public static ProfileService getProfileService()
| {
| if (profileService == null)
| {
| InitialContext initialContext;
| try
| {
| initialContext = new InitialContext();
| }
| catch (NamingException e)
| {
| LOG.error("Unable to get an InitialContext to JBoss AS 5", e);
| return null;
| }
|
| try
| {
| profileService = (ProfileService) initialContext.lookup("ProfileService");
|
| /*ManagementView view = getCurrentProfileView();
| ComponentType type = new ComponentType("DataSource", "LocalTx");
| Set<ManagedComponent> components = view.getComponentsForType(type);*/
| }
| catch (NamingException e)
| {
| LOG.error("Could not find ProfileService Name on JBoss AS 5", e);
| }
| catch (Exception e)
| {
| LOG.error("Exception thrown when looking up ProfileService on JBoss AS 5", e);
| }
| }
| return profileService;
| }
|
|
Then for each ComponentType it will run the following code
| ComponentType componentType = ConversionUtil.getComponentType(resourceType);
|
| ManagementView mgtView = ProfileServiceFactory.getCurrentProfileView();
|
| Set<ManagedComponent> components = null;
| try
| {
| components = mgtView.getComponentsForType(componentType);
| }
| catch (Exception e)
| {
| LOG.error("Unable to get component for type " + componentType, e);
| }
|
| The factory call to getCurrentProfileView() is here
|
| /**
| * Get the current profile's Management view. This will get the domains from the profile service
| * and return the first one in the list.
| *
| * @return ManagementView the management view of the first domain
| */
| public static ManagementView getCurrentProfileView()
| {
| if (currentProfileView == null)
| {
| currentProfileView = getProfileService().getViewManager();
| refreshCurrentProfileView();
| }
| return currentProfileView;
| }
|
|
| the refreshCurrentProfileView() call above is below, but it is one and the same as you saw at the beginning of the code I just posted. :)
|
|
|
| /**
| * This will refresh the managementView to have all the newest resources.
| * It simply nulls out the "singleton" reference in this factory and calls
| * getCurrentProfileView to reload the view with loadProfile();
| */
| public static void refreshCurrentProfileView()
| {
| try
| {
| Profile activeProfile = getProfileService().getActiveProfile();
| ProfileKey activeKey = activeProfile.getKey();
| getCurrentProfileView().loadProfile(activeKey);
| }
| catch (Exception e)
| {
| LOG.error("Could not find default Profile in Current Profile View", e);
| }
| }
|
|
This is the code that was working before to discovering the Datasources and refreshing when creating and deleting datasource.
Mark
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137226#4137226
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137226
18 years
[Design of JBoss jBPM] - Re: LDAP assignment handler
by kukeltje
@Tom,
anonymous wrote : right ?
right
anonymous wrote : * to make it pluggable for LDAP as well, all the relations would have to be navigated over the session facade as well. that on itself is not a big deal, but it breaks a bit the simplicity that we get by systematically using the hibernate persistence architecture. So? Ditch it... (just kidding) I bet in real live few people will use the identity service as it is. Isn't that why Alex had to build an ldap impl?
I have no real preference but it really needs cleaning up
@Alex
anonymous wrote : Is this the kind of cleanup you did?
Exactely... IdentitySession got ditched, IdentityService configurable via jbpm.cfg.xml but the difficult part is the User and Group object dependency. If I create interfaces for those (they moved from the identity project to the core in my case), hibernate complains about the mappings and I'm to little a hibernate expert to fix that at the moment...
anonymous wrote :
| Earlier I proposed merging ExpressionSession into IdentityService. On a second thought, the separation between the interfaces also corresponds to the separate requirements of each client of the identity service. Identity implementors could choose to implement only those interfaces that correspond to the features in use.
Hmmm I think I understand what you mean, but because of simplicity, I'd still merge them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137218#4137218
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137218
18 years