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] Entity and session bean
Wrong mailing list. -- Juha On Mon, 16 Jul 2001, Saint-Martin Cecile wrote: > Hi, > > I have a question about entity and session bean. ___ 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] URGENCY? WSDL/UDDI/ebXML
On Wed, 15 Aug 2001, Dan - Blue Lotus Software wrote: > Just a quick question. Is the preference to use ebXML for web services > instead of SOAP? No, ebXML uses SOAP as its transport. > The reason I ask is that I saw a technical demonstration of ebXML and the > XML-One conference in London about 5 months ago, and it looked seriously > undercooked. As in, it looked like the demo was held together by bubblegum > and duct tape. I had since written it off as the non-MS solution to compete > with SOAP It's more like a non-MS solution to the MS BizTalk servers. It is really a platform for building b2b applications that support a whole lot of features, including the transport (SOAP), messaging (sort of JMS like), registry (UDDI competes here), Business Service Interfaces (I guess competes with WSDL) also something called Collaboration Protocol Profiles and Collaboration Protocol Agreements that allows the parties to negotiate how the messages are being sent back and forth between the trading partners. They also go to some length describing how the business processes should be exposed in the ebXML registry. It is really a big big spec :) It goes beyond what the UDDI/WSDL define today. There was overlap in the transport layer before but the ebxml spec writers made the transition to SOAP, I think after SOAP 1.1 came out and addressed some of the issues they had with it. There's still overlap in the registry, UDDI and ebXML registries do have some differences in (I can't remember how fundamental on the top of my head), there's been talk about merging that too but don't know if any progress is made there. -- 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] 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] jbossmq selector parser grammer source
> > 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
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] *.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] 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 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] 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
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] 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] 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] 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] 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: > > default="jboss.security:service=JaasSecurityManager"> > SecMgr is a read-write attribute added at the metadata level > for which there is no state in the User2 instance. > > SecMgr > javax.management.ObjectName > > > 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. > > default="jboss.security:service=JaasSecurityManager"> > SecMgr is a read-write attribute added at the metadata level > for which there is no state in the User2 instance. > > SecMgr > javax.management.ObjectName > > > > > > 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] 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] 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] 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] 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] 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] 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] 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
[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.
>*
>* Persists the MBean to the file system using an Object Stream.
>* Includes code based on examples in Juha's JMX Book.
>*
>* 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");
>
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] Ant fork fails to exit
Anyone else see this problem or have a workaround for it? Using JDK1.4, running 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 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 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] 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 , 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
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.mor
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, (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 Juha 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
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 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
[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
> > xxxx
> >
> > - 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] How is Constructor Info used?
On Tue, 8 Oct 2002, Matt Munz wrote: > When I first saw XMBean XML, I assumed that 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] 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(); [execmodu
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 > > > jms/QueFactory > javax.jms.QueueConnectionFactory > ConnectionFactory > > > 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.(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.servle
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
[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
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] 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
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
[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: [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
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 > |> > |>|> name="jboss.deployment:type=DeploymentScanner,flavor=URL"> > |> > |> > |> 5000 > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> > |> |optional-attribute-name="Deployer">jboss.system:service=MainDeploye > |r |s> > |> > |> > |> > |> > |> |name="jboss.deployment:type=DeploymentSorter,order=type"/> > |> |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
[JBoss-dev] [JL] Is it time for a new enterprise solution?
Critique on JBoss configuration. http://www.javalobby.org/thread.jsp?forum=61&thread=3254 -- Juha ___ 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
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
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] 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=66&thread=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=66&thread=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: RE: [JBoss-dev] Dropping the System.out calls in the jmx code
which also means the price of the log implementation can be zero (no hard class interface references, just a jmx invocation) -- Juha On Thu, 2 May 2002, Juha-P Lindfors wrote: > > .. 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=66&thread=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] > > > http
Re: [JBoss-dev] Usage of J2EE
On Wed, 15 May 2002, Joseph Olson wrote: > I would like to incorporate a number of mobile agent, AI systems into JBOSS. > > I would like to use these Resource Manager Connection Factory References > > java:comp/env/Agent/AIKernel (AI Kernel http://aikernel.sourceforge.net/) this one is quite an interesting project > The References will be pointing to Agent Containers earlier created through MBeans >(in development). > > Are there any current or future restrictions, within JBoss, of what can go into a >J2EE platform? No. We do not and will not restrict your services in anyway. You're free to configure the JBoss server as you see fit to host your services (and in fact more and more people are doing so, as they see no value in restricting themselves strictly to the J2EE platform). -- 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: [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] 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] 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] 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] 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 Barnes&Noble http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=6AWE6O0GSL&mscssid=P8DUDFK1W30T9P49N6M7UG91HXC87KN1&isbn=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
its separate under 'jmx' for now, until it gets the build structure and all that and is integrated to jboss -- Juha On Wed, 5 Dec 2001, Luke Taylor wrote: > Date: Wed, 05 Dec 2001 18:39:08 + > From: Luke Taylor <[EMAIL PROTECTED]> > To: "Jboss-Development@Lists. Sourceforge. Net" > <[EMAIL PROTECTED]> > Subject: Re: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss > > Great. Is it included as part of jboss-all, or a separate module in CVS? > > > Luke. > > -- > Luke Taylor. Monkey Machine Ltd. > PGP Key ID: 0x57E9523Chttp://www.mkeym.com > > > > > ___ > 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 > > > > Barnes&Noble > > > >http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=6AWE6O0GSL&mscssid=P8DUDFK1W30T9P49N6M7UG91HXC87KN1&isbn=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] 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=66&thread=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] 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
[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] 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=1470&alloc_id=3638&op=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_id70&alloc_id638&op=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_id70&alloc_id638&opÌk > ___ > 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_id70&alloc_id638&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.verifier.strategy.AbstractVerifier.hasEJBCreateMethod(Class c, boolean isSession)
Hi, On Mon, 26 Mar 2001, Jung , Dr. Christoph wrote: > Browsing through the spec, I could not find a in Chapter 6 that requires > create methods to be non-final. EJB 1.1, 6.10.3 ejbCreate Methods * the method must not be declared final or static -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ANT Verifier task?
You don't need an explicit task for it, see admin/build.xml for an example http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/admin/build/build.xml?cvsroot=jboss --8<-- --8<-- -- Juha On Thu, 29 Mar 2001, marc fleury wrote: > Any news on the Task for ANT that does "verification"? > > marc > > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ > > ___ > 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] ANT Verifier task?
well.. ermm.. there's the ant documentation for the task... *cough* :) -- Juha On Thu, 29 Mar 2001, marc fleury wrote: > Oh goodness!!! it is of course well documented isn't it? > > marc > > > |-Original Message- > |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > |Sent: Thursday, March 29, 2001 2:37 AM > |To: marc fleury > |Cc: Jboss-Development@Lists. Sourceforge. Net > |Subject: Re: [JBoss-dev] ANT Verifier task? > | > | > | > |You don't need an explicit task for it, > |see admin/build.xml for an example > |http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/admin/build/build.xml > |?cvsroot=jboss > | > |--8<-- > | > | > | > | > | > | > | > |--8<-- > | > |-- Juha > | > | > |On Thu, 29 Mar 2001, marc fleury wrote: > | > |> Any news on the Task for ANT that does "verification"? > |> > |> marc > |> > |> _ > |> Marc Fleury, Ph.D > |> [EMAIL PROTECTED] > |> _ > |> > |> ___ > |> 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
Re: [JBoss-dev] Rewrite of ejb.jar, et al
On Thu, 29 Mar 2001, Jay Walters wrote: > I'm not good with names, but how > about jboss-ee, jboss-external, ee-spec or just external? Why not just drop it under contrib/ in its own submodule (api?) and then a module per API? Seems these might find some use outside the JBoss project as well. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] PATCHES
Submitting Patches -- All patches (diffs and code snippets) should be submitted through the Sourceforge Patch Tracker interface: http://sourceforge.net/tracker/?group_id=22866&atid=376687 Use the submit form on this page if you want your patch to make it into the CVS tree. Your patch will be stored, evaluated, possibly commented and then committed to the CVS. All new patch reports will be emailed to the JBoss-development list automatically for developers to take notice. Please try to give a detailed description of your patch, the symptoms and the intended behaviour so that all developers are able to test your patch and commit it. Unified diff (diff -u) is preferred, but all formats are welcome. All developers have been granted the right to make changes to patch reports. Please, if you decide to take a patch for testing and commit to cvs, assign yourself to that task so no duplicate work occurs. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] minor patch
http://sourceforge.net/tracker/?group_id=22866&atid=376687 Anything else will be discarded. -- Juha On Wed, 4 Apr 2001, Samuel Niles Peretz wrote: > org/jboss/logging/Log.java: > > Changed use of deprecated DataInputStream.readLine method to use preferred > BufferedReader.readLine instead in debug(Throwable) and exception(Throwable) methods > as recommended in the java API docs (see > http://java.sun.com/j2se/1.3/docs/api/java/io/DataInputStream.html#readLine() ). > > Here is the diff, with the new version of the file first. Note that the only 2 > lines that have changed are lines 145 and 162. > > bash-2.02$ diff -bB org/jboss/logging/log.java /tmp/saved/log.java > 145c145 > < BufferedReader din = new BufferedReader(new InputStreamReader(new > ByteArrayInputStream(baos.toByteArray(; > --- > > DataInputStream din = new DataInputStream(new > ByteArrayInputStream(baos.toByteArray())); > 162c162 > < BufferedReader din = new BufferedReader(new InputStreamReader(new > ByteArrayInputStream(baos.toByteArray(; > --- > > DataInputStream din = new DataInputStream(new > ByteArrayInputStream(baos.toByteArray())); > bash-2.02$ > > > > ___ > 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
