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

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

by julien＠jboss.com

ok I see. the other use case it does not answer is that, I need to have some Container bean that list all the related failed POJO to show that it is possible to restart them so: | public class Container | { | private Set<Contained> containeds = new HashSet<Contained>(); | public void addContained(Contained contained} { // trivial } | public void removeContained(Contained contained} { // trivial } | public Set<Contained> listContainedThatFailed() { // trivial } | } | | public class Contained | { | private Container container; | public void setContainer(Container container) { | // Will be removed when it is possible to do install/uninstall on a specified state, ideally would be instantiated (instead of installed), Ales told me he is working on that feature | if (container != null) | { | container.addContained(this); | } | else | { | this.container.removeContained(this); | } | this.container = container; | } | so admin could browse the "failed" beans and attempt to restart some of them using the admin tool, or in a programmatic way | for (Contained contained : container.listContainedThatFailed()) | { | contained.invokeStart(); | } | I think that the whole point is that I need to consider a bean in the 3 following states: stop/installed/failed and trigger trnasitions :-) where invokeStart() delegates to | // Here controllerContext is the one of the failed bean | controller.change(controllerContext, ControllerState.INSTALLED); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130756#4130756 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130756

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 : | | | <bind pointcut="execution((a)com.acme.Singleton->new())"> | | <advice name="constructorAdvice" aspect="Singleton"/> | | </bind> | | | | @com.acme.Singleton | | public class MyBean {} | | | This pointcut language is wrong, since it requires you to annotate the constructor rather than the bean, but I'm sure you can lookup the correct syntax in the aop docs. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130754#4130754 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130754

18 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

"julien(a)jboss.com" wrote : | Please try to get an answer understandable by someone that has little knowledge about MC. This isn't really an MC question, it's a programming patterns question :-) The answer is to use a factory/singleton pattern. e.g. These two would use the object constructed by MyFactory (which can also be an instance class rather than the shown static method). | <bean name="Bean1"> | <constructor factoryClass="MyFactory" factoryMethod="getInstance"/> | </bean> | | <bean name="Bean2"> | <constructor factoryClass="MyFactory" factoryMethod="getInstance"/> | </bean> | | ALTERNATIVE: | | If you don't like the boiler plate of coding a singleton factory, | I wrote an aspect that does it for you: | http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/aop/trunk/asp... | which I guess could also be configured with an annotation (although it doesn't exist currently). | | | | <bind pointcut="execution((a)com.acme.Singleton->new())"> | | <advice name="constructorAdvice" aspect="Singleton"/> | | </bind> | | | | @com.acme.Singleton | | public class MyBean {} | | | | I'm sure you can adapt it to your needs if it doesn't do exactly what you want. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130750#4130750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130750

18 years, 1 month

1
0
0 / 0

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

by mazz＠jboss.com

