February 2008 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by mazz＠jboss.com

anonymous wrote : There won't be a jboss instance to run it in! I may have misunderstood you here. So, I want to be clear - your plugins run in the RHQ Agent. The RHQ Agent is NOT a JBoss instance, its a standalone, separate J2SE VM. If your remoting stuff is running in some standalone VM itself, the plugin would just need to remotely connect to your VM (remember, the agent VM is running on the same box as the products its managing (i.e. your remoting VM is on the same box as the agent VM) so it can connect over 127.0.0.1, in case there are networking issues that you want to avoid). Using the JMX plugin, you can connect to remote JMX MBeanServer's because it uses the EMS library which can connect to any number of remote MBeanServer implementations (the standard JRE5 platform mbeanserver can be remoted, for example, using the "normal remote JMX way" - the EMS library handles this for us. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130778#4130778 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130778

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by thomas.heute＠jboss.com

Sorry i rephrase: GWT comes in mind as an example of presentation framework usage. The presentation framework will be part of JBoss Portal 2.8 If you can do basic HTML and GWT you can do pretty much everything (Swing could also be an option ideally) More: * http://wiki.jboss.org/wiki/Wiki.jsp?page=PresentationFramework * on this forum * Code... but you're on your own, that's work in progress: https://svn.jboss.org/repos/portal/branches/presentation/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130777#4130777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130777

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by apwalker

anonymous wrote : | | For standalone though, we probably won't be able to use this. There won't be a jboss instance to run it in! | | If they want to manage that standalone jbm server then they will run a rhq/jon server somewhere else and run an agent on the server running jbm --Aaron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130776#4130776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130776

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by mazz＠jboss.com

anonymous wrote : For standalone though, we probably won't be able to use this. There won't be a jboss instance to run it in! Depends on how you are exposing your remote management interface. If its just JMX, you can piggy back on our JMX plugin and have your plugin connect to your remoting services using direct JMX. You can extend existing plugins to reuse existing plugin capabilities. This is how we wrote several of our plugins. For example, the JBossAS4 plugin as well as the Hibernate plugin use the JMX plugin to connect to the JMX MBeanServer hosting the services we want to manage. Under the covers it uses MC4J's EMS library so it supports all different kinds of JMX MBeanServers (standalone JDK5 platform MBS, JBossAS MBeanServer, BEA WebLogic, etc. etc.). See: http://svn.rhq-project.org/repos/rhq/trunk/etc/custom-jmx-plugin/src/main... In that case, there is no Java code to write. You just write your plugin's XML descriptor and tell it which JMX operations/attributes your services support, and we utilize the JMX plugin to do the dirty work of calling the appropriate JMX APIs. So, for example, write simple JMX MBeans that manage your remoting services and just write the XML descriptor that describe your management MBean interfaces and the JMX plugin takes care of the actual connection to and calling the MBeans. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130775#4130775 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130775

18 years, 1 month

1
0
0 / 0

[Javassist development Forum] - Re: Byte code limits?

by mburger

"mburger" wrote : I have similar problems, while instrumenting classes I get various exceptions: I just submitted an issue: http://jira.jboss.com/jira/browse/JASSIST-43 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130768#4130768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130768

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Handling contexts in error

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : There's no notion of holding onto a broken bean | (except for error reporting - see above). | Maybe we could add a notion of errorCallback? i.e. if a bean errors during the startup process then we would invoke this callback, something like: | public class Container | { | @Install | public void addContained(Contained contained} { // trivial } | @Uninstall | public void removeContained(Contained contained} { // trivial } | @Error | public void addError(Contained container) {} | @Removed | public void removeError(Contained container) {} | } | The @Removed is because the only time it will go out of the error state is when it is removed altogether from the controller during the redeploy. But this seems a bit hacky to me? It's looking less like a POJO and more like what the class says it is a "Container" ;-) Perhaps a better approach would be for you to register for events on your "contained" contexts, so you would actually receive: Pseudo code | // Your api | removeContained(contained); | // Out-of-band notifications from the MC | errorOccurred(contained, throwable); | uninstalled(contained); | // Re-installed | addContained(contained); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130766#4130766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130766

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by ataylor

