November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: JBC and RPC

by ben.wang＠jboss.com

Calling RPCDispatcher is no problem. Key is how to share the same JGroups channel. How about we expose the JBC channel in the CacheSPI, say, getJChannel()? This way, a regular Cache user won't have access to that API but a customized provider can. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983337#3983337 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983337

19 years, 5 months

1
0
0 / 0

[Design of JBossXB] - DtdAwareContentHandler to support SAX2 LexicalHandler events

by scott.stark＠jboss.org

The only way I can get the version for ejb2.x descriptors is to get the doctype. I hacked in some support for this by adding an extended ContentHandler that supports the startDTD/endDTD from the SAX2 LexicalHandler: | interface DtdAwareContentHandler extends ContentHandler | { | public void startDTD(String name, String publicId, String systemId); | public void endDTD(); | } | The DelegatingContentHandler supports this, and the ObjectModelBuilder and DelegatingObjectModelFactory have been updated to pass this even on based on reflection of the type ObjectModelFactory: | public class BookObjectFactory | implements ObjectModelFactory | { | // ObjectModelFactory implementation | | public void startDTD(String name, String publicId, String systemId) | { | // Get version info from publicId... | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983333#3983333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983333

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Injection of MBeanServer

by scott.stark＠jboss.org

The compile time dependency is the bad thing about annotations. You can specifiy this via xml and I would not even use the JMX annotation for something like a cache (or any core jboss framework classes) since there are likely to be many of them and no reasonable defaults that should be hard-coded. See the microntainer aop-mc-int/src/resources/tests/org/jboss/test/microcontainer/test/JMXDecoratedTestCase.xml where this is demonstrated: | ... | <bean name="Bean" class="org.jboss.test.microcontainer.support.SimpleBeanImpl"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="", exposedInterface=org.jboss.test.microcontainer.support.SimpleBean.class)</annotation> | </bean> | | <bean name="Bean1" class="org.jboss.test.microcontainer.support.SimpleBeanImpl"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="test:name=NotBean1", exposedInterface=org.jboss.test.microcontainer.support.SimpleBeanImplMBean.class)</annotation> | </bean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983323#3983323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983323

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Injection of MBeanServer

by bstansberry＠jboss.com

Thanks. The use of the annotation is what I'd read and forgotten. I thought the "inject the MBeanServer via a property" approach seemed too hacky! "scott.stark(a)jboss.org" wrote : | The org.jboss.test.microcontainer.test.JMXDecoratedTestCase illustrates the use of a JMX annotation and associated org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction which handles the registration of a simple bean like: | | | | package org.jboss.test.microcontainer.support; | | | | import org.jboss.aop.microcontainer.aspects.jmx.JMX; | | | | @JMX(name="test:name=AnnotatedBean", exposedInterface=SimpleBeanImplMBean.class) | | public class SimpleBeanAnnotatedImpl extends SimpleBeanImpl | | { | | } | | | | Let's get this fleshed out with Kabir's help. | OK. For clustering the part I'm going to want to be sure works well is overriding the @JMX name attribute via XML. Most clustering beans can be deployed multiple times with different partitions, with the partition name as an attribute of the ObjectName. And of course there can be multiple JBC instances in the server. Manik, one thing this implies is a compile-time dependency in JBC on the microcontainer jars. I think that was an inevitability anyway. We could avoid this by having the JMX integration in the AS cluster module or the fledgling cluster project, but that seems ugly. anonymous wrote : | In the interim if you run into issues, I would look at creating a CacheJmxWrapper that exposes the mbean interface and delegates to the pojo cache to make sure jmx is fully separated out of the core. | I did that this morning; even named the class "CacheJmxWrapper". Pending sorting out use of @JMX, it knows how to register itself w/ JMX if the MC injects an MBeanServer, a la AspectManager. That may be how I leave it for the next week or so while I focus on getting all the AS clustering code working with the new JBC 2.0 API. This class will probably also be the basis for integrating JBC 2.0 in the old JMX Microkernel. There's still legacy code in TreeCache that let's TreeCache register itself w/ JMX; I'll remove that tomorrow once others get a chance to read this thread and express any opinions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983319#3983319 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983319

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Injection of MBeanServer

