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

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

by scott.stark＠jboss.org

"timfox" wrote : "@JMX" is not a standard annotation from the JDK libraries, so we can't have it in our core classes since it will introduce a build time dependency on whatever library that comes from (AOP?), and we don't want to force our embedded users to drag in jars they don't need. This is the main issue that requires administration to be treated as an aspect that can be applied as an integration concern. We override the default jms destinations to apply the management aspect in jbossas. In general, we need to support different aspect mappings to allow projects to use whatever is natural to them. If you want to use jmx, fine. If you want to use the mc @ManagementObject stuff, fine. The integration layer need to define the correct aspect that allows this information to be properly brought into the management view of the environment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130913#4130913 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130913

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by PMN

ok, then it is like other "solution oriented" features, the only advanced feature is to choose among 4 approaches without defining concepts. The layout - currently provided with a jsp and renderer - is defined at page level not portlet level and that 's the point. Flex is easily embedded in ajax and ajax is only an extension of "html classic", ajax is beyond the portal logic, your approach is not clear or flaked. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130912#4130912 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130912

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JMS Topics/Queues in ProfileService

by scott.stark＠jboss.org

Sorry, I had to go to a jcp meeting down at Sun today, so lost yesterday to travel. I'll start working on it again tonight on my way home. If I don't get it tonight, it will be done tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130911#4130911 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130911

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by julien＠jboss.com

The PF is a way to decouple the portal from its presentation layer so you can have the implementation of your choice: - HTML (Classic) - Ajax - Flex - Swing the need really comes from the fact that the portal *must* not rely on a specific kind of presentation technology. For instance your portal should not behave differently if you use HTML or Ajax, what I mean by behave here is the portal logic, like if I click on page XYZ, it shows page page XYZ). The PF does other things, I wrote a document that outlines it, you can see read it http://docs.google.com/Doc?id=dhfvtj95_1fnrk2f We can discuss about it in that forum. "thomas.heute(a)jboss.com" wrote : No the presentation framework sure doesn't rely on an ajax framework. It's decoupled from the view actually. | | If you want to base your view on YUI the good thing is that you can. But if your neighbor want it based on GWT (Which is quite popular, like it or not) he can, and if someone else want plain old HTML he can too. | | The presentation framework gives you the necessary abstraction ! We won't rely on a technology, it changes too quickly, and that's why the presentation framework is born :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130909#4130909 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130909

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by PMN

I don't see how you can support multiple ajax framework on the same page without being subject to side effects, especially when it comes to layouts. If jbp team succeeds to do that, then it is awsome, I want to see it and at this point I don't see this as feasible. You need to fix the layout first and thus rely or provide a technology for that. All versions of jbp lacks of this concepts and still, 2.8 is not clear -"what is well thought can be explained with words" sorry for paraphrasing ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130908#4130908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130908

18 years, 1 month

1
0
0 / 0

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

by bytor99999

Hi guys, glad to be a part of this conversation. After reading through the thread, I thought I'd add my 2 cents with regards to using RHQ and Embedded Console, if that is the route you should choose. (Which I think is the best route :) ) OK, so think of this in just three parts. 1) The UI (Embedded Console) 2) Plugins and the RHQ Plugin Container 3) Your Management Interface for JBM I hope you don't mind be going top down. 1) The Embedded Console is just a Seam app, so all it needs is something that can "deploy" a Seam app, I believe that includes the Microcontainer. The great thing about the console is that it is generic, just create a plugin and drop it in the plugins dir, and the console will display it nice and pretty. It does use the RHQ plugin container embedded in it. Think of this as an embedded RHQ agent, so no seperate server or agent to start up. So its dependencies are Seam JSF RichFaces JSTL JDom 3 apache commons jars RHQ core 2) Plugins You include whatever plugins you want the UI to display. This is the only thing for the UI that you will need to create. Mazz gave you all the info about plugins and what they need. The plugin's dependencies are anything it needs to communicate to what it plans to manage and monitor. In a lot of cases it might already have been provided for you. In looking at our plugins, it is only the jmx-plugin that has one jar with it for the EMS library that it uses. 3)Your Management Interface for JBM. Now this is completely up to you. All the plugin will need is an ability to connect to it, locally or remotely. Remotely more for everyone to re-use your plugin in other servers. So you can choose any transport you want. You just might need to include that transports jar files in the plugin jar. Let me use an example of the AS 5 plugin. AS 5 has the Profile Service which is the management interface that AS 5 exposes (3). In the AS 5 plugin, it simply does a JNDI lookup for the profile service and then just codes to that api. In the rhq-plugin.xml I define my resources and what props, metric statistics and operations each resource type can expose (2). I simply drop the AS 5 plugin into the plugins directory of the Embedded Console war and now the Console manages and monitors AS 5 (1). So the dependencies are very small, the JON team designed and built it such that it was as simple as possible for plugin developers to add management and monitoring capabilities to their products. I hope that helps. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130901#4130901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130901

18 years, 1 month

1
0
0 / 0

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

by julien＠jboss.com

anonymous wrote : The reason it can't do the failure part is because it follows what is an accepted | generally good programming practice (e.g. ejbs do the same) | that if the container invokes a bean and it throws an error then you discard | that bean. You can't know that the bean is still in a good state because | you don't know why it threw the error. this is the programming model that is designed as such. If you take Servlet or Portlet (modelled after Servlet) it is not the same and it is more like a service programming model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130898#4130898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130898

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by thomas.heute＠jboss.com

No the presentation framework sure doesn't rely on an ajax framework. It's decoupled from the view actually. If you want to base your view on YUI the good thing is that you can. But if your neighbor want it based on GWT (Which is quite popular, like it or not) he can, and if someone else want plain old HTML he can too. The presentation framework gives you the necessary abstraction ! We won't rely on a technology, it changes too quickly, and that's why the presentation framework is born :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130896#4130896 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130896

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by PMN

Thanks for the pointer. Design ideas are nice, other text is too vague to get an idea. It seems to me that a presentation framework starts with an ajax framework and thus the choice of an ajax dev kit. YUI has low level and excellent concepts that would be very well adapted to a "framework" that would support building block "solutions" such as gwt or place holder for region and windows. I would have no time to dig into the code as I amalready a full yer late on my product -(a View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130893#4130893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130893

18 years, 1 month

1
0
0 / 0

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

by julien＠jboss.com

Actually the way I am using it is rather dynamic and it creates metadata at runtime using the Kernel metadata stuff and does not use XML or Annotations. I guess that what I have can be considered as a "deployer" (i.e take meta data and create a set of runtime kernel managed objects). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130891#4130891 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130891

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