so basically to expose a set of operations we implement the OperationFacet and it will look something like this: OperationResult invokeOperation(String name, Configuration parameters) | { | if(name.equals("createQueue")) | { | String queue = parameters.get("queue").getStringValue(); | String binding = parameters.get("binding").getStringValue(); | jmsServerManager.createQueue(queue, binding); | return new OperationResult("success"); | } | else if(name......) | { | | } | } For standalone though, we probably won't be able to use this. There won't be a jboss instance to run it in! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130765#4130765 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130765

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Handling contexts in error

by adrian＠jboss.org

I don't really understand what you are trying to do? Guessing... INSTALL - MC wiring The add/removeContained looks like either the install or installCallback stuff. However, if a bean goes to the error state then it will have its uninstall or uninstallCallback invoked. There's no notion of holding onto a broken bean (except for error reporting - see above). CONTROLLER - a bit more control for yourself If you want to control the states manually then consider writing your own facade over the MC controller, e.g. take a look at what the ServiceController (in the jbossas system-jmx project) does to support the legacy JMX api. i.e. http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/system-jmx/src/m... * stopping and starting mbeans from the mbean's own jmx operations mbeanserver.invoke() -> mbean.stop() -> servicecontroller.stop() -> MC * emulating the old SAR deployer or programmatic use of the ServiceController to manually change the mbean states * maintaining the legacy ServiceContext and listing them by state [url]http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/system-jmx/s...] e.g. List listIncompletelyDeployed() {...} etc. For your usecase, it doesn't sound like it needs to be as complicated as the JMX stuff, but the "invokeStart() delegates to" sounds like a facade/wrapper to me? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130761#4130761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130761

18 years, 1 month

1
0
0 / 0

[Javassist development Forum] - Re: Byte code limits?

by mburger

Hello! I have similar problems, while instrumenting classes I get various exceptions: Caused by: java.lang.NullPointerException | at javassist.bytecode.ConstPool.getInterfaceMethodrefClassName(ConstPool.java:413) | at javassist.expr.MethodCall.getClassName(MethodCall.java:91) | at javassist.expr.MethodCall.getCtClass(MethodCall.java:75) | at javassist.expr.MethodCall.getMethod(MethodCall.java:114) And: Caused by: java.lang.ClassCastException: javassist.bytecode.ClassInfo | at javassist.bytecode.ConstPool.getFieldrefClassName(ConstPool.java:254) | at javassist.expr.FieldAccess.getClassName(FieldAccess.java:97) | at javassist.expr.FieldAccess.getCtClass(FieldAccess.java:89) | at javassist.expr.FieldAccess.getField(FieldAccess.java:112) Any idea what causes these failures? Regards Martin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130760#4130760 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130760

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

by mazz＠jboss.com

Watch this short, 2 minute demo: https://network.jboss.com/confluence/display/JON2/Demo-Intro All the features you see in this core UI comes out of box from RHQ - you write a plugin that sits in our agent, and you get all of these features without having to write any UI or server-side code. You just write code that talks to the new remoting management interface and RHQ takes care of the rest. So, for example, if you want to support the ability for your customers to remotely view and edit configuration for your remoting services, you have your plugin implement the Configuration facet: http://svn.rhq-project.org/repos/rhq/trunk/modules/core/plugin-api/src/ma... Your configuration facet implementation would talk to your remoting services management interface to set configuration properties directly on your remoting objects. If you want to monitor your remoting services, you implement the MeasurementFacet: http://svn.rhq-project.org/repos/rhq/trunk/modules/core/plugin-api/src/ma... The measurement facet implementation talks to your remoting services management interface to obtain measurements emitted by them. Take a look at our other facets: http://svn.rhq-project.org/repos/rhq/trunk/modules/core/plugin-api/src/ma... to see what management features are supported. You can implement one, some or all of the facets. If you do not implement one, RHQ simply ignores that functionality for your plugin and assumes it is not supported (so if you do not implement the Configuration facet, the core UI will not show you the config screens that would have allowed you to remotely configure your remoting services). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130757#4130757 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130757

18 years, 1 month

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 February 2008