Oh, forgot to talk about JON and how this all works with the JBoss5 profile service. First off, JON (JBoss Operations Network 2.0) will have at its core the RHQ stuff. It will be built with RHQ, but we'll add additional things - like support for content delivery through the JBoss Customer Support Portal (so we can pull down via our customer CSP RSS feeds the JBoss cumulative patches and so we can ship those CPs to agents and have those patches applied - remote patching and upgrading of your deployed JBossAS servers is what we are going to achieve). Now - the profile service. The JBoss5 profile service is simply JBoss5's way of providing management services. This is analogous to, say, Apache and its SNMP module - where Apache provides its management features through an SNMP mod (in fact, this is how RHQ's apache plugin works - it talks to the Apache SNMP mod). Its analogous to JMX in JBoss4 - this is how the jboss4 plugin works - we talk to the JBossAS server over the JNP port so we can talk JMX to the server and do things like collect monitoring data and control things like the data source MBean and the like. JBoss5 will be exposing its management features via the Profile Service. So our jboss-5 plugin will remotely talk to a JBoss5 server via the profile service to do things like configure JBossAS services. I think the jboss-5 plugin will also talk to the server via direct JMX to get things like monitoring data (I'm not 100% sure on this, but if its not correct, I'm close). The point here is, a plugin needs to interface with the products its managing using that product's management interface, whatever that interface is. Apache plugin wants to manage Apache - it does that by talking to Apache's SNMP management interface. The JBossAS-4 plugin wants to manage JBossAS 4.x - it does that by talking to JBossAS 4's JMX interface. JBossAS-5 plugin wants to manage JBossAS5 - it does that by talking to it via the Profile Service. You get the idea. This is why it is important for products that want to be managed to provide SOME kind of management interface. If it does, the plugin simply uses the management interface provided by the product to manage it. The RHQ plugin API then puts a common interface around it all so the RHQ Server can generically manage any and all products that have a plugin for it. Note that the core UI that the RHQ Server provides knows nothing about how to manage a JBossAS5 server - or Apache - or Tomcat - or... It knows nothing about the Profile Service, or SNMP or JMX or any of it. That's the plugins' job and only the plugins' job. So, if you write a remoting plugin that talks to your remoting management interface (however you implement it), you will have to do nothing else to get: audited configuration updates, auditing operational control over your remoting servers, monitoring, alerting, etc. If you do not want to support remote configurability for your remoting services, then don't implement the configuration facet in your plugin and RHQ just ignores it (you won't see the configuration features when looking at your remoting services in the RHQ UI). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130749#4130749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130749

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by PMN

Where are these presentation framework discussions? By teh way, GWT is again solution oriented and a very ugly dev kit. If JBP 2.8 is based on GWT I'll drop down Jbp and stay with 2.6 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130746#4130746 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130746

18 years, 1 month

1
0
0 / 0

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

by mazz＠jboss.com

OK, here's what RHQ is (a previous post described it well). The RHQ Server is a custom JBossAS application - it has a webapp inside of it that you use as the "core UI" - it provides core management functionality for ALL managed products (a JBoss/Remoting instance would be just one, you could manage that along with JBossAS servers, operating systems, Tomcat servers, Apache Web Servers, Hibernate services, blah blah blah). So you log into the core UI that RHQ provides and it gives you out of box features like operational control over your managed products, view/edit configuration of those products, monitoring, fine grain user control and auditing, alerting, etc. etc. This is out of box - you don't have to write any of it. The RHQ Server has a web service front end with an API that you can use to write your own apps (Swing app if you want, or other web apps - we have prototyped a Turbo Gears web app written in Python that talks to our RHQ Server via the web services). That's the server side and you typically need to do nothing on that side but run it. No development necessary under 99% of the use-cases. Then you have the agents. The RHQ Agent talks to an RHQ Server - the agent ships up to the server things like: monitoring data, results of an operation execution, auto-discover results (i.e. what was found running on the box, et. al.). This agent-to-server comm is JBoss/Remoting 2 with an additional command/command response framework built on top of it that gave us things like client-side spooling/guaranteed delivery, asynchronous calls, remote POJO RPC features, etc. - but this is all not interesting as you as the RHQ user won't even see or use it directly, so ignore what I just said :-)). The RHQ Agent runs on each machine that is running managed products. Its the typical hub-n-spoke model. So, if you have a box running Apache Web Server, Tomcat, JBossAS server, some hibernate services running in these things, some JBoss Remoting services running in these things, etc, you'd run one RHQ Agent on that box to manage it all. The RHQ Agent has inside of it a plugin container that hosts "plugins" - each plugin manages one or more managed products. For example, the JBossAS plugin manages the JBossAS server itself, the JMS queues and topics, the data sources, etc. The Hibernate plugin manages the Hibernate services (deployed entities, entity cache, etc.). In the Jboss Remoting case, you would write a "remoting plugin" that simply hooks in using our plugin API. Its very very easy to write a plugin. It snaps into the RHQ framework and you immediate get all the functionality that the core UI provides for all the other products. You only implement the things in your plugin that you want to support. If you just want monitoring, just implement the monitoring API facet and don't implement the others, as an example. See: http://support.rhq-project.org/display/RHQ/Writing+Custom+Plugins http://support.rhq-project.org/display/RHQ/Design-Introduction The wiki home is here, poke around for more design doc info, user guide type info, etc.: http://support.rhq-project.org/display/RHQ/Home View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130745#4130745 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130745

18 years, 1 month

1
0
0 / 0

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

by julien＠jboss.com

So actually Ales is trying to explain a use case that I need MC to handle for me. Suppose we have the POJO: | public class Bean { | | private int count = 0; | | public void start() throws InitializationException | { | if (count++ == 0) | throw new InitializationException(); | } | | } | Can MC handle a use case where the failure is not trigerred by its initial state (bean meta data if I understand correctly) like in the use case I am posting ? How can I handle the following transitions: NOT_INSTALLED -> CREATE -> start() -> ERROR -> start() -> INSTALLED if the Bean I listed above is reinstantiated every time it will fail whatsoever. If the same instance is used then it will fail only the first time. Please try to get an answer understandable by someone that has little knowledge about MC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130743#4130743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130743

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by PMN

Layout: I am interested, how and when can I change programmatically the layout of the page being computed? For all other things I already have some code to cover my needs, I would not rely on features that are not clearly stated in the objectives. I'll have a look at the presentation framework. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130741#4130741 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130741

18 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

"alesj" wrote : | We could enable the push from Error or just add some more info that this is not what the user should do. You can't push from error for at least three reasons: 1) In a manual process, you'll have people doing: change(state1); // This errors change(state2); // This will error again (pointlessly) Even worse, it will do the wrong thing at undeploy deploy: change(state1); // ok change(state2); // error -> undeployed undeploy: (reversing the state machine) change(state1); // so it has now deployed to state1 during an undeploy???? 2) The above can happen transitively where changing the state of one context will try to push other contexts that depend on it and are now satisfied by the changed state (again leading to lots of errors) 3) If you change the metadata like you say, then you are supposed to re-install. Like I've being saying on other threads, we should be cloning that metadata so your change in the above example would have no affect anyway. If the deployment has errored then it has gone. The context is only retained for error summary purposes. If there was no need for the IncompleteDeploymentException then an error would have been defined to uninstall. It's also potentially problematic if somebody changes the BeanMetaData in a incompatible way midway through the deployment process which is another reason why we should avoid "out-of-band" changes, we should require a re-install. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130735#4130735 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130735

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by thomas.diesler＠jboss.com

Merci, we'll look into it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130732#4130732 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130732

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