RE: [JBoss-dev] Deployment directory for singleton services
couldn't the deployer just pick up a tag from the descriptor -- rather than add yet another deployment directory? On Thu, 18 Mar 2004, Adrian Brock wrote: On Wed, 2004-03-17 at 10:37, Dimitris Andreadis wrote: How about having a sub-directory farm/singleton instead? They serve different orthogonal purposes. farm - is for applications deployed across a cluster deploy-hasingleton - is for applications that should only be run on one server at a time. I can see a case for the deploy-hasingleton directory getting replicated across the cluster. But the deployment will still only be active on one server in the cluster. Regards, Adrian I guess is a little bit more difficult to implement, having the farm watcher ignore this particular dir, but it looks more intuitive to me. /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivelin Ivanov Sent: , 15 2004 2:47 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deployment directory for singleton services In 3.2.4 under config server/all there is going to be another deployment directory, parallel to deploy and farm, which will host services that are deployed on exactly one node in the cluster. The tentative name is deploy-hasingleton. A service under deploy declared in deploy-hasingleton-service.xml will deploy the directory in question. JMS is the first service that will take advantage of this new directory. My question is how should we name the directory and what other services are good candidates for it? Cheers, Ivelin --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638opk ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Director of Training http://www.jboss.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] lock errors on commit attempts
Definitely had password problems today. For a moment I thought I had forgotten mine or simply cannot type anymore.. -- Juha On Fri, 20 Jun 2003, Adrian Brock wrote: Hi Scott, I've been seeing the same errors and it was not accepting my password sometimes. I was just persistent. Regards, Adrian Adrian Brock Director of Support Back Office JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 20 June 2003 05:59 To: [EMAIL PROTECTED] Subject: [JBoss-dev] lock errors on commit attempts Everytime I try to do a commit I'm seeing a failure like the following: cvs server: failed to create lock directory for `/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins' (/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/#c vs.lock): Permission denied cvs server: lock failed - giving up cvs [server aborted]: lock failed - giving up cvs commit: saving log message in /tmp/cvsIiqHry I saw Adrian check in some files recently. Is anyone else seeing this error? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Oswego util.concurrent jar updated
by the time they're through JSR..? On Thu, 3 Apr 2003, Nathan Phelps wrote: Any chance they'll ever update the package name to get rid of the capital EDU... drives me crazy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Thursday, April 03, 2003 4:02 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Oswego util.concurrent jar updated I updated the Oswego util.concurrent jar in 3.0+ from the rather ancient 1.3.0 version to 1.3.2 as we found some serious concurrency failures in the ConcurrentHashMap and ConcurrentReaderHashMap classes in looking into some JMS load test failures. A bit ironic that the concurrent package was messing up concurrency. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss web-site issues
works with 1.2.1 + w2k too The 1.3 release of Mozilla is not showing this issue. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Anatoly Akkerman [EMAIL PROTECTED] To: JBoss-Dev [EMAIL PROTECTED] Sent: Monday, March 31, 2003 12:22 PM Subject: [JBoss-dev] jboss web-site issues Hello, guys Since the website was switched to Nukes, Mozilla 1.2 on Win2K consistently pops up connection refused. IE6 works fine. Any ideas what is wrong? -- Anatoly. --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XMBean and transient attributes
it should set the value to -1 in the MBeanAttributeInfo descriptor if no getMethod fields are specified // if no method mapping, enable caching automatically if (getMethod == null currTimeLimit == null) descr.setField(CURRENCY_TIME_LIMIT, -1); -- Juha On Sat, 29 Mar 2003, Scott M Stark wrote: I'm working on updating the xmbean tests in 3.2 to make sure what we will have in the 3.2.0 release is usable and there is an issue with transient attributes and the default value for currencyTimeLimit. An attribute element like: attribute access=read-write default=jboss.security:service=JaasSecurityManager descriptionSecMgr is a read-write attribute added at the metadata level for which there is no state in the User2 instance. /description nameSecMgr/name typejavax.management.ObjectName/type /attribute where there is no currencyTimeLimit defined fails to have a value for this attribute, and a value cannot be set. Given that it has a default value this does not seem like valid behavior. If the currencyTimeLimit set to -1 then the default value is seen as the initial value for the attribute and it may be updated. attribute access=read-write default=jboss.security:service=JaasSecurityManager descriptionSecMgr is a read-write attribute added at the metadata level for which there is no state in the User2 instance. /description nameSecMgr/name typejavax.management.ObjectName/type descriptors currencyTimeLimit value=-1/ /descriptors /attribute The question is why should a failure to specify the attribute descriptors result in an unusable attribute? Either the caching logic is faulty or the implicit settings for the attribute descriptors a not correct. --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ 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: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Regarding JBoss site
It's not the new look that is bad (the red bar and the menu) its all the other stuff that blinks worse than your average porn site. An eyesore. Too much stuff that just bounces around. Looks is good, should continue to apply it to the rest of the stuff. Layout is bad, needs a complete redesign (mostly ads). -- Juha On Thu, 27 Mar 2003, marc fleury wrote: Points taken on the website. Do you prefer the look though? we are trying the more pro approach. I think it sucks but ben my sales guy is all excited about it... what do you think? we just released NUKES, the forums were switched and yes we lost a couple of hours of posts. Apologies and thanks for sending us broken links and stuff. As for the TSS hate it is not hate, it is simple jealousy. We said for the first time that we make money and that we share it. Put yourself in the shoes of the mediocrity that usually reads/writes there and he used to sit smug thinking about how DUMB we are because we do open source and we probably BEG for money and all of the sudden BM we make money while he struggles to keep his stupid company afloat. Jealousy is a deep reptilian feeling that in fact takes precedence over common sense. It is a fact of life. The more success we have the more we are going to see of that, I mean think MS the biggest and baddest of them all attracts even more jealousy. Meaning: let them be jealous and lets stay the course, we will start receiving resumes from these mediocrities that never wrote a line of OSS code in the coming weeks, stay the course marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lennart Petersson Sent: Thursday, March 27, 2003 10:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Regarding JBoss site Please would it possible to have JBoss site stabilised? As it is now you never know what it will be like next time surfing there and forum messages that i sent yesterday is now suddenly gone and other threads reports to be updated but they arent And are there really 620 guests on-line :) I know there is development going on but does it have to affect the production site? Especially since there is a lot of JBoss hate going on (look at TSS if you haven't yet) I think there will be a lot of curious people coming surfing and this is not what I want them to see... /L --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ 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: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Regarding JBoss site
no I am saying rethink how you lay them out -- having them appear all over the place (top, bottom, several on both sides) like they are now doesn't look very good. its a layout issue, it sucks On Thu, 27 Mar 2003, marc fleury wrote: you are saying get rid of the ads? that is not going to be possible right now :) if it is something more precise let me know marcf --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Regarding JBoss site
On Thu, 27 Mar 2003, Jeff Haynie wrote: Also, when I try and login, I get a Logging you in, hang tight! and the page never returns The IE globe spins to infinity works for me, when the site is actually responding (IE6 + W2K) however, the remember me thingy doesnt work, probably something to do with cookies and something julien should have a look at -- Juha --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Regarding JBoss site
move main menu on left side to top because now it is in different place everytime depending what ad is on top of it, try to keep all pics on the same side of the page (docu, faces, ad), get rid of the ad box at the bottom of every page and cycle them on the top bar -- Juha On Thu, 27 Mar 2003, marc fleury wrote: OK fine, be specific on where you would put them, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha-P Lindfors Sent: Thursday, March 27, 2003 12:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Regarding JBoss site no I am saying rethink how you lay them out -- having them appear all over the place (top, bottom, several on both sides) like they are now doesn't look very good. its a layout issue, it sucks On Thu, 27 Mar 2003, marc fleury wrote: you are saying get rid of the ads? that is not going to be possible right now :) if it is something more precise let me know marcf --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ 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: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Regarding JBoss site
convert the main page text box titles to use same style as in menu and side bars. On Thu, 27 Mar 2003, marc fleury wrote: OK fine, be specific on where you would put them, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha-P Lindfors Sent: Thursday, March 27, 2003 12:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Regarding JBoss site no I am saying rethink how you lay them out -- having them appear all over the place (top, bottom, several on both sides) like they are now doesn't look very good. its a layout issue, it sucks --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
There's no requirement from JMX to use 1.4 yet. (excluding JSR160/Remoting) On Thu, 6 Mar 2003, Scott M Stark wrote: Originally I said I thought we needed to keep 4.0 buildable by JDK 1.3, but I'm starting to think otherwise. I'm about to give in to this demand. If users cannot switch to JDK 1.4 then I'm willing to say they cannot make use of the full set of features in 4.0. The remaining question I had was can the core services remain binary compatible with JDK 1.3, meaning JMX, AOP, deployers, etc. required to have a highly functional microkernel for building on top of. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:59 AM Subject: [JBoss-dev] Is JDK 1.4 required to build Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ 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: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
On Mon, 3 Mar 2003, Bill Burke wrote: 1. Source located in neutral territory, namely the common module. ok 2. Sequence of interceptors determined by (iterator in) invocation object. This could be a modifiable iterator at some point. This allows the interceptor stack to be modified per invocation at runtime if necessary depending on logic in previous interceptor. This type of functionality would call for an authenticated invocation from the client. An example where I want to collect stats from the service I'm invoking. I don't need the relevant interceptors to exist for any other than one or few specific invocations. 3. Construction of interceptors through interceptor factories. ok 4. Storing interceptor specific metadata in the invocation factory (e.g. for ejbs, this is the currently the Container). This makes it easy to write stateless interceptors. Are statless interceptors shared between components or per component. There's experimental system wide shared interceptors in the mx base if that type of functionality appeals to anyone. Metadata should be in 2 places. The class or invocation factory, and the actual instance. 5. multiple interceptor chains per InvocationFactory, e.g. each method gets a separate interceptor chain. (Idea from current mbean interceptor implementation) Do we really need per method interceptor chains? We did not need them to implement EJBs. It makes some interceptors less complex to implement. It makes sense at service interception where we may have a separation between attributes/operations. Say I want to persist 2 out of 3 attributes I'm changing. Operations don't need the persistence interceptor, nor do all the attributes. I find it more intuitive to config separate stacks rather than building one stack with everything in it and then start filtering per method. 6. Ability to replace the interceptor interator. This is not directly supported now but is essentially what happens when an invocation goes from the client interceptor stack to the invoker interceptor stack. (Currently the only example of an invoker interceptor stack is the trunk invoker.) Not sure what you mean by replacement. Do you mean hot-deploy of new interceptors? I have this now in AOP framework for POJOs. I understood it as modification of the stack per invocation if necessary.. -- Juha --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBeanProxy with JBoss Remoting
yes On Wed, 19 Feb 2003, Anatoly Akkerman wrote: Hi, I don't know if this is obvious and I am treading old ground or makes sense or not, but given that JMX remoting already works, if one creates a Java proxy to an MBean via MBeanProxy and that Proxy instance gets shipped through the Remoting infrastructure, wouldn't it make sense to make the JMXInvocationHandler to push invocations on this proxy to the original MBean through the Remoting pipe that it arrived through? This would be useful if an invocation on an MBean returns such a proxy object (say, this MBean is a Factory MBean for other MBeans but clients prefer typed invocation on the factory) and now you want to invoke this factory MBean remotely and still get meaningful objects back. -- Anatoly --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] File Persistence and Crash
FD.sync() all your writes... ? On Mon, 9 Dec 2002, Andy wrote: Does someone know how to implement a file based persistence that does not become corrupted except maybe when the file is written during a crash. --- 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] Problem compiling 3.2 beta testsuite
Can't get 3.2 testsuite to compile due to the errors below compile-classes-only: [javac] Compiling 932 source files to C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\classes [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jca\ejb\LocalWrapperCleanupTestSessi onBean.java:23: cannot resolve symbol [execmodules] symbol : class LocalConnection [execmodules] location: package local [execmodules] import org.jboss.resource.adapter.jdbc.local.LocalConnection; [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle anupTestSessionHome.java:16: cannot resolve symbol [execmodules] symbol : class LocalConnection [execmodules] location: package local [execmodules] import org.jboss.resource.adapter.jdbc.local.LocalConnection; [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle anupTestSession.java:16: cannot resolve symbol [execmodules] symbol : class LocalConnection [execmodules] location: package local [execmodules] import org.jboss.resource.adapter.jdbc.local.LocalConnection; [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ClientFailTest.java:1 13: warning: stop() in java.lang.Thread has been deprecated [execmodules] t.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:77: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:121: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:143: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:161: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ExceptionListenerTest .java:63: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [execmodules] tf.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:111: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:113: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:168: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:170: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:74: wa rning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:116: w arning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop();
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
[JBoss-dev] Build testsuite
does the testsuite work yet or is this still work in progress? I can't get it to run from either /build or /testsuite $ ./build.bat run-basic-testsuite Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger run-basic-testsu ite Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property configure-project: [echo] groups: default [echo] modules: jmx,common,system,j2ee,naming,management,transaction,server,blocks,co nsole,security,messaging,connector,varia,cluster,jetty,jboss.net,iiop run-basic-testsuite: [execmodules] Missing build file; skipping module: testsuite BUILD SUCCESSFUL Total time: 2 seconds Press any key to continue . . . $ ./build.bat tests-unit Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger tests-unit Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property [copy] Copying 1 file to D:\test\jboss-all\testsuite\output\gen\classes\org\jboss\tes t\cts\interfaces [ BIG SNIP ] UnitTestCase.java:285: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j .Category has been deprecated [javac] root.setPriority(XLevel.TRACE); [javac] ^ [javac] D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\SRPUnitTestC ase.java:112: cannot resolve symbol [javac] symbol : method getResourceURL (java.lang.String) [javac] location: class org.jboss.test.JBossTestSetup [javac] String authConfPath = super.getResourceURL(security-srp/auth.conf ); [javac]^ [javac] D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\XMLLoginModu lesUnitTestCase.java:41: warning: setPriority(org.apache.log4j.Priority) in org.apache.log 4j.Category has been deprecated [javac] root.setPriority(XLevel.TRACE); [javac] ^ [javac] 1 error [javac] 43 warnings BUILD FAILED file:d:/test/jboss-all/testsuite/../tools/etc/buildfragments/targets.ent:45: Compile faile d; see the compiler error output for details. Total time: 58 seconds Press any key to continue . . . --- 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 testsuite
cool, thanks On Sat, 5 Oct 2002, Scott M Stark wrote: Its fixed now. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Juha-P Lindfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 05, 2002 8:24 AM Subject: [JBoss-dev] Build testsuite does the testsuite work yet or is this still work in progress? I can't get it to run from either /build or /testsuite $ ./build.bat run-basic-testsuite Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger run-basic-testsu ite Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property configure-project: [echo] groups: default [echo] modules: jmx,common,system,j2ee,naming,management,transaction,server,blocks,co nsole,security,messaging,connector,varia,cluster,jetty,jboss.net,iiop run-basic-testsuite: [execmodules] Missing build file; skipping module: testsuite BUILD SUCCESSFUL Total time: 2 seconds Press any key to continue . . . $ ./build.bat tests-unit Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger tests-unit Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property [copy] Copying 1 file to D:\test\jboss-all\testsuite\output\gen\classes\org\jboss\tes t\cts\interfaces [ BIG SNIP ] UnitTestCase.java:285: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j .Category has been deprecated [javac] root.setPriority(XLevel.TRACE); [javac] ^ [javac] D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\SRPUnitTestC ase.java:112: cannot resolve symbol [javac] symbol : method getResourceURL (java.lang.String) [javac] location: class org.jboss.test.JBossTestSetup [javac] String authConfPath = super.getResourceURL(security-srp/auth.conf ); [javac]^ [javac] D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\XMLLoginModu lesUnitTestCase.java:41: warning: setPriority(org.apache.log4j.Priority) in org.apache.log 4j.Category has been deprecated [javac] root.setPriority(XLevel.TRACE); [javac] ^ [javac] 1 error [javac] 43 warnings BUILD FAILED file:d:/test/jboss-all/testsuite/../tools/etc/buildfragments/targets.ent:45: Compile faile d; see the compiler error output for details. Total time: 58 seconds Press any key to continue . . . --- 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
Re: [JBoss-dev] Build testsuite
although I'm not having much success running 'tests-unit' on HEAD... I seem to get a few infinite loops from log4j that eventually die to stack overflows and a test success rate of only about 44% anyone else having better luck with it? On Sat, 5 Oct 2002, Juha-P Lindfors wrote: cool, thanks On Sat, 5 Oct 2002, Scott M Stark wrote: Its fixed now. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Juha-P Lindfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 05, 2002 8:24 AM Subject: [JBoss-dev] Build testsuite does the testsuite work yet or is this still work in progress? I can't get it to run from either /build or /testsuite $ ./build.bat run-basic-testsuite Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger run-basic-testsu ite Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property configure-project: [echo] groups: default [echo] modules: jmx,common,system,j2ee,naming,management,transaction,server,blocks,co nsole,security,messaging,connector,varia,cluster,jetty,jboss.net,iiop run-basic-testsuite: [execmodules] Missing build file; skipping module: testsuite BUILD SUCCESSFUL Total time: 2 seconds Press any key to continue . . . $ ./build.bat tests-unit Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger tests-unit Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property [copy] Copying 1 file to D:\test\jboss-all\testsuite\output\gen\classes\org\jboss\tes t\cts\interfaces [ BIG SNIP ] UnitTestCase.java:285: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j .Category has been deprecated [javac] root.setPriority(XLevel.TRACE); [javac] ^ [javac] D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\SRPUnitTestC ase.java:112: cannot resolve symbol [javac] symbol : method getResourceURL (java.lang.String) [javac] location: class org.jboss.test.JBossTestSetup [javac] String authConfPath = super.getResourceURL(security-srp/auth.conf ); [javac]^ [javac] D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\XMLLoginModu lesUnitTestCase.java:41: warning: setPriority(org.apache.log4j.Priority) in org.apache.log 4j.Category has been deprecated [javac] root.setPriority(XLevel.TRACE); [javac] ^ [javac] 1 error [javac] 43 warnings BUILD FAILED file:d:/test/jboss-all/testsuite/../tools/etc/buildfragments/targets.ent:45: Compile faile d; see the compiler error output for details. Total time: 58 seconds Press any key to continue . . . --- 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 -- 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
RE: [JBoss-dev] creating persistent MBeans dynamically
On Fri, 4 Oct 2002, Sacha Labourey wrote: Hello, And what about deployment order? wouldn't the order be explicit if the registry stores a script-like file of its changes and then reads it at startup? similar to how a db constructs itself from a tx log -- 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
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. 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 :) perhaps -- 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
Re: [JBoss-dev] EJB's as Xmbeans?
all that is needed is init, start, stop, destroy On Thu, 3 Oct 2002, David Jencks wrote: proposed mbean interceptor: create start stop destroy setMBeanInvoker //not sure of name, this is like setContainer. getNext insert or setNext invoke Now, this is an mbean stack, so there needs to be something to call the lifecycle methods. It could be something in the top of the stack, but I think it is better to have a single interceptor that looks for lifecycle methods and recycles them through the stack. no, the invoker initializes its own interceptor stack, it can call init, start, stop, destroy explicitly. -- 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
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 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. erm, you're losing the control of the vehicle, matt. keep deployment out of it for now, focus on how to get the restart to work. 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. mbeaninfo is the definition, not the state, the state is in the object instances, separate -- 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
Re: [JBoss-dev] creating persistent MBeans dynamically
On Thu, 3 Oct 2002, David Jencks wrote: The location does not have to be accessible after deployment, so the mbean persistence mechanism has to store it itself. why wouldn't it be accessible? and if my persistence mechanism is something like Dain's CMP engine, I don't expect it to store the whole mbean info object graph, only the values of individual attributes True, but the values of attributes are stored in the mbean info objects theyre cached there, this is no reason to store the whole mbean info structure if a simple getAttribute() will get me the value can be stored in the xmbean xml. You can already specify initial values for mbean attributes in the xml rather than specifying them in jboss mbean dd. In fact you can supply the xmbean xml in the *-service.xml file complete with values. oh well, I give up. too much talk already and no code. you guys do what you do, no biggie. -- 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
Re: [JBoss-dev] creating persistent MBeans dynamically
On Wed, 2 Oct 2002, David Jencks wrote: 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. yes, agreed, add a flag to the mbean descriptor that says this mbean should be recreated at startup -- 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
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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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)
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
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
[JBoss-dev] Ant java fork fails to exit
Anyone else see this problem or have a workaround for it? Using JDK1.4, running java task with fork=true fails to exit the VM sometimes (more often than not). ie the execution hangs forever waiting. Ant version is whatever we're using. -- 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
Re: [JBoss-dev] Ant java fork fails to exit
nevermind.. On Sun, 22 Sep 2002, Juha-P Lindfors wrote: Anyone else see this problem or have a workaround for it? Using JDK1.4, running java task with fork=true fails to exit the VM sometimes (more often than not). ie the execution hangs forever waiting. Ant version is whatever we're using. -- 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
Re: [JBoss-dev] Build System... any ideas
jbossmx already has its own module specific test suite rather than
integrating with the jboss testsuite module so I would welcome the change
jason suggests where jboss testsuite integrates tests from individual modules if
they exist
-- Juha
On Thu, 19 Sep 2002, David Jencks wrote:
They'd probably solve the problem of 7 minutes to build to run a single
test that I experience.
Moving stuff to module specific test dirs would be a lot of work. I wonder
if instead we could make dir-specific generic build targets -- something
like in ${test.module} run xdoclet, compile all classes, then run jar for
${test.module}, then run tests in that module also. Sort of like test
but limiting the xdoclet and jar tasks also.
The build file is getting so large this might help make it more
comprehensible also.
david jencks
On 2002.09.19 17:36:29 -0400 Scott M Stark wrote:
I don't really see how module local tests are any improvement over the
test and
one-test targets in the existing testsuite module. In some ways it is a
problem
because now you have additional dependencies to build and run the tests
in
the module.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 10:29 PM
Subject: RE: [JBoss-dev] Build System... any ideas
David and I talked about this on the way back from Tahoe. I would like
to revisit the entire TestSuite, putting a testsuite in each module,
which would perform Unit tests for components and parts of components
for that module alone. Then the jboss/testsuite would be an
integration
testsuite.
This way, if you are working on bits from the cluster module, you can
write simple tests to validate your component and run the tests
quickly.
Then when you are satisfied, you can write an integration test, which
would actual test a real component inside of a JBoss instance.
This will get us more coverage, but will also encourage developers to
make smaller, simpler tests for stuff and make it more likely they will
run them, as it won't take forever.
Also, on the subject of build systems and testsuites, I have been
toying
with the idea of allow Java and Jython tests to be run together. Using
Jython it will be faster to throw together small and functional tests
with much less code and a lot less trouble. We would still need Java
tests to run stuff that is type dependant, but the two could live
together happy.
The build system overhaul is a dependency of this I believe.
I have been planning on doing all of the above... just I haven't had
the
time to make any progress. Also I really want to finish the basic
command line console framework.
Fuck, I need my boss to stop making me work on their lame ass projects.
Who cares about that shit really... bah!
--jason
---
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
--
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
[JBoss-dev] RE: [jboss-cvs] jmx/src/main/org/jboss/mx/persistenceObjectStreamPersistenceManager.java OsPersistMgr.java
I use jEdit 4.0 final with the latest JavaStyle plugin from the plugin
central. Seems to work (and the JavaStyle plugin has gone a long way since
the last version I used).
I entered the parameters in the plugin GUI by hand. I assume it stores the
config somewhere I'll check if I can find the file, can email it to you.
Donät know about ANT integration, there was some work on it once but I
think it might have been dropped.
-- Juha
On Tue, 17 Sep 2002, Matt Munz wrote:
Juha group,
I figured I missed a few i's and t's in there...
Is this the JavaStyle plugin for JEdit? I can't seem to get it to work at
the moment. But assuming I do, is there profile / rule-set for the jboss
coding conventions I can import, or do I need to enter them in by hand? Are
there similar profiles available for any of the other source code formatters
out there?
I've been thinking about using a formatter, especially one that I can
integrate into my build processes (ANT), and optionally Eclipse -- I'd
appreciate any pointers.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Juha
Lindfors
Sent: Tuesday, September 17, 2002 1:25 PM
To: [EMAIL PROTECTED]
Subject: [jboss-cvs] jmx/src/main/org/jboss/mx/persistence
ObjectStreamPersistenceManager.java OsPersistMgr.java
User: juhalindfors
Date: 02/09/17 10:25:19
Added: src/main/org/jboss/mx/persistence
ObjectStreamPersistenceManager.java
Removed: src/main/org/jboss/mx/persistence OsPersistMgr.java
Log:
OsPersistMgr renamed to ObjectStreamPersistenceManager
Code run through JavaStyle to enforce JBoss coding style.
Revision ChangesPath
1.1
jmx/src/main/org/jboss/mx/persistence/ObjectStreamPersistenceManager.java
Index: ObjectStreamPersistenceManager.java
===
package org.jboss.mx.persistence;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import javax.management.Attribute;
import javax.management.AttributeList;
import javax.management.Descriptor;
import javax.management.MBeanAttributeInfo;
import javax.management.MBeanException;
import javax.management.MBeanInfo;
import javax.management.modelmbean.ModelMBeanAttributeInfo;
import javax.management.modelmbean.ModelMBeanInfo;
import javax.management.modelmbean.ModelMBeanInfoSupport;
import org.apache.log4j.Logger;
import org.jboss.mx.modelmbean.ModelMBeanConstants;
import org.jboss.mx.modelmbean.ModelMBeanInvoker;
import org.jboss.mx.persistence.PersistenceManager;
/**
* Object Stream Persistence Manager. p
*
* Persists the MBean to the file system using an Object Stream.
* Includes code based on examples in Juha's JMX Book. p
*
* Object Streams written to disk are admittedly lacking in the area of
long-term, portable,
* or human-readable persistence. They are fairly straightforward,
however.
* Primarily, this class is useful for demonstration and quick dirty
persistence.
*
* @todo currently metadata as well as data is stored. only data
needs to be stored.
* @authorMatt Munz
*/
public class ObjectStreamPersistenceManager
extends Object
implements PersistenceManager
{
protected boolean fIsLoading;
protected Logger fLogger;
// Constructors --
public ObjectStreamPersistenceManager()
{
super();
}
// Public
/**
* deserializes state from the object input stream
*
* @param mbean
* @param metadata
* @exception MBeanException
*/
public void load(ModelMBeanInvoker mbean, MBeanInfo metadata) throws
MBeanException
{
logger().debug(FilePersist.load; metadata: + metadata);
// based on jmx book
if (metadata == null)
{
return;
}
Descriptor d = ((ModelMBeanInfo)metadata).getMBeanDescriptor();
String dir =
(String)d.getFieldValue(ModelMBeanConstants.PERSIST_LOCATION);
String file =
(String)d.getFieldValue(ModelMBeanConstants.PERSIST_NAME);
if (file == null)
{
return;
}
try
{
File f = new File(dir, file);
FileInputStream fis = new FileInputStream(f);
ObjectInputStream ois = new ObjectInputStream(fis);
metadata = (ModelMBeanInfoSupport)ois.readObject();
logger().info(metadata deserialized);
loadFromMetadata(mbean, (ModelMBeanInfo)metadata);
}
catch (Exception e)
{
logger().error(Error
Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans
On Sat, 10 Aug 2002, Scott M Stark wrote: This probably breaks the MLet processing. But then I think it was already broken, MLets are URLClassLoaders not UCLs. actually we detect ULR in the mlet code and register one UCL per URL in case ULR is used... -- 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
Re: [JBoss-dev] code submission
diff posted to SF tracker or you can ask marcf for rw if you feel like fixing more bugs -- Juha On Wed, 17 Jul 2002, Seth Sites wrote: I have a patch for bug [ 564890 ] JMS recover/redelivery errors that I have tested and am ready to submit for review. I just have a few questions. 1) What is the best way to submit code patches for bugs. Is diff output preferred or just include the entire method that is changed? 2) Is it best to submit the code through the sourceforge interface at the bug report, or just email it to the dev list? Thanks, Seth --- 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 Tel: +358 40 8656 751 (GSM) --- 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] Viewing mbean operation results
On Thu, 27 Jun 2002, Scott M Stark wrote: I thought 'presentationString' only applied to model mbeans. How can we integrate the presentation metadata into the existing standard and dynamic mbeans? You can't, as neither one defines a way to extend the metadata. -- Juha --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
On Tue, 25 Jun 2002, Paul Ward wrote: I am currently in the process of creating an XMBean descendant and PersistenceManager implementation We don't need an XMBean descendant, just the PM implementation. Is there any interest in having this added to the JBoss head? Yes. If so, does anyone have input as to how this should be tied into the system? What do you mean? This combined with the fact that the MBeanServerImpl class fires up an instance of the required model mbean in it's constructor makes the options for connecting to a datasource rather limited. Why is it a problem for your PM implementation if the server creates a model mbean instance on its own? -- Juha --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
On Wed, 26 Jun 2002, Paul Ward wrote: Why I had to create an XMBean descendant: First, XMBean's link to the PM interface is through the instance created in the static initializer for the ModelMBeanInvoker class. This class is hard coded to use the NullPersistence class as it's PM. True, as we don't have any PMs yet. Just change this implementation to allow you to configure any PM. Second, the PM needs a reference to the XMBean instance so that it may call the MBeanInvoker.getAttribute and MBeanInvoker.setAttribute methods. It is not practical to try and access the attributes through the stack since we'll need to restore the values before the mbean is registered with the server. Maybe I'm missing something here about another way to access the mbean attribute values themselves. We will make the callback to load() as part of the MBean's registration phase, after the interceptor stack has been properly set up (rather than making the completely brain dead load() in the constructor which is what the spec mandates). Therefore it might be worth it to change the PM interface to contain a reference to the invoker directly rather than to the metadata (which will be available through the invoker) and therefore you will have direct access to the set/getAttribute as well (with properly working stack by the time your load() is called). Third, the PM needs the objectName value of the bean to persist. Might be missing something here as well. This will also be available through the MBeanInvoker interface. I will commit these changes in about a week to the CVS. Obviously, these issues can be resolved if we're able to modify the existing XMBean. You are. I was going under the assumption that the PM I'm writing might not be merged into the CVS tree. You're the first one wanting to take a stab at it. I will get you a CVS RW. If we could specify the PM to use on an XMBean by XMBean basis Yes that is the idea. (I'm assuming in the descriptor here or maybe in the mbean tag if we want even finer control), Yes. What I mean by 'how this should be tied into the system?': How we address the above issues. Go ahead and make the changes directly to the XMBean implementation. There are some changes coming to the invoker/invocation though. I will commit these by the end of the month. You might want to wait for those to appear first. BTW, I have the implementation up and running. The user must not specify the default values in the jboss-service.xml though, since doing so persists the default values right over top of the values persisted on the last server run. Any insight you could provide to address this issue would be appreciated. I don't know how jboss-service.xml works. -- Juha --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
On Wed, 26 Jun 2002, David Jencks wrote: This may work fine for packages deployed by a deploymentScanner, but will work less well for packages deployed by directly calling MainDeployer.deploy. Scanning for packages may not be the most useful deployment method... even though right now it is the easiest to use. What if we thought of the mbean server as more or less a database of persistent objects, and the deploy/undeploy/redeploy operations using service.xml files as the insert/delete/update operations? If you deployed a package, those mbeans would stay until you explicitly undeployed them, whether or not the *service.xml file was accessible on server restart. My comments on persisting timestamps over server restarts were based on this idea and attempting to think of how the deployment scanner might work with it. The registry of the MBean server is an MBean itself, and can be persisted by configuring a persistence interceptor to its invocation chain. Implement an interceptor that makes the persistence callbacks on registerMBean() and unregisterMBean() calls. This will give you a persisted state of the MBean server's registry. The registry allows you to attach metadata for each entry in the registry. Use this to store the URL to the MBeans management interface definition, constructor signature and values used for creating the MBean instance. This allows you to write a PM that persists the registry in an MLET like file format, with the metadata (usual rules about types needing string representation apply). You can recreate the contents of a registry by adding an Mlet like MBean to the MBean server at startup that points to this file. -- Juha --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Viewing mbean operation results
yes, see the 'presentationString' descriptor field in the spec that's where I'd put the model, then have your console render the view -- Juha On Wed, 26 Jun 2002, Scott M Stark wrote: So I'm testing the new htmladaptor for the upcoming release and some of the default String representations just look like crap(MainDeployer.listDeployed() for example). So the obvious need is a mechanism for obtaining an xml representation of any mbean attribute or operation result as the basis for console applications. Do we have that notion? Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ 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 Tel: +358 40 8656 751 (GSM) --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Detected JMX bug??
You can safely ignore that message. -- Juha On Tue, 11 Jun 2002, Ram Ramesh wrote: Hi all, Is this a JMX bug? or is it a configuration issue? --Ram --- [09:43:45,208,ConfigurationService] Deployers set to J2EE:service=J2eeDeployer; JCA:service=RARDeployer in EJB:service=AutoDeployer [09:43:45,213,ConfigurationService] URLs set to ../deploy,../deploy/lib in EJB:service=AutoDeployer [09:43:45,223,ConfigurationService] MaxActiveClientCount set to 10 in Adaptor:name=html [09:43:45,223,ConfigurationService] Port set to 8082 in Adaptor:name=html [09:43:45,228,ConfigurationService] JNDIName set to Mail in :service=Mail [09:43:45,233,ConfigurationService] ConfigurationFile set to mail.properties in :service=Mail [09:43:45,262,ConfigurationService] User set to user_id in :service=Mail [09:43:45,266,ConfigurationService] Password set to password in :service=Mail [09:43:45,298,ConfigurationService] Detected JMX Bug: Server reports attribute 'ResourceAdapterName' is not writeable for MBean 'JCA:name=JmsXA,service=ConnectionFactoryLoader' ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Problem with UCL.equals and Proxies
this will break the classes we generate in memory though, as they do not have an url On Mon, 27 May 2002, marc fleury wrote: |The result is that UnifiedClassLoader can't override equals. To validate On the top of my head (but I don't remember too well these days) this wouldn't break stuff marcf |that duplicate URLs are not placed into the UnifiedLoaderRepository |the UnifiedClassLoader URL must be used as the unique key. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ 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 Senior Developer, JBoss Group LLC ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Problem with UCL.equals and Proxies
ignore, I misunderstood your message On Tue, 28 May 2002, Juha-P Lindfors wrote: this will break the classes we generate in memory though, as they do not have an url On Mon, 27 May 2002, marc fleury wrote: |The result is that UnifiedClassLoader can't override equals. To validate On the top of my head (but I don't remember too well these days) this wouldn't break stuff marcf |that duplicate URLs are not placed into the UnifiedLoaderRepository |the UnifiedClassLoader URL must be used as the unique key. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ 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 Senior Developer, JBoss Group LLC -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions Senior Developer, JBoss Group LLC ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developersenvironment
On Mon, 20 May 2002, Dain Sundstrom wrote: [I moved this to the dev list] I think the real power of JMX is you can have disparate components that can all talk to a central object without becoming tightly coupled. Here is my idea: We have an optional port server MBean. Before a service opens a port it checks for the existence of the port server, and if (and only if) it exists, it asks the port server for a port passing the service name and port name (both are just any string). If the port service doesn't exist, it follows the default code. This would require that the MBean wrappers for any serveice that opens a port to follow know about the possibility of a port service, but I don't think that is a big deal. Most MBeans already know about many services. another possibility would be to persist these attributes containing port numbers to a single location, e.g. config/ports.properties where all ports would be in a single file. This would not require the MBean developers to change their coding in any way (Jules point about simple contracts) but would just require us to config the initial server setup for the MBeans in question to use the same location for these attributes. New user MBeans could also be configured to use the same storage. Same approach would work for other system resources as well (whatever they might be) without having to impose yet another contractual requirement for MBean developers. However, this requires that we convert to using persistent mbeans, which is a more long term project. Short term your solution is the easier fix. my .02 -- Juha ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ejb-name conflict, help me!!!
On Wed, 1 May 2002, Andreas Schaefer wrote: I guess that JBossMX does not provide a fix for that, correct ? no because an object name like that is not spec compliant -- Juha ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] Dropping the System.out calls in the jmx code
.. aaand make the logger interface available as an mbean in JMImplementation so my third party service impl can flash that red light too via the jmx bus -- Juha On Thu, 2 May 2002, Adrian Brock wrote: This is what I am trying to do with the JBossMX logger. You have a single logging interface org.jboss.mx.Logger so there are no code changes in other parts of the system and then choose your actual implementation. This could be do nothing - the NullLoggerAdaptor or FlashRedWarningLightLoggerAdaptor ;-) Regards, Adrian The idea of a logger in an embedded system is kind of strange, what are you going to log to ??? I mean most of the time is your embedded chip going to lug around a 50Gig barracuda IDE??? no... are you going to open an socket just for logging... no... are you going to fill your memory (tight if we believe specs) with log message... no. Logging in J2ME (JBoss4.0) strikes me as a DEBUGGING feature. Useful while in development. Then YES you want to know what is going on, that much is trivial to see. This is where log4j becomes interesting, we would essentially DISABLE it for use in production J2ME while keeping it on for development but the code remains the same. So the port to log4j is interesting in that respect. So the question for you JBoss4.0 fans out there is how small can we get log4j to be to do NOTHING, i.e. redirect all messages to /dev/null but still keep the code the same in our JBossMX/JBoss layers. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of |Adrian Brock |Sent: Thursday, May 02, 2002 7:05 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Dropping the System.out calls in the jmx code | | |Making the JBossMX logger use log4j is easy enough. |The only problem is log4j isn't configured until |after the MBeanServer is created in ServerImpl. |This isn't a big problem since the loggers are designed |to boot with System.err and swap over to the required |logging implementation when it becomes available. | |There are also some places in the code that do |System.out directly that need fixing. | |I'll do this at the weekend. | |I'm was also looking at reducing the footprint for |embedded, while allowing functionality to be added later. |My early attempt isn't very good. The footprint is |9k compared with 2k for common's Logger. | |Regards, |Adrian |* * * | |View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=146 2 __ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment __ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14612 ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ 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 Senior Developer, JBoss Group LLC ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
XML is now the lingua franca of human-readable structured data. XHTML, JSTL, Ant configs, SOAP, etc., mean that any serious designer of web applications must be proficient in reading and writing XML. Saying unreadable XML in the 21st century is like saying unreadable French in the 18th century. It's a statement of one's illiteracy, not an indictment of the method of representation. And here I was thinking the point of XML was to make it easier for the *machine* to parse structured data. -- Juha, the illiterate jns:java jns:comment![CDATA[Hello, World]]/jns:comment jns:package name=my.stuff/ jns:import name=java.lang.System/ jns:class name=Main extends=java.lang.Object/ jns:implements name=MyInterface/ jns:implements name=ThatOtherInterface/ /jns:class jns:method name=main PUBLIC STATIC jns:comment![CDATA[Print the message]]/jns:comment jns:return-typevoid/jns:return-type jns:signature jns:arg name=args/ jns:type name=java.lang.String ARRAY/ /jns:signature jns:body jns:invokestatic name=java.lang.System reference=out jns:method name=println jns:value![CDATA[Hello, World]]/jns:value /jns:method /jns:invokestatic /jns:body /jns:method /jns:java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Sun, 28 Apr 2002, Michael Robinson wrote: Someone who was literate in XML, but with no prior exposure to the syntax and semantics of Java, could get more meaning out of the XML version than the Java version. Really? To me both would look like nonsense. that language will be more concise which I believe is what was requested. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is new ObjectName() so slow?
because an object name contains a set of properties that need to be parsed and may also be a pattern which needs to be determined the current implementation does this eagerly at object name creation time -- Juha On Sun, 28 Apr 2002, marc fleury wrote: ok, I know I asked already and I can't remember the reason why creating an ObjectName should be S slow. Can one of the JMX gurus enlighten me and explain the reason. (yes again sorry) last I remembered the new ObjectName would take half the time of the invocation (!). If that is still the case then it is going to invalidate a lot of the thinking around the ObjectName MBean client proxy stuff which is quite powerful. But it is software and software is fixable so I can't imagine that there is a real life reason for this to be so slow. marcf x Marc Fleury, Ph.D President JBoss Group, LLC x ___ 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 Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: |because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined right the value=name pairs |the current implementation does this eagerly at object name creation |time can we do this lazily? can't we build equality and hash on the FULL string? no, we need a canonical presentation for equality check (because the name is a set of properties, not just an array of characters.. we need to sort the properties before we can check for equality) it strikes that the eager parsing is silly (eats up 50% of the time !!!) and only really useful in querying? Can you think of optimizations? the optimizations that we can do inside ObjectName would only include possibly optimizations to Java's string handling, maybe replacing generic collections with type specific ones, and avoiding Collections.sort() (I don't know how it is implemented or how well it performs). However, the problem with even these optimizations is that Sun plans to push JMX as part of JDK from the next 1.5 version on. They however have no plans to publish an SPI which means whatever is inside javax.management packages will from the next version on be Sun's implementation. And as you and I well know, Sun's implementation isn't exactly performing or industrial strength. The question at the moment is, why do you need to create an object name per invocation? Is it possible to cache the object names by mapping them to *real* identifies as opposed to this property nonsense? (how many MBean's do you imagine having in your server, could you create the object names for them on the server side and lookup the same instances from a cache -- I know it sounds ass backwards but given then future plans on JMX it would be best to avoid too much reliance on the JMX classes themselves. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, Hiram Chirino wrote: Using a set of properties to identify an object just seems werid to me. yes. it's not just wierd, its clearly a poor design choice in this case. the object name is used as an identifier and therefore needed for lookup. overloading the identifier to become something other than just an array of chars we can compare is a problem. WHY did the JMX spec do this??? Why not just use a unique string to identify an object??? I do not know. Yes, I see one reasone, so you can do querys and lookup objects based on properties, buy you could still do that without making the properties part of the identifier. Do you know what I mean?? totally. see my other post. yes the object name should be just an identifier -- none of this property/pattern business. just a key for lookups. should probably spend some time trying to figure out how to bypass the object name use completely (leave it as internal to the server only) and see if we can replace it with a real identifier. I don't know if it would work or possible... need to think about it -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: Juha for example. By spec must we have Domain1:name1=value1;name2=value2 == Domain1:name2=value2;name1=value1 ??? I would imagine so, yes and this is the problem for performance -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: 2 solutions. 1- I build a mapper that takes String and returns ObjectName 2- you build a ObjectName implementation that caches the ObjectName and returns the right Object if you pass me exactly the same String. Come to think of it we probably need the first one. Can you expose it at the JMX level? I have an idea for it but (obviously) haven't looked at the details yet. Might be a deliverable. Right now I need to take a time out on this. Need to finish the inforIT, explain our interceptors to EG and then do that finetuning for training slides. -- Juha I believe the registry idea must be present at the JMX level, then you would put the objectname mapped to the String name and that is fast enough for me to use and STANDARDIZE on inside the server. Bar that, the spirit dies for a spec quirk |MBean's do you imagine having in your server, could you create the object |names for them on the server side and lookup the same instances from a |cache -- I know it sounds ass backwards but given then future plans on |JMX it would be best to avoid too much reliance on the JMX classes |themselves. correct that is what I understand we need that cache. It is the Registry idea with more generic mappings. It is a system level Registry juha. In a invoker I want to pass the String and use that to map to the ObjectName on the server or maybe expose an invoke that doesn't work with ObjectNames? something that makes sense. Keep exceptions out of the design. marcf I will not watch my people die while you discuss this invasion in a commitee -- some silly queen in a SF movie-- -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Fri, 26 Apr 2002, marc fleury wrote: One step at a time, when we finalize 3.x releases i.e. in a couple of weeks, I say we move on 4.0 development and the overhaul of the admin with persistence through the modelmbeans will require some tweaking of the XMBeans (I believe the current implementation lacks) where you put your own umm, we dont really have any implementation for persistence at the moment so yes it does lack :) -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JL] Is it time for a new enterprise solution?
Critique on JBoss configuration. http://www.javalobby.org/thread.jsp?forum=61thread=3254 -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
On Mon, 22 Apr 2002, marc fleury wrote: *and unreadable XML* oh my -- Juha just tired of it all, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Larry |Sanderson |Sent: Sunday, April 21, 2002 3:10 PM |To: [EMAIL PROTECTED] |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ? | | |I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention |a little less likely to stumbled upon by unknowing users. I suggest: |jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for |indexed deployments first, and sort the remainder by type. This allows a |simple, global comparator, but removes the fine-grained support |you suggest. |So given the following within a directory: | |jetty.sar |my_ejb_ver4.jar |jar_jb5.jar |sar_jb10.sar | |This would order them thus: |jar_jb5.jar -- all indexed deployments first |sar_jb10.sar |jetty.sar -- all others second, in order of sar,rar,jar,war,ear |my_ejb_ver4.jar | |Hell, if they really need the flexibility you suggest then they |can set up a |second scanner, but I can't imagine any place where this is not sufficient. | |-Larry | | I'm not sure specifying the global sorter for a whole scanner is the way |we | want to go... on the other hand extensibility is nice... Do we want to | encourage people to have lots of scanners? | | At the risk of making things more complicated than necessary, |yet striving | for simplicity, how about | | mbean code=org.jboss.deployment.scanner.URLDeploymentScanner | name=jboss.deployment:type=DeploymentScanner,flavor=URL | | | attribute name=ScanPeriod5000/attribute | | | attribute name=URLs |dir name=./deploy/core order=type/ |dir name=./deploy/app order=lexical/ |url name=.deploy/other/jar1.jar/ |url name=.deploy/other/sar2.sar/ |url name=.deploy/other/war3.war/ | /attribute | | | | !-- Uncomment (and comment/remove version below) to enable usage of | the DeploymentCache | depends |optional-attribute-name=Deployerjboss.deployment:type=Deployment |Cache/de |pends | -- | depends |optional-attribute-name=Deployerjboss.system:service=MainDeploye |r/depend |s | | | /mbean | | mbean code=... |name=jboss.deployment:type=DeploymentSorter,order=type/ | mbean code=... |name=jboss.deployment:type=DeploymentSorter,order=lexical/ | | The deployment scanner looks up the requested ordering using the naming | pattern on the DeploymentSorter mbeans. | | I'm not sure if we really need explicit dependencies listed in the | DeploymentScanner. | | Striving towards simplicity (believe it or not;-) | | david jencks | | | On 2002.04.21 16:37:46 -0400 Larry Sanderson wrote: | As larry said (do you have rw yet?) | | Yup. I've already checked in at least one bug :-) | | let's not shove it down people's throat | and let's document all of this. Case closed. Implementation |needed :) | | Simple, and not too hacked implementation: | | Add MBean attribute to URLDeploymentScanner: URLComparator | make default comparator point to: org.jboss.deployment.DeploymentSorter | (make this a comparator that does the correct ordering) | in scanDirectory, change: list = sorter.sortURLs(list); | to: if (urlComparator != null) Collections.sort(list, urlComparator); | | This allows users unhappy with the ordering scheme to replace it with | their | own Comparator (or simply drop it to remove all ordering). If this | sounds | OK, I am mucking about in that code anyway. Would you like me to make | these | changes? | | -Larry | | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ 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 Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Final 3.0 beta will happen this week
On Thu, 11 Apr 2002, Luke Taylor wrote: Scott M Stark wrote: Its all junk as far as I'm concerned. If nobody claims maintence they are history. Is the stuff in the admin directory actually used at all either? nope. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: AW: [JBoss-user] RE: Bomb the bug parade! was AW: [JBoss-dev]Thr ead deadlock in class loader
On Thu, 11 Apr 2002, Jung , Dr. Christoph wrote: Anyone knows how this works? Will they publish the thing not until it reviewed, or what? yeah they'll review it to see if it makes sense, and then assign a bug id for it at which point you usually get an email about it -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Scheduled MBeans (Suggested Patch)
looking at the code, I think the timer should override the sendNotification() to use multiple threads to call listener handleNotification() methods (threadpool if it seems creating new Threads per listener call won't perform, which is likely) however the default behavior in the notificationbroadcaster support should be left as is imho, iow similar to java event handling ideally we could just drop in a different nb support implementation but since the spec forces us to subclass the default implementation instead of just implementing the notificationbroadcaster interface this seems the way to go about it I leave the decision for Adrian though, it is his code :) -- Juha On Tue, 9 Apr 2002, Andreas Schaefer wrote: Hi Corby Thanx for looking into it. Will check with Juha / Adrian to see what they think. My patch addresses this problem without altering NotificationBroadcastSupport. The SchedulerMBean receives the synchronous notification, creates a new Thread to actually invoke the MBean, and returns the original Thread of control back to the Timer so that it can immediately fire the next notification. Anyway, let me know if you'd like the patch. It might be faster for you to just code the fix yourself. Currently I don't think we should fix it on the Scheduler level. The problem is that even when the Scheduler does not delay the call there can be another listener which does not go along with this. If we can fix this on JMX level then do it this way. Andy ___ 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 Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] JMX HTML... From the Pure Fluff Department...
On Mon, 8 Apr 2002, David Jencks wrote: Look into the modelmbean descriptors. I think they include a priority as a standard descriptor, this could be used to determine whether to display something. visibility to determine the granularity of mbeans (spec defines levels 1-4) presentationString is what the adaptor should look for to get presentation information an XML string describing the mbean view layout. Look for W3C XForms (work in progress web forms) or just roll your own (quicker). The key is for the components to be able to specify how to present and modify non-primitive types that are part of the management interface, e.g if java.net.URL is in the interface how it should be presented in the management tool (string, validate its a real URL, etc). -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossMX - Core/Kernel
On Sat, 23 Mar 2002, Adrian Brock wrote: If we really wanted to provide a minimal kernel, Standard and ModelMBeans are really services on top of the DynamicMBean core. But that's probably not relevent to most users of JMX The Model MBean implementation should at least eventually move out of the kernel jar. -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMX 1.0 Beta Release
You can download it from sourceforge http://prdownloads.sourceforge.net/jboss/JBossMX-1_0_Beta.tgz http://prdownloads.sourceforge.net/jboss/JBossMX-1_0_Beta.zip This beta release includes the JMX 1.0 specified functionality -- all standard services: MLet, Monitoring, Relation and Timer services, queries, advanced logging, bytecode optimized FAST invocations for Standard MBeans, etc. Please take it for a spin and report bugs/omissions. Special thanks to Trevor and Adrian for their hard work. -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Jboss-development digest, Vol 1 #2686 - 13 msgs
Hmm ok... it's a TODO for the next volunteer ;-) -- Juha --__--__-- Message: 9 Date: Mon, 28 Jan 2002 16:44:04 -0500 From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jmx/src/main/test/compliance/server ServerSUITE.java I haven't had a chance to look at your jmx tests but you might consider naming them consistently with the jboss testsuite tests and seeing if the ant-based test framework can be used also. In particular I have yet to find a use for adding tests explicitly to suites unless I am wrapping them in a setup. Getting these tests run nightly with the other jboss tests would be really nice. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jmx build.xml
huh? On Wed, 12 Dec 2001, Jason Dillon wrote: Why don't these have vendor directories? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossMX and jboss-all
That's up to bill and sacha.. but I think you're right, moving might be more trouble than its worth -- Juha On Thu, 6 Dec 2001, Jason Dillon wrote: What is the deal with the cluster stuff? It is currently in jbossmx module in cvs. It should be moved, but moving it will break all jboss-all checkouts, which I am not really into doing too often. I think we should leave it there until there is time to fix the CVS depot of all of its namespace issues. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Versioning? (Was: current mbean structure confusing)
On Thu, 6 Dec 2001, Andrew Scherpbier wrote: While reading the thread current mbean structure confusing I was thinking about some other issues with mbeans, specifically versioning. In the special purpose app server we developed at my previous company we ran into a problem with upgrades. Our complete system consisted of something similar to mbeans (we developed this before the JMX stuff was around...) running in a simple container. (Sounds familiar? :-)) When we sent a new version of our software to a client (our clients included our own IT) we needed a way for the software to recognize that newer versions of some of the components were available. So we extended our component system to make it aware of its own version number and allowed a special method to perform upgrade tasks (it got the old version number, so it could perform the correct upgrade) I see this type of thing as a very useful extension to the current JMX stuff. Any thoughts on this? Does JMX 1.1 address this? If there is interest, I am willing to seriously look at implementing something like this. This can already be supported in JMX 1.0; see for example the VERSION tag in the M-Let text file. Multiple class loaders (one per version) can also be done in 1.0 via the M-Let classloading mechanism. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossMX and jboss-all
hmm? did I drop my module in the wrong place in the CVS? -- Juha On Thu, 6 Dec 2001, Jason Dillon wrote: Date: Thu, 6 Dec 2001 16:45:57 -0700 (MST) From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBossMX and jboss-all come to think of it, users will have to checkout again to get the jboss-all/jmx directory too. we really need to reorganize the repository to avoid this in the future. :( --jason View: http://jboss.org/forums/thread.jsp?forum=66thread=4999 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossMX and jboss-all
Is there a way to co and build a standalone jbossmx? that should be possible, can it be done the way MQ uses CVS now? -- Juha On Thu, 6 Dec 2001, Jason Dillon wrote: Date: Thu, 6 Dec 2001 17:25:43 -0700 (MST) From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBossMX and jboss-all just added build files. you will need to checkout jboss-all again to get the changes. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jmx build.bat build.sh build.xml
Thanks for this work, Jason. -- Juha On Thu, 6 Dec 2001, Jason Dillon wrote: Date: Thu, 06 Dec 2001 16:33:20 -0800 From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] CVS update: jmx build.bat build.sh build.xml User: user57 Date: 01/12/06 16:33:20 Added: .build.bat build.sh build.xml Log: o adding build files Revision ChangesPath 1.1 jmx/build.bat ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss
And for those of you who want to place preorders for the book: Amazon: http://www.amazon.com/exec/obidos/ASIN/0672322889/104-6670791-7933546 BarnesNoble http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=6AWE6O0GSLmscssid=P8DUDFK1W30T9P49N6M7UG91HXC87KN1isbn=0672322889 Hope you enjoy it :) -- Juha sig under construction On Wed, 5 Dec 2001, marc fleury wrote: Date: Wed, 5 Dec 2001 12:27:09 -0500 From: marc fleury [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Subject: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss Folks, JMX as you know is deep inside our server and the basis for our new microkernel architecture. JBoss when it is born is nothing more than the JMX.jar and the ServiceLibraries with it. Juha Lindfors has just finished writing the forthcoming JMX book for sams publishing and it will hit the market in early 2002, it is an excellent book. From the insights he collected as he was writting it, JBossMX is born, a JMX based implementation in JBoss. As you can see as of this morning the first imports are already in CVS, the code is alive. JBossMX is going to be big, bigger than the server itself methinks, JBoss is going to be JBossMX in the new future. That is what we are really working on these days, david, scott, rickard, myself, and now juha putting forth the base code for it. It is a first implementation and I expect it to mature rapidly. So go buy the book and participate in the implementation, JBossMX is a clear system vision, one we share and the JMX future is bright, I expect it will be in all sorts of embedded and servers as I outlined in the edge/central view earlier, it is the common infrastructure for us, the base for the super server. It will leave in its own little jar separate of the rest of JBoss and really be, like the RI is today the boot jar of JBoss. in fact in the current codebase, JBoss is really JBossMX (today the SUN RI to be replaced, just to many problems so far, maybe the upcoming release will be better, but getting things fixed has just proved too problematic, open source is clearly superior there) but we will focus on providing a SMALL and FAST implementation, juha has some ideas on how to do that well, and then other services will probably be mbeans themselves ;). So you will have a JBoss that fits in 200k like it does today when it boots, probably even less if we strip some of higher services that you don't need immediately. We expect advanced add-ons to be sold like the snmp stacks from vendors and whatnot. Then everything including the EJB interceptors, the plugins, the services, the webservices invokers all mbeans all on a fast bus all on infrastructure we can debug at lightning speed and push in the field with wider distribution that even SUN achieves. With 500,000 page views a month and 50,000 downloads we are going to push our system view of the world we are going to make it real we are going to make it a success. The guardians are cold, but they are working, they know the flame is coming, they are working. The sound of the real deal your mind we heal -- LTJ bukem, Mc conrad -- Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss
Hi, end of January, 2002 I don't have an exact date -- Juha On Wed, 5 Dec 2001, Dave Bettin wrote: Is there an official publication date for the book?? Thanks, Dave --- Juha-P Lindfors [EMAIL PROTECTED] wrote: And for those of you who want to place preorders for the book: Amazon: http://www.amazon.com/exec/obidos/ASIN/0672322889/104-6670791-7933546 BarnesNoble http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=6AWE6O0GSLmscssid=P8DUDFK1W30T9P49N6M7UG91HXC87KN1isbn=0672322889 Hope you enjoy it :) -- Juha sig under construction ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Subclassing of Remote Interface
Is it an exception from the container or from the verifier?
-- Juha
On Wed, 5 Dec 2001, Andreas Schaefer wrote:
Date: Wed, 5 Dec 2001 11:35:51 -0800
From: Andreas Schaefer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Subclassing of Remote Interface
Hi Geeks
I ran into a problem and looking for quick anwser because
I am in a discussion on another mailing-list.
I have a Home-interface with this create() method:
- public A create() throw CreateException;
Now I have this Remote-interface:
- public interface B extends A {}
In the ejb-jar.xml interface B is the declared Remote-
interface.But the JBoss verifier is complaining that the
Home-interface has to return B in its create method
and I get some exception thrown.
I heard that this scenario is allowed by the EJB spec.
x
Andreas Schaefer
Senior Consultant
JBoss Group, LLC
x
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss
he signed the contracts On Wed, 5 Dec 2001, Bill Burke wrote: Date: Wed, 5 Dec 2001 14:35:26 -0500 From: Bill Burke [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED], Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss How come it says the author is Marc Fleury? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss
and its being fixed :) On Wed, 5 Dec 2001, Bill Burke wrote: Date: Wed, 5 Dec 2001 14:35:26 -0500 From: Bill Burke [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED], Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss How come it says the author is Marc Fleury? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS DEV LIST AND ***FORUM*** USAGE
On Wed, 5 Dec 2001, marc fleury wrote: ONE REQUEST FOR THE USERS OF EMAILS PLEASE DO NOT OVERQUOTE *** and one request for the users of forum: do quote (not over quote), otherwise your messages make very little sense when read from the mailing list -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loadingBasicLoaderRepository.java LoaderRepository.java
you're right, thanks
-- Juha
On Mon, 3 Dec 2001, David Jencks wrote:
Date: Mon, 3 Dec 2001 19:15:34 -0500
From: David Jencks [EMAIL PROTECTED]
To: Juha Lindfors [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading
BasicLoaderRepository.java LoaderRepository.java
Are you sure you don't mean
Iterator it = loaders.iterator();
while (it.hasNext()) {
ClassLoader cl = (ClassLoader)it.next();
if (cl != skipLoader) {
try {
clazz = cl.loadClass(className);
return clazz;
}
catch (ClassNotFoundException ignored) {
// go on and try the next loader
}
}
}
throw new ClassNotFoundException(className);
}
at the end of loadClassWithout?
The original version looks through all classloaders and you get the last
version that loads, rather than stopping when you find one working version.
???
thanks
david jencks
On 2001.12.02 21:13:31 -0500 Juha Lindfors wrote:
User: juhalindfors
Date: 01/12/02 18:13:31
Added: src/main/org/jboss/mx/loading BasicLoaderRepository.java
LoaderRepository.java
Log:
build fancy loaders here
Revision ChangesPath
1.1 jmx/src/main/org/jboss/mx/loading/BasicLoaderRepository.java
Index: BasicLoaderRepository.java
===
/*
* LGPL
*/
package org.jboss.mx.loading;
import java.util.Set;
import java.util.Iterator;
import java.util.HashSet;
public class BasicLoaderRepository implements LoaderRepository {
private static LoaderRepository instance = null;
public synchronized static LoaderRepository getInstance() {
if (instance != null)
return instance;
else {
instance = new BasicLoaderRepository();
return instance;
}
}
protected Set loaders = new HashSet();
private BasicLoaderRepository() {
}
public Class loadClass(String className) throws
ClassNotFoundException {
return loadClassWithout(null, className);
}
public Class loadClassWithout(ClassLoader skipLoader, String
className) throws ClassNotFoundException {
Class clazz = null;
// try ctx cl first
ClassLoader ctxLoader = Thread.currentThread().getContextClassLoader();
if (ctxLoader != skipLoader) {
try {
clazz = ctxLoader.loadClass(className);
}
catch (ClassNotFoundException e) {
// ignore and move on to the loader list
}
}
if (clazz != null)
return clazz;
Iterator it = loaders.iterator();
while (it.hasNext()) {
ClassLoader cl = (ClassLoader)it.next();
if (cl != skipLoader) {
try {
clazz = cl.loadClass(className);
}
catch (ClassNotFoundException ignored) {
// go on and try the next loader
}
}
}
if (clazz == null)
throw new ClassNotFoundException(className);
return clazz;
}
public void addClassLoader(ClassLoader cl) {
loaders.add(cl);
}
public void removeClassLoader(ClassLoader cl) {
loaders.remove(cl);
}
}
1.1 jmx/src/main/org/jboss/mx/loading/LoaderRepository.java
Index: LoaderRepository.java
===
/*
* LGPL
*/
package org.jboss.mx.loading;
public interface LoaderRepository {
public Class loadClass(String className) throws
ClassNotFoundException;
public Class loadClassWithout(ClassLoader loader, String className)
throws ClassNotFoundException;
public void addClassLoader(ClassLoader cl);
public void removeClassLoader(ClassLoader cl);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
Hi, Marc / everyone, When you asked about this Dynamic mbean thing I'm working on, were you thinking of me applying it to RequiredModelMBean? I wrote a ModelMBean implementation for the book and will commit an implementation based on it (with some other stuff) in the next couple of days. If I read correctly, we are required to supply an implementation of that class, no? Just implementing the ModelMBean interface will be enough. 1) What are the expectations for determining the MBeanInfo? Should we expect a XYZMBean interface to match the XYZ implementation the user provides? (similar to regular MBeans) This would be easy to add. Since I already have the code that walks the methods of any specified interface to compose the operation/attribute info structures. The metadata can be built using introspection on the resource class, read from a database, read from a file, looked up from the JNDI. The rules for introspection can follow the standard MBean rules, or you can create your own naming rules for a specific resource type. 2) What should be the rules for determining the operations/attributes? I have written and re-written this logic in my own code about 15 times, never really happy with it. Example, how to handle: int getXYZ(); void setXYZ(float); Do you consider the get to be a RO attribute and one to be an operation? Or throw an exception for non-compliant naming? I see nothing in the spec regarding naming standards on dynamic mbean oper/attr or int getXYZ(); void setXYZ(int); void setXYZ(float); Do we consider get/set(int) to be a RW attr, and set(float) to be an operation? Or throw again? If you are talking about the Standard MBean behaviour, that would cause a NotCompliantMBeanException to be thrown. However, for ModelMBeans you could build your own resource types that allow this kind of interface to be handled differently. As for persistence, have you finished rolling on the floor laughing at my idea of using EJBs to store? I have noticed that no other components use EJBs for their JDBC based persistence. Is there a reason for this? The MMBean persistence can be abstracted behind a simple PersistenceManager interface with load and store operations. The persistence implementation may then be file based, direct JDBC, JDO or EJB. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
On Mon, 12 Nov 2001, marc fleury wrote: |It is very similar to GLUE |(http://www.themindelectric.com/products/glue/glue.html). there you go, let's do it then... the problem with glue is we can't distribute the lib with jboss it will require each user to go and download it individually -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
On Mon, 12 Nov 2001, marc fleury wrote: |the problem with glue is we can't distribute the lib with jboss |it will require each user to go and download it individually ok let's stop this, who said we wanted to distribute the libraries from glue? I would want to, cause its a very good lib. And free (beer). But can't distribute with an IDE or app server, which sucks :p anyway... how does AXIS do it differently... and why? -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH, Jetty, testsuite, Exceptions...
Hmm.. you sure the auth.conf file is available in your classpath for the client? -- Juha On Mon, 17 Sep 2001, Julian Gosnell wrote: Date: Mon, 17 Sep 2001 21:49:05 +0100 From: Julian Gosnell [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH, Jetty, testsuite, Exceptions... Thanks David that's one more cleared up: I had to change resource-ref res-ref-namejms/QueFactory/res-ref-name res-typejavax.jms.QueueConnectionFactory/res-type jndi-nameConnectionFactory/jndi-name /resource-ref The JNDI name was wrong. I shall check this in soon - so if i am wrong, let me know pronto ! I only appear to have one problem left, it just repeats a few times. I would appreciate any pointers : [Jetty] Servlet Exception for /jbosstest/ClientLoginServlet java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.getAppConfigurationEntry(ConfigFile.java:221) at javax.security.auth.login.LoginContext.init(Unknown Source) at javax.security.auth.login.LoginContext.init(Unknown Source) at org.jboss.test.web.servlets.ClientLoginServlet.doLogin(Unknown Source) at org.jboss.test.web.servlets.ClientLoginServlet.processRequest(Unknown Source) at org.jboss.test.web.servlets.ClientLoginServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:488) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.http.HandlerContext.handle(HandlerContext.java:1027) at org.mortbay.http.HandlerContext.handle(HandlerContext.java:982) at org.mortbay.http.HttpServer.service(HttpServer.java:674) at org.mortbay.http.HttpConnection.service(HttpConnection.java:732) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:889) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:746) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:146) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) at org.mortbay.util.ThreadPool$PoolThreadRunnable.run(ThreadPool.java:613) at java.lang.Thread.run(Thread.java:484) If anyone knows anything about this exception, I would appreciate a few pointers. Cheer, Jules David Maplesden wrote: I don't know anything about this test, but I can see one problem straight away, JBossMQ no longer uses the name QueueConnectionFactory in its default setup so unless you have changed the MQ configuration (which is unlikely, yes?) then the name that should be looked up by the test is just ConnectionFactory. Cheers David. -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 18, 2001 8:18 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] RH, Jetty, testsuite, Exceptions... It looks like some new tests may have gone into the web test module. I am trying to get RH/Jetty to pass and have come up against the following : [Jetty] ENCServlet: init [Default] ejb/bean0 = ENCBean0Home [Default] ejb/bean1 = ENCBean1Home [Default] ejb/bean2 = ENCBean1Home [Default] ejb/UnsecuredEJB = jbosstest/ejbs/UnsecuredEJBHome [Default] ejb/SecuredEJB = jbosstest/ejbs/SecuredEJBHome [Default] jdbc/DefaultDS = org.jboss.resource.adapter.jdbc.JDBCDataSource@661fd1 [Default] mail/DefaultMail = javax.mail.Session@4ab2f [Default] javax.naming.NameNotFoundException: QueueConnectionFactory not bound [Default] at org.jnp.server.NamingServer.getBinding(Unknown Source) [Default] at org.jnp.server.NamingServer.getBinding(Unknown Source) [Default] at org.jnp.server.NamingServer.getObject(Unknown Source) [Default] at org.jnp.server.NamingServer.lookup(Unknown Source) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at javax.naming.InitialContext.lookup(InitialContext.java:350) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.testJMS(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.testENC(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.processRequest(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.doGet(Unknown Source) [Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) [Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [Default] at
Re: [JBoss-dev] requirements for build
On Fri, 31 Aug 2001, Dan - Blue Lotus Software wrote: I'm sorry if this is obvious to everyone on this list. It wasn't for me, though. The directions for buildmagic say nothing about how to *install* it. And the build script contains the record tag, which is only supported in v1.4beta1 and beyond. I didn't need to install anything... worked fine for me. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] *.kpx files
On Sun, 26 Aug 2001, Jason Dillon wrote: Does anyone still use these? What are they for? Kawa IDE Project Files. Don't really belong to the CVS. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq selector parser grammer source
It's here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/spyderMQ/src/java/org/spydermq/selectors/
this is the boolean equal check:
//CST group
if (s.equals(TRUE)) {
yylval = new parserval((Object)Boolean.TRUE);
return CST;
}
if (s.equals(FALSE)) {
yylval = new parserval((Object)Boolean.FALSE);
return CST;
}
-- Juha
On Wed, 22 Aug 2001, Hiram Chirino wrote:
Can you send it to me??? I'll check it in.
Regards,
Hiram
From: Juha-P Lindfors [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 13:01:02 +0300 (EET DST)
I have just fixed (and verified) both of these problems. Should I
commit
them? Silly me, of course I should commit them... but where is jms.y?
I have the jms.y as part of the old spyderMQ module in
src/java/org/spydermq/selectors.
No idea where it is in the newer modules, or if it was ever transferred.
But check the SpyderMQ in CVS.
-- Juha
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq selector parser grammer source
On Wed, 22 Aug 2001, Jason Dillon wrote: Do you know what is used to generate parser.java from jms.y? //### This file created by BYACC 1.8(/Java extension 0.92) //### Java capabilities added 7 Jan 97, Bob Jamison //### Updated : 27 Nov 97 -- Bob Jamison, Joe Nieten //### 01 Jan 98 -- Bob Jamison -- fixed generic semantic //### 01 Jun 99 -- Bob Jamison -- added Runnable support //### Please send bug reports to [EMAIL PROTECTED] //### static char yysccsid[] = @(#)yaccpar 1.8 (Berkeley) 01/20/90; -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq selector parser grammer source
Try http://troi.lincom-asg.com/~rjamison/byacc/
(at the bottom of the page)
it contains a win exe, with byaccj 1.1 (so slightly newer)
yacc -Jclass=parser jms.y
-- Juha
On Wed, 22 Aug 2001, Hiram Chirino wrote:
I think Byacc. Can I get a win32 ver of that???
Regards,
Hiram
From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 12:41:33 -0700 (PDT)
Unless s has been toUpperCase() (which I did not explictly check), then
this
is not spec compliant. It needs to check for true and false too.
Do you know what is used to generate parser.java from jms.y?
--jason
On Wed, 22 Aug 2001, Juha-P Lindfors wrote:
It's here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/spyderMQ/src/java/org/spydermq/selectors/
this is the boolean equal check:
//CST group
if (s.equals(TRUE)) {
yylval = new parserval((Object)Boolean.TRUE);
return CST;
}
if (s.equals(FALSE)) {
yylval = new parserval((Object)Boolean.FALSE);
return CST;
}
-- Juha
On Wed, 22 Aug 2001, Hiram Chirino wrote:
Can you send it to me??? I'll check it in.
Regards,
Hiram
From: Juha-P Lindfors [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 13:01:02 +0300 (EET DST)
I have just fixed (and verified) both of these problems. Should
I
commit
them? Silly me, of course I should commit them... but where is
jms.y?
I have the jms.y as part of the old spyderMQ module in
src/java/org/spydermq/selectors.
No idea where it is in the newer modules, or if it was ever
transferred.
But check the SpyderMQ in CVS.
-- Juha
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
_
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] URGENCY? WSDL/UDDI/ebXML
On Wed, 15 Aug 2001, Dan - Blue Lotus Software wrote: My opinion of it back 5 months ago was that it was not really even close to usable yet. Have things changed radically since then? Well, I think the emergence of UDDI/WSDL gave them a boost to speed up, and all the core specs seem to have gained at least 1.0 status now. I don't know if anyone has the full platform implemented yet (I think it's unlikely), but there are parts of it being implemented - prototype ebXML registries set up, and so forth. Sun has released an ebXML registry for J2EE (iPlanet) that is available here: http://www.sun.com/software/xml/developers/regrep/ but I haven't ever tried it. They're also taking ebXML into consideration when designing the Java XML Registry and Java XML Messaging API's which should allow you to interface with ebXML by using a correct service implementation, approach similar to JNDI I think. I know IBM have a UDDI implementation in beta. Any chance we can convince them to donate it to Apache, Jakarta, or JBoss (I figure it's more likely they would open-source it to one of the first two, given their currently relationship with Apache)? There are open source UDDI implementations in the works, for example jUDDI.org and pUDDIng (http://www.opensorcerer.org/). What needs to be added to provide WSDL support? Maybe I'm missing something, but it seems like it's merely a description language for services--a file you might retrieve from a UDDI registry that describes a SOAP service. In this case, what is needed to provide support for WSDL? Anything? Conversion tools from existing interfaces (ejb?) to the WSDL XML schema, I suppose. I've always pictured WSDL as an XML IDL (but not 'human readable' IDL, anyone who says WSDL is more readable than IDL is nuts ;-). I guess WSDL supports a more webby definition of an interface. And its XML, which is verry verry important :p -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] URGENCY? WSDL/UDDI/ebXML
On Wed, 15 Aug 2001, marc fleury wrote: |Isn't SOAP nothing more than human readable IIOP? Or is it more? yes but not everybody lives in the we see technology for what it really is sphere. And I would like to state for the record that just because it is XML doesn't necessarily mean its human readable ;-) -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] how do i
At the end of the page: To change your subscription (set options like digest and delivery modes, get a reminder of your password, or unsubscribe from Jboss-development), enter your subscription email address: Follow the link :p -- Juha On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote: unsubscribe from this list? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mail Delivery Status Notification
I just togged nomail on him. -- Juha On Tue, 10 Jul 2001, Scott M Stark wrote: How long before this guy gets wacked from the list? - Original Message - From: Postmaster [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 10, 2001 12:22 PM Subject: [JBoss-dev] Mail Delivery Status Notification MAIL ESSENTIALS SENDER NOTIFICATION ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: J2eeGlobalScopeDeployer.java
umm... binary file? -497 lines? you sure? -- Juha On Fri, 15 Jun 2001 [EMAIL PROTECTED] wrote: User: schaefera Date: 01/06/15 22:53:38 Modified:src/main/org/jboss/deployment/scope J2eeGlobalScopeDeployer.java Log: Added the support for classes with a single string as only argument for the constructor to the ConfigurationService. Some fixes and additional methods for the JBoss management. Revision ChangesPath 1.8 +0 -497 jboss/src/main/org/jboss/deployment/scope/J2eeGlobalScopeDeployer.java Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Is Monday still a good 2.4 freeze date
We're not making a new FINAL release on Monday, it's a feature freeze for 2.4 BETA. AFAIK, Monday is still ok. -- Juha On Fri, 15 Jun 2001, Vincent Harcq wrote: Hi, IMHO, the re-deployment problem (see below) should stop you making a new release. For my part, I will test/validate the new DTD validation option as some elements are still missing from jaws.dtd (cmp-field is not defined). I will take care of dtd corrections. Vincent. [Container Management Proxy] Destroyed [Default] javax.management.InstanceAlreadyExistsException: Management:container=bank/Account [Default] at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134 ) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja va: [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388) [Default] [Default] at org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:716) [Default] [Default] at org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory.java:7 00) [Default] [Default] at org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:599) [Default] [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471) [Default] [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366) [Default] [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) [Default] [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Default] [Default] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489) [Default] [Default] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467) [Default] [Default] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211) [Default] [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [Default] [Default] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379) [Default] [Default] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217) [Default] [Default] at java.lang.Thread.run(Unknown Source) [Default] -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : vendredi 15 juin 2001 2:24 À : JBoss Dev Objet : [JBoss-dev] Is Monday still a good 2.4 freeze date Is Monday still a good 2.4 freeze date for the features that will go into the 2.4 release or is more time needed? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RabbitHole branch created
hi, why a branch? It's easier to work on the main trunk and since most development effort is going into 3.0 let's just freeze 2.4, branch the 2.4, release 2.4 BETA and fix 2.4 issues in the branch. Keep main development in the trunk. -- Juha On Mon, 11 Jun 2001, Scott M Stark wrote: I created a RabbitHole branch off of the current main line for prototyping the 3.0 generation of JBoss. You can access the branch via the command line version of cvs using: cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co -r RabbitHole jboss ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ADMIN] Test
spam warning test ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB 2.0 DTD LocalResolver
go ahead.. -- Juha On Mon, 4 Jun 2001, Vincent Harcq wrote: Hi, Does it bother anybody if I add a LocalResolver of DTD for //Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN to a local version of http://java.sun.com/dtd/ejb-jar_2_0.dtd ? Vincent. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMSContainerInvoker.java
On Fri, 1 Jun 2001, Peter Antman wrote:
You see what will happen? Yes, the client will send its messages to one
topic (no automatic creation here), and the MDB will listen on ANOTHER
topic, namely a to the system unknown destination, since it was not
correctly spelled.
What do you other guys say on the list? Hiram?
I agree with you it's not a good change. If the developer has made a
mistake in his code or forgot to add the topic he should be warned during
the deployment, instead of allowing the application to silently fail.
Also, since the created topics are persistent, this requires the developer
to go clean up the jbossmq configuration file from time to time to make
sure resources aren't wasted on topics that never meant to be there in the
first place. I think thats worse than the requirement of having to create
the topic upfront, especially since the developer may not even be aware he is
accidentally creating new topics.
So if the idea was to help the developer to avoid finding out about our
obscure configuration files, I think this change may have made the problem
even worse. Now you HAVE TO go browse them, just to fix your typos that
won't go away.
-- Juha
//Peter
On 31 Maj, [EMAIL PROTECTED] wrote:
User: thedug
Date: 01/05/31 16:53:44
Modified:src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
Log:
Add auto generation for topic/queue if topic/queue doesn't already exist.
Uses the mbean server to create a new topic/queue..
Revision ChangesPath
1.11 +54 -7
jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
Index: JMSContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JMSContainerInvoker.java 2001/05/07 19:19:57 1.10
+++ JMSContainerInvoker.java 2001/05/31 23:53:44 1.11
@@ -45,18 +45,24 @@
import org.jboss.jms.jndi.JMSProviderAdapter;
import org.jboss.jms.asf.ServerSessionPoolFactory;
+import org.exolab.jms.client.JmsServerSessionPool;
+
import org.w3c.dom.Element;
+import javax.management.MBeanServerFactory;
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+
/**
* ContainerInvoker for JMS MessageDrivenBeans, based on JRMPContainerInvoker.
* description
- *
+ *
* @see related
* @author Peter Antman ([EMAIL PROTECTED])
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];Sebastien
Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @version $Revision: 1.10 $
+ * @version $Revision: 1.11 $
*/
public class JMSContainerInvoker implements
ContainerInvoker, XmlLoadable
@@ -205,7 +211,24 @@
// Set up pool
ServerSessionPoolFactory poolFactory =
(ServerSessionPoolFactory)jbossContext.lookup(serverSessionPoolFactoryJNDI);
-
+
+ // jndiSuffix is merely the name that the user has given the MDB.
+ // since the jndi name contains the message type I have to split at the
/
+ // if there is no slash then I use the entire jndi name.
+ String jndiSuffix = ;
+ if(destinationJNDI != null){
+int indexOfSlash = destinationJNDI.indexOf(/);
+if(indexOfSlash != -1){
+ jndiSuffix = destinationJNDI.substring(indexOfSlash+1);
+}else{
+ jndiSuffix = destinationJNDI;
+}
+
+// if the jndi name from jboss.xml is null then lets use the ejbName
+}else{
+jndiSuffix = config.getEjbName();
+}
+ MBeanServer server =
(MBeanServer)MBeanServerFactory.findMBeanServer(null).iterator().next();
if (destinationType.equals(javax.jms.Topic))
{
@@ -230,7 +253,18 @@
}
// Lookup destination
-Topic topic = (Topic)context.lookup(destinationJNDI);
+ // First Try a lookup.
+ // If that lookup fails then try to contact the MBeanServer and
inoke a new...
+ // Then do lookup again..
+String topicJndi = topic/+jndiSuffix;
+Topic topic;
+try{
+ topic = (Topic)context.lookup(topicJndi);
+}catch(NamingException ne){
+ Logger.log(JndiName not found:+topicJndi + ...attempting
to recover);
+ server.invoke(new ObjectName(JMS,service,JMSServer),
newTopic, new Object[]{jndiSuffix}, new String[] {java.lang.String});
+ topic = (Topic)context.lookup(topicJndi);
+}
RE: [JBoss-dev] JMSContainerInvoker.java
On Fri, 1 Jun 2001, Ferguson, Doug wrote: It will be trial to remove the topic/queue at undeployment, if and only if I added it at deploy time ok.. We already display a message at deploytime that says that the queue/topic doesn't exist. So it isn't really correct that the server hides your fuck ups. It merely deals with them in an itelligent fashion. make it a big and ugly, the size of a stack trace. Anything else will go unnoticed. We print out too much information anyhow, one liners will drown in the noise. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ConfigurationService buggy
On Mon, 7 May 2001, marc fleury wrote: Juha, when we were in London, debugged that to work the right way so we could demo how the remote installation worked. Juju, do you have that fix in mind still? care to put it in? I think Vinay committed the fix on Saturday. Not sure all the cases you're seeing were covered (only one bytes.available() call was fixed). -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RFC: Add isolation level attribute in jboss.xml orjaws.xml?
Yes, please go ahead and implement this -- Juha On Sat, 5 May 2001, danch wrote: Does anyone have opinions on whether this would be a good feature or not? The 1.1 spec does not specify how isolation levels should be handled, except for BMT session beans, and by saying/implying that beans can call resource manager specific APIs to set it themselves (carefully). If this seems like a good idea, should this setting be in jboss.xml (and cover BMP and CMP entities as well as sessions), or in jaws.xml (covering _only_ CMP entities, since others are free to call the resource manager's APIs)? thanks, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NamingAlias: won't compile
Scott, the current CVS checkout won't compile because ServiceMBean interface is missing STARTING and STARTED variables which are required by the NamingAlias class. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS client/ssh
On Wed, 11 Apr 2001, Peter Braswell wrote: I'm using a W2K machine. I've tried jCVS (no support for ssh), winCVS (seems to support ssh, but won't work properly) and cygwin's command line CVS from within the Unix shell. Nothing seems to work. Cygwin pretty much works out of the box for me on NT4. What sort of problems were you having with it? export CVS_RSH=ssh cvs -d :ext:username@cvs.jboss.sourceforge.net:/cvsroot/jboss co jboss make changes cvs commit changedfile type in your pw press insert edit log msg in vim ESC:wq done -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
On Wed, 11 Apr 2001, [EMAIL PROTECTED] wrote: I still don't see anything wrong with type check for org.jboss.util.Service. Me neither. That should be enough to identify the mbeans adhering to the JBoss service life cycle management. Will you make this change? -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
