RE: [JBoss-dev] ModelMBean persistence appears broken
I have a vague recollection of writing a test or two, but that may just be wishful thinking ;) I stopped working on this quite a while ago as someone (can't remember who) came forward with AOP persistence or somesuch that made what I was doing irrelevant... - Matt -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 7:53 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ModelMBean persistence appears broken Its his persistence implementation that cannot work with the duplication of descriptors as this is what I modified and used for the 3.2.3 and earlier persistence tests. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Monday, January 05, 2004 4:51 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ModelMBean persistence appears broken If there are no unit tests for the persistence in the HEAD test suite then it hasn't. I can't remember if Matt Munz added any tests for his persistence implementation or not. -- Juha --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371opÕick ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: [JBoss-user] Re: Recent CVS removals
Bill, Opinions on professionality aside, isn't forking a very expected activity in open source development? If someone can't take Open Source code and make a new (Open Source) product with it, then what is the difference between Open Source and (closed) Shared Source?[1] As long as a given fork adheres to the LGPL, what differentiates a good fork from a bad one? Or are all forks bad? FWIW, I don't have an opinion about this particular dispute, but am rather trying to learn more about the LGPL, Open Source, and your/JBoss.org's views on them. [1] Assuming, of course, that trademarks, etc. are not violated. - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED] Sent: Thu 8/7/2003 1:11 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] RE: [JBoss-user] Re: Recent CVS removals -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Greg Wilkins Sent: Wednesday, August 06, 2003 8:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-user] Re: Recent CVS removals Firstly a note to the list moderator: This is a request for CVS access, so I believe that it is on topic and should not be censored. Bill Burke wrote: JBoss Group, as caretaker of the JBoss project, has recently decided to remove CVS access committers for a few of our committers. We do not remove from CVS without good reason nor without just cause. These are the reasons for the removals: I'll take these in reverse order: 3. There is just too much conflict of interest of developers working on two different J2EE projects that are being developed under two very different open-source licenses. Surely that is for the developers or their actions to determine? Or is this taking the Bush doctrine of pre-emptive action to it's logical extreme? There are conflicts all the time in open source development - between the day job and the project - between license types - between duplicate projects - between competing clients both using your code - between time developing and time to have a life etc. The fact remains that you participated in a JBoss fork. This shows a complete lack of commitment to the JBoss project and community. You have lost the trust of the JBoss project admins. As the author of Jetty, I have helped it be integrated with JBoss, JOnAS and avalon among other proprietary projects. I am serving on JSR154 and give effort to improve all J2EE containers. I have worked with and submitted bug reports and patches for tomcat. I frequently consult to competative companies.I believe I have proven that I can deal with such conflicts in a professional manner. Participating in a fork of JBoss is not professional. You and other Jetty developers are listed as CVS developers of Elba. JBoss has many users and JBG has many clients that they have encouraged to use Jetty/JBoss as a stable and supported platform. JBoss is currently the best J2EE platform out there and I only wish to continue supporting it - and fullfilling the implicit promise made to all JBoss users that we will make best efforts to support our contributions. If you give us back our CVS access - what harm can it be? If we vandalize the code, or become idle for a long period - then remove our access. But we only wish to maintain our contributions and support the JBoss community. The only reasons that I can see for removing us is so you can make no jboss developer marketting claims. Granting of CVS is a contract of trust between the project admins and yourself. You have broken this trust. You are free to submit patches through Sourceforge, but you have lost your CVS privilege. 2. More importantly, we have learned that they have forked JBoss. We also believe they are preparing to submit it, or some derivation, to the new Apache Geronimo project which would violate copyright and LGPL. Our proof? http://sourceforge.net/projects/elba I'm not exactly up to speed with the full motivation for Elba, but it is not for submission to geronimo - nor would the ASF accept it if it was offered. We are contacting ASF
RE: [JBoss-dev] [PROPOSAL]: clean conf/jboss-service.xml deploy
Sacha, Regarding #2, I find the current state of /deploy to be highly intuitive, personally. Would it be possible to make your scheme work by giving .sar's the ability to be nested? That way, /deploy/JMS.sar (a directory) could contain jms-foo.sar and jms-bar.sar. That's already possible (russian dolls), but then: - you need a fake META-INF/jboss-service.xml - you cannot simply re-deploy one of the element in the directory: you have to re- deploy the whole JMS thing Cool. So /deploy/A.sar/B.sar implies that A *depends* on B and therefore should be redeployed if B.sar is modified. Perhaps it would be possible to add a line to jboss-service.xml like isComposite/ that indicates that nested sar's are not dependencies. As far as the fake (A.K.A. empty) descriptor goes, I can't imagine this is a big deal. If it is, then perhaps the sar deployer can/should be modified to take the lack of a jboss-service.xml to indicate an empty configuration (perhaps with a default setting of isComposite). Or, maybe I just like recursion too much ;) - Matt --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [PROPOSAL]: clean conf/jboss-service.xml deploy
Sacha, The thing I care about most is ease of configurability (which, for the most part, I think we already have). I like the idea that I can add or remove functionality by adding or removing modules from /deploy. Much of the functionality of the server works this way (jmx-console, for example). There is, however, quite a bit of information in /conf/service.xml. If this information could be refactored out to /deploy, I'd find that a much simpler situation. At the moment, if I want to pare down jboss to some small feature set, I need to edit /conf/service.xml. That's not a big deal, but the less of that I need to do, the better (especially for automation). Regarding #2, I find the current state of /deploy to be highly intuitive, personally. Would it be possible to make your scheme work by giving .sar's the ability to be nested? That way, /deploy/JMS.sar (a directory) could contain jms-foo.sar and jms-bar.sar. - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2003 5:53 AM To: Jboss-Dev Subject: [JBoss-dev] [PROPOSAL]: clean conf/jboss-service.xml deploy Importance: Low Hello, Currently, the content of conf/jboss-service.xml and deploy is not very clean. 1°) Some services defined in conf/jboss-service.xml require services later deployed in deploy Exemples: - the EJBDeployer depends on the JMS Pool - some invokers (3.2+) require jboss-jca.jar Could we avoid that? Why does the DJBDeployer requires the JMS Pool (MDB I guess). In this case, shouldn't we extract the EJBDeployer from conf/jboss-service.xml and create a ejb-service.xml (or better ejb.jar) that contains everything required for EJB behaviour. 2°) IMHO, way to many files exist in /deploy This is counterintuitive for jboss-users: it may be fine for jboss developers but I don't think it is ok for simple users. First suggestion: we add a new directory to be scanned: system = we put all jboss files in /system and users can put their own files in /deploy (empty or almost at first) Second suggestions: we create a SubDirSubDeployer that deploy the content of simple sub-directories in /deploy (that is not the case right now: *.xAR are deployed but xxx-service.xml files are *not*) or we modify the current deployers so that it happens. Then, we create some functionnaly-self-contained directories for each macro-services i.e. /deploy/JMS /deploy/management /deploy/web /deploy/JCA etc. In /deploy/JMS we would find jbossmq-destinations-service.xml, jbossmq-service.xml, jms-ra.rar, jms-service.xml. Thus, if a user doesn't want JMS behaviour, he doesn't have to dig in all these files and try to remove them: he simply removes the JMS sub-directory and that's it. BTW, both suggestions can be mixed: we may have JMS, JCA, etc. sub-directories in a system directory. Feedback welcome. Cheers, Sacha --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] stop using JDK 1.4 for development
Bill, I thought JBoss was going to support 1.4. Is this not the case? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED] Sent: Fri 2/28/2003 8:42 AM To: Jboss-Dev Cc: Subject: [JBoss-dev] stop using JDK 1.4 for development There have been a lot of build breakages lately because people are using JDK 1.4 features and they break in JDK 1.3 builds. WE STILL SUPPORT JDK 1.3. My suggestion? Stop developing JBOss with jdk 1.4 and develop with 1.3. Please stop the sloppiness. Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] stop using JDK 1.4 for development
Bill, JRE 1.4. I don't care how you compile. I just want to make sure that running JBoss under 1.4 (which is what I'm doing now) is supported. - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Fri 2/28/2003 9:18 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] stop using JDK 1.4 for development We're not going to have .jpp or other ant switches just so that people can use nested exceptions -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED] Behalf Of Matt Munz Sent: Friday, February 28, 2003 8:54 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] stop using JDK 1.4 for development Bill, I thought JBoss was going to support 1.4. Is this not the case? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED] Sent: Fri 2/28/2003 8:42 AM To: Jboss-Dev Cc: Subject: [JBoss-dev] stop using JDK 1.4 for development There have been a lot of build breakages lately because people are using JDK 1.4 features and they break in JDK 1.3 builds. WE STILL SUPPORT JDK 1.3. My suggestion? Stop developing JBOss with jdk 1.4 and develop with 1.3. Please stop the sloppiness. Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] stop using JDK 1.4 for development
David, This is probably none of my business, but... I'd prefer to have a reliable way to report these problems, since I don't consider it realistic for me to develop on 1.3.1. How do you detect them? Isn't this what integration builds and tests are for? If someone checks in code that does not compile and pass integration tests on all supported platforms, then it should probably be rolled back. How could we make this better known and popularize it? Perhaps a code conventions guide in addition to the code style guide? The Checkstyle tool (http://checkstyle.sourceforge.net) might also be used/modified to enforce this and other usage rules. - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Fri 2/28/2003 10:16 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] stop using JDK 1.4 for development I'd prefer to have a reliable way to report these problems, since I don't consider it realistic for me to develop on 1.3.1. How do you detect them? For the particular problem of nested exceptions, I think we should always use the jboss NestedThrowable stuff Jason wrote since it provides a much more reasonable stack trace. Dain and I made as much as we could find of the jca and jta frameworks use this with good results. How could we make this better known and popularize it? thanks david jencks On 2003.02.28 08:42 Bill Burke wrote: There have been a lot of build breakages lately because people are using JDK 1.4 features and they break in JDK 1.3 builds. WE STILL SUPPORT JDK 1.3. My suggestion? Stop developing JBOss with jdk 1.4 and develop with 1.3. Please stop the sloppiness. Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] is head all messed up?
Bill, I have been seeing errors since I rebuilt with the latest source about 1 hour ago. I'm not sure yet what the problem is. When I run -c default, the server crashes after a few seconds... - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 3:35 PM To: Jboss-Dev Subject: [JBoss-dev] is head all messed up? Is anybody seeing a million errors just booting run -c all? How bad is the testsuite failing? I'm in the process of getting a clean checkout, but would appreciate if anybody has any info right now. Thanks, Bill --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-jmx.jar
Hi all,
I'm working on the XML Persistence Manager for MBeans. I put the manager in
org.jboss.mx.persistence. When I compile, this class is put in jboss-jmx.jar, yet
when I look at $server_root/server/all/lib, it's not in there.
I found the following code in /build/build.xml -- which seems to reference
jboss-jmx.jar. What is the desired effect? If not in jboss-jmx.jar, where should my
class be put so that it ends up as part of the server?
target name=_module-jmx-most
property name=_module.name value=jmx override=true/
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
!-- Copy the generated libraries --
mkdir dir=${install.lib}/
copy todir=${install.lib} filtering=no
fileset dir=${_module.output}/lib
include name=jboss-jmx.jar/
/fileset/copy
- Matt
+Ñzf¢+,¦ì¢·o$¨º· àxIízºkÇv+b¢Ï{±Zåu*zØb
yèm¶ÿÃ
/jÊ ·«yÊ%º,±×¯zZ)éí¨¥x%ËIn,uëÞfz{eËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?º,±×¯zZ)éí
RE: [JBoss-dev] jboss-jmx.jar
Scott,
Thanks.
- Matt
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Mon 2/10/2003 4:22 PM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [JBoss-dev] jboss-jmx.jar
jboss-jmx.jar is in the root lib directory since its part of the core
microkernel.
build 190ls /usr/Main/jboss-head/build/output/jboss-4.0.0alpha/lib/
bcel.jar*jboss-boot.jar*jdom.jar*
commons-httpclient.jar* jboss-cache.jar* log4j-boot.jar*
concurrent.jar* jboss-common.jar* webdavlib.jar*
getopt.jar* jboss-jmx.jar* xercesImpl.jar*
gnu-regexp.jar* jboss-jsr77.jar* xml-apis.jar*
javassist.jar* jboss-management.jar*
jboss-aop.jar* jboss-system.jar*
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Matt Munz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 12:35 PM
Subject: [JBoss-dev] jboss-jmx.jar
Hi all,
I'm working on the XML Persistence Manager for MBeans. I put the manager
in org.jboss.mx.persistence. When I compile,
this class is put in jboss-jmx.jar, yet when I look at
$server_root/server/all/lib, it's not in there.
I found the following code in /build/build.xml -- which seems to reference
jboss-jmx.jar. What is the desired effect? If
not in jboss-jmx.jar, where should my class be put so that it ends up as part
of the server?
target name=_module-jmx-most
property name=_module.name value=jmx override=true/
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
!-- Copy the generated libraries --
mkdir dir=${install.lib}/
copy todir=${install.lib} filtering=no
fileset dir=${_module.output}/lib
include name=jboss-jmx.jar/
/fileset/copy
- Matt
NHSMX銲uxZ + .)jŕن jz~zqzz
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
winmail.dat
RE: [JBoss-dev] JBoss-IDE 1.0 alpha released (Solved)
Nevermind. I just noticed the three launch configurations for JBoss servers (denoted by a grey server icon) in the debug launch configurations window. - Matt -Original Message- From: Matt Munz on behalf of Matt Munz Sent: Fri 1/31/2003 5:15 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] JBoss-IDE 1.0 alpha released Hans, JBoss + Eclipse == :) I've installed JBoss-IDE, and it looks good -- but how do I use it? The docs are great but perhaps I'm missing something. I'm trying to add my server to the Server Navigator. I right click on the empty Server Navigator view, and the only option is a greyed-out configuration. When I select configuration, I get the error Project does not exist. Does the server need to be running first or do I need the server code loaded in Eclipse or something else? - Matt -Original Message- From: Hans Dockter [mailto:[EMAIL PROTECTED]] Sent: Wed 1/29/2003 6:08 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] JBoss-IDE 1.0 alpha released I'm delighted to announce the release of JBoss-IDE 1.0 alpha. The JBoss-IDE is based on Eclipse. Link to the JBoss-IDE project page: http://www.jboss.org/developers/projects/jboss/jbosside.jsp You can download JBoss-IDE from: http://prdownloads.sourceforge.net/jboss/jbosside1.0a_05.zip?download Enjoy (-: Hans --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
David, Thanks so much. To paraphrase, there's basically a JBoss-specific MBean type that requires invoking stop() before setting any attributes and start() after doing so. This sounds quite reasonable. Thanks again. - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 9:00 PM To: [EMAIL PROTECTED] Cc: Subject: Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Anyway, to see why this might be useful, lets hypothesize an mbean that takes a long time to create (just as an object) and has a socket. You want to set the ip address and port on the socket as separate attributes on the mbean. Well, creating a new socket whenever you change the host or port is not very satisfactory since there's a good chance you want to change both. Changing just one will leave the mbean in a unusable state, pointing to the right host but wrong port. You don't want to replace the mbean object with a new one because it takes a long time to create. So , the service lifecycle lets you: stop (mbean is now theoretically unusable: this should be implemented in an interceptor, but is not right now)(this would discard the old socket) change both attributes (while the mbean is off) start (this creates a new socket with all correct parameters)(mbean is now usable again). There are also mbean dependencies, whereby if your mbean has an ObjectName valued attribute, and you tell jboss, your mbean can't start until the referenced mbean has started. This is used to get most of jboss to start in an order that will work. The code that does this is now spread over ServiceController, ServiceConfigurator, and ServiceContext with a little bit of ServiceCreator thrown in. Hope this clarifies what is going on a little bit. There are no attributes that have no effect... its just that say a port number may not get into the socket until you cycle the mbean, in case you want to change the host also. I also mentioned earlier that there's an xmbean attribute indicating what the effect on service lifecycle should be of changing an attribute value. The idea behind this (unimplemented) is that if you set several attributes at once, jboss should be able to cycle the lifecycle state for you. david jencks On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote: David, We are miscommunicating. In all the mbeans I have written and seen in jboss, aside from egregious bugs, if setting an attribute doesn't have an immediate effect, it does have the desired effect if you run through the service lifecycle (usually stop, start, occasionally stop, destroy, create, start). My view is that mbeans in jboss can take advantage of the service lifecycle. If you don't want to, make all your attribute changes have their effects immediately. All our mbeans are pretty much jboss specific and most heavily use the service lifecycle. They just won't run without it. I still think it is a really convenient extension to vanilla jmx and don't see why we should replace it. I barely know what the service lifecycle is. I have not used it. I am not arguing to replace it. I never said that. You said that. How do I set an attribute correctly, step by step, for a Bean that uses the service lifecycle? It helps me to use a state metaphor when considering lifecycle issues. It sounds like there are several states a lifecycle-oriented bean can be in: destroyed, created, running. In which state is it safe
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 8:00 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Can it be used at server startup instead of the jboss-service.xml, etc. files? i.e. can it create all Mbeans and apply all attributes value at runtime or can he only capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name Master Configuration Service may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some things around MetaData and centralized configuration and configuration chains in AOP that I'd like to merge with the rest of JBoss. Please see the topic configuration and metadata in the AOP forum. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, January 22, 2003 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Dain, I put this together with your use cases in mind. If possible, check it out, and let me know what you think. - Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Change Notes item #672538, was opened at 2003-01-22 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: Master Configuration Service Initial Comment: A Service which writes and reads all of the JMX RW attributes to a single file in the Java Properties Format. I figured that this would be a good step on the road to an XML MBean Persistence engine. This service operates externally to the MBeans it persists. It is not really in line with the JMX spec, so it doesn't provide MBean Persistence in the way implied by the spec. Nonetheless, a snapshot of the server can be written and loaded quite easily. The details can be found in the documentation located under
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 8:00 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Can it be used at server startup instead of the jboss-service.xml, etc. files? i.e. can it create all Mbeans and apply all attributes value at runtime or can he only capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name Master Configuration Service may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans with inconsistent interfaces. - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 10:30 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Not exatly. Take a look at the Naming Service MBean for example. It has a Port and IPAddress RW attribute for example because when the MBean is started the following occurs: - an instance of the Naming Service class is created (new blabla()) - the attribute values found in jboss-service.xml for this mbean are assigned to the RW attributes of the Naming Service MBean - the service controller invokes create and then start on the MBean instance - inside the create/start methods, the Port/IPAddress attribute values are used to connect to the appropriate port Once this is done, changing the Port RW attribute will have *no* effect i.e. the naming service will not unbind/rebind with a new address/port. For this, you must stop the service, change the values and restart it. Do you follow me? Cheers, sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:59 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out
[JBoss-dev] Mail Filter?
I sent 3 messages to this list since 11:50 EST, but they haven't appeared in my inbox. Did anyone else get them? None had attachments -- is there some sort of filter in effect? - Matt N¬HSDMéX¬²'²Þu¼¢êÜxZ+á'µêé®+ Øþ .)îÅj+Ô¨ëax6I硶Úÿ 0½«(~Üç(è²Ç^½éh¦g§¶f¢)à+-%º,±×¯zZ)éí+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþ6è²Ç^½éh¦g§
FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
this one didn't make it either... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 12:18 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, If you will, take a step back with me. Think JMX and not JBoss-JMX. You are writing a tool to do generic operations on MBeans. This is the purpose of JMX in the first place. Your tool encounters a RW attribute. What assumptions can be made, reasonably? Here are my assumptions: 1. get the value of the attribute and store it in an object. Do not modify the object. Set the value of the attribute to the object. No error will occur. 2. set the attribute to a given value that is not equivalent to the current value. The behavior / state of the MBean will change in a meaningful way. Does the JMX spec enforce these? Perhaps not. Is it nevertheless reasonable to expect this behavior? I think so. Neither of these assumptions are upheld, however, in the current use of MBeans in JBoss. I realize that re-writing mbeans might cause pain for the project. I'm not suggesting that it should even be done, necessarily, at least not right away. I am, however, trying to reconcile the notion of a RW attribute where writing the value has no effect. Can this be explained simply? BTW, I don't see how the lifecycle is related to this particular issue. Perhaps you could explain this in more depth? - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 11:44 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service On Friday, January 24, 2003, at 11:07 AM, Matt Munz wrote: Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). I think our current lifecycle based approach is quite workable as long as you use it as described in my previous post. As I understand it you are suggesting replacing the jboss lifecycle idea with the following: 1. All attributes that currently require lifecycle state changes should be made read only and set in the mbean constructor. 2. There should be some easy to use way to recreate an mbean with the same object name, some unchanged attributes, but new constructor arguments, at least as easy as the current stop-change-start technique. 3. No lifecycle methods. This might work, I haven't thought of any fatal problems with it. +: Currently most of our mbeans are probably insufficiently synchronized. By setting all arguments in the constructor, such problems could perhaps be reduced. -: This would require rewriting nearly every jboss mbean. I'd like to see more advantages before undertaking such an enormous project. david jencks What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Scott,
Email is bad format for emoting -- intent is often misinterpreted. I sincerely hope
that I have not offended anyone. This is never my intent.
I don't understand. I don't understand how the RW attribute issue relates to the
service lifecycle. I am not being critical, I am not being coy. I am sure that you
are right and I am wrong, but I don't know why. If you can spare the time, please
elaborate on this issue.
Twiddling attributes is an operation indepedent of restarting
a service and if you don't agree with that then we are at a viewpoint impass.
I just don't understand what this means. I have no intent of restarting a service. I
am not talking about restarting services. I am talking about the MBean interface.
David brought up the service lifecycle. I barely know what the service lifecycle is.
Could you please elaborate on this issue?
Setting
a RW attribute has an effect. Its just not the effect you are looking for so either
get
on board and work within the service life cycle or go play in your JMX sandbox.
setFoo(Object newFoo) { } /** this is an effect? */
Let me reiterate that I am not being critical, I am not telling anyone what to do, and
I am here to learn.
JBoss is great. The JBoss developers are awesome. It is a privelege to be a part of
this discussion in the first place.
- Matt Munz
Apelon, Inc.
winmail.dat
RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
David,
We are miscommunicating.
In all the mbeans I have written and seen in jboss, aside from
egregious bugs, if setting an attribute doesn't have an immediate
effect, it does have the desired effect if you run through the service
lifecycle (usually stop, start, occasionally stop, destroy, create,
start). My view is that mbeans in jboss can take advantage of the
service lifecycle. If you don't want to, make all your attribute
changes have their effects immediately. All our mbeans are pretty much
jboss specific and most heavily use the service lifecycle. They just
won't run without it. I still think it is a really convenient
extension to vanilla jmx and don't see why we should replace it.
I barely know what the service lifecycle is. I have not used it. I am not
arguing to replace it. I never said that. You said that.
How do I set an attribute correctly, step by step, for a Bean that uses the
service lifecycle?
It helps me to use a state metaphor when considering lifecycle issues. It
sounds like there are several states a lifecycle-oriented bean can be in: destroyed,
created, running. In which state is it safe to set RW attributes on
lifecycle-oriented beans?
Is the following the appropriate way to set values on a lifecycle-oriented
bean (pseudo-code)?
if(bean.isLifecycleOriented())
{
if(bean.isRunning())
{
bean.stop();
}
bean.setAttribute(newValue);
bean.start();
}
I'm here to learn :)
- Matt
N¬HSDMéX¬²'²Þu¼¢êÜxZ+á'µêé®+ Øþ .)îÅj+Ô¨ëax6I硶Úÿ
0½«(~Üç(è²Ç^½éh¦g§¶f¢)à+-%º,±×¯zZ)éí+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþ6è²Ç^½éh¦g§
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Dain, I put this together with your use cases in mind. If possible, check it out, and let me know what you think. - Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Change Notes item #672538, was opened at 2003-01-22 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=672538group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: Master Configuration Service Initial Comment: A Service which writes and reads all of the JMX RW attributes to a single file in the Java Properties Format. I figured that this would be a good step on the road to an XML MBean Persistence engine. This service operates externally to the MBeans it persists. It is not really in line with the JMX spec, so it doesn't provide MBean Persistence in the way implied by the spec. Nonetheless, a snapshot of the server can be written and loaded quite easily. The details can be found in the documentation located under $jboss-head/varia/src/reources/master- config.sar/documentation . There are a few little details that should probably be ironed out, but for those that need MBean persistence today, this is a viable solution. The main audience for this tool is the system admin that does not use or prefer gui / html configuration tools. The use of the Properties file format is intentional, as it provides a more compact and readible interface when compared with the XML format. I'm not sure about the location of this code in the source tree, so I just put it in varia for now. I'd appreciate any ideas on a better place for it. - Matt Munz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=672538group_id=22866 --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Oops. I have one more file to check in... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:38 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE However, since no packages are imported, xjavadoc has assumed that the referred classes belong to the same package as the referring class. The classes are: org.jboss.jdbc.HypersonicDatabase -- HypersonicDatabaseMBean qualified to HypersonicDatabaseMBean org.jboss.jdo.castor.CastorJDOImpl -- CastorJDOImplMBean qualified to CastorJDOImplMBean org.jboss.mail.Email2JMSConverter -- Email2JMSConverterMBean qualified to Email2JMSConverterMBean org.jboss.mail.MailService -- MailServiceMBean qualified to MailServiceMBean org.jboss.services.binding.ServiceBindingManager -- ServiceBindingManagerMBean qualified to ServiceBindingManagerMBean org.jboss.tm.plugins.tyrex.CoordinatorRemoteInterface -- Remote qualified to Remote org.jboss.tm.plugins.tyrex.TransactionManagerService -- TransactionManagerServiceMBean qualified to TransactionManagerServiceMBean org.jboss.varia.autonumber.AutoNumber -- EJBObject qualified to EJBObject org.jboss.varia.autonumber.AutoNumberHome -- EJBHome qualified to EJBHome org.jboss.varia.counter.CounterService -- CounterServiceMBean qualified to CounterServiceMBean org.jboss.varia.deployment.BeanShellSubDeployer -- BeanShellSubDeployerMBean qualified to BeanShellSubDeployerMBean org.jboss.varia.deployment.FoeDeployer -- FoeDeployerMBean qualified to FoeDeployerMBean org.jboss.varia.deployment.convertor.WebLogicConvertor -- WebLogicConvertorMBean qualified to WebLogicConvertorMBean org.jboss.varia.masterconfig.TestService -- TestServiceMBean qualified to TestServiceMBean org.jboss.varia.process.ChildProcessService -- ChildProcessServiceMBean qualified to ChildProcessServiceMBean org.jboss.varia.property.PropertyEditorManagerService -- PropertyEditorManagerServiceMBean qualified to PropertyEditorManagerServiceMBean org.jboss.varia.property.SystemPropertiesService -- SystemPropertiesServiceMBean qualified to SystemPropertiesServiceMBean org.jboss.varia.scheduler.AbstractScheduleProvider -- AbstractScheduleProviderMBean qualified to AbstractScheduleProviderMBean org.jboss.varia.scheduler.DBScheduleProvider -- DBScheduleProviderMBean qualified to DBScheduleProviderMBean org.jboss.varia.scheduler.ScheduleManager -- ScheduleManagerMBean qualified to ScheduleManagerMBean org.jboss.varia.scheduler.Scheduler -- SchedulerMBean qualified to SchedulerMBean org.jboss.varia.scheduler.SingleScheduleProvider -- SingleScheduleProviderMBean qualified to SingleScheduleProviderMBean org.jboss.varia.scheduler.XMLScheduleProvider -- XMLScheduleProviderMBean qualified to XMLScheduleProviderMBean org.jboss.varia.scheduler.example.SchedulableMBeanExample -- SchedulableMBeanExampleMBean qualified to SchedulableMBeanExampleMBean Running null/ Generating output for 'org.jboss.varia.masterconfig.Configurator' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jbossmx-xml-descriptor.xdt'. Running null/ Generating output 'transaction-service.xml' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jboss-service-template.xdt'. INFO:Some classes refer to other classes that were not found among the sources or on the classpath. (Perhaps the referred class doesn't exist? Hasn't been generated yet?) The referring classes do not import any fully qualified classes matching these classes. However, since no packages are imported, xjavadoc has assumed that the referred classes belong to the same package as the referring class. The classes are: org.jboss.varia.masterconfig.TestService -- TestServiceMBean qualified to TestServiceMBean _default:compile-classes: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/varia/output/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 96 source files to /home/jboss/jbossci/jboss-head/varia/output/classes /home/jboss/jbossci/jboss-head/varia/src/main/org/jboss/varia/masterconfig/Configurator.java:391: getPrimativeClass(java.lang.String) is not public in org.jboss.jmx.adaptor.control.Server;
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some things around MetaData and centralized configuration and configuration chains in AOP that I'd like to merge with the rest of JBoss. Please see the topic configuration and metadata in the AOP forum. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, January 22, 2003 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Dain, I put this together with your use cases in mind. If possible, check it out, and let me know what you think. - Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Change Notes item #672538, was opened at 2003-01-22 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: Master Configuration Service Initial Comment: A Service which writes and reads all of the JMX RW attributes to a single file in the Java Properties Format. I figured that this would be a good step on the road to an XML MBean Persistence engine. This service operates externally to the MBeans it persists. It is not really in line with the JMX spec, so it doesn't provide MBean Persistence in the way implied by the spec. Nonetheless, a snapshot of the server can be written and loaded quite easily. The details can be found in the documentation located under $jboss-head/varia/src/reources/master- config.sar/documentation . There are a few little details that should probably be ironed out, but for those that need MBean persistence today, this is a viable solution. The main audience for this tool is the system admin that does not use or prefer gui / html configuration tools. The use of the Properties file format is intentional, as it provides a more compact and readible interface when compared with the XML format. I'm not sure about the location of this code in the source tree, so I just put it in varia for now. I'd appreciate any ideas on a better place for it. - Matt Munz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
BTW, I realize that the name Master Configuration Service may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some things around MetaData and centralized configuration and configuration chains in AOP that I'd like to merge with the rest of JBoss. Please see the topic configuration and metadata in the AOP forum. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, January 22, 2003 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Dain, I put this together with your use cases in mind. If possible, check it out, and let me know what you think. - Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Change Notes item #672538, was opened at 2003-01-22 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: Master Configuration Service Initial Comment: A Service which writes and reads all of the JMX RW attributes to a single file in the Java Properties Format. I figured that this would be a good step on the road to an XML MBean Persistence engine. This service operates externally to the MBeans it persists. It is not really in line with the JMX spec, so it doesn't provide MBean Persistence in the way implied by the spec. Nonetheless, a snapshot of the server can be written and loaded quite easily. The details can be found in the documentation located under $jboss-head/varia/src/reources/master- config.sar/documentation . There are a few little details that should probably be ironed out, but for those that need MBean persistence today, this is a viable solution. The main audience for this tool is the system admin that does not use or prefer gui / html configuration tools. The use of the Properties file format is intentional, as it provides a more compact and readible interface when compared with the XML format. I'm not sure about the location of this code in the source tree, so I just put it in varia for now. I'd appreciate any ideas on a better place for it. - Matt Munz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships
[JBoss-dev] xDoclet - jboss.xmbean array attributes
xDoclet Users,
Are arrays supposed to be denoted as [Lsample.package.SampleClass; or as
sample.package.SampleClass[]? xDoclet seems to be doing the latter, but the JMX
Console seems to prefer the former.
For reference, the following code generates the XML snippet below, via xDoclet.
/**
* @jmx.managed-attribute
*/
public void setStringArray(String[] fStringArray)
{
this.fStringArray = fStringArray;
}
/**
* @jmx.managed-attribute
*/
public String[] getStringArray()
{
return fStringArray;
}
attribute access=read-write
getMethod=getStringArray
setMethod=setStringArray
description(no description)/description
nameStringArray/name
typejava.lang.String[]/type
descriptors
persistence/
/descriptors
/attribute
- Matt
N¬HSDMéX¬²'²Þu¼
¬-yÊ]¼n+lº«qêí³¥©e£
¨ºÚ ÆקvØ^(!zËZZ0yÝvñ¸zw+Êb¢{hjYr¢êÜ'§¶Ç¯zx¶²ºÇ®,z»-
«Zéb+^vÚ8Ѹzw+Êb¢qµ¨.סz·¡¶Úý§l²«qç讧zßÜâúÞv*ÞrÚe¶°ÓMôzr[¢Ë z÷¥¢ÙX§X¬´è²Ç^½éh¦g§¶X¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣøÛ¢Ë z÷¥¢
RE: [JBoss-dev] Main is not building
WIth current xdoclet, you have to be VERY CAREFUL TO IMPORT ALL CLASSES
ONE BY ONE AND NEVER EVER USE A import ...*; Doing this in one class
can easily mess up xdoclets class resolving and result in MANY OTHER
generated classes not fully qualifying their class names. I suspect
this has happened here, but don't have the latest source with me to
check.
I'm not an xdoclet user (yet), but may I suggest that the xdoclet parser be modified
to throw an exception (fail) the instant it encounters the first import...*;?
I have found that this use of errors to keep the user in line can be quite beneficial.
- Matt
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Fri 1/17/2003 9:10 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [JBoss-dev] Main is not building
WIth current xdoclet, you have to be VERY CAREFUL TO IMPORT ALL CLASSES
ONE BY ONE AND NEVER EVER USE A import ...*; Doing this in one class
can easily mess up xdoclets class resolving and result in MANY OTHER
generated classes not fully qualifying their class names. I suspect
this has happened here, but don't have the latest source with me to
check.
david jencks
On Thursday, January 16, 2003, at 04:47 AM, Scott M Stark wrote:
The server module in jboss-head is not currently building:
[javac]
C:\usr\Main\jboss-
head\server\output\gen\classes\org\jboss\invocation\trunk\client\Connec
tionManagerMBean.java:9:
cannot resolve symbol
[javac] symbol : class ServiceMBean
[javac] location: interface
org.jboss.invocation.trunk.client.ConnectionManagerMBean
[javac] public interface ConnectionManagerMBean extends
ServiceMBean {
[javac] ^
[javac]
C:\usr\Main\jboss-
head\server\output\gen\classes\org\jboss\invocation\trunk\client\TrunkI
nvokerProxyMBean.java:9:
cannot resolve symbol
[javac] symbol : class ServiceMBean
[javac] location: interface
org.jboss.invocation.trunk.client.TrunkInvokerPr
oxyMBean
[javac] public interface TrunkInvokerProxyMBean extends
ServiceMBean {
[javac] ^
[javac]
C:\usr\Main\jboss-
head\server\output\gen\classes\org\jboss\proxy\ProxyXAResourceMBean.jav
a:9: cannot resolve
symbol
[javac] symbol : class ServiceMBean
[javac] location: interface org.jboss.proxy.ProxyXAResourceMBean
[javac] public interface ProxyXAResourceMBean extends ServiceMBean
{
[javac] ^
[javac]
C:\usr\Main\jboss-head\server\src\main\org\jboss\ejb\EnterpriseConte
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by
implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
winmail.dat
RE: [JBoss-dev] Jboss JMX View Attributes
Stefan, Could you please clarify? What is an eclipse property sheet? What is a primitive in this gui? What is an over scaled complex object? If by complex object, you mean a Java Collection, and the ability to inspect / edit it in the gui, then I guess I prefer b, but a clarification would really help. - Matt -Original Message- From: Stefan Groschupf [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:21 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] Jboss JMX View Attributes Hi jboss friends, please vote: based on the jmx specification a JMX Mbeant attribute can be each object. I want to implement the Attribute editing in the jboss jmx gui next days. You think it make sence to edit the attributes as a.) Primitive in the eclipse property sheet view. b.) with a may be over scaled complex object instance wizard. Thanks for your input. Stefan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] MBean persistence?
Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] MBean persistence?
Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] MBean persistence?
(copied from a message I sent direct to Bill) Bill, I couldn't figure out how to add a comment to the task, so I'm just emailing you. I think we want seemless integration here I think you're integrating apples and oranges ;) What you've described does not match the current behavior of the ObjectStreamPersistenceManager. Are you saying that the jboss-service.xml files should be dynamically modified? I think that this adds unneeded complexity. Here is how I currently use MBean Persistence in my applications. --- jboss-service.xml - describes the initial (deploy-time) configuration of the bean, and the location of the corresponding XMBean descriptor xml. *-xmbean.xml - describes the signature of the metadata for the MBean. Includes the persistence configuration. Specifies the persistence type (ObjectOutputStream) and the persistence store name. /$Persistence_Dir/$Persistence_Store_Name.oos - the file where the MBean Server stores the record of the dynamically changing state of the MBean. --- Exchange XML for ObjectOutputStream and .xml for .oos in the above, and I believe we have a production-ready MBean Persistence mechanism. MBean persistence and MBean deployment are two separate mechanisms/concepts. This separation of concerns is *very* important, IMO, to preserve flexibility and ease-of-use/development. There are all sorts of things that need to go into a deployment descriptor that have little to do with the persistent state of the MBean, and vice versa. Although I see the motivation for a Grand Unified Descriptor, I don't see a rationale for it. I think a use case would really help here. For example, I don't see an individual in the deployment role ever touching the deployed archive. Rather they would use the JMX Console to modify the MBean attributes, which would be recorded in the MBean Persistence Store (XML, JDBC, OOS, whatever), and that would be the extent of their configuration work. In the case of an extreme server failure (uncommon), they could hack the store directly when the server was off-line (XML files, JDBC Tables...). Although this case is relatively uncommon, I believe this is one example where the separation of concerns mentioned above is useful. If I get the server into an inconsistent state and, as a result, it fails at restart (the inconsistency is reloaded), then, I can always delete the Persistence Store. When the server restarts, it returns to a clean-slate (deploy-time) state. If, as you seem to be suggesting, the (inconsistent) state has been stored in the deployment descriptors themselves, however, this clean-slate is not possible. One must go through each descriptor until the erroneous state information is found. Then it must be manually corrected. Since the MBean persistence engine will be writing to these files automatically, it may not be apparent how to do this. Could you explain further the behaviour you would like to see in MBean Persistence? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Mon 1/13/2003 10:54 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] MBean persistence? Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence
RE: [JBoss-dev] MBean persistence?
Dain, Please see my recent email in response to Bill. I origionally started with this approach, but the more I thought about it, the more untenable it seemed. Based on my experience so far, I just don't want the server mucking with my deployment descriptors. I'm sure I can figure out the autodeployer ;) But look what you're saying. Implement Persistence, modify deployer. Do you see how the two concerns are being tightly bound by this approach? We don't need AOP to solve this one ;) -- just locate the persistence in a separate place (this is what it wants to do anyway, IMO -- consider standalone applications. I've never seen an application open up its jars and stuff info into them. They always use a separate DB). BTW, I want to relocate this discussion to the Forums, as Bill suggests, but which one? I see at least 3 JMX-related forums! - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 11:38 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? Yes basically. Here is what I have in mind: as each attribute is loaded from the source xml the location from where it was loaded is remembered. When an attribute is changed that was loaded from the xml, the persistence manager overwrites the existing XML. I don't think you have to explode the jar, but I do think you basically have to rewrite the entire file. I think the trick will be to convince the auto deployer to not redeploy the modified file (if you can't figure that out it is ok... I get David J to get it to work :-) Does this sound do-able? -dain On Monday, January 13, 2003, at 09:54 AM, Bill Burke wrote: Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence
RE: [JBoss-dev] MBean persistence?
Dain, First off, thank you for providing much-needed field data for this work. Your comments on Persistence in general are identical to my reasons for working on MBean Persistence in the first place. When I suggest that we could write out a new different xml file that has the configuration changes, they all hated it. They want to be able to goto one file and know what is going on. Why do they want this specifically? It is important to take customer concerns and turn them into needs. Consider cooking at a restaurant. If the customer orders chocolate cake and you don't have it, do you bake a cake just because they want it? Perhaps we can give the sys admins chocolat pots de creme instead? They might even like it better... The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across upgades, they all chose the last. I personally would have gone for the second option, but I'm not an admin. I don't see the options this way. Losing stored MBean state across upgrades may end up being an application-specific detail at best. If the MBeans change, then the stored MBean state will likely be out of synch, regardless of where that state is stored. I don't see this as related to the issue of whether or not the mbean state store and the deployment descriptor should be merged. They want to be able to goto one file and know what is going on. Could you elaborate on this? Why would they be looking at files at all? I think we are running into a bit of a jam here, conceptually. They say they want to use the console to make persistent changes. Do they also want to use the filesystem to make changes? Two interfaces for the same device -- are they requesting any others? Why would they hack config files if they have the handy dandy console? ;) I can think of many possible answers to these questions, but how would the sys admins answer them? Please stick with me on this one. I think that if we can develop a solid use case for these things, we can get to some of the core issues, and perhaps you'll understand my rationale. The use case that you gave before is completely solved by my approach, BTW. Perhaps answering the questions above will help generate a use case that shows why two files is worse than one... - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 1:01 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? Jeremy, Specific comments are inline... On Monday, January 13, 2003, at 11:33 AM, Jeremy Boynes wrote: Like Matt, I have concerns about modifying the files in the deployment as well. I think his concerns about division of roles are valid - I'd go further and say this needs to be able to handle a split between 'deployer' and 'operator/sys admin' as well (where e.g. deployer defines which database to use, the sys admin defines the connection pool size). Every place has a different distinction between what a developer and an admin does. At some places the developers defines the entire db pool, at some the developer really only specifiec the pool name, and there are places in between the two. I am not making the claim that this is the solution for everyone, especially developers. I am saying that the average admin wants this feature. There are also circumstances where the SAR will be unmodifyable - e.g. if it is set read-only on the OS or if it is loaded from an http: URL. If a attribute is not persistable, then we don't persist it. We should modify the jmx-console to notify the user if an attribute is persistent or not. One possibility might be to store the local changes as a transform applied against the original file e.g. an XSLT. There are very few developers that understand XSLT, I would guess even less admins. This also has the advantage that local changes don't get lost when a new version is received from development. Also the same file can be rolled dev-test-stage-prod without needing to modify the deployment descriptor each time (one of the biggest compaints I've had from sys admins). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across
RE: [JBoss-dev] MBean persistence?
Dain, I like your give-them-what-they-want attitude. Rest assured that I am *very* aware of config file hell and am likewise motivated to avoid complexity. Please note that the current XMBean deployment involves at least *two* config files already. If the goal is to have only one, then perhaps the XMBean descriptor needs to be merged with jboss-service.xml? Ok. How do you see the options? To be honest, there are too many possibilities to enumerate here. Yes. They want it both ways. Some admins hate consoles, and some hate config files. A lot of times you have two admins, one that can't handle file configs and one that can't stand GUIs (even web GUIs). Sure. Well, the text guys are ok about the status quo, right? Or do they want a text-based dynamic interface to the JMX Server? ;) Anyway having a single config file has a big advantage, portability. Hmm. So you're saying that one file is more portable than two? I'm not sure that I buy that, especially if they are colocated or otherwise linked. In fact, when one big file with two distinct parts is separated into two files, I think it becomes *more* portable because it allows one to move only the relevant file, if needed. You can check it into CVS, you can copy it to another machine. Again, CVS is happy to take 2...n files. These are attributes of all files AFAIK. You can configure it with the GUI undeploy the admin screen (security and all) and still be able to config the system with vi. Now here is the beginning of a relevant use case. One admin uses the GUI, another uses the file system exclusively. We need to keep them in synch, right? GuiGuy browses the web to the relevant bean and modifies an attribute. The server then saves that to the persistence store. FileSystemGuy then browses the filesystem to the persistence store for that bean and also makes a change. On XMBean.load(), that change takes effect. Just as there is only one url for each mbean, there is one file system location for the record of its state. GuiGuy knows just where to look, and so does FileSystemGuy. So where's the beef? Yeah, FileSystemGuy may be used to looking at jboss-service.xml, but he doesn't have to look there anymore (Yea!). The *only* place he needs to go for server state records is the persistence store. State information in jboss-service.xml is thus used for default (deploy-time) values only. This is not confusing (at least not to me). I may not be explaining it correctly, however, so feel free to throw some questions my way. Hey, I'm not an admin, and when a whole bunch of them at different companies tell me they want it a very specific way, I say lets do it. I just don't agree with this at all. Your way right away may work at Burger King, but I don't think it works for creating lasting software. You're not an admin, but they're not software architects either. I fully respect this point of view, but also respectfully disagree. What if they all wanted to jump off a bridge? ;) If this approach is required, then perhaps someone else should take this task. The existing architecture aupports multiple persistence managers anyway... - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 2:59 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? On Monday, January 13, 2003, at 01:26 PM, Matt Munz wrote: Dain, First off, thank you for providing much-needed field data for this work. Your comments on Persistence in general are identical to my reasons for working on MBean Persistence in the first place. When I suggest that we could write out a new different xml file that has the configuration changes, they all hated it. They want to be able to goto one file and know what is going on. Why do they want this specifically? It is important to take customer concerns and turn them into needs. Consider cooking at a restaurant. If the customer orders chocolate cake and you don't have it, do you bake a cake just because they want it? Perhaps we can give the sys admins chocolat pots de creme instead? They might even like it better... Good point. To extend you analogy, if the customer wants a hamburger you don't give them cordon bleu, just because you think they will like it better (which they would :). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options
RE: [JBoss-dev] MBean persistence?
Scott, Thanks. I think the common point to both strategies is the MBean - XML serializer. I'll get started on that. For what date is the 3.2 release planned? - Matt -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 5:07 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 11:59 AM Subject: Re: [JBoss-dev] MBean persistence? ... --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
[JBoss-dev] PHP
Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Bill, Don't worry, I'm not going to blast you for not eating your own dog food. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) We're gonna call it JNuke sounds interesting... - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP new website. Its PHP and PostNuke. Its OK. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. Julien Viet is looking into porting it to the Java world. We're gonna call it JNuke. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 1:38 PM To: JBoss Developers Group (E-mail) Subject: [JBoss-dev] PHP Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP problems
Marc, Don't forget that hardware is cheap compared to man-hours. If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. If not, be prepared to eat it in the long run on man hours / maintennance. I think that the use of the tissue-paper methodology flies in the face of OSS. Why bother to open-source your IP if nobody will ever read it and you're just going to throw it away anyway? I'm glad to hear that this is a stopgap solution. BTW, thanks for providing a real-world case to justify my PHP allergy :) - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:56 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] PHP problems OK so we are really in a bind here. The script kiddy code may be functional, this lack of caching is really killing us. The site is pegged at 100 with dips at 50% on occasion but all in all the profile looks pretty bad. The Java code was 3 times faster. I feel good on one hand because this is yet another point in the cache is king category but it is also horrible scalability. It also makes the website next to un-usable since the response time is so bad. Next time I hear some ignorant bozo tell me apache is fast and c is fast and java is slow I take my baseball bat and smash his head in. I am tired of the rampant ignorance even among the geeks. It is just amusing at this point. We need to port the functionality we use in the website one to one with EJB's backing it up and offering some caching so we can multiply the speed by 10 and go back to our usual 10% CPU utilization. JNUKE will be a killer project. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP problems
what's a pronoun? :) - Matt -Original Message- From: danch [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 3:49 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] PHP problems Matt Munz wrote: Marc, If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. If not, be prepared to eat it in the long run on man hours / maintennance. And remember that eating used tissue-paper is never a good thing. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
James,
We called it our Groove Killer but never got enough $$ after 9-11 to
launch it full scale. I'd like to rewrite the framework I built our
product on using Jboss and open source it. Something like Eclipse but
not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for
You might be interested to know that the release plan for eclipse 2.2 includes a
separation of the IDE concern from the Application Framework concern. Although it is
possible now to use Eclipse as a non-IDE platform, I believe that they are going to
support this officially, perhaps even providing a separate download just for the
application framework component.
- Matt
-Original Message-
From: James Higginbotham [mailto:[EMAIL PROTECTED]]
Sent: Mon 12/23/2002 12:22 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE:
[eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
How much of what you are thinking of would be handled by:
jmx
Most if not all of it - the JMX timer would be responsible for the async
work of taking down and upgrading the module and its dependencies. In
addition, the rich client platform would benefit from JMX itself. The
only problem is transports between rich clients, but that is out of
scope for long enough that the JMX spec should catch up anyway. Besides,
JXTA could handle that if I really needed peer-to-peer rather than a
more client-server approach. Or, I could just use your built-in
clustering using JavaGroups as another option.
jboss service lifecycle
All of it, as I would see a module as the equiv of an EJB on the
client side from the standpoint of componentized development and the
need for component lifecycles. I actually built a similar application
that was Swing-based, used JXTA, and resembled something like Groove..
We called it our Groove Killer but never got enough $$ after 9-11 to
launch it full scale. I'd like to rewrite the framework I built our
product on using Jboss and open source it. Something like Eclipse but
not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for
the modules and provided a Module context for accessing known
platform services, plus a service locator for a more dynamic lookup
(including web services on the desktop over JXTA - that was fun!).
jboss mbean dependencies enhanced by including the version as
a key in the ObjectName and using queries or filter
conditions rather than equality for resolution of dependencies.
Jboss dependencies would be a must. I hadn't thought about versioning in
the name.. In the past I've shyed away from things like that in a
name, but since its unique to the JMX container, that should be fine..
Like encoding the version number in a OID I guess.
BTW in jboss 4 clients using the trunk invoker already have jmx client
side: others will follow when I get to work on tx
propagation for the other transports.
True, but I would want the JMX container initialized first thing..
Consider the typical startup as something like splash, init Jboss
Kernel, Load core platform services, load user services, launch user
application.
david jencks
James
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
N¬±ùÞµéX¬²'²Þu¼)äç¤Yé\¢g¢½éá¶ÚþØbH zG(û %º,±×¯zZ)éí¨¥x%ËIn,uëÞfz{eËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?º,±×¯zZ)éí
RE: [JBoss-dev] Good-bye II
Marc, I don't want to encourage this thread by adding to it, but I think a few clarifications would be beneficial for me. Andy is working on a competing implementation to jboss. Would it be possible to name this competing implementation? We cannot have a competitor's code in our base as it exposes us legally Is the issue that Andy does not own the code he wrote, and therefore does not have the right to contribute it to JBoss.org? It is my understanding of the LGPL that it permits proprietary derivatives, such that I may embed JBoss within another product, and even modify JBoss, as long as modifications to JBoss are released publicly. Modifications made to the product JBoss is embedded within would not need to be released to the public. I see no distinction whereby, if the encapsulating product is itself an enterprise server (a competitor), that this behavior would be prohibited. Am I misinterpreting the license? I imagine that one legal scenario is that several commercial competitors would all share the same opensource kernel at their core -- That one would see a product like Joe's Enterprise Server, with 'JBoss Inside'(TM). Perhaps you mean something else when you say compete? - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Mon 12/23/2002 10:49 AM To: [EMAIL PROTECTED] Cc: 'JBoss Group' Subject: jRE: [JBoss-dev] Good-bye II Andy is working on a competing implementation to jboss. His own lawyers at his company have requested he not work on JBoss, he was doing so anyway under an alias. We only found out about the competing aspect a couple of days ago. To protect ourselves legally, we removed Andy's RW, we will in fact remove the code contributions. We cannot have a competitor's code in our base as it exposes us legally. It is only the second time this has happened in our history. The mail below is an expression of Andy's personal gripes and bitterness. Period. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michael Bartmann Sent: Monday, December 23, 2002 9:09 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Good-bye II None of the JBG supporters has written everything by himself. This is of course a matter of control and organization, which you do very well as master of the tree. I wont let everybody do everything, but if somebody wants to contribute in the right direction he should not be blocked. OTOH if somebody would insist to commit something you dont want to go in and he refuses to restrain himself this is another question. In the end you'll have to protect jbg (and jboss) from sabotage. I cannot judge about what happend in Andy's case; most of the discussion fortunately seems to have happened in private mail. I just want to get rid of the doubt that something went wrong due to political reasons. Otherwise contributors might come to the conclusion that they support jbg, not the jboss community. So I simply wanted to provoke some clarifications; a little bit of meta-discussion might be ok on this list and of interest for other contributors, too. Regards, Michael Bartmann PS.: The forum would be ok for me, simply tell me where to go... Scott M Stark wrote: Development and support are not separable. Do you let anyone modify code you support? This discussion needs to move the forums. Marc will take it up tomorrow. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Michael Bartmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 23, 2002 1:54 AM Subject: Re: [JBoss-dev] Good-bye II - Andy: please keep cool and stay online (I like EJB timers :-) - Marc: consider developing and consulting as two different jboss ASPECTS. Again, I fear I misjudge because of lacking knowledge, but I couldn't resist to comment on this. I really don't like the idea of non-technical clash on jboss-developement. Regards, Michael Bartmann
[JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
Christophe, Well, I'm not aware of a doc that refers to loading/unloading specifically. JMX is a specification that focuses on instrumentation of networked components, and it, like many Java Specifications, has a limited focus, with few implementation details described in the specification. It has noetheless become apparent to some that JMX is useful as a backbone for a modular plugin architecture. I'm copying the JBoss development list on this thread, as there are a lot of JMX implementors there that could give more insight on the loading/unloading mechanism. Perhaps one of them knows about a concise document that explains the process? You might be interested in the following short description of JBoss/JMX which mentions classloading. The book mentioned on this page is also an excellent resource. http://jboss.org/developers/projects/jboss/jbossmx.jsp A more lengthy (but helpful) read is the JMX Specification itself. http://java.sun.com/products/JavaManagement/download.html The following developerworks articles don't really discuss loading, but I found them useful in evaluating JMX. http://www-106.ibm.com/developerworks/java/library/j-jmx1/ The reason I think of JBoss/JMX is its deploy folder. Drop in a module, and the server loads it automagically. Delete the module, and the server unloads it. Everything is configured with XML. It seems to me that this might be where Eclipse wants to go in terms of dynamic loading/unloading. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Fri 12/20/2002 4:03 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted Ed, I see the following item in the list: Allow plug-in deactivation. Not sure how far we can go Matt, Can you point us to some short-concise JMX doc about loading/unloading ? I want to know how far the Update Manager can reuse some of the techniques Christophe Elek Eclipse Platform - IBM Toronto Lab. (905) 413-3467 Friday, December 20, 2002 4:09 PM To: [EMAIL PROTECTED] cc: From: Matt Munz [EMAIL PROTECTED] Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted Ed eclipse-dev, One item that I think should be on the 2.2 plan is dynamic loading and unloading of Eclipse plugins... Is there any interest in using Java Management eXtensions and/or the JBoss microkernel for this purpose? It seems to me that the differences between server-side dynamic module loading and client side dynamic module loading are few, if any. Based on my experience with Eclipse and JBoss I see a lot of similarities in architecture and approach. JMX is also generally gaining acceptance, and comes with a lot of useful features beyond dynamic loading. - Matt -Original Message- From: Ed Burnette [mailto:[EMAIL PROTECTED]] Sent: Friday, December 20, 2002 3:23 PM To: [EMAIL PROTECTED] Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted One item that I think should be on the 2.2 plan is dynamic loading and unloading of Eclipse plugins. This would allow the user to install and uninstall features and plugins without restarting Eclipse. Currently Eclipse exits with a special return code and the native Eclipse executable re-invokes the java part. If there's not currently an open feature request on this (I didn't find one on a search) I'll be happy to open one. Thanks. -Original Message- From: John Wiegand [mailto:[EMAIL PROTECTED]] Sent: Friday, December 20, 2002 1:06 PM To: [EMAIL PROTECTED] Subject: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted The initial draft of the Eclipse 2.2 plan is available for review at http://www.eclipse.org/eclipse/development/eclipse_project_pla n_2_2.html. ... Please send comments about this draft plan to the [EMAIL PROTECTED] developer mailing list. We will be reviewing your feedback in the new year. ___ eclipse-dev mailing list [EMAIL PROTECTED] http://dev.eclipse.org/mailman/listinfo/eclipse-dev ___ eclipse-dev mailing list [EMAIL PROTECTED] http://dev.eclipse.org/mailman/listinfo
RE: [JBoss-dev] ATTENTION! Developers with CVS access
Bill, 1. What have you worked on in the past? Management. XMBean Persistence. 2. What are you currently working on? I'm not actively working on JBoss code at the moment. 3. What will you be working on and when? At some point, I plan on returning to the XMBean Persistence implementation, adding XML and/or JDBC implementations. I'd also like to make some enhancements to the existing user interfaces for JBoss management. I'm not exactly sure when I'll be working on these things -- the timing depends on priorities that aren't set by me :( 4. What do you want to work on? The primary areas that relate to the projects I'm working on include management and Web Services. 5. What is your SourceForge name/id? (So I can cross you off list of who contacted me). mattmunz By the way, (Apleon and ) I really appreciate the privilege of commit access. Since our use of JBoss hasn't progressed much past prototyping, at this point, we're not as involved in JBoss development as I would like. It is my intention, however, to increase my involvement in JBoss development as our JBoss-dependent projects move closer to production. - Matt Apelon, Inc. -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wed 12/11/2002 9:20 PM To: Jboss-Group@Jboss. Org; Jboss-Dev Cc: Subject: [JBoss-dev] ATTENTION! Developers with CVS access Hi all! Its time to gear up and embark on the journey that is JBoss 4.0. Our schedule is ambitious. We want to get a release done by JavaOne(the next JBossOne) in June 2003 so its gonna take a lot of hard work and focus from us over the next 6 months. That being said, I need some information from those developers/contributors that have CVS read/write access. 1. What have you worked on in the past? 2. What are you currently working on? 3. What will you be working on and when? 4. What do you want to work on? 5. What is your SourceForge name/id? (So I can cross you off list of who contacted me). The requirements/feature set for 4.0 is available here. http://www.jboss.org/developers/projects/jboss/projects.jsp Please comment and suggest bugs/features/requirements you want added to this list. I really need this information from you. You RISK LOSING YOUR CVS access if you don't respond! So please get back to me soon. Also, this information will also be used to help the Compensation Committee determine if you are eligible to receive incentive from the Compensation Program. http://www.jboss.org/news/compensation.jsp If you're wondering, my job as Chief Architect will be to make sure that everybody is focused on the vision of JBoss 4.0. This vision will be based on your collective vision as a group. I will also make sure that things are getting done and moving forward. If you say you will do something and end up not doing after a certain amount of time, I will recruit somebody else to do it. After I've collected this information from you, we(Marc, Scott, and I) will be deciding upon the lead developers for each of JBoss's subprojects. Lead Developers will have a list of responsibilites and perks that I will discuss at a later time. I will also be setting up Task lists for each sub-project on SourceForge so we can track how things are going. Thanks for your cooperation! Bill Burke Chief Architect JBoss Group, LLC --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] MetaDataRepository Proposal
Dain, and the worst part is we have no control over it at runtime. It is way simpler. You'll see. It sounds like you have a vision. Please continue to make the effort to get the rest of us into the loop. I want to see also, but I'd prefer to do so sooner rather than later (not after it's done and finished). The easiest case for me the read ahead configuration in entity beans. There is no reason for this to be static. In fact it should be manageable at runtime, and if I'm luck I'll be able to pull it off for 4.0. Scott tells me there is a similar need to manage security at Great, now we're getting somewhere. Can you pick one of these (perhaps the read ahead), and provide some details? What does the server admin have to do that is particularly time consuming? It may be obvious to you, but I'd love to hear the details on this one. runtime. There really is no need to shut down an application in production just to change some configuration data. This is *exactly* what MBean Persistence is supposed to do, IMO. Feel free to reread that last sentence for added emphasis. Why not channel this energy into making MBean Persistence even better? Shouldn't any and all server configuration be done through JMX anyway? Isn't that the point of JMX in the first place? Even if there is no real need the code is simpler. Simple is the key word. I'm new and all, so feel free to ignore me, but this whole thing just sets off my KISS alarm system -- it actually sounds rather complicated. - Matt --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.net email transport
Jason, Well, you've peaked my interest... This method(with digital signatures/encryption) would be more secure than the Http(s) transport, Really? Any articles on the subject? Authentication would be near definite (rather hard to fake), Is there something in the mail protocol that facilitates this? I'd love to see a strong argument for email is more secure than https... the server would not be exposed to the big bad internet, Hmmm. Email attacks are fairly common. Email is, by definition, a part of the internet. I'm not sure where you're going with this... and the company's IT guys don't have to set up a VPN to every outside source that needs to update data in the server. VPNs are bad ;) What's wrong with the tried and true poking a hole in the firewall technique? What about https? Is the idea that they have to have email anyway, so let's just tunnel over that? Wasn't this same argument used for HTTP tunnelling? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Jason Essington Sent: Thursday, November 14, 2002 10:33 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jboss.net email transport Hi Matt, Given an instance where a company would place a server on its intranet (behind a firewall that does not allow incoming connections from the internet). Now, If this company wanted to receive periodic updates to some semi-static data (iso country codes for instance) from a source on the internet. This source would need a VPN to get through the companies firewall (major hassle if this source has to update many servers, or if the company needs data updated from many different sources) or it could send a Signed and possibly Encrypted email to a mail account the company has set up for the server. The server checks it's email at a configured interval and processes any soap messages it finds there. The digital signature is used for message verification and authentication, while encryption could be used to protect sensitive parts of the message. The message is processed and it's response (or fault) is returned to the original sender via the mail server. This method(with digital signatures/encryption) would be more secure than the Http(s) transport, Authentication would be near definite (rather hard to fake), the server would not be exposed to the big bad internet, and the company's IT guys don't have to set up a VPN to every outside source that needs to update data in the server. All in all, and email transport with digital signatures and encryption has quite a bit of promise as a secure way to allow data to pass through/around a firewall without too much extra hassle. There would need to be a mechanism for key exchange, but no work on the part of IT. -jason On Thursday, November 14, 2002, at 07:21 AM, Matt Munz wrote: Jason, Just out of curiosity, what would you use this for? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Jason Essington Sent: Wednesday, November 13, 2002 5:48 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] jboss.net email transport Hi all I have managed to get a fairly crude email transport working in jboss.net (It is lurking in head). I would appreciate any comments / design ideas from folks who are interested. Check the javadocs in org.jboss.net.axis.mail.MailTransportService to see how to set it up. It will currently process emails with simple soap messages (no attachments). It requires the content type to be application/soap+xml with the action attribute set to the desired service. i.e. content-type: application/soap+xml; action=SomeService The response message is returned to the sender via email. Since email doesn't really have any type of authentication framework the transport will only work with ejb's / ejb methods's that have unchecked permissions. I have been able to sign (DSA) a soap message using apache's xml-security library and have jboss.net verify the signature (I haven't submitted this handler yet, as it depends on the apache xml-security library that would have to be added to the thirdparty libs). I think this is the first step to some sort of authentication via email (and cryptographic authentication by other transports as well). but . . . I haven't figured out how to go about trusting a given signature and mapping it to a Subject. This is where I could use the help of someone with a better knowledge of jaas and JBossSX than myself. Thanks for any feedback -jason --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https
RE: [JBoss-dev] jboss.net email transport
Jason, You rock. Thanks. I have a much better understanding now of why it helps to have this tool in the toolbox. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Jason Essington Sent: Thursday, November 14, 2002 12:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jboss.net email transport On Thursday, November 14, 2002, at 08:55 AM, Matt Munz wrote: Jason, Well, you've peaked my interest... This method(with digital signatures/encryption) would be more secure than the Http(s) transport, Really? Any articles on the subject? Using digital signatures / xml encryption would make the soap message more secure over any transport http://www.xml.com/pub/a/2001/08/08/xmldsig.html Here are two from JavaWorld about Securing web services in general. http://www.javaworld.com/javaworld/jw-08-2002/jw-0823-securexml.html http://www.javaworld.com/javaworld/jw-10-2002/jw-1011-securexml.html And two from developerworks on xml encryption in general http://www-106.ibm.com/developerworks/library/x-encrypt/index.html http://www-106.ibm.com/developerworks/library/x-encrypt2/index.html Authentication would be near definite (rather hard to fake), Is there something in the mail protocol that facilitates this? I'd love to see a strong argument for email is more secure than https... Email has really NO good authentication system, so rather than depend on the smtp (or whatever) protocal for security and authentication, we use XML-Signature and XML-Encryption to secure the SOAP message. This method will add additional security to any transport. http://www.w3.org/TR/SOAP-dsig/ http://www.w3.org/TR/xmldsig-core/ http://www.w3.org/TR/xmlenc-core/ the server would not be exposed to the big bad internet, Hmmm. Email attacks are fairly common. Email is, by definition, a part of the internet. I'm not sure where you're going with this... The app server itself would not be exposed, it would still have an indirect connection via email (mail server), but the email transport only handles a very small subset of email types and discards the rest. and the company's IT guys don't have to set up a VPN to every outside source that needs to update data in the server. VPNs are bad ;) What's wrong with the tried and true poking a hole in the firewall technique? What about https? Some companies are rather picky about what gets poked through their firewall, and in some companies certain departments fear the IT group and would rather not bother them to do such things. This just gives another option that doesn't require the poking of holes in the firewall. Is the idea that they have to have email anyway, so let's just tunnel over that? Wasn't this same argument used for HTTP tunnelling? HTTP(S) is nice, and would be completely sufficient if incoming packets were allowed in every environment, but since there are situations where this is not possible there is a need for another method. Since the email transport initiates the transaction (contacts the email server to collect messages) it is capable of if performing in situations where http could not. And yes, since the app server already has it's own email account, this is a ready made path to follow. I am in no way saying that the http transport is bad, I am just trying to create an option for situations where http is not feasible. Email has it's inherent shortcomings that the implementation of xml-security would help alleviate. So really what we have here is two-fold, a security infrastructure that allows soap messages to be digitally signed and possibly encrypted and an additional transport that depends on that infrastructure to allow for the secure transmission and authentication of data. -jason --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Dain, Please excuse my ignorance. I'm a bit JMX-centric at the moment. I see an org.jboss.mx.server.Invocation that doesn't seem to know about / relate to org.jboss.invocation.Invocation. Obviously the names are the same. Is there any deeper relationship? When I hear metadata JBoss in the same sentence, I think of JMX MBeanInfo. Since I recently wrote some code to facilitate MBeanInfo persistence, I'm interested in any changes to the way MBeanInfo is stored in the server. Is this related at all? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 2:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Matt Munz wrote: Dain, Meta data for an invocation. I assume you refer here to EJB/servlet invocations. No, I mean JBoss invocation. It doesn't matter if it an EJB, servlet, JMS message... and org.jboss.invocation.Invocation will do. Just out of curiosity, how is that metadata currently stored? Scattered across all the code. Most of it is in the container and interceptors. The big problems are the data is all static for the life of the container, and there is no good place to put defaults for an entire application or domain. -dain --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Bill, Components register their XML with this service. MBean, EJB, whatever... For MBeans, you're talking about *-service.xml, right? Would this apply also to XMBean XML? JMX console needs an additional XML editor for MBean attributes that are XML elements. I think it would be great to expand the JMX console to handle all sorts of common types, for input and output. Collection obects and arrays in particular would be a powerful addition. I believe that the PropertyEditor mechanism may be useful for this. I always thought that w3c DOM Elements were transient objects -- a stepping stone between XML text and full-fledged objects. I'm curious -- why do they need to be stored as MBean attributes? BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? Is there something specific to this metadata problem that makes a central XML file a more attractive solution? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 1. I'm not talking about a central config file...Components register their XML with this service. MBean, EJB, whatever... 2. You know what XPATHs are right? If not, look them up. They are really cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. What's not supported, which we would have to write, would be the ability to register for change notifications via an XPATH. Other ideas: - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. Services/components registered as listening for changes, recieve notification. - JMX console needs an additional XML editor for MBean attributes that are XML elements. - This sort of centralized service allows you to query, via XPATHS, for all components that have a port attribute for instance. Allows you to do global things on configuration when you don't know the actual components that have that type of attribute Another thing about configuration I wanted to have is the concept of Configuration Domains. A component would get configuration by searching a set of chained configuration domains. invocation domain-instance domain-component domain-app server domain-cluster domain etc... So, when a component needs config information, it looks it up via the chain. Any domain in the chain can override a config value. As the chain is traversed, if the config info is not there, it searches farther up the chain. This would allow us to have a layered way of obtaining default config information, or overriding existing configuration at different levels at different times. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Wednesday, November 13, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service Dain, Meta data for an invocation. I assume you refer here to EJB/servlet invocations. Just out of curiosity, how is that metadata currently stored? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Meta data for an invocation. What are the tx attributes? What is the security manager? What are the required roles? What is the readahead configuration? That kind of data. -dain Matt Munz wrote: Dain/Bill/Scott, Could you clarify this? Metadata for what data? Are you referring to MBeanInfo, or something else? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 12:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Bill Burke wrote: Dain and I were IMing. He said Scott was thinking about a MetaData service... My idea for a MetaData/Configuration service would be the ability to register for callbacks based on XPATHS. So, all config of jboss would be stored in one big XML Document. Components insert their config there, and register for callbacks on this config via XPATHS. So, this config can be managed centrally, yet, components can easily be notified with changes via a simple mechanism. I didn't know you could do that. What spec/library is this in? I want to read it. Scott and I were really only talking about use. We need something like this for component, application, and domain data, but we didn't get into the actually implementation. We just decided to have an metadata loader interceptor and a metadata loader interface for the interceptor
RE: [JBoss-dev] Metadata Service
Got me. I am a bit to EJB centric at the moment. I would guess that plan it to merge them, but I don't know. I'd be interested in hearing more about this topic. I imagine AOP converges on this issue as well? Cool. I'm interested in the MBean persistence stuff. I have no plans on writing the final metadata repository, I just want to use one, so I will quickly write something with a very simple interface that can be replaced later. I feel that all this stuff is related, we just need to figure out how it all fits together. Well, that is pretty much the approach with the MBean persistence stuff, AFAIK. The mechanism is pluggable, and the implementation is really a RI / straw man. Personally, I think that persistence of metadata for the server (JMX or otherwise) should be pluggable -- file, XML file, JDBC, whatever on the back end. To me, JMX is all about metadata -- in a sense, it is the metadata that makes detyped invocation work. When you talk about adding metadata to an invocation, and storing that metadata somewhere, it sounds just like MBean persistence. At a minimum, you should be able to reuse some ideas, if not code, from the management module... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Matt Munz wrote: Dain, Please excuse my ignorance. I'm a bit JMX-centric at the moment. I see an org.jboss.mx.server.Invocation that doesn't seem to know about / relate to org.jboss.invocation.Invocation. Obviously the names are the same. Is there any deeper relationship? Got me. I am a bit to EJB centric at the moment. I would guess that plan it to merge them, but I don't know. When I hear metadata JBoss in the same sentence, I think of JMX MBeanInfo. Since I recently wrote some code to facilitate MBeanInfo persistence, I'm interested in any changes to the way MBeanInfo is stored in the server. Is this related at all? Cool. I'm interested in the MBean persistence stuff. I have no plans on writing the final metadata repository, I just want to use one, so I will quickly write something with a very simple interface that can be replaced later. I feel that all this stuff is related, we just need to figure out how it all fits together. -dain --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Bill, My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured Well, so do DTDs and XML schemas. It is an interesting argument that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Is there something specific to this metadata problem that makes a central XML file a more attractive solution? I saying Document as in the Java Object. Not in a XML file stored on disk. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 1. I'm not talking about a central config file...Components register their XML with this service. MBean, EJB, whatever... 2. You know what XPATHs are right? If not, look them up. They are really cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. What's not supported, which we would have to write, would be the ability to register for change notifications via an XPATH. Other ideas: - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. Services/components registered as listening for changes, recieve notification. - JMX console needs an additional XML editor for MBean attributes that are XML elements. - This sort of centralized service allows you to query, via XPATHS, for all components that have a port attribute for instance. Allows you to do global things on configuration when you don't know the actual components that have that type of attribute Another thing about configuration I wanted to have is the concept of Configuration Domains. A component would get configuration by searching a set of chained configuration domains. invocation domain-instance domain-component domain-app server domain-cluster domain etc... So, when a component needs config information, it looks it up via the chain. Any domain in the chain can override a config value. As the chain is traversed, if the config info is not there, it searches farther up the chain. This would allow us to have a layered way of obtaining default config information, or overriding existing configuration at different levels at different times. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Wednesday, November 13, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service Dain, Meta data for an invocation. I assume you refer here to EJB/servlet invocations. Just out of curiosity, how is that metadata currently stored? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Meta data for an invocation. What are the tx attributes? What is the security manager? What are the required roles? What is the readahead configuration? That kind of data. -dain Matt Munz wrote: Dain/Bill/Scott, Could you clarify this? Metadata for what data? Are you referring to MBeanInfo, or something else? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin
RE: [JBoss-dev] Metadata Service
Anatoly, Actually, Jakarta JXPath can handle practically any java object graph (consisting of JavaBeans, Maps, etc. ) and traverse it via an XPATH query, so you don't have to tie yourselves to DOM objects. check out http://jakarta.apache.org/commons/jxpath/ Wow. Thanks. Coolest thing I've seen today :) Bill, Perhaps this might bridge your need for cross-cutting metadata searches without using an XML object as a memory storage mechanism... - Matt --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Bill, What I was trying to suggest is that complex xml config data is modified via a file or through some Management Console at runtime. Components can register via XPATHS to listen to this changed data. They are notified and update their local config, construct new objects, whatever... Hmmm...I'm starting to see what you're saying. MBeans already have notifications and ways to query, right? Yes. Why not build on JMX and JBoss Management instead of around it? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? XPATHs would be a perfect fit for something like this. Why recreate? A matter of implementation, right? Perhaps the search features are an extension of JMX (more of a JBoss Management feature). Maybe the jxPath route might work -- maybe something else? I don't know if the current search implementation could be replaced easily with something else or not... The MBean registry seemed fairly simple at first glance... something like a big Hashtable... Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Well, MBeans are fairly neutral. I'm sure that we could pile on whatever structure we want. For example, to make MBean persistence work, we used a certain MBean attribute to denote that an MBean could be persisted in a certain way. Nothing in the spec. requires this -- it's just an extension. Your configuration domains might be treated in a similar manner. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. Use cases are good. I don't know much about JBoss clustering -- I wouldn't know where to start. Is it possible to give a single-machine example? - Matt --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
David, I'm thinking of a minimal that is perhaps smaller than that. I think that the MBean API + proxies should be sufficient for many clients. Currently setting up the sar deployer is done in the jboss startup code, and the minimal jboss-service.xml is then read in. Without this, how do you propose to efficiently deploy and configure mbeans? What's wrong with mbeanServer().registerMBean(mmb, name) ? I guess I'm thinking that some clients will not want to get overly involved with the file system. JMX on the client side and JBoss on the client side are two different things, right? AFAIK, MBeanServerFactory.createMBeanServer() doesn't require the service deployer. If it does, that's another thing... - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss.net and performance tuning
CGJ,
Discuss this when I come back, ok? It´s crucial and your measures should
help a lot in that respect.
Sure. Enjoy your time off :) . FWIW, I am not seeing a significant
improvment w/ Axis + Tomcat (no JBoss) either, so I am guessing that axis
itself is the primary bottleneck...
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Jung
, Dr. Christoph
Sent: Friday, November 08, 2002 12:54 PM
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] JBoss.net and performance tuning
Matt,
Currently we just do prototyping with the stuff, no profiling at all. I´m
away three weeks for holiday. Let us
Discuss this when I come back, ok? It´s crucial and your measures should
help a lot in that respect.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:mmunz;apelon.com]
Gesendet: Freitag, 1. November 2002 18:14
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] JBoss.net and performance tuning
hi again,
Anybody out there working on or using JBoss.net?
Attached are some files I'm using to test, in a very simplistic way, the
performance of jmx.net.
My current timing so far is on average .3 seconds to complete the simplest
possible transaction (as far as I can tell) -- returning a very short string
object.
Does this number sound reasonable? If so, what are you using JBoss.Net
for? Perhaps I have the wrong idea...
Not included in the archive is the class JmxNetProxy, which is a delegate
for the mechanism used in the JBoss.Net test cases. Here's the relevant
method from that class.
public Object invoke(String webServiceName, String mbeanServiceName,
String methodName,
Object[] arguments, Class[] classes)
throws Exception
{
...
MBeanInvocationHandler handler;
handler = createMBeanInvocationHandler(target);
return handler.invoke(mbeanServiceName,
methodName,
arguments,
classes); // classes
}
Any comment would be greatly appreciated.
- Matt ([EMAIL PROTECTED])
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz
Sent: Thursday, October 31, 2002 11:17 AM
To: JBoss Developers Group
Subject: [JBoss-dev] JBoss.net and performance tuning
CGJ and JBoss.net guys,
My fledgeling JBoss.net enabled application is growing up and it needs
some performance enhancements. Particularly, Marshalling/Unmarshalling
appears to take significantly longer than expected.
Here's my setup.
1) I'm using the JMX.net proxy classes used in the test cases.
2) I am working with short, frequent transactions.
3) I am using the bean serializer to send simple custom objects across the
wire.
4) On the server side, an MBean is the recipient of the request.
RE: #1 -- Would WSDL2Java be any faster? Is MBean to wsdl generation
working yet?
RE: #2 -- I know, course-grained transactions are preferred, but are they
required? My objects are small, almost tiny. How fast can a transaction
be? If I can get it under .05 seconds, this should suffice for the moment.
RE: #3 -- Any tips / tricks here? Would switiching to primitives and
Strings be markedly faster?
Any help would be greatly appreciated. Links to benchmarks / performance
tests would help too.
- Matt
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
Is this a good idea? Should we look at it for 4.0? It makes sense to me. The closer a client environment models the server, the better, IMO. Of course, the client should be as complex as necessary and no more, etc. Things are getting more distributed all the time... could I end up with 2 kernels in the same VM? Just a thought.. Are we still talking about client-server? I thought that by definition, the client is in a separate VM, if not a separate physical machine... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Friday, November 08, 2002 3:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? Yep, these are the technical issues. We should be able to code around them, but it may be challenging. I am really interested in what everyone else thinks. Is this a good idea? Should we look at it for 4.0? -dain James Higginbotham wrote: That would be interesting. I've really wanted to put together a rich client framework using jboss as the kernel for adding services and hotdeploying client functionality, but haven't had the time. Just something to think about: what happens if you do this and I want my app to start a kernel - what sort of classloader implications are there - could I end up with 2 kernels in the same VM? Just a thought.. This would rock! James -Original Message- From: Dain Sundstrom [mailto:dain;daingroup.com] Sent: Friday, November 08, 2002 11:25 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? Yes that is exactly what I am suggesting. When you first contact the JBoss server we start an MBeanServer if non is available. I think we may have problems if we use features specific to the JBoss JMX code (like not having huge bugs), but that is a discussion for another day. -dain James Higginbotham wrote: Interesting.. Are you guys talking about a small JMX container on the client invoker side? Or something else? -Original Message- From: David Jencks [mailto:davidjencks;directvinternet.com] Sent: Thursday, November 07, 2002 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? +1000 This will greatly simplify many things, such as the trunk invoker client. I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: Why don't we require jmx on the client side? I bet it takes almost no memory and it has a small jar size. If do require it on the client side, we can reuse all the services we are building on the server, like a jcache mbean. It would also simply server to client messages, which will be used for cache invalidations and jms messages. This is because we can reuse the invoker architecture. There will still be a problem with socket back channels to clients on the other side of a firewall, but we would get a ton of reuse and simplification. -dain --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
Imagine a world where jboss is installed everywhere - client and server. ;) You're talking about (more evenly) distributed systems (a.k.a. P2P)? I think you're still going to need a delineation of roles -- some nodes are going to be thicker than others. You don't want to start up an entire JBoss stack just to run JNotepad (fictional). Likewise, I'd imagine you don't want all of your client side applications running in the same JVM. It seems to me that a measure of fault tolerance is worth the extra memory use (by starting up separate VMs) in this case (although I'm interested in arguments to the contrary). It seems to me that when you're designing a node in a distributed system, you start out by defining the role/functionality. Then take the most minimal JBoss kernel. Then start stacking on functionality until you have what you want. What makes this better than client-server, IMO, is that all nodes (should) share a common architecture. That way, server-side code can easily be pushed to the client for added performance. So JNotepad uses a Web-service based remote spellchecker. You like it? OK, download spellchecker.sar, and any server modules that it depends on. What makes this worse than client-server is that it doesn't exist yet, AFAIK :) ... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of James Higginbotham Sent: Friday, November 08, 2002 4:42 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JMX on the client side? I think James had more esoteric plans... -danch Right.. I'm not talking about Jboss proper, I'm speaking of a rich client platform that uses jboss as its service arch kernel. Imagine a world where jboss is installed everywhere - client and server. ;) James --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
David, Hard to know. We do have the minimal jboss configuration, which is a good starting place: as I recall basically all it can do is deploy .sars. AFAIK I'm thinking of a minimal that is perhaps smaller than that. I think that the MBean API + proxies should be sufficient for many clients. It's a lot easier for me to think about the container starting first, and I think it will provide less surprising performance, but I'm not sure we can Isn't Dain's method just lazy instantiation (by definition harder to measure performance-wise)? I imagine a client proxy factory that 1) checks for an mbean server, creates it if necessary, and then 2) checks if required client-side MBeans are loaded and then loads them if necessary, before returning the proxy. Either way, this all sounds good. Too bad I don't have a real use for it yet ;) - Matt --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MBeanInfoDB-xmbeandd.xml - is under alien influence
Peter, WTF - I am trying to test stuff an my invocation looks like : AFAIK, there are no server resources that depend on this MBean, so just delete it if you don't like the error message. \ ? is bad stuff - get a real OS ... Po-tay-toes, po-tah-toes. What's real, anyway? :) Perhaps you'd like to replace this DTD URI with another one that works. I've asked the list for suggestions, and haven't gotten much of a response. I've been meaning to try replacing it with the following doctype declaration, which I think may do the job. !DOCTYPE mbean PUBLIC -//JBoss//DTD JBOSS XMBEAN 1.0//EN http://www.jboss.org/j2ee/dtd/jboss_xmbean_1_0.dtd; I may not get to this for a while. Perhaps you'd like to try it. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Peter Fagerlund Sent: Thursday, November 07, 2002 12:21 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] MBeanInfoDB-xmbeandd.xml - is under alien influence WTF - I am trying to test stuff an my invocation looks like : 18:02:40,640 INFO [MainDeployer] Starting deployment of package: file:/Users/pf/jboss-head/build/output/jboss-4.0.0alpha/server/default/ deploy/mbean-info-db-service.xml 18:02:40,657 INFO [SARDeployer] looking for nested deployments in : file:/Users/pf/jboss-head/build/output/jboss-4.0.0alpha/server/default/ deploy/mbean-info-db-service.xml 18:02:40,828 INFO [STDOUT] JDOM Exception: org.jdom.JDOMException: Error in building: no protocol: ..\docs\dtd\jboss_xmbean_1_0.dtd 18:02:40,831 ERROR [STDERR] org.jdom.JDOMException: Error in building: no protocol: ..\docs\dtd\jboss_xmbean_1_0.dtd 18:02:40,834 ERROR [STDERR] at org.jdom.input.SAXBuilder.build(SAXBuilder.java:306) \ ? is bad stuff - get a real OS ... :-) 18:02:40,836 ERROR [STDERR] at org.jdom.input.SAXBuilder.build(SAXBuilder.java:583) 18:02:40,839 ERROR [STDERR] at org.jboss.mx.metadata.XMLMetaData.build(XMLMetaData.java:242) 18:02:40,846 ERROR [STDERR] at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:214) 18:02:40,849 ERROR [STDERR] at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:240) 18:02:40,852 ERROR [STDERR] at java.lang.reflect.Constructor.newInstance(Native Method) 18:02:40,854 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:868 ) 18:02:40,857 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:302 ) 18:02:40,859 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:329 ) 18:02:40,862 ERROR [STDERR] at org.jboss.system.ServiceCreator.install(ServiceCreator.java:139) 18:02:40,865 ERROR [STDERR] at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator .java:161) 18:02:40,867 ERROR [STDERR] at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:12 4) 18:02:40,869 ERROR [STDERR] at org.jboss.system.ServiceController.install(ServiceController.java:220) 18:02:40,872 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 18:02:40,875 ERROR [STDERR] at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.jav a:72) 18:02:40,877 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:56) 18:02:40,880 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:81) 18:02:40,883 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav a:159) 18:02:40,885 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:547) 18:02:40,888 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) 18:02:40,890 ERROR [STDERR] at $Proxy6.install(Unknown Source) 18:02:40,892 ERROR [STDERR] at org.jboss.deployment.SARDeployer.create(SARDeployer.java:226) 18:02:40,895 ERROR [STDERR] at org.jboss.deployment.MainDeployer.create(MainDeployer.java:791) 18:02:40,897 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641) 18:02:40,900 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:606) 18:02:40,902 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 18:02:40,905 ERROR [STDERR] at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.jav a:72) 18:02:40,907 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:56) 18:02:40,910 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:81) 18:02:40,912 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav a:159) 18:02:40,917 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:547) 18:02:40,920 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) 18:02:40,922 ERROR [STDERR] at $Proxy9.deploy(Unknown Source) 18:02:40,925 ERROR [STDERR] at
RE: [JBoss-dev] MBeanInfoDB-xmbeandd.xml - is under alien influence
Peter, I will try ... but that is kind of a waste of bandwith ;-) ... and I would feel more comfortable using a ssh tunnel then. DTD URIs are supposed to be cached and accessed offline. Typically, they do not point to an actual document. I am surprised that there is actually a server serving up DTDs from this location. It would be poor design to require access to this site for correct server operation. I suppose that there is an Entity Resolver that redirects this URI to a local cache? Anyone familiar with XMBean, feel free to chime in ;) - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Peter Fagerlund Sent: Thursday, November 07, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MBeanInfoDB-xmbeandd.xml - is under alien influence torsdagen den 7 november 2002 kl 19.32 skrev Matt Munz: \ ? is bad stuff - get a real OS ... Po-tay-toes, po-tah-toes. What's real, anyway? :) true - only on mushrooms one se real in this age ... !DOCTYPE mbean PUBLIC -//JBoss//DTD JBOSS XMBEAN 1.0//EN http://www.jboss.org/j2ee/dtd/jboss_xmbean_1_0.dtd; I may not get to this for a while. Perhaps you'd like to try it. I will try ... but that is kind of a waste of bandwith ;-) ... and I would feel more comfortable using a ssh tunnel then. Thanxs --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX-RMI headaches
Scott, Please excuse my ignorance of the details of RMI... Well apparently the closure of the referenced object graph is including QName due to an object holding onto an XML element or the like, and the client and server don't agree on the definition of javax.xml.namespace.QName. Is this the object graph on the server side? In other words, the response object graph? The response object is really just a glorified Vector of Strings. Now it is possible, perhaps, but unlikely, that some server-side parser holds a reference to these String objects. But why should that matter? Objects that have a reference to the response object shouldn't be in the graph, right? Only the objects that the responce refers to are relevant. Should I assume that RMI is the easiest way to get this done? the client and server don't agree on the definition of javax.xml.namespace.QName. This is also strange to me since I am fairly sure that the client and server are using identical copies of jaxrpc.jar. Is there an easy way to debug this? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott M Stark Sent: Thursday, November 07, 2002 3:14 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX-RMI headaches Well apparently the closure of the referenced object graph is including QName due to an object holding onto an XML element or the like, and the client and server don't agree on the definition of javax.xml.namespace.QName. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Matt Munz [EMAIL PROTECTED] To: JBoss Developers Group [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 11:35 AM Subject: [JBoss-dev] JMX-RMI headaches Hi all, For unit tests, I thought the RMI adaptor might be easier than JMX-NET. Unfortunately, I've been running into some snags... When I try to message an MBean, that takes a Vector parameter, over the RMI adaptor, I get the exception below. What is confusing to me is that I don't use QNames at all. Why is the adaptor complaining about an object I don't even use (it is on the classpath)? Is there an easier solution than RMI for remote access to the MBeans in the server? TIA. - Matt Munz [junit] Error unmarshaling return; nested exception is: [junit] java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc ser ialVersionUID = -9120448754896609940, local class serialVersionUID = -5673018430892733549 --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMX-RMI headaches
Hi all, For unit tests, I thought the RMI adaptor might be easier than JMX-NET. Unfortunately, I've been running into some snags... When I try to message an MBean, that takes a Vector parameter, over the RMI adaptor, I get the exception below. What is confusing to me is that I don't use QNames at all. Why is the adaptor complaining about an object I don't even use (it is on the classpath)? Is there an easier solution than RMI for remote access to the MBeans in the server? TIA. - Matt Munz [junit] Error unmarshaling return; nested exception is: [junit] java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc ser ialVersionUID = -9120448754896609940, local class serialVersionUID = -5673018430892733549 [junit] java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: [junit] java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc ser ialVersionUID = -9120448754896609940, local class serialVersionUID = -5673018430892733549 [junit] at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) [junit] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) [junit] at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl_Stub.invoke(Unknown Source) [junit] at com.apelon.emr.decisionsupport.test.KnowledgeBaseTest.testFetchDiseasesForSy mptomSetDb(KnowledgeBaseT est.java:130) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) [junit] at com.apelon.emr.projectbuilder.RunTestsTask.execute(RunTestsTask.java:23) [junit] at com.apelon.emr.projectbuilder.EmrTaskInvoker.execute(EmrTaskInvoker.java:44) [junit] Caused by: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classd esc serialVersionUID = -9120448754896609940, local class serialVersionUID = -5673018430892733549 [junit] at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:459) [junit] at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521) [junit] at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) [junit] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) [junit] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) [junit] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845) [junit] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) [junit] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646) [junit] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) [junit] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845) [junit] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) [junit] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646) [junit] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) [junit] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845) [junit] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) [junit] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646) [junit] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) [junit] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) [junit] ... 30 more --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX-RMI headaches
Scott, starksm@ironmaiden[lib] 519jar -tf wsdl4j.jar | grep QName com/ibm/wsdl/util/xml/QNameUtils.class javax/xml/namespace/QName.class starksm@ironmaiden[lib] 520serialver -classpath wsdl4j.jar javax.xml.namespace.QName javax.xml.namespace.QName:static final long serialVersionUID = -9120448754896609940L; thank you. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott M Stark Sent: Thursday, November 07, 2002 5:59 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX-RMI headaches Is this the object graph on the server side? In other words, the response object graph? Its the object being unmarshalled in the client vm that originated from the server. The response object is really just a glorified Vector of Strings. Now it is possible, perhaps, but unlikely, that some server-side parser holds a reference to these String objects. But why should that matter? Objects that have a reference to the response object shouldn't be in the graph, right? Only the objects that the responce refers to are relevant. Yes, only the response matters. Should I assume that RMI is the easiest way to get this done? Yes. the client and server don't agree on the definition of javax.xml.namespace.QName. This is also strange to me since I am fairly sure that the client and server are using identical copies of jaxrpc.jar. Is there an easy way to debug this? You will have to search the server jars. The -9120448754896609940 version is coming from the IBM wsdl.jar.. starksm@ironmaiden[lib] 519jar -tf wsdl4j.jar | grep QName com/ibm/wsdl/util/xml/QNameUtils.class javax/xml/namespace/QName.class starksm@ironmaiden[lib] 520serialver -classpath wsdl4j.jar javax.xml.namespace.QName javax.xml.namespace.QName:static final long serialVersionUID = -9120448754896609940L; --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] securing the jmx console in JBoss 4.x
Hi all, P. 53 of the JBoss Admin manual refers to ~/jmx-console.war/WEB-INF/jboss-web.xml. I am, however, unable to find this file in the head version. Following all of the other instructions results in a basic authentication dialog that allows any username/password combination. Should I attempt to re-create this file, or is there a new way for securing the console? - Matt --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] securing the jmx console in JBoss 4.x (Solved)
I pasted the code for jboss-web.xml into a new file with that name, and it automagically worked... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Thursday, November 07, 2002 8:28 PM To: JBoss Developers Group Subject: [JBoss-dev] securing the jmx console in JBoss 4.x Hi all, P. 53 of the JBoss Admin manual refers to ~/jmx-console.war/WEB-INF/jboss-web.xml. I am, however, unable to find this file in the head version. Following all of the other instructions results in a basic authentication dialog that allows any username/password combination. Should I attempt to re-create this file, or is there a new way for securing the console? - Matt --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] securing the jmx console in JBoss 4.x
Scott, Thanks again. Just to make sure I have it right -- 3.0 has features that 4.0 doesn't? I suppose this is a result of bug fixes not making it upstream... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott M Stark Sent: Thursday, November 07, 2002 8:46 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] securing the jmx console in JBoss 4.x main is lagging the more stable branches for production enhancements. Look to 3.0 for the changed and migrate to main or use it as guide. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Matt Munz [EMAIL PROTECTED] To: JBoss Developers Group [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 5:27 PM Subject: [JBoss-dev] securing the jmx console in JBoss 4.x Hi all, P. 53 of the JBoss Admin manual refers to ~/jmx-console.war/WEB-INF/jboss-web.xml. I am, however, unable to find this file in the head version. Following all of the other instructions results in a basic authentication dialog that allows any username/password combination. Should I attempt to re-create this file, or is there a new way for securing the console? - Matt --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] janitorial work
Ben, sorry about the misread. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Ben Tompkins Sent: Thursday, October 31, 2002 5:03 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] janitorial work Perhaps I worded this somewhat confusingly - although it seems clear to me (you may want to reread the sentences prior to your comment below). I said that I have not bothered to try building JBoss in an IDE because it is generally ***harder*** to build ***inside*** an IDE than outside of one. On Thu, 2002-10-31 at 13:16, Matt Munz wrote: Ben, I'd also like to know whether anyone has succeeded in building/debugging with Eclipse. http://jboss.org/developers/guides/eclipse-howto/ is generally harder to build inside an IDE than outside one - so I haven't even bothered to try it. IMO not true in this case. In fact, JBoss cannot be built at all in Eclipse. Eclipse will generate some class files, sure, but it won't create the full set of distributables that make up the server. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Ben Tompkins Sent: Thursday, October 31, 2002 1:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] janitorial work Is there some reason why the precise commands required to checkout a correct build cannot simply be posted somewhere? I am using: CVSROOT=pserver:[EMAIL PROTECTED]:/cvsroot/jboss cvs login (if necessary) cvs co jboss-head or cvs co -r release-tag release-module I see that some recent commits have specified Branch_3_0. So my next attempt will be: cvs co -r Branch_3_0 jboss-3.0 Someone please correct me if I am wrong. As far as I can make out, the only system dependency is the Java VM and the PATH. The build scripts unset/ignore ANT_HOME, because ant, as well as the various XML parsers are included in the build, right? I'd also like to know whether anyone has succeeded in building/debugging with Eclipse. There was a mailing regarding this to the effect that the thirdparty subdirectory needs to be configured especially for Eclipse and that builds prior to jboss-head are not so configured- but I haven't even been able to build anything that recent outside of Eclipse and is generally harder to build inside an IDE than outside one - so I haven't even bothered to try it. On Thursday 31 October 2002 10:35 am, danch wrote: So, Ben...are you hinting that your less than satisfied with the build system? That's odd, _nobody_ _ever_ complains about the build system! ;^}) yours in sympathy, danch --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss.net and performance tuning
hi again,
Anybody out there working on or using JBoss.net?
Attached are some files I'm using to test, in a very simplistic way, the
performance of jmx.net.
My current timing so far is on average .3 seconds to complete the simplest
possible transaction (as far as I can tell) -- returning a very short string
object.
Does this number sound reasonable? If so, what are you using JBoss.Net
for? Perhaps I have the wrong idea...
Not included in the archive is the class JmxNetProxy, which is a delegate
for the mechanism used in the JBoss.Net test cases. Here's the relevant
method from that class.
public Object invoke(String webServiceName, String mbeanServiceName,
String methodName,
Object[] arguments, Class[] classes)
throws Exception
{
...
MBeanInvocationHandler handler;
handler = createMBeanInvocationHandler(target);
return handler.invoke(mbeanServiceName,
methodName,
arguments,
classes); // classes
}
Any comment would be greatly appreciated.
- Matt ([EMAIL PROTECTED])
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt
Munz
Sent: Thursday, October 31, 2002 11:17 AM
To: JBoss Developers Group
Subject: [JBoss-dev] JBoss.net and performance tuning
CGJ and JBoss.net guys,
My fledgeling JBoss.net enabled application is growing up and it needs
some performance enhancements. Particularly, Marshalling/Unmarshalling
appears to take significantly longer than expected.
Here's my setup.
1) I'm using the JMX.net proxy classes used in the test cases.
2) I am working with short, frequent transactions.
3) I am using the bean serializer to send simple custom objects across the
wire.
4) On the server side, an MBean is the recipient of the request.
RE: #1 -- Would WSDL2Java be any faster? Is MBean to wsdl generation
working yet?
RE: #2 -- I know, course-grained transactions are preferred, but are they
required? My objects are small, almost tiny. How fast can a transaction
be? If I can get it under .05 seconds, this should suffice for the moment.
RE: #3 -- Any tips / tricks here? Would switiching to primitives and
Strings be markedly faster?
Any help would be greatly appreciated. Links to benchmarks / performance
tests would help too.
- Matt
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
jmx-net-test.zip
Description: Zip compressed data
[JBoss-dev] JBoss.net and performance tuning
CGJ and JBoss.net guys, My fledgeling JBoss.net enabled application is growing up and it needs some performance enhancements. Particularly, Marshalling/Unmarshalling appears to take significantly longer than expected. Here's my setup. 1) I'm using the JMX.net proxy classes used in the test cases. 2) I am working with short, frequent transactions. 3) I am using the bean serializer to send simple custom objects across the wire. 4) On the server side, an MBean is the recipient of the request. RE: #1 -- Would WSDL2Java be any faster? Is MBean to wsdl generation working yet? RE: #2 -- I know, course-grained transactions are preferred, but are they required? My objects are small, almost tiny. How fast can a transaction be? If I can get it under .05 seconds, this should suffice for the moment. RE: #3 -- Any tips / tricks here? Would switiching to primitives and Strings be markedly faster? Any help would be greatly appreciated. Links to benchmarks / performance tests would help too. - Matt --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] janitorial work
Ben, I'd also like to know whether anyone has succeeded in building/debugging with Eclipse. http://jboss.org/developers/guides/eclipse-howto/ is generally harder to build inside an IDE than outside one - so I haven't even bothered to try it. IMO not true in this case. In fact, JBoss cannot be built at all in Eclipse. Eclipse will generate some class files, sure, but it won't create the full set of distributables that make up the server. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Ben Tompkins Sent: Thursday, October 31, 2002 1:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] janitorial work Is there some reason why the precise commands required to checkout a correct build cannot simply be posted somewhere? I am using: CVSROOT=pserver:[EMAIL PROTECTED]:/cvsroot/jboss cvs login (if necessary) cvs co jboss-head or cvs co -r release-tag release-module I see that some recent commits have specified Branch_3_0. So my next attempt will be: cvs co -r Branch_3_0 jboss-3.0 Someone please correct me if I am wrong. As far as I can make out, the only system dependency is the Java VM and the PATH. The build scripts unset/ignore ANT_HOME, because ant, as well as the various XML parsers are included in the build, right? I'd also like to know whether anyone has succeeded in building/debugging with Eclipse. There was a mailing regarding this to the effect that the thirdparty subdirectory needs to be configured especially for Eclipse and that builds prior to jboss-head are not so configured- but I haven't even been able to build anything that recent outside of Eclipse and is generally harder to build inside an IDE than outside one - so I haven't even bothered to try it. On Thursday 31 October 2002 10:35 am, danch wrote: So, Ben...are you hinting that your less than satisfied with the build system? That's odd, _nobody_ _ever_ complains about the build system! ;^}) yours in sympathy, danch --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[4]: [JBoss-dev] -service.xml generator
Alex group, I've meant to add some MBean persistence docs, but haven't gotten to it yet. IMO, *-service.xml *is* a form of persistence. It represents state of the server that is present after server restart. It is great, flexible, easy to understand, etc., but with all due respect, not overly robust or featureful as a persistence mechanism per se. The MBean persistence mechanism I've implemented includes a default persistence engine that uses Object Streams (derived from an example in Juha's JMX book). As I've mentioned before, this should be supplemented with XML and possibly JDBC versions. Since an Object Stream is not human-readible, I believe it provides a sub-optimal alternative for persistence in this case. As I also mentioned previously, there are several places in the JBoss codebase where text (de)serialization of MBeans occurs. Notably, this includes the *-service.xml reading and jmx-console writing parts of the server. One of the next steps to make MBean persistence widely usable is to re-use this serialization code for the purpose of reading and writing MBean info and MBean state XML. I believe that this code relies on the PropertyEditor mechanism -- a solution which appears to be a good fit for the job. I hope that someone familiar with this code/process might jump into this work. When appropriate for my current work, I'll try to do this myself, but the opportunity may not appear for a while. In the meantime, I'm happy to answer any questions on the subject... - Matt Munz -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Alex Loubyansky Sent: Monday, October 28, 2002 3:26 AM To: Sacha Labourey Subject: Re[4]: [JBoss-dev] -service.xml generator Hello Sacha, I thought about it too. As alternative or other implementation of MBean persistence. Though, I am not familiar with MBean persistence stuff yet. Are they meant to be serialized as java objects? I think, having MBeans persisted in xml form is much better. Because I can see what is persisted and change something manually. alex Monday, October 28, 2002, 10:06:36 AM, you wrote: SL Hello, SL Exactly, it may help to solve one of the current biggest issue wrt SL configuration: any configuration done through any GUI (or mbean, etc.) is not persisted = only transient configuration can be started remotly or SL programatically. Having a generic way to build new persisted mbean SL definition is important. SL But we spoke about this on this ML a few weeks ago and we still have some SL issues wrt implicit dependencies. Anyway, we need a way to persist SL configuration that is currently only transient. SL cheers, SL Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Alex Loubyansky Envoye : lundi, 28 octobre 2002 07:17 A : Anatoly Akkerman Objet : Re[2]: [JBoss-dev] -service.xml generator Anatoly, this looks cool and draws other perspectives. I'm in thought. Any other thoughts/comments? Thanks. alex Sunday, October 27, 2002, 4:07:15 PM, you wrote: AA Hi, Alex AA Jelly would give you similar ease of use but without having to write any AA XSL. You would initialize the JellyContext by creating in first and then AA setting variables in it from attributes like this: AA ctx.setVariable(name, value); AA (values can be any Java objects) AA you load your modified *-service.xml script from a URL into Jelly and AA run it as a script in the context which you just set up. The result of AA this operation is XML again. AA This is simplest usage of Jelly. You do need a library, though, and AA possibly, not one but a bunch from jakarta-commons. AA I am using Jelly in a slightly more advanced fashion. I wrote a few very AA simple tags that allow output of Jelly to be a jar file. Something like: AA j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib AA zipper:zip AA zipper:entry name=META-INF/ejb-jar.xml AA parametrized ejb-jar.xml contents go here AA /zipper:entry AA zipper:entry name=META-INF/jboss.xml AA parametrized jboss-xml contents go here AA /zipper:entry AA /zipper:zip AA /j:jelly AA Set up the JellyContext for running this script with appropriately AA configured variables (say from a DB of configurations or from attributes AA of an MBean). Run the script in the context. AA After running this script, the JellyContext contains a Jar archive (as a AA byte[] stored under some variable name) of reconfigured descriptors. AA The way I use it is to have a servlet that parses its path request and AA deduces from the path request which script to run and which AA configuration to pull from storage. The servlet outputs either XML or AA JAR depending on the requested module and its script
RE: [JBoss-dev] developing on windows
Could some sort of caching be used here, where only the part of the tree that is being viewed (and its surrounding context) is in memory, and the rest is written to disk? ... Just an idea -- I'm unfamiliar with xdoclet. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of David Jencks Sent: Friday, October 18, 2002 8:34 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] developing on windows Some of the xdoclet tasks run out of memory with less that 640mb. They read and parse the entire module source into some sort of AST. david jencks On 2002.10.18 17:53:40 -0400 Matt Munz wrote: Does setting -Xms640m help/resolve the problems you are having on win32? Haven't tried it yet, as things are working alright for me at the moment. Does the build system really require 640 MB of ram, or is there a JVM bug that this setting resolves? It seems to me that a linear build system should not require much memory if the tasks are sufficiently self-contained -- allocate memory for the task, run the task, gc the task, repeat. I imagine that the third step is not happening often enough if the build requires 640 MB... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Jason Dillon Sent: Friday, October 18, 2002 5:36 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] developing on windows Does setting -Xms640m help/resolve the problems you are having on win32? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Matt Munz Sent: Friday, October 18, 2002 2:24 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] developing on windows Alex, I have had the same problems -- you are not alone. As long as I don't clean, once I have a good build (usually the third try), the problems go away. It seems like a memory problem to me too. Perhaps someone should run the build system using a profiler ;) One of the ant tasks probably leaks... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Alex Loubyansky Sent: Friday, October 18, 2002 5:03 PM To: JBoss-Dev Subject: [JBoss-dev] developing on windows Developing on Windows became a nightmare. Sometimes to bulid the server or run a testsuite I need to run build.bat several times. The worst thing it fails with so dreadful errors. It's hard to determine whether I did something wrong or not enough memory. I am on P4, 1.7GHz, 512M Win2K SP2 Sun JDK1.3.1_01 in scripts I add -Xmx640m. Is it only me facing it? Any workarounds? Thanks. alex --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
I think this is a JDK 1.4 thing... I'll re-write it JDK 1.3.x compilant... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 18, 2002 1:35 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed = ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/jmx/output/gen/classes _default:compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/jmx/output/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 557 source files to /disk/orig/home/lubega/jbossro/jboss-all/jmx/output/classes /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:58: warning: getPriority() in org.apache.log4j.Category has been deprecated return category.getPriority().toInt(); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:64: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been deprecated category.setPriority(Priority.toPriority(level)); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:82: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated return p.isGreaterOrEqual(category.getChainedPriority()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:100: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated return p.isGreaterOrEqual(category.getChainedPriority()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:118: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated return p.isGreaterOrEqual(category.getChainedPriority()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:136: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated return p.isGreaterOrEqual(category.getChainedPriority()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:154: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated return p.isGreaterOrEqual(category.getChainedPriority()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:172: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated return p.isGreaterOrEqual(category.getChainedPriority()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/l og4j/Log4jAdapter.java:190: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated return p.isGreaterOrEqual(category.getChainedPriority()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/persisten ce/MbeanInfoDbPm.java:279: cannot resolve symbol symbol : method replaceAll (java.lang.String,java.lang.String) location: class java.lang.String fileName = fileName.replaceAll(objNameSeparator(), objNameSepRep()); ^ /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/persisten ce/MbeanInfoDbPm.java:288: cannot resolve symbol symbol : method replaceAll (java.lang.String,java.lang.String) location: class java.lang.String objectName = objectName.replaceAll(objNameSepRep(), objNameSeparator()); ^ 2 errors 9 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/jmx/../tools/etc/buildfragment s/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 49 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email
RE: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 16-October-2002
While we're on the subject -- I'm unable to reach the junit reports from
lubega.com. Does anyone have the right links for this?
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Wednesday, October 16, 2002 4:15 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results:
16-October-2002
Hey scott, just what is this last failing test anyway?
david jencks
On 2002.10.16 16:05:11 -0400 [EMAIL PROTECTED] wrote:
Number of tests run: 949
Successful tests: 948
Errors:1
Failures: 0
[time of test: 16 October 2002 12:52 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2.1]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only
highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix
the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] PersistenceInterceptor isn't being used anymore?
Juha group, After syncing with the latest source, MBean Persistence seems to be turned off. I just did a grep for PersistenceInterceptor against the jmx module source and came up with no instantiations of this class. What's going on here? Any ideas? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j
Jason, The major issue with Log4j that I have is size... it is huge. You might want to look again at the log4j website or ask the log4j guys for more input on this. Last time I checked, there was a minimal log4j-core.jar that could be used in the place of the full log4j.jar. I believe that there is also a log4j-ME (not the actual name) that is designed for use in limited resource environments. Like some other admirable open source projects coughJBoss/cough, log4j places design and function slightly higher up the totem pole of priorities than performance. You might be interested in a recent thread on log4j-dev, entitled Proposed architecture changes to log4j for improved memory usage. Some guy used JProbe to profile log4j under an extremely heavy load and posted the results. Some quotes from Ceki (log4j project lead) on that topic: Object reuse and optimizing memory usage was one of the themes I was seriously considering for future log4j releases. ... In log4j defense, I should say that log4j aims to be reliable, fast and extensible, in that order of priority. It is easier to be reliable with simpler but albeit less optimized code. From my experience, the log4j folks are very sensitive to performance issues, and spend a greater than average amount of time on optimizing their code. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Wednesday, October 09, 2002 12:31 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Design: Plans to decouple JBoss from log4j The major issue with Log4j that I have is size... it is huge. Commons is very small. If Log4j has a 20k footprint (or smaller) for client usage an dprovided a simple method to disable logging, then I would see no need for Commons Logging. Generally I am a pro-just use log4j, but our own requirement for org.jboss.logging.Logger (for TRACE, removing need for huge jars on client and serialization) makes me wonder of the commons approache is really a better solution... backed by Log4j of course. What were the specific CL issues you had witrh XDoclet? --jason On Tue, 8 Oct 2002, David Jencks wrote: Apparently several people have had trouble with jakarta-commons logging, including xdoclet; this got mentioned on their list: http://www.qos.ch/logging/thinkAgain.html Personally I'd be in favor of unwrapping log4j and using it asis. I'm not convinced that the debug/trace split buys us very much. david jencks On 2002.10.08 21:24:12 -0400 Jason Dillon wrote: It is too bad commons logging does not provide abstractions for a ContextStack or ContextMap similar to Log4j's NDC and MDC. These are valuable constructs. Do you know anyone on the commons logging team? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of James Higginbotham Sent: Friday, October 04, 2002 6:41 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j Do you know how you switch the LogFactory impl? I am guessing there is a system property, but I did not see anything obvious by looking at the javadocs. I've been using commons logging for a few months now - not bad at all.. You drive the impl from a properties file called commons-logging, like so: org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog If you put in log4j, just put the log4j properties or xml file in the classpath so log4j can initialize when needed. The nice thing about using this API is that they have done the factory work for you, allowing jboss clients to use the simplelog they provide, a null log, jdk1.4 (ugh), or whatever. Sure, you have that abstraction, but do you really want to do the simple factory work? Probably not, as you guys have more important things to do ;) James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How is Constructor Info used?
JMX gurus, When I first saw XMBean XML, I assumed that constructor/ referred to the constructor for the resource (model object). On a closer look, it appears that this information (ModelMBeanConstructorInfo) refers only to the constructor for the MB itself. Is this information being used in any way in the server? What purpose is it intended to serve? When loading the registry from the store, I need to instantiate the appropriate resources (model objects). Any reason why I shouldn't store the constructor information for the resource in the MMB descriptor, similar to what I did with the persistence information? - Matt Munz --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Fixing module defintions now for head, 3.0 3.2
To effectivly test I would need to replicate the entire repository. FWIW, this could easily be done with rsync, but, as David pointed out, SF.net probably doesn't allow this level of access to their servers. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Tuesday, October 08, 2002 3:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Fixing module defintions now for head, 3.0 3.2 To effectivly test I would need to replicate the entire repository. --jason On Tue, 8 Oct 2002, Tom Coleman wrote: Why don't we set up a CVS testbed somewhere to test CVS changes? You (editorial 'you') don't (shouldn't) commit changes to code without thorough testing. Considering what's at risk, it seems to me that CVS changes should be made even more cautiously. This project already has too many 'moving targets' to try to deal with. I have to modify CVSROOT/modules to test, so please be patient if something does not function. I will make sure that all jboss-* projects function by the days end. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] How is Constructor Info used?
Juha, It could be worse -- I could be trying to interpret legal documents ;) it is not clearly defined which it should refer to in case of MMB. It might be better defined in JMX 1.2 version of the spec. Let me reccommend that the resource object constructor info be given a (defined) place in the MMB info in a future version of the spec. It seems to me that this information is required for MMB info persistence, and probably useful for MMB state persistence as well. For now, I'm just going to go ahead with storing this info in the MMB info object as mentioned previously. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Tuesday, October 08, 2002 2:51 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] How is Constructor Info used? On Tue, 8 Oct 2002, Matt Munz wrote: When I first saw XMBean XML, I assumed that constructor/ referred to the constructor for the resource (model object). On a closer look, it appears that this information (ModelMBeanConstructorInfo) refers only to the constructor for the MB itself. it is not clearly defined which it should refer to in case of MMB. It might be better defined in JMX 1.2 version of the spec. Is this information being used in any way in the server? no, as far as I know What purpose is it intended to serve? not sure -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Okay, sounds interesting. Do you have an concreate ideas on a design for such a beast? Nope, just broad generalizations ;) David's idea for a re-write (refactoring) makes sense to me if done incrementally. Off the top of my head... I think a good first step would be to wrap the ant engine in an MBean, allowing programmatic access to the engine to load and run tasks. Once ANT can live in the JMX server, the ANT architecture can be replaced with its JMX equivalent, step by step. Next I'd find a way to wrap an MBean in a Task proxy, and wrap a Task in an MBean. This would allow Tasks in the JMX server and MBeans in the ant environment. Then I'd replace ANT's classloading with JMX classloading. At some point, Task would go away and be replaced with MBeans. Work done by the Task interface and introspection could be accomplished with MBean metadata, I.e. the execute() method for the Javac MBean is compile(). At some point, ANT XML could simply become a way to specify an order in which MBeans are instantiated, registered, and invoked to accomplish the goals for a given target. Each one of these steps has a lot of benefits, and I think the whole shebang is a large project. Something that I find very interesting and valueable, but not necessary for the work I'm doing now :( I'm glad to see your interest in this -- I hope some of this helps. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Saturday, October 05, 2002 3:42 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Okay, sounds interesting. Do you have an concreate ideas on a design for such a beast? --jason On Fri, 4 Oct 2002, Matt Munz wrote: Can you explain the Ant MBean thing to me please. Here's the way I see it. ANT features: core system composed of engine + modules engine loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every Task in ANT is invoked via Task.execute() XML definition allows flexible definition of Tasks (ANT XML) JMX features: core system composed of server + modules server loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every MBean in JMX is invoked via MBean.invoke() XML definition allows flexible definition of MBeans (XMBean XML) So much overlap. For many of these things, JMX simply does the job better. Ever try to add a plugins feature to an application, so that your clients can add on their own extensions? After I found out about JMX, it was like a light went on -- this is the way to do it... What we're all trying to do -- build robust applications out of building blocks, self-consistent units. What ant has going for it is the functionality. All the cross-platform wrinkles worked out -- the javac task just works. What JMX has going for it is the architecture -- powerful, clear, classloading figured out, dependable, flexible. If we can put these together, we'll have many benefits for both projects. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Friday, October 04, 2002 7:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project
RE: [JBoss-dev] Build System... any ideas
Jason, The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Not sure by what you mean re: maitennance. If you're talking about reading the code, I think that it's going to be easier for Joe JBoss Developer to read well-written Java code than it would be to read JavaScript, ANT XML, or some other language. We already know Java :) Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. Again, I'm new, so I don't know what an included module is... The build process in the compiled-build-system approach can be quite simple. The way the it works, is that you bootstrap your build system. Write a snippet of ANT XML that builds the build system ( 50 lines). Then run the build system like any other Java application. The thing that makes ant useful is the platform independence and API, and not the XML format, IMO. What do you gain with a scripting language over ANT XML? Expressiveness - control structures, other APIs, flexibility... You get all of this plus instant familiarity and a minimal learning curve when you use Java. What do you gain with a scripting language over Java? Doesn't require compilation. I know that it is conventional wisdom that build systems should be scripts, but I don't see the need in this case. Again, I know that this is an unusual method, and as such don't expect you to adopt it. I am, however, happy to discuss it further if you are interested. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think
RE: [JBoss-dev] Build System... any ideas
David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think
RE: [JBoss-dev] creating persistent MBeans dynamically
Sacha, I think the counter idea will work fine, given a presupposition that all MBs that a given MB (whose info is to be persisted) depends on also have their MB info persisted. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha Labourey Sent: Friday, October 04, 2002 9:52 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hello, And what about deployment order? When I was thinking about it (and we exchanged a few e-mails with David), the deployment order issue has poped up. When you have explicit information about dependencies, that's fine but you don't have this all the time i.e. if you create a new topic through jmx-console, the mbean is successsfuly created because the server is running. Nevertheless, at reboot-time, things may go differently. I suggested to use an internal counter in JBoss that increments each time a new service is deployed. As part of the MBean info that is persisted, we could store this id and, when restarting jboss, deploy the mbeans (which have no explict dependency info) in the sequence of their ID. This scheme is simple and support mbeans that are updated/deleted/created. Another option would be to have, for each MBean, a list of required services. But this was already discussed when we had to deal with dependencies at first. Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Juha-P Lindfors Envoye : jeudi, 3 octobre 2002 23:19 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] creating persistent MBeans dynamically On Thu, 3 Oct 2002, Matt Munz wrote: all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. sure. The entity that persists the MB info should be responsible for loading it at server start. yes, but an MBean loads its own state based on that metadata If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? no idea, I'm not sure how you got there Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. persistence of the metadata is different from the runtime state (the values in your attributes) I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications
[JBoss-dev] Why is the MB Registry a MMB?
Juha JMX-dev, Why is the MB Registry a MMB? Could it be a Dynamic MB instead? I'm running into a chicken-and-egg problem. The persistence interceptor instantiated in preRegister() for the MB REgistry MMB tries to create a Timer MB. This requires that the MB registry MMB has already been registered, which of cousre, it hasn't. Since the MB Registry needs a custom persistence manager anyway, perhaps it could handle its own persistence internally? An alternative to this would be to modify the persistence interceptor so that it does not use the Timer MB in this special case. Either way, let me know your preference/ideas. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is the MB Registry a MMB?
Hi all, Just thought of another (better?) option. Leave the registry as a MMB with the default NullPersistenceManager. Then persist using an internal mechanism (this is what the Dynamic MB would do anyway). - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Friday, October 04, 2002 1:39 PM To: JBoss Developers Group Subject: [JBoss-dev] Why is the MB Registry a MMB? Juha JMX-dev, Why is the MB Registry a MMB? Could it be a Dynamic MB instead? I'm running into a chicken-and-egg problem. The persistence interceptor instantiated in preRegister() for the MB REgistry MMB tries to create a Timer MB. This requires that the MB registry MMB has already been registered, which of cousre, it hasn't. Since the MB Registry needs a custom persistence manager anyway, perhaps it could handle its own persistence internally? An alternative to this would be to modify the persistence interceptor so that it does not use the Timer MB in this special case. Either way, let me know your preference/ideas. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Can you explain the Ant MBean thing to me please. Here's the way I see it. ANT features: core system composed of engine + modules engine loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every Task in ANT is invoked via Task.execute() XML definition allows flexible definition of Tasks (ANT XML) JMX features: core system composed of server + modules server loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every MBean in JMX is invoked via MBean.invoke() XML definition allows flexible definition of MBeans (XMBean XML) So much overlap. For many of these things, JMX simply does the job better. Ever try to add a plugins feature to an application, so that your clients can add on their own extensions? After I found out about JMX, it was like a light went on -- this is the way to do it... What we're all trying to do -- build robust applications out of building blocks, self-consistent units. What ant has going for it is the functionality. All the cross-platform wrinkles worked out -- the javac task just works. What JMX has going for it is the architecture -- powerful, clear, classloading figured out, dependable, flexible. If we can put these together, we'll have many benefits for both projects. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Friday, October 04, 2002 7:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm
RE: [JBoss-dev] Build System... any ideas
David, As far as I know ant is still remarkably unfriendly to attempts to run it inside anything else, most of the methods needed are private or package access. Yeah, there's a lot of paranoid classes in there. If we show them that something useful can be done by opening up more of the ant core to the public interface, however, I think they'll fold it into the code base. It's not like it needs that much tweaking. I think that they are mainly concerned about not falling into the same pitfalls as make did. As long as it's clear that we're not trying to change ANT into something baroque and complex and contorted, I think they'll be alright. Plus, opening up the core API is good for IDE integration -- one of their goals. Of course, this assumes that politics is not an issue... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, October 04, 2002 8:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Probably not:-) My idea involved a complete rewrite of ant as a bunch of mbeans, using as much jmx functionality as possible. This was based on the observation that the ant team seems to struggle a lot with classloading and questions of exactly how detyped their interfaces should be, plus dynamic extensions. Since these are what jmx is so good at, I thought building ant on jmx made a lot of sense. I think perhaps what marc is talking about is to run ant within jboss as an mbean. Back in February I spent a week or so trying to make this work (so we could have an xdoclet deployer, drop your source code in and it gets xdoclet-ized, compiled, and deployed) but I could not work around the ant classloaders to make anything work. (as I recall, really basic ant scripts worked but xdoclet did not at all). As far as I know ant is still remarkably unfriendly to attempts to run it inside anything else, most of the methods needed are private or package access. david jencks On 2002.10.04 19:01:58 -0400 Jason Dillon wrote: Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. Could you clarify the following from P. 87 of the spec? store Writes the MBean in a persistent store. Should only called by an implementation of the ModelMBean interface to store itself according to persistence policy for the MBean. When used, it may be called with every invocation of setAttribute or on a periodic basis. (optional) If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense, especially considering the fact that dynamic changes to the MBeanInfo are ignored by the server. Perhaps this sentence should be re-written? developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Wednesday, October 02, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Wed, 2 Oct 2002, Matt Munz wrote: Perhaps we're using 'persist' differently. The mbean registry contains object references to all of the mbeans in the server.To me, persisting the registry (or a part of it), means serializing those objects completely (MB info + data). no, the individual mbeans already persisted their state they need on their own, what you need to persist from the registry is the information to recreate the mbeans (who will then go an load() their own state they already persisted), ie which constructor to use at startup, what args go into the constructor As I understand it, MBs that want to persist their state must implement the PersistentMBean interface. If the state for all MBs in the server is also to be persisted, then I suppose that all MBs registered must be adapted to the PersistentMBean interface. Does this sound reasonable? I think you're confusing the two different modes of persistence: say I registered an XMbean instance from location http://foo/bar.xml (which is my mbean definition). When you register this mbean to the registry you pass in the valueMap that info, init(URL) was used with arg http://foo/bar.xml + objectname blah. Registry stores this info as part of its own state. When registry is recreated (server restart) it goes to its own persistence location and gets this info, calls the constructor, creates the new mbean instance, bar.xml has the persistence info for the mbean and the bean will load() its own state. I tried to scan the spec for some guidance, but was unable to find portions relating to persistence or lifecycle issues that would be relevant here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. It would definately be more convienient if some of these issues were addressed in the spec, IMHO. It seems to me that this whole discussion is a logical extension of MMB persistence in the first place, and that MB developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, sometimes design-by-email is not a fast route :) ... all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. The entity that persists the MB info should be responsible for loading it at server start. If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) I don't have the pleasure of knowing 2.0 ;), but I think I kind of know what you're talking about. Deployment of XMBeans, for example, involves two similar files with nonetheless distinct roles. I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. The other option is to say that the deploy folder is the MB info store (this is kind of how it works today). I don't favor this -- I like to keep my peas on one side of the plate, and my mash potatoes on the other side ;) There is a way to make this work, if desired, but I believe that the route there is to delegate the responsibility for MB info persistence to an object other than the MB registry. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. This is how it should be in general, I think. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Thursday, October 03, 2002 10:07 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Thu, 3 Oct 2002, Matt Munz wrote: Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. The only changing part in the metadata should be the descriptor which should be persisted regardless of how the mbeaninfo was loaded to the runtime system in the first place. So a simple key, value map or a property file even. The rest of the metadata should remain unchanged during the lifetime of the MBean. Could you clarify the following from P. 87 of the spec? how an mbean is persisted is really not defined in the spec. If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense if the assumption doesn't make sense, and we both agree it doesn't make sense, then concentrate on the part that *does* make sense ;-) Well, I'm very interested. The work I do is spec-friendly
RE: [JBoss-dev] creating persistent MBeans dynamically
Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime. There are some options here. Juha wrote the following. make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. The MBean registry is a large Object graph, comprising much of the entire server. It seems that this is a lot to tackle, as I don't want to serialize/deserialize the entire server, just a few dynamically created MBeans. I'm willing to try this, or any approach that makes the most sense, but I'd like to hear more design ideas on the subject before going forward. Here's the direction I'm coming from... The process for creating MBs is 1) make MBeanInfo, 2) Make an MBean with that MBeanInfo, and 3) register. After #3, the state of that MBean will be persisted, if appropriate. What will not be persisted is the MBeanInfo generated in step #1. In the case of MBeans created by the ServiceCreator/Deployer, the MBeanInfo is already persistent (stored in *-service.xml in the deploy folder). To achieve this, the dynamically created MBeans need a mechanism to A) persist the MBeanInfo, and B) reload the MBeanInfo and execute steps #2 and #3 at server start. After that, the system will work automatically. This is where I could use some design input. (A) is relatively trivial. To achieve (B), I could create an MBean responsible for loading MBeans from the MBeanInfo database created by (A), at startup. This, of course, is precisely what the Service Deployer does, with the difference that this deployer will not try to load the MBeanInfo stores when they are written (A). Perhaps the solution is to provide a programmatic interface to the service deployer that will write the MBeanInfo for a given MB to the deploy folder, but won't try to re-deploy it? Pheraps there is a better idea? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
A slight correction -- when I refer to *-service.xml, I really mean *-service.xml _and_ the XMBean definition XML. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, October 02, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime. There are some options here. Juha wrote the following. make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. The MBean registry is a large Object graph, comprising much of the entire server. It seems that this is a lot to tackle, as I don't want to serialize/deserialize the entire server, just a few dynamically created MBeans. I'm willing to try this, or any approach that makes the most sense, but I'd like to hear more design ideas on the subject before going forward. Here's the direction I'm coming from... The process for creating MBs is 1) make MBeanInfo, 2) Make an MBean with that MBeanInfo, and 3) register. After #3, the state of that MBean will be persisted, if appropriate. What will not be persisted is the MBeanInfo generated in step #1. In the case of MBeans created by the ServiceCreator/Deployer, the MBeanInfo is already persistent (stored in *-service.xml in the deploy folder). To achieve this, the dynamically created MBeans need a mechanism to A) persist the MBeanInfo, and B) reload the MBeanInfo and execute steps #2 and #3 at server start. After that, the system will work automatically. This is where I could use some design input. (A) is relatively trivial. To achieve (B), I could create an MBean responsible for loading MBeans from the MBeanInfo database created by (A), at startup. This, of course, is precisely what the Service Deployer does, with the difference that this deployer will not try to load the MBeanInfo stores when they are written (A). Perhaps the solution is to provide a programmatic interface to the service deployer that will write the MBeanInfo for a given MB to the deploy folder, but won't try to re-deploy it? Pheraps there is a better idea? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
David, Thanks. That helps a lot. Regarding persisting MB info... I want to change the use of the ServiceController/Creator/Configurator so it is ONLY used when you first deploy a package, NOT when you shut down jboss and restart it. What about re-deployment? If, after server start, I modify/touch a package already in the deploy folder, will it be re-deployed? For making it work in the short term perhaps only persisting mbeans with a particular descriptor will be the best plan, Makes sense to me. I think that following Juha's suggestion and persisting the entire mbean registry is the best way to do this. Perhaps we're using 'persist' differently. The mbean registry contains object references to all of the mbeans in the server.To me, persisting the registry (or a part of it), means serializing those objects completely (MB info + data). Isn't this excessive? I would prefer to persist only the MB info objects for these beans, as the rest of the state is unnecessary. As I understand it, MBs that want to persist their state must implement the PersistentMBean interface. If the state for all MBs in the server is also to be persisted, then I suppose that all MBs registered must be adapted to the PersistentMBean interface. Does this sound reasonable? Regarding the JMX spec... I tried to scan the spec for some guidance, but was unable to find portions relating to persistence or lifecycle issues that would be relevant here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). One issue that isn't discussed is the set of expectations for registration that relate to the server lifecycle. When I register my MB, is that for the current session (whatever that may be), the life of the server, the life of the JVM, perpetuity, etc. ? If registration is intended to last for the life of the server only, then MBs would expect not to have their MB info persisted, and an opt-in mechanism (like your added descriptor) would be needed. Otherwise, an opt-out (also using a descriptor) might make more sense. I could see a use for transient MBs that were never persisted in any way - I suppose there are many living in the JBoss Server now... It would definately be more convienient if some of these issues were addressed in the spec, IMHO. It seems to me that this whole discussion is a logical extension of MMB persistence in the first place, and that MB developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? - Matt Munz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Wednesday, October 02, 2002 12:26 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] creating persistent MBeans dynamically I don't have time to think this through extensively, but I would like the MBeanRegistry to persit the mbean info of either --all mbeans or --all mbeans with a particular descriptor in their mbeaninfos. I want to change the use of the ServiceController/Creator/Configurator so it is ONLY used when you first deploy a package, NOT when you shut down jboss and restart it. I want the mbean persistence mechanism to take care of reestablishing all the mbeans previously present. I think that following Juha's suggestion and persisting the entire mbean registry is the best way to do this. If you get this working I will take care of making the ServiceController stuff not interfere. For making it work in the short term perhaps only persisting mbeans with a particular descriptor will be the best plan, you can set this descriptor for your dynamically created mbeans now, and we can set it for all the others later. thanks david jencks On 2002.10.02 10:23:50 -0400 Matt Munz wrote: A slight correction -- when I refer to *-service.xml, I really mean *-service.xml _and_ the XMBean definition XML. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, October 02, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime. There are some options here. Juha wrote the following. make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config
RE: [JBoss-dev] Directory hot-deploy granularity
We might have to somehow lock the directory during changes and unlock it afterwards. It's interesting the way Cruise Control deals with the same issue. A time interval could be specified where the deployment scanner would wait to see if there were any more updates before proceeding with the deployment -- kind of like microwave popcorn -- Wait until 2 seconds between pops before removing from the microwave. This could allow batch updates in a fully automatic manner. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, October 02, 2002 3:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Directory hot-deploy granularity Hi, I think we have to consider race conditions here. What keeps a deployment scanner from starting in the middle of an update when only some (i.e. inconsistent) changes have occured yet. We might have to somehow lock the directory during changes and unlock it afterwards. But this lowers the degree of automaticity; you would at least have to trigger the redeployment process manually at some appropriate time. Regards, Michael Gredler, Dani wrote: Hi, I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change. Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development. I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in: org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory. org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead. Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers? Thanks for reading my long rambling post :) Dani --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a new
error :)
Below, I include my MBean Info generation code, and some error output. When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
02)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:284)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151)
at
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha,
do you have operation info for the operation names you are mapping to
(setId getId)?
Nope, and I now see where this causes the problem. At least I'm learning...
Thanks for all the assistance.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Juha-P Lindfors
Sent: Tuesday, October 01, 2002 12:20 PM
To: JBoss Developers Group
Subject: RE: [JBoss-dev] creating persistent MBeans dynamically
do you have operation info for the operation names you are mapping to
(setId getId)?
On Tue, 1 Oct 2002, Matt Munz wrote:
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a
new
error :)
Below, I include my MBean Info generation code, and some error output.
When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new
ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and
signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha group, It appears that there are two registries available in org.jboss.mx.server.registry. org.jboss.mx.server.ServerConstants seems to indicate that org.jboss.mx.server.registry.BasicMBeanRegistry is the registry that is actually used. Is this the registry that you refer to? What does org.jboss.mx.server.registry.JBossMBeanRegistry do -- is it being used in the server? Also, I'd like to stay as spec-centric as possible. I noticed that MBeanServer has a registerMBean() method. Any reason not to use it? Looking a little further at the spec and the implementation, I'm getting a bit confused, to be honest. I suppose that I need to create a Model MBean using the createMBean() method on MBeanServer. Then I suppose I would set the MBeanInfo (including persistence settings), and call register on the MBean. The only problem here is that the createMBean() method has already registered the bean. Does this mean that I am supposed to directly instantiate the Model MBean? I got the impression that the server was supposed to provide the Model MBean implementation. Am I missing something here? Why isn't there a method createModelMBean(Object modelObject, MBeanInfo info) on MBeanServer? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Friday, September 27, 2002 11:05 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] creating persistent MBeans dynamically make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, Matt Munz wrote: Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree? Now for the more general question... What I am trying to do is to allow dynamic generation of persistent objects in the server. These objects need to be exposed as web services, and have access to databases, other web services, and JMS topics. As instances of the same class, all of these ojects will have the same interface, yet will have different state, and need to expose this through the web service protocol. Once I have created these instances, I don't want them to go away unless I specifically remove them. If I restart the server, they should show up again (technically different instances with identical state). Ultimately, all I want to do is to say create a widget named foo via web services, restart the server, say tell me something about the widget named foo via web services, and get a response. I know that there are many ways to skin a cat. Is there a better way here? Would EJB or some other structure make more sense? I am generally trying to stay away from EJB for the moment to avoid the overhead of RMI (I don't need distributed objects), but I am open to any solution that makes sense. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https
RE: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss?
marc f XML is bullshit. What? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] creating persistent MBeans dynamically
Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree? Now for the more general question... What I am trying to do is to allow dynamic generation of persistent objects in the server. These objects need to be exposed as web services, and have access to databases, other web services, and JMS topics. As instances of the same class, all of these ojects will have the same interface, yet will have different state, and need to expose this through the web service protocol. Once I have created these instances, I don't want them to go away unless I specifically remove them. If I restart the server, they should show up again (technically different instances with identical state). Ultimately, all I want to do is to say create a widget named foo via web services, restart the server, say tell me something about the widget named foo via web services, and get a response. I know that there are many ways to skin a cat. Is there a better way here? Would EJB or some other structure make more sense? I am generally trying to stay away from EJB for the moment to avoid the overhead of RMI (I don't need distributed objects), but I am open to any solution that makes sense. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Gosling has Web Services right...
Hi, I should probably know better to add to this discussion, but... I am unfamiliar with CORBA, and new to Web Services. Nonetheless, the type of web services (SOAP + UDDI) that we are looking at now seems useful to me. Since I think Web Services is useful, I'm of course interested in anything that may be better. For starters, the phrase Web Services makes little sense - might as well call it Buzzword^2. Web Services don't exist on the Web, and, under a sufficiently general definition, what is not a service? The more that things change, the more they get worse. Things are getting better for me. I used to get data from third parties via http posts html scraping. Now I have an API, standards, specifications -- a tool set that doesn't dissapear when I try to interact with someone else's (unique yet similar) interface. Some of the things I've seen written against the Google and Amazon services are impressive. I also find XML-RPC to be useful. How many different, unique yet similar ways do we need to encode requests and responses? XML makes sense to me for data description. Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. As I understand it, the transport protocol is interchangeable in most web services implementations. It also seems that many of your objections are being addressed in layers on top of SOAP. The AXIS and JBoss.Net APIs, for example, hide much of the implementation details. They are there if you need them, of course... As far as the performance issue is concerned, I only ask my systems to be fast enough, and no faster ;) . XML may be verbose, but it can also be compressed. I have seen a few articles about (compressed) binary encoding of XML streams -- I'm interested -- does anyone have any arguments against this? So, if CORBA is a Web Services framework, under the broad definition of Web Services, what makes it better? How should I compare? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, September 27, 2002 8:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Gosling has Web Services right... It doesn't even have the concept of object identity, so it is even pre Corba. I figure they have about 5 years to catch up with what Corba has today. Of course, I think Corba will continue to die the slow death. -dain danch wrote: Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. Oh, by the way - Web Services also exposes a lot of the detail of the protocol to the programmer, just to really piss off the people who though writing then compiling IDL was a pain in the ass. Now, of course, you get to choose between compiling or generating the IDL, which is so chock full of fun little XML quirks as to be unreadable by normal humans anyway. Bah! The more that things change, the more they get worse. -danch Bill Burke wrote: What I've been saying all along... People have been building Web services under different names for 20 or 30 years, he explains. We've been building distributed systems for years out using CORBA and RMI and all of that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
David, I've been hearing this in bits an pieces for a while. Thanks for laying it all out. I think that most of that sounds quite sensible, and is in line with my goals for server management. I look at this as a matter of function. Currently, if you want to make a temporary (life of the server) change, you can use the APIs, Adaptors, JMX Console, etc. If you want to make a permanent change, you need to edit the XML and redeploy the MBean. Since one seldom wants to make a temporary change (except when testing, and probably not even then), this makes some of the most interesting functionality less usable. As far as the mbean persistence stuff goes, I think the main thing we need is a canonical or distinguished persistence location, that is examined on server startup, and all the mbeans stored there are recreated. I've been putting mine in /conf/mbean-state for now. If object names are unique, then they provide a useful map for persistence locations. I could see user:service=FooMBean being stored at ../mbean-state/user/service/FooMBean.xml (Note the xml extension -- my guess is that the best file based persistence will be XML- and PropertyEditor-based). A similar construct could be used for a JDBC persistence mechanism. The thing that might help with this would be a Persistence Manager MBean that could be used to serialize or load any other MBean (I think you suggested this previously). One question I have is how does all of this relate to the JMX spec. I assume that OnUpdate, Never, etc. values for persistence are part of the spec. There really isn't an OnShutdown. Does the spec mention anything about defaults? It seems to me to be a reasonable behavior to persist unless told not to, but of course I could understand arguments to the contrary as well... Really interesting stuff... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, September 27, 2002 9:08 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] creating persistent MBeans dynamically There have been some discussions about this, and my opinion is not universally accepted by any means... At the moment there isn't any provision for persisting any mbean configuration and using it in any way. I hope that we can use the persistence stuff you wrote to make the following scheme work easily. I think jboss and the mbean server should be basically a database of mbeans. When you shut down your database server, the contents are saved. Similarly, when you shut down jboss, the mbeans present should be saved and reappear when the mbean server is restarted. Shutting down jboss should not undeploy anything. You didnt' ask to undeploy anything, you asked to stop the server. Similarly, when you restart jboss, the packages that were deployed when you shut down should be in a deployed state when you restart jboss, without having to find them and redeploy them. For instance, if you deploy a package through the ant jmx task or the jmx-console, there is no need for the url to remain accessible after deployment is complete. When you restart jboss, you shouldn't need to access the url, just load the mbeans represented by the deployment from storage. As far as the mbean persistence stuff goes, I think the main thing we need is a canonical or distinguished persistence location, that is examined on server startup, and all the mbeans stored there are recreated. As far as the rest of jboss goes, we have to stop undeploying anything on shutdown, and on restart first recreate all the DeploymentInfo mbeans: then the deployment scanner can tell if a package has been refreshed while jboss was down. Thanks david jencks On 2002.09.27 17:23:13 -0400 Matt Munz wrote: Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, Ok, that sounds cool. I'll try it on Monday. Have a good weekend. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Friday, September 27, 2002 11:05 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] creating persistent MBeans dynamically make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, Matt Munz wrote: Hi all, I have two questions here, a specific one relating to the subject, and a more general question pertaining to the larger problem that I'm trying to solve. First off, what is the best way to create new MBeans while the server is running, in a persistent fashion? Say, for example, I have a class Widget, and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a method createNewWidget(String mbeanName, Object[] widgetFeatures); that has the purpose of creating a new instance of Widget, wrapping it in a ModelMBean with the name mbeanName, and adding that mbean to the server. If I use the mbean server API for this, then the new MBean is loaded in the VM, but dissapears on server restart. One solution for this, I imagine, would be, instead of using the mbean server API, to actually write a *-service.xml file to the deploy folder each time createNewWidget() is called. Another solution might be to maintain references to the widgets in the widget factory, and serialize and load them through it. There are likely many more solutions. Have any of you tried something like this before? Is there code that does this in the JBoss source tree? Now for the more general question... What I am trying to do is to allow dynamic generation of persistent objects in the server. These objects need to be exposed as web services, and have access to databases, other web services, and JMS topics. As instances of the same class, all of these ojects will have the same interface, yet will have different state, and need to expose this through the web service protocol. Once I have created these instances, I don't want them to go away unless I specifically remove them. If I restart the server, they should show up again (technically different instances with identical state). Ultimately, all I want to do is to say create a widget named foo via web services, restart the server, say tell me something about the widget named foo via web services, and get a response. I know that there are many ways to skin a cat. Is there a better way here? Would EJB or some other structure make more sense? I am generally trying to stay away from EJB for the moment to avoid the overhead of RMI (I don't need distributed objects), but I am open to any solution that makes sense. - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ JBoss.Net developers,
After working with wsdl2Java, I have come to the conclusion that the wsdl
being generated by org.jboss.net.jmx.server.MBeanProvider is not accurate.
I have included both the WSDL and the interface generated by wsdl2Java. Any
ideas? It seems to me that the method signatures of my MBean should show up
in the wsdl. Is this an accurate assumption? If so, what might be
preventing accurate wsdl generation in this case?
- Matt
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
targetNamespace=http://localhost:8080/jboss-net/services/CustomTerminologyM
anagementService xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:apachesoap=http://xml.apache.org/xml-soap;
xmlns:impl=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService
xmlns:intf=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
wsdl:portType name=XMBean
/wsdl:portType
wsdl:binding name=CustomTerminologyManagementServiceSoapBinding
type=impl:XMBean
wsdlsoap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http/
/wsdl:binding
wsdl:service name=XMBeanService
wsdl:port binding=impl:CustomTerminologyManagementServiceSoapBinding
name=CustomTerminologyManagementService
wsdlsoap:address
location=http://localhost:8080/jboss-net/services/CustomTerminologyManageme
ntService/
/wsdl:port
/wsdl:service
/wsdl:definitions
/**
* XMBean.java
*
* This file was auto-generated from WSDL
* by the Apache Axis WSDL2Java emitter.
*/
package localhost;
public interface XMBean extends java.rmi.Remote {
}
-Original Message-
From: Matt Munz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 10:49 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ,
Thanks for your response.
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
This is the first thing that I tried and it did not work. I didn't take a
lot of time to firgure out why this is the case, since the jboss.net
testcase code was easy to understand, so I may have missed something
simple...
This may work for simple cases, but once you declare additional
data structures and serializers, it becomes very hairy on the client side,
otherwise.
Well, for my purposes, I don't intend on sending complex Object graphs
over the wire. I also think that the Bean Serializer should be sufficient
for my purposes. By may work, do you mean will work without errors for
simple cases, or probably won't work for any case, so don't even try it?
Is there a test case that demonstrates the technique (A B above) that
you reccommend? I would find this quite useful. If I have time, I'll try
to write one myself, if it doesn't already exist.
On code generation in general, I must admit that I have a bit of healthy
skepticism on the matter. In this example, the amount of client side code
required to use the deprecated technique totals no more than a few lines,
while the output of wsdl2java comprises multiple full-fledged classes. It
seems to me that, auto-generated or not, this compromises a significant
ramp-up in code maitennance costs.
Based on your experience, what makes code generation the way to go in this
case? Do you find the generated code reasonable, easy to maintain,
scalable, reliable, etc.?
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jung
, Dr. Christoph
Sent: Tuesday, September 24, 2002 10:06 AM
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt,
For getting the client-side invocations and stub classes right, we recommend
The following steps:
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
Using Axis/MbeanInvocationHandler lacks a lot of deployment information
(basically,
The client-side of the web-service.xml) that we try to default
from java reflection.
This may work for simple cases, but once you declare additional
data structures and serializers, it becomes very hairy on the client side,
otherwise.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 20. September 2002 17:41
An: JBoss Developers Group
Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ JBoss.Net Developers,
First, let me say Thank you. I now have MBeans in the server exposed as
web services. Although it took a bit of research to figure out how to do
this, the minimal amount of (xml) code required to expose MBeans as
webservices (should I call this JMX.Net?) speaks for itself.
I was again pleased to see that the client side is also straightforward,
once I knew what to do. Basically, I