by scott.stark＠jboss.org

"bstansberry(a)jboss.com" wrote : | Question: how does stuff get registered in JMX if deployed via a -beans.xml? I vaguely recall reading somewhere months ago that that could be done, but I can't find anyplace showing how. From what I see now (e.g. the AspectManager bean in the AS), it looks like the bean needs to expose a property where the MC passes in the MBeanServer; presumably it's then the bean's responsibility to register itself. Please let me know if that's wrong. Yes, that is wrong. The bean should not be doing anything except its core purpose. Beans are not registered with jmx automatically. There has to be a configuration that expresses this aspect, and the jmx aspect should be exposing the configured attributes/operations from the pojo. The org.jboss.test.microcontainer.test.JMXDecoratedTestCase illustrates the use of a JMX annotation and associated org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction which handles the registration of a simple bean like: | package org.jboss.test.microcontainer.support; | | import org.jboss.aop.microcontainer.aspects.jmx.JMX; | | @JMX(name="test:name=AnnotatedBean", exposedInterface=SimpleBeanImplMBean.class) | public class SimpleBeanAnnotatedImpl extends SimpleBeanImpl | { | } | Let's get this fleshed out with Kabir's help. In the interim if you run into issues, I would look at creating a CacheJmxWrapper that exposes the mbean interface and delegates to the pojo cache to make sure jmx is fully separated out of the core. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983308#3983308 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983308

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Injection of MBeanServer

by bstansberry＠jboss.com

The core cache only 'needs' the MBeanServer so it can register itself and it's interceptors with it, if it's configured to do so. But, you're right, that's not the way to go. The core cache shouldn't be dealing with this stuff. Question: how does stuff get registered in JMX if deployed via a -beans.xml? I vaguely recall reading somewhere months ago that that could be done, but I can't find anyplace showing how. From what I see now (e.g. the AspectManager bean in the AS), it looks like the bean needs to expose a property where the MC passes in the MBeanServer; presumably it's then the bean's responsibility to register itself. Please let me know if that's wrong. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983302#3983302 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983302

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: enterprise services ready

by andyredhead

This is very good news :) I've just moved house and broadband hasn't been connected yet (and I should really get on with unpacking boxes left over from the move) so it will be a couple of days before I can give it a go - however I know at least one place where I can try the jee scheduler... Thanks for making this happen. Cheers, Andy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983287#3983287 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983287

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: a jms message sending node type

by andyredhead

A collection of useful "How-To"s sounds like a very good idea :) For part of this case (sending messages to JMS through an action handler) I have some generic code which I'd be quite happy to post if its of interest - sorry, I don't have anything that does the listening for responses part :( A lesson learned the hard way when using jBPM and JMS message queues inside JBoss is if you use a transaction to wrap some jbpm activity and sending a message and you want a rollback of the transaction to include not sending a message - make sure you use the JMS factory bound under java:/JmsXA View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983285#3983285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983285

19 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Ejb3ClientDeployer handling j2ee14 clients

by scott.stark＠jboss.org

So I have added a general org.jboss.client.AppClientMain that can handle any app client type by allowing for alternate launchers that implement: | public interface AppClientLauncher | { | /** | * Launch a javaee client application. | * | * @param clientClass - the class whose main(String[]) will be invoked | * @param clientName - the client name that maps to the server side JNDI ENC. | * May be null indicating the name should be taken from the client jar | * descriptors/annotations. | * @param args - the args to pass to main method | * @throws Throwable | */ | public void launch(String clientClass, String clientName, String[] args) | throws Throwable; | } | and org.jboss.ejb3.client.ClientLauncher now implements this interface. An ordered list fo such launchers can be passed to the AppClientMain. The first to succeed defines the launcher behavior. These changes are checked in but I'm still testing them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983281#3983281 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983281

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: PLEASE everybody switch to jdk 1.4....

by kukeltje

no problem, it was an easy fix locally, but it should be fairly easy to prevent ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983280#3983280 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983280

19 years, 5 months

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 November 2006