RE: [JBoss-dev] Deployment directory for singleton services

2004-03-18 Thread Juha-P Lindfors

couldn't the deployer just pick up a tag from the descriptor -- rather
than add yet another deployment directory?

On Thu, 18 Mar 2004, Adrian Brock wrote:

 On Wed, 2004-03-17 at 10:37, Dimitris Andreadis wrote:
  How about having a sub-directory farm/singleton instead?
 

 They serve different orthogonal purposes.
 farm - is for applications deployed across a cluster
 deploy-hasingleton - is for applications that should only be run on
 one server at a time.

 I can see a case for the deploy-hasingleton directory getting
 replicated across the cluster. But the deployment will still only
 be active on one server in the cluster.

 Regards,
 Adrian

  I guess is a little bit more difficult to implement, having the farm watcher 
  ignore this particular dir, but it looks more intuitive to me.
 
  /Dimitris
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivelin Ivanov
  Sent: , 15  2004 2:47 
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] Deployment directory for singleton services
 
 
 
  In 3.2.4 under config server/all there is going to be another deployment
  directory, parallel to deploy and farm, which will host services that are
  deployed on exactly one node in the cluster.
 
  The tentative name is deploy-hasingleton. A service under deploy declared
  in deploy-hasingleton-service.xml will deploy the directory in question.
 
  JMS is the first service that will take advantage of this new directory.
 
  My question is how should we name the directory and what other services are
  good candidates for it?
 
  Cheers,
 
  Ivelin
 
 
 
  ---
  This SF.Net email is sponsored by: IBM Linux Tutorials
  Free Linux tutorial presented by Daniel Robbins, President and CEO of
  GenToo technologies. Learn everything from fundamentals to system
  administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
  ___
  JBoss-Development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
  ---
  This SF.Net email is sponsored by: IBM Linux Tutorials
  Free Linux tutorial presented by Daniel Robbins, President and CEO of
  GenToo technologies. Learn everything from fundamentals to system
  administration.http://ads.osdn.com/?ad_id70alloc_id638op=click
  ___
  JBoss-Development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 --
 
 Adrian Brock
 Director of Support
 Back Office
 JBoss Inc.
 



 ---
 This SF.Net email is sponsored by: IBM Linux Tutorials
 Free Linux tutorial presented by Daniel Robbins, President and CEO of
 GenToo technologies. Learn everything from fundamentals to system
 administration.http://ads.osdn.com/?ad_id70alloc_id638opk
 ___
 JBoss-Development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



--
Juha Lindfors
Director of Training
http://www.jboss.com


---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70alloc_id638op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] lock errors on commit attempts

2003-06-20 Thread Juha-P Lindfors

Definitely had password problems today. For a moment I thought I had
forgotten mine or simply cannot type anymore..

-- Juha

On Fri, 20 Jun 2003, Adrian Brock wrote:

 Hi Scott,

 I've been seeing the same errors
 and it was not accepting my password sometimes.

 I was just persistent.

 Regards,
 Adrian

 
 Adrian Brock
 Director of Support
 Back Office
 JBoss Group, LLC
 


  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On
  Behalf Of Scott M Stark
  Sent: 20 June 2003 05:59
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] lock errors on commit attempts
 
 
  Everytime I try to do a commit I'm seeing a failure like the
  following:
 
  cvs server: failed to create lock directory for
  `/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins'
  (/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/#c
  vs.lock):
  Permission denied
  cvs server: lock failed - giving up
  cvs [server aborted]: lock failed - giving up
  cvs commit: saving log message in /tmp/cvsIiqHry
 
  I saw Adrian check in some files recently. Is anyone else
  seeing this error?
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
 
 
  ---
  This SF.Net email is sponsored by: INetU
  Attention Web Developers  Consultants: Become An INetU
  Hosting Partner.
  Refer Dedicated Servers. We Manage Them. You Get 10% Monthly
  Commission!
  INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 





 ---
 This SF.Net email is sponsored by: INetU
 Attention Web Developers  Consultants: Become An INetU Hosting Partner.
 Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
 INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development





---
This SF.Net email is sponsored by: INetU
Attention Web Developers  Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Oswego util.concurrent jar updated

2003-04-03 Thread Juha-P Lindfors

by the time they're through JSR..?

On Thu, 3 Apr 2003, Nathan Phelps wrote:

 Any chance they'll ever update the package name to get rid of the
 capital EDU... drives me crazy.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 Scott M Stark
 Sent: Thursday, April 03, 2003 4:02 PM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] Oswego util.concurrent jar updated

 I updated the Oswego util.concurrent jar in 3.0+ from the rather ancient
 1.3.0
 version to 1.3.2 as we found some serious concurrency failures in the
 ConcurrentHashMap and ConcurrentReaderHashMap classes in looking into
 some JMS load test failures. A bit ironic that the concurrent package
 was messing
 up concurrency.

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 


---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] jboss web-site issues

2003-03-31 Thread Juha-P Lindfors

works with 1.2.1 + w2k too

  The 1.3 release of Mozilla is not showing this issue.
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
  - Original Message -
  From: Anatoly Akkerman [EMAIL PROTECTED]
  To: JBoss-Dev [EMAIL PROTECTED]
  Sent: Monday, March 31, 2003 12:22 PM
  Subject: [JBoss-dev] jboss web-site issues
 
 
   Hello, guys
  
   Since the website was switched to Nukes, Mozilla 1.2 on Win2K
   consistently pops up connection refused. IE6 works fine.
  Any ideas what
   is wrong?
  
   -- Anatoly.


---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] XMBean and transient attributes

2003-03-29 Thread Juha-P Lindfors

it should set the value to -1 in the MBeanAttributeInfo descriptor if no
getMethod fields are specified

 // if no method mapping, enable caching automatically
 if (getMethod == null  currTimeLimit ==
null)
descr.setField(CURRENCY_TIME_LIMIT, -1);

-- Juha


On Sat, 29 Mar 2003, Scott M Stark wrote:

 I'm working on updating the xmbean tests in 3.2 to make sure what we will
 have in the 3.2.0 release is usable and there is an issue with transient attributes
 and the default value for currencyTimeLimit. An attribute element like:

attribute access=read-write 
 default=jboss.security:service=JaasSecurityManager
   descriptionSecMgr is a read-write attribute added at the metadata level
  for which there is no state in the User2 instance.
   /description
   nameSecMgr/name
   typejavax.management.ObjectName/type
/attribute

 where there is no currencyTimeLimit defined fails to have a value for this attribute,
 and a value cannot be set. Given that it has a default value this does not seem like
 valid behavior. If the currencyTimeLimit set to -1 then the default value is seen
 as the initial value for the attribute and it may be updated.

attribute access=read-write 
 default=jboss.security:service=JaasSecurityManager
   descriptionSecMgr is a read-write attribute added at the metadata level
  for which there is no state in the User2 instance.
   /description
   nameSecMgr/name
   typejavax.management.ObjectName/type
   descriptors
  currencyTimeLimit value=-1/
   /descriptors
/attribute

 The question is why should a failure to specify the attribute descriptors result in
 an unusable attribute? Either the caching logic is faulty or the implicit settings 
 for
 the attribute descriptors a not correct.




 ---
 This SF.net email is sponsored by:
 The Definitive IT and Networking Event. Be There!
 NetWorld+Interop Las Vegas 2003 -- Register today!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Regarding JBoss site

2003-03-27 Thread Juha-P Lindfors

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

2003-03-27 Thread Juha-P Lindfors

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

2003-03-27 Thread Juha-P Lindfors
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

2003-03-27 Thread Juha-P Lindfors

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

2003-03-27 Thread Juha-P Lindfors

convert the main page text box titles  to use same style as in menu and
side bars.


On Thu, 27 Mar 2003, marc fleury wrote:

 OK fine, be specific on where you would put them,

 marcf

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On
  Behalf Of Juha-P Lindfors
  Sent: Thursday, March 27, 2003 12:09 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] Regarding JBoss site
 
 
 
  no I am saying rethink how you lay them out -- having them
  appear all over the place (top, bottom, several on both
  sides) like they are now doesn't look very good.
 
  its a layout issue, it sucks
 


---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Is JDK 1.4 required to build

2003-03-06 Thread Juha-P Lindfors

There's no requirement from JMX to use 1.4 yet.
(excluding JSR160/Remoting)

On Thu, 6 Mar 2003, Scott M Stark wrote:

 Originally I said I thought we needed to keep 4.0 buildable by JDK 1.3,
 but I'm starting to think otherwise. I'm about to give in to this demand.
 If users cannot switch to JDK 1.4 then I'm willing to say they cannot
 make use of the full set of features in 4.0. The remaining question I had
 was can the core services remain binary compatible with JDK 1.3,
 meaning JMX, AOP, deployers, etc. required to have a highly functional
 microkernel for building on top of.

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 

 - Original Message -
 From: Dain Sundstrom [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Thursday, March 06, 2003 9:59 AM
 Subject: [JBoss-dev] Is JDK 1.4 required to build


  Is JDK 1.4 now required to build?  If not when are we going to add this
  requirement?
 
  I need an IdentityHashMap for the ObjectCopier and would like to
  encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of
  speed) and for JDK 1.3 I will just is an IdentityKey wrapper.  This
  code will be way easier to write if I can assume that we are compiling
  in 1.4.
 
  For now I will just write the 1.3 version.
 
  -dain



 ---
 This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
 for complex code. Debugging C/C++ programs can leave you feeling lost and
 disoriented. TotalView can help you find your way. Available on major UNIX
 and Linux platforms. Try it free. www.etnus.com
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Proposal for jboss-wide interceptor framework

2003-03-03 Thread Juha-P Lindfors
On Mon, 3 Mar 2003, Bill Burke wrote:
 
  1. Source located in neutral territory, namely the common module.

ok

 
  2. Sequence of interceptors determined by (iterator in) invocation object.

This could be a modifiable iterator at some point. This allows the
interceptor stack to be modified per invocation at runtime if necessary
depending on logic in previous interceptor. This type of functionality
would call for an authenticated invocation from the client. An example
where I want to collect stats from the service I'm invoking. I don't need
the relevant interceptors to exist for any other than one or few specific
invocations.


3. Construction of interceptors through interceptor factories.  

ok

  4. Storing interceptor specific metadata in the invocation factory (e.g.
  for ejbs, this is the currently the Container).  This makes it easy to
  write stateless interceptors.

Are statless interceptors shared between components or per component.
There's experimental system wide shared interceptors in the mx base if
that type of functionality appeals to anyone.


 Metadata should be in 2 places.  The class or invocation factory, and
 the actual instance.

  5. multiple interceptor chains per InvocationFactory, e.g.  each method
  gets a separate interceptor chain. (Idea from current mbean interceptor
  implementation)
 

 Do we really need per method interceptor chains?  We did not need them to
 implement EJBs.

It makes some interceptors less complex to implement. It makes sense at
service interception where we may have a separation between
attributes/operations. Say I want to persist 2 out of 3 attributes I'm
changing. Operations don't need the persistence interceptor, nor do all
the attributes. I find it more intuitive to config separate stacks rather
than building one stack with everything in it and then start filtering per
method.

  6. Ability to replace the interceptor interator.  This is not directly
  supported now but is essentially what happens when an invocation goes from
  the client interceptor stack to the invoker interceptor stack.  (Currently
  the only example of an invoker interceptor stack is the trunk invoker.)
 

 Not sure what you mean by replacement.  Do you mean hot-deploy of new
 interceptors?  I have this now in AOP framework for POJOs.

I understood it as modification of the stack per invocation if necessary..

-- Juha



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] MBeanProxy with JBoss Remoting

2003-02-19 Thread Juha-P Lindfors

yes

On Wed, 19 Feb 2003, Anatoly Akkerman wrote:

 Hi,

 I don't know if this is obvious and I am treading old ground or makes
 sense or not, but given that JMX remoting already works, if one creates
 a Java proxy to an MBean via MBeanProxy and that Proxy instance gets
 shipped through the Remoting infrastructure, wouldn't it make sense to
 make the JMXInvocationHandler to push invocations on this proxy to the
 original MBean through the Remoting pipe that it arrived through? This
 would be useful if an invocation on an MBean returns such a proxy object
 (say, this MBean is a Factory MBean for other MBeans but clients prefer
 typed invocation on the factory) and now you want to invoke this factory
 MBean remotely and still get meaningful objects back.

 -- Anatoly



---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] File Persistence and Crash

2002-12-10 Thread Juha-P Lindfors

FD.sync() all your writes... ?


On Mon, 9 Dec 2002, Andy wrote:

 Does someone know how to implement a file based persistence that
 does not become corrupted except maybe when the file is written
 during a crash.




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] Problem compiling 3.2 beta testsuite

2002-11-10 Thread Juha-P Lindfors

Can't get 3.2 testsuite to compile due to the errors below

compile-classes-only:
[javac] Compiling 932 source files to
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\classes
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jca\ejb\LocalWrapperCleanupTestSessi
onBean.java:23: cannot resolve symbol
[execmodules] symbol  : class LocalConnection
[execmodules] location: package local
[execmodules] import
org.jboss.resource.adapter.jdbc.local.LocalConnection;
[execmodules]  ^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle
anupTestSessionHome.java:16: cannot resolve symbol
[execmodules] symbol  : class LocalConnection
[execmodules] location: package local
[execmodules] import
org.jboss.resource.adapter.jdbc.local.LocalConnection;
[execmodules]  ^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle
anupTestSession.java:16: cannot resolve symbol
[execmodules] symbol  : class LocalConnection
[execmodules] location: package local
[execmodules] import
org.jboss.resource.adapter.jdbc.local.LocalConnection;
[execmodules]  ^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ClientFailTest.java:1
13: warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t.stop();
[execmodules]   ^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest
.java:77: warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t1.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest
.java:121: warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t2.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest
.java:143: warning: stop() in java.lang.Thread has been deprecated
[execmodules]   t1.stop();
[execmodules] ^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest
.java:161: warning: stop() in java.lang.Thread has been deprecated
[execmodules]   t1.stop();
[execmodules] ^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ExceptionListenerTest
.java:63: warning: stop() in java.lang.Thread has been deprecated
[execmodules]   t1.stop();
[execmodules] ^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:75:
warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t1.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:129:
 warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t1.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:133:
 warning: stop() in java.lang.Thread has been deprecated
[execmodules]  tf.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr
ibers.java:111: warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t1.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr
ibers.java:113: warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t2.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr
ibers.java:168: warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t1.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr
ibers.java:170: warning: stop() in java.lang.Thread has been deprecated
[execmodules]  t2.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:74:
wa
rning: stop() in java.lang.Thread has been deprecated
[execmodules]  t1.stop();
[execmodules]^
[execmodules]
C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:116:
w
arning: stop() in java.lang.Thread has been deprecated
[execmodules]  t2.stop();

Re: [JBoss-dev] How is Constructor Info used?

2002-10-08 Thread Juha-P Lindfors

On Tue, 8 Oct 2002, Matt Munz wrote:

   When I first saw XMBean XML, I assumed that constructor/ referred to the
 constructor for the resource (model object).  On a closer look, it appears
 that this information (ModelMBeanConstructorInfo) refers only to the
 constructor for the MB itself.

it is not clearly defined which it should refer to in case of MMB. It
might be better defined in JMX 1.2 version of the spec.

   Is this information being used in any way in the server?

no, as far as I know

 What purpose is it intended to serve?

not sure

-- Juha




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] Build testsuite

2002-10-05 Thread Juha-P Lindfors


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

2002-10-05 Thread Juha-P Lindfors


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

2002-10-05 Thread Juha-P Lindfors


although I'm not having much success running 'tests-unit' on HEAD... I
seem to get a few infinite loops from log4j that eventually die to stack
overflows and a test success rate of only about 44%

anyone else having better luck with it?


 On Sat, 5 Oct 2002,
Juha-P Lindfors wrote:


 cool, thanks

 On Sat, 5 Oct 2002, Scott M Stark wrote:

  Its fixed now.
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
  - Original Message -
  From: Juha-P Lindfors [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Saturday, October 05, 2002 8:24 AM
  Subject: [JBoss-dev] Build testsuite
 
 
  
   does the testsuite work yet or is this still work in progress?
  
   I can't get it to run from either /build or /testsuite
  
   $ ./build.bat run-basic-testsuite
   Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger
   run-basic-testsu
   ite
   Buildfile: build.xml
  
   _buildmagic:init:
   Trying to override old definition of task property
  
   configure-project:
[echo] groups:  default
[echo] modules:
   jmx,common,system,j2ee,naming,management,transaction,server,blocks,co
   nsole,security,messaging,connector,varia,cluster,jetty,jboss.net,iiop
  
   run-basic-testsuite:
   [execmodules] Missing build file; skipping module: testsuite
  
   BUILD SUCCESSFUL
   Total time: 2 seconds
   Press any key to continue . . .
  
  
   $ ./build.bat tests-unit
   Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger
   tests-unit
   Buildfile: build.xml
  
   _buildmagic:init:
   Trying to override old definition of task property
[copy] Copying 1 file to
   D:\test\jboss-all\testsuite\output\gen\classes\org\jboss\tes
   t\cts\interfaces
  
  
   [ BIG SNIP ]
  
   UnitTestCase.java:285: warning: setPriority(org.apache.log4j.Priority) in
   org.apache.log4j
   .Category has been deprecated
   [javac]   root.setPriority(XLevel.TRACE);
   [javac]   ^
   [javac]
   D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\SRPUnitTestC
   ase.java:112: cannot resolve symbol
   [javac] symbol  : method getResourceURL  (java.lang.String)
   [javac] location: class org.jboss.test.JBossTestSetup
   [javac] String authConfPath =
   super.getResourceURL(security-srp/auth.conf
   );
   [javac]^
   [javac]
   D:\test\jboss-all\testsuite\src\main\org\jboss\test\security\test\XMLLoginModu
   lesUnitTestCase.java:41: warning: setPriority(org.apache.log4j.Priority)
   in org.apache.log
   4j.Category has been deprecated
   [javac]   root.setPriority(XLevel.TRACE);
   [javac]   ^
   [javac] 1 error
   [javac] 43 warnings
  
   BUILD FAILED
   file:d:/test/jboss-all/testsuite/../tools/etc/buildfragments/targets.ent:45:
   Compile faile
   d; see the compiler error output for details.
  
   Total time: 58 seconds
   Press any key to continue . . .
 
 
 
  ---
  This sf.net email is sponsored by:ThinkGeek
  Welcome to geek heaven.
  http://thinkgeek.com/sf
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 

 --
 Juha Lindfors
 Author of JMX: Managing J2EE with Java Management Extensions





 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] creating persistent MBeans dynamically

2002-10-04 Thread Juha-P Lindfors

On Fri, 4 Oct 2002, Sacha Labourey wrote:

 Hello,

 And what about deployment order?

wouldn't the order be explicit if the registry stores a script-like file
of its changes and then reads it at startup?

similar to how a db constructs itself from a tx log

-- Juha




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] creating persistent MBeans dynamically

2002-10-03 Thread Juha-P Lindfors

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?

2002-10-03 Thread Juha-P Lindfors


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

2002-10-03 Thread Juha-P Lindfors

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

2002-10-03 Thread Juha-P Lindfors

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

2002-10-02 Thread Juha-P Lindfors

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

2002-10-02 Thread Juha-P Lindfors

On Wed, 2 Oct 2002, Matt Munz wrote:

   Perhaps we're using 'persist' differently.  The mbean registry contains
 object references to all of the mbeans in the server.To me, persisting
 the registry (or a part of it), means serializing those objects completely
 (MB info + data).

no, the individual mbeans already persisted their state they need on their
own, what you need to persist from the registry is the information to
recreate the mbeans (who will then go an load() their own state they
already persisted), ie which constructor to use at startup, what args go
into the constructor

   As I understand it, MBs that want to persist their state must implement
 the PersistentMBean interface.  If the state for all MBs in the server is
 also to be persisted, then I suppose that all MBs registered must be adapted
 to the PersistentMBean interface.  Does this sound reasonable?

I think you're confusing the two different modes of persistence:

say I registered an XMbean instance from location http://foo/bar.xml
(which is my mbean definition). When you register this mbean to the
registry you pass in the valueMap that info, init(URL) was used with arg
http://foo/bar.xml + objectname blah. Registry stores this info as part of
its own state.

When registry is recreated (server restart) it goes to its own persistence
location and gets this info, calls the constructor, creates the new mbean
instance, bar.xml has the persistence info for the mbean and the bean will
load() its own state.


   I tried to scan the spec for some guidance, but was unable to find
 portions relating to persistence or lifecycle issues that would be relevant
 here.  Incidentally, it appears to indicate that the entire MMB (MMB info
 and data) should be persisted at store().

no, just the state of the attributes (or diff update on one changed
attribute, actually)... imagine an ON_UPDATE policy
writing the whole metadata down to storage every time, doesn't make sense.

   It would definately be more convienient if some of these issues were
 addressed in the spec, IMHO.  It seems to me that this whole discussion is a
 logical extension of MMB persistence in the first place, and that MB
 developers are going to want to know that their beans will be treated
 similarly across implementations when it comes to the server lifecycle 
 persistence.  Does anyone coughJuha/cough know if this is likely?

there doesn't seem to be much interest in that at the moment

on the other hand it gives us the freedom to write implementations that
make sense

-- Juha




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] creating persistent MBeans dynamically

2002-10-01 Thread Juha-P Lindfors


do you have operation info for the operation names you are mapping to
(setId  getId)?


On Tue, 1 Oct 2002, Matt Munz wrote:

 Juha  Group,

  make sure you add the getMethod and setMethod mapping to your MMB
  attributes.

 Thanks.  I did this and started re-reading your JMX book.  I now have a new
 error :)

 Below, I include my MBean Info generation code, and some error output.  When
 I try to view the jmx-console page for my new MBean, the servlet tries to
 get all of the bean's attributes.  The attribute getId is requested, but
 this information is stored by the name Id.  I assume that there is
 something wrong with my MBean info, but I can't figure out what it is.
 Error  debug output are listed below.  Any help would be appreciated.

   - Matt

 ### metadata generation

   public ModelMBeanInfo getModelMBeanInfo()
   {
 final boolean READABLE = true;
 final boolean WRITABLE = true;
 final boolean BOOLEAN = true;
 // build 'Id' read-write attribute
 Descriptor descr1 = new DescriptorSupport();
 descr1.setField(name, Id);
 descr1.setField(descriptorType, attribute);
 descr1.setField(displayName, Identification);
 descr1.setField(setMethod, setId);
 descr1.setField(getMethod, getId);
 ModelMBeanAttributeInfo idAttrInfo;
 idAttrInfo = new ModelMBeanAttributeInfo(Id,
  String.class.getName(),
  Identification.,
  READABLE,
  WRITABLE,
  !BOOLEAN,
  descr1);
 // MBean descriptor
 Descriptor descr4 = new DescriptorSupport();
 descr4.setField(name, Widget);
 descr4.setField(descriptorType, mbean); // was MBean
 // create ModelMBeanInfo
 ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
 idAttrInfo };
 ModelMBeanOperationInfo[] operationInfo = new ModelMBeanOperationInfo[]
 {};
 ModelMBeanInfo info = new
 ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
 Widget,
 attrInfo,
 null,
 operationInfo,
 null,
 descr4);
 return info;
   }

 ### AttributeOperationREsolver constructor

 11:33:33,020 INFO  [STDOUT] !!!m attributes[0]:
 ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
 or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
 on,getMethod=getId)]

 ### AttributeOperationREsolver.store()

 11:33:33,020 INFO  [STDOUT] !!!m storing attrName: Id and code: 0

 ### AttributeOperationREsolver.lookup()

 11:34:06,141 INFO  [STDOUT] !!!m looking up actionName: getId and signature:
 [Ljava.lang.String;@1c87031

 ### error

 java.lang.NoSuchMethodException: Unable to locate method for: getId()
 at
 org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
 cher.java:300)
 at
 org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
 terceptor.java:66)
 at
 org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
 rceptor.java:54)
 at
 org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
 r.java:91)
 at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
 at
 org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
 rceptor.java:129)
 at
 org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
 r.java:99)
 at
 org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
 at
 javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
 an.java:147)
 at
 org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
 at
 org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
 :125)
 at
 org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
 at
 org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
 02)
 at
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362)
 at
 org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
 

Re: [JBoss-dev] creating persistent MBeans dynamically

2002-09-27 Thread Juha-P Lindfors


make the mbean registry persistent (it's already an mbean) triggering
store() on registerMBean() calls, and have your widget factory register
mbeans using the registry mbean operation registerMBean(Object,
ObjectName, Map) where you pass in the valueMap the additional info to
store for recreating the mbeans (constructor signature, args, other config
info). At registry load() read and recreate mbeans, and then mbeans each
load() their state.

-- Juha


 On Fri, 27 Sep 2002, Matt Munz wrote:

 Hi all,

   I have two questions here, a specific one relating to the subject, and a
 more general question pertaining to the larger problem that I'm trying to
 solve.

   First off, what is the best way to create new MBeans while the server is
 running, in a persistent fashion?  Say, for example, I have a class Widget,
 and a class WidgetFactory.  Suppose I create a WidgetFactoryMBean that has a
 method

 createNewWidget(String mbeanName, Object[] widgetFeatures);

   that has the purpose of creating a new instance of Widget, wrapping it in
 a ModelMBean with the name mbeanName, and adding that mbean to the server.

   If I use the mbean server API for this, then the new MBean is loaded in
 the VM, but dissapears on server restart.

   One solution for this, I imagine, would be, instead of using the mbean
 server API, to actually write a *-service.xml file to the deploy folder each
 time createNewWidget() is called.  Another solution might be to maintain
 references to the widgets in the widget factory, and serialize and load them
 through it. There are likely many more solutions.

   Have any of you tried something like this before? Is there code that does
 this in the JBoss source tree?

   Now for the more general question...

   What I am trying to do is to allow dynamic generation of persistent
 objects in the server.  These objects need to be exposed as web services,
 and have access to databases, other web services, and JMS topics.  As
 instances of the same class, all of these ojects will have the same
 interface, yet will have different state, and need to expose this through
 the web service protocol.  Once I have created these instances, I don't want
 them to go away unless I specifically remove them.  If I restart the server,
 they should show up again (technically different instances with identical
 state).

   Ultimately, all I want to do is to say create a widget named foo via web
 services, restart the server, say tell me something about the widget named
 foo via web services, and get a response.

   I know that there are many ways to skin a cat.  Is there a better way
 here?  Would EJB or some other structure make more sense?  I am generally
 trying to stay away from EJB for the moment to avoid the overhead of RMI (I
 don't need distributed objects), but I am open to any solution that makes
 sense.

   - Matt







 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] Ant java fork fails to exit

2002-09-22 Thread Juha-P Lindfors


Anyone else see this problem or have a workaround for it?

Using JDK1.4, running java task with fork=true fails to exit the VM
sometimes (more often than not). ie the execution hangs forever waiting.

Ant version is whatever we're using.

-- Juha





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Ant java fork fails to exit

2002-09-22 Thread Juha-P Lindfors


nevermind..

On Sun, 22 Sep 2002, Juha-P Lindfors wrote:


 Anyone else see this problem or have a workaround for it?

 Using JDK1.4, running java task with fork=true fails to exit the VM
 sometimes (more often than not). ie the execution hangs forever waiting.

 Ant version is whatever we're using.

 -- Juha



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Build System... any ideas

2002-09-19 Thread Juha-P Lindfors


jbossmx already has its own module specific test suite rather than
integrating with the jboss testsuite module so I would welcome the change
jason suggests where jboss testsuite integrates tests from individual modules if
they exist

-- Juha

 On Thu, 19 Sep 2002, David Jencks wrote:

 They'd probably solve the problem of 7 minutes to build to run a single
 test that I experience.

 Moving stuff to module specific test dirs would be a lot of work.  I wonder
 if instead we could make dir-specific generic build targets -- something
 like in ${test.module} run xdoclet, compile all classes, then run jar for
 ${test.module}, then run tests in that module also.  Sort of like test
 but limiting the xdoclet and jar tasks also.

 The build file is getting so large this might help make it more
 comprehensible also.

 david jencks

 On 2002.09.19 17:36:29 -0400 Scott M Stark wrote:
 
  I don't really see how module local tests are any improvement over the
  test and
  one-test targets in the existing testsuite module. In some ways it is a
  problem
  because now you have additional dependencies to build and run the tests
  in
  the module.
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
  - Original Message -
  From: Jason Dillon [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Wednesday, September 18, 2002 10:29 PM
  Subject: RE: [JBoss-dev] Build System... any ideas
 
 
   David and I talked about this on the way back from Tahoe.  I would like
   to revisit the entire TestSuite, putting a testsuite in each module,
   which would perform Unit tests for components and parts of components
   for that module alone.  Then the jboss/testsuite would be an
  integration
   testsuite.
  
   This way, if you are working on bits from the cluster module, you can
   write simple tests to validate your component and run the tests
  quickly.
   Then when you are satisfied, you can write an integration test, which
   would actual test a real component inside of a JBoss instance.
  
   This will get us more coverage, but will also encourage developers to
   make smaller, simpler tests for stuff and make it more likely they will
   run them, as it won't take forever.
  
   Also, on the subject of build systems and testsuites, I have been
  toying
   with the idea of allow Java and Jython tests to be run together.  Using
   Jython it will be faster to throw together small and functional tests
   with much less code and a lot less trouble.  We would still need Java
   tests to run stuff that is type dependant, but the two could live
   together happy.
  
   The build system overhaul is a dependency of this I believe.
  
   I have been planning on doing all of the above... just I haven't had
  the
   time to make any progress.  Also I really want to finish the basic
   command line console framework.
  
   Fuck, I need my boss to stop making me work on their lame ass projects.
   Who cares about that shit really... bah!
  
   --jason
  
 
 
  ---
  This sf.net email is sponsored by:ThinkGeek
  Welcome to geek heaven.
  http://thinkgeek.com/sf
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 


 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] RE: [jboss-cvs] jmx/src/main/org/jboss/mx/persistenceObjectStreamPersistenceManager.java OsPersistMgr.java

2002-09-17 Thread Juha-P Lindfors


I use jEdit 4.0 final with the latest JavaStyle plugin from the plugin
central. Seems to work (and the JavaStyle plugin has gone a long way since
the last version I used).

I entered the parameters in the plugin GUI by hand. I assume it stores the
config somewhere I'll check if I can find the file, can email it to you.

Donät know about ANT integration, there was some work on it once but I
think it might have been dropped.

-- Juha

On Tue, 17 Sep 2002, Matt Munz wrote:



 Juha  group,

   I figured I missed a few i's and t's in there...

   Is this the JavaStyle plugin for JEdit?  I can't seem to get it to work at
 the moment.  But assuming I do, is there profile / rule-set for the jboss
 coding conventions I can import, or do I need to enter them in by hand?  Are
 there similar profiles available for any of the other source code formatters
 out there?

   I've been thinking about using a formatter, especially one that I can
 integrate into my build processes (ANT), and optionally Eclipse -- I'd
 appreciate any pointers.

   - Matt

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Juha
 Lindfors
 Sent: Tuesday, September 17, 2002 1:25 PM
 To: [EMAIL PROTECTED]
 Subject: [jboss-cvs] jmx/src/main/org/jboss/mx/persistence
 ObjectStreamPersistenceManager.java OsPersistMgr.java


   User: juhalindfors
   Date: 02/09/17 10:25:19

   Added:   src/main/org/jboss/mx/persistence
 ObjectStreamPersistenceManager.java
   Removed: src/main/org/jboss/mx/persistence OsPersistMgr.java
   Log:
   OsPersistMgr renamed to ObjectStreamPersistenceManager

   Code run through JavaStyle to enforce JBoss coding style.

   Revision  ChangesPath
   1.1
 jmx/src/main/org/jboss/mx/persistence/ObjectStreamPersistenceManager.java

   Index: ObjectStreamPersistenceManager.java
   ===
   package org.jboss.mx.persistence;

   import java.io.File;
   import java.io.FileInputStream;
   import java.io.FileOutputStream;
   import java.io.IOException;
   import java.io.ObjectInputStream;
   import java.io.ObjectOutputStream;
   import javax.management.Attribute;
   import javax.management.AttributeList;
   import javax.management.Descriptor;
   import javax.management.MBeanAttributeInfo;
   import javax.management.MBeanException;
   import javax.management.MBeanInfo;
   import javax.management.modelmbean.ModelMBeanAttributeInfo;
   import javax.management.modelmbean.ModelMBeanInfo;
   import javax.management.modelmbean.ModelMBeanInfoSupport;
   import org.apache.log4j.Logger;
   import org.jboss.mx.modelmbean.ModelMBeanConstants;
   import org.jboss.mx.modelmbean.ModelMBeanInvoker;
   import org.jboss.mx.persistence.PersistenceManager;

   /**
* Object Stream Persistence Manager. p
*
* Persists the MBean to the file system using an Object Stream.
* Includes code based on examples in Juha's JMX Book. p
*
* Object Streams written to disk are admittedly lacking in the area of
 long-term, portable,
* or human-readable persistence.  They are fairly straightforward,
 however.
* Primarily, this class is useful for demonstration and quick  dirty
 persistence.
*
* @todo  currently metadata as well as data is stored.  only data
 needs to be stored.
* @authorMatt Munz
*/
   public class ObjectStreamPersistenceManager
   extends Object
   implements PersistenceManager
   {
  protected boolean fIsLoading;
  protected Logger fLogger;


  // Constructors --

  public ObjectStreamPersistenceManager()
  {
 super();
  }


  // Public 

  /**
   * deserializes state from the object input stream
   *
   * @param  mbean
   * @param  metadata
   * @exception  MBeanException
   */
  public void load(ModelMBeanInvoker mbean, MBeanInfo metadata) throws
 MBeanException
  {
 logger().debug(FilePersist.load;  metadata:  + metadata);
 // based on jmx book
 if (metadata == null)
 {
return;
 }
 Descriptor d = ((ModelMBeanInfo)metadata).getMBeanDescriptor();
 String dir =
 (String)d.getFieldValue(ModelMBeanConstants.PERSIST_LOCATION);
 String file =
 (String)d.getFieldValue(ModelMBeanConstants.PERSIST_NAME);
 if (file == null)
 {
return;
 }
 try
 {
File f = new File(dir, file);
FileInputStream fis = new FileInputStream(f);
ObjectInputStream ois = new ObjectInputStream(fis);
metadata = (ModelMBeanInfoSupport)ois.readObject();
logger().info(metadata deserialized);
loadFromMetadata(mbean, (ModelMBeanInfo)metadata);
 }
 catch (Exception e)
 {
logger().error(Error 

Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans

2002-08-10 Thread Juha-P Lindfors

On Sat, 10 Aug 2002, Scott M Stark wrote:

  This probably breaks the MLet processing. But then I think it
  was already broken, MLets are URLClassLoaders not UCLs.

actually we detect ULR in the mlet code and register one UCL per URL in
case ULR is used...

-- Juha



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] code submission

2002-07-17 Thread Juha-P Lindfors


diff posted to SF tracker

or you can ask marcf for rw if you feel like fixing more bugs

-- Juha

On Wed, 17 Jul 2002, Seth Sites wrote:

 I have a patch for bug [ 564890 ] JMS recover/redelivery errors that I
 have tested and am ready to submit for review.  I just have a few questions.

 1) What is the best way to submit code patches for bugs.  Is diff output
 preferred or just include the entire method that is changed?

 2) Is it best to submit the code through the sourceforge interface at the
 bug report, or just email it to the dev list?

 Thanks,
 Seth


 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Tel: +358 40 8656 751 (GSM)




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Viewing mbean operation results

2002-06-27 Thread Juha-P Lindfors

On Thu, 27 Jun 2002, Scott M Stark wrote:

 I thought 'presentationString' only applied to model mbeans. How
 can we integrate the presentation metadata into the existing standard
 and dynamic mbeans?

You can't, as neither one defines a way to extend the metadata.

-- Juha




---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] JMX: Adding Model MBean database persistence

2002-06-26 Thread Juha-P Lindfors

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

2002-06-26 Thread Juha-P Lindfors

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

2002-06-26 Thread Juha-P Lindfors

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

2002-06-26 Thread Juha-P Lindfors


yes, see the 'presentationString' descriptor field in the spec

that's where I'd put the model, then have your console render the view

-- Juha



On Wed, 26 Jun 2002, Scott M Stark wrote:

 So I'm testing the new htmladaptor for the upcoming release and some
 of the default String representations just look like
 crap(MainDeployer.listDeployed()
 for example).

 So the obvious need is a mechanism for obtaining an xml representation of
 any mbean attribute or operation result as the basis for console
 applications.
 Do we have that notion?

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 



 ---
 This sf.net email is sponsored by: Jabber Inc.
 Don't miss the IM event of the season | Special offer for OSDN members!
 JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Tel: +358 40 8656 751 (GSM)




---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Detected JMX bug??

2002-06-11 Thread Juha-P Lindfors


You can safely ignore that message.

-- Juha


On Tue, 11 Jun 2002, Ram Ramesh wrote:

 Hi all,
  Is this a JMX bug? or is it a configuration issue?

 --Ram
 ---
 [09:43:45,208,ConfigurationService] Deployers set to
 J2EE:service=J2eeDeployer;
 JCA:service=RARDeployer in EJB:service=AutoDeployer
 [09:43:45,213,ConfigurationService] URLs set to ../deploy,../deploy/lib
 in EJB:service=AutoDeployer
 [09:43:45,223,ConfigurationService] MaxActiveClientCount set to 10 in
 Adaptor:name=html
 [09:43:45,223,ConfigurationService] Port set to 8082 in
 Adaptor:name=html
 [09:43:45,228,ConfigurationService] JNDIName set to Mail in
 :service=Mail
 [09:43:45,233,ConfigurationService] ConfigurationFile set to
 mail.properties in :service=Mail
 [09:43:45,262,ConfigurationService] User set to user_id in :service=Mail

 [09:43:45,266,ConfigurationService] Password set to password in
 :service=Mail
 [09:43:45,298,ConfigurationService] Detected JMX Bug: Server reports
 attribute 'ResourceAdapterName' is not writeable for MBean
 'JCA:name=JmsXA,service=ConnectionFactoryLoader'



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - 
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Problem with UCL.equals and Proxies

2002-05-28 Thread Juha-P Lindfors


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

2002-05-28 Thread Juha-P Lindfors


ignore, I misunderstood your message

On Tue, 28 May 2002, Juha-P Lindfors wrote:


 this will break the classes we generate in memory though, as they do not
 have an url


 On Mon, 27 May 2002, marc fleury wrote:

  |The result is that UnifiedClassLoader can't override equals. To validate
 
  On the top of my head (but I don't remember too well these days) this
  wouldn't break stuff
 
  marcf
 
  |that duplicate URLs are not placed into the UnifiedLoaderRepository
  |the UnifiedClassLoader URL must be used as the unique key.
  |
  |
  |Scott Stark
  |Chief Technology Officer
  |JBoss Group, LLC
  |
  |
  |
  |___
  |
  |Don't miss the 2002 Sprint PCS Application Developer's Conference
  |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
  |
  |___
  |Jboss-development mailing list
  |[EMAIL PROTECTED]
  |https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
  ___
 
  Don't miss the 2002 Sprint PCS Application Developer's Conference
  August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 

 --
 Juha Lindfors
 Author of JMX: Managing J2EE with Java Management Extensions
 Senior Developer, JBoss Group LLC




--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Senior Developer, JBoss Group LLC



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developersenvironment

2002-05-21 Thread Juha-P Lindfors

On Mon, 20 May 2002, Dain Sundstrom wrote:

 [I moved this to the dev list]

 I think the real power of JMX is you can have disparate components that
 can all talk to a central object without becoming tightly coupled.

 Here is my idea:

 We have an optional port server MBean.  Before a service opens a port it
 checks for the existence of the port server, and if (and only if) it
 exists, it asks the port server for a port passing the service name and
 port name (both are just any string).  If the port service doesn't
 exist, it follows the default code.

 This would require that the MBean wrappers for any serveice that opens a
 port to follow know about the possibility of a port service, but I don't
 think that is a big deal. Most MBeans already know about many services.

another possibility would be to persist these attributes containing port
numbers to a single location, e.g. config/ports.properties where all ports
would be in a single file.

This would not require the MBean developers to change their coding in any
way (Jules point about simple contracts) but would just require us to
config the initial server setup for the MBeans in question to use the same
location for these attributes. New user MBeans could also be configured to
use the same storage. Same approach would work for other system resources
as well (whatever they might be) without having to impose yet another
contractual requirement for MBean developers.

However, this requires that we convert to using persistent mbeans, which
is a more long term project. Short term your solution is the easier fix.

my .02

-- Juha



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] ejb-name conflict, help me!!!

2002-05-02 Thread Juha-P Lindfors

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

2002-05-02 Thread Juha-P Lindfors


.. aaand make the logger interface available as an mbean in
JMImplementation so my third party service impl can flash that red light
too via the jmx bus

-- Juha

 On Thu, 2 May 2002, Adrian Brock wrote:

 This is what I am trying to do with the JBossMX logger.

 You have a single logging interface org.jboss.mx.Logger
 so there are no code changes in other parts of the
 system and then choose your actual implementation.
 This could be do nothing - the NullLoggerAdaptor
 or
 FlashRedWarningLightLoggerAdaptor ;-)

 Regards,
 Adrian

  The idea of a logger in an embedded system is kind
  of strange, what are
  you going to log to ??? I mean most of the time is
  your embedded chip going
  to lug around a 50Gig barracuda IDE??? no... are you
  going to open an socket
  just for logging... no... are you going to fill
  your memory (tight if we
  believe specs) with log message... no.
 
  Logging in J2ME (JBoss4.0) strikes me as a DEBUGGING
  feature.  Useful while
  in development. Then YES you want to know what is
  going on, that much is
  trivial to see.
 
  This is where log4j becomes interesting, we would
  essentially DISABLE it for
  use in production J2ME while keeping it on for
  development but the code
  remains the same.  So the port to log4j is
  interesting in that respect.
 
  So the question for you JBoss4.0 fans out there is
  how small can we get
  log4j to be to do NOTHING, i.e. redirect all messages
  to /dev/null but still
  keep the code the same in our JBossMX/JBoss layers.
 
  marcf
 
 
  |-Original Message-
  |From: [EMAIL PROTECTED]
  |[mailto:[EMAIL PROTECTED]
  On Behalf Of
  |Adrian Brock
  |Sent: Thursday, May 02, 2002 7:05 AM
  |To: [EMAIL PROTECTED]
  |Subject: Re: [JBoss-dev] Dropping the System.out
  calls in the jmx code
  |
  |
  |Making the JBossMX logger use log4j is easy enough.
  |The only problem is log4j isn't configured until
  |after the MBeanServer is created in ServerImpl.
  |This isn't a big problem since the loggers are
  designed
  |to boot with System.err and swap over to the
  required
  |logging implementation when it becomes available.
  |
  |There are also some places in the code that do
  |System.out directly that need fixing.
  |
  |I'll do this at the weekend.
  |
  |I'm was also looking at reducing the footprint for
  |embedded, while allowing functionality to be added
  later.
  |My early attempt isn't very good. The footprint is
  |9k compared with 2k for common's Logger.
  |
  |Regards,
  |Adrian
  |* * *
  |
  |View thread online:
  http://jboss.org/forums/thread.jsp?forum=66thread=146
  2
 
  __
  
 
  Have big pipes? SourceForge.net is looking for
  download mirrors. We supply
  the hardware. You get the recognition. Email Us:
  [EMAIL PROTECTED]
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-dev
  lopment
 
 
  __
  
 
  Have big pipes? SourceForge.net is looking for
  download mirrors. We supply
  the hardware. You get the recognition. Email Us:
  [EMAIL PROTECTED]
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-dev
  lopment


 * * *

 View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14612

 ___

 Have big pipes? SourceForge.net is looking for download mirrors. We supply
 the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Senior Developer, JBoss Group LLC



___

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?

2002-04-28 Thread Juha-P Lindfors


 XML is now the lingua franca of human-readable structured data.
 XHTML, JSTL, Ant configs, SOAP, etc., mean that any serious designer of web
 applications must be proficient in reading and writing XML.

 Saying unreadable XML in the 21st century is like saying
 unreadable French in the 18th century.  It's a statement of one's
 illiteracy, not an indictment of the method of representation.

And here I was thinking the point of XML was to make it easier for
the *machine* to parse structured data.

-- Juha, the illiterate


jns:java
 jns:comment![CDATA[Hello, World]]/jns:comment
 jns:package name=my.stuff/
 jns:import name=java.lang.System/

 jns:class name=Main extends=java.lang.Object/
   jns:implements name=MyInterface/
   jns:implements name=ThatOtherInterface/
 /jns:class

 jns:method name=main PUBLIC STATIC
   jns:comment![CDATA[Print the message]]/jns:comment
   jns:return-typevoid/jns:return-type
   jns:signature
  jns:arg name=args/
  jns:type name=java.lang.String ARRAY/
   /jns:signature
   jns:body
  jns:invokestatic name=java.lang.System reference=out
 jns:method name=println
jns:value![CDATA[Hello, World]]/jns:value
 /jns:method
 /jns:invokestatic
   /jns:body
 /jns:method
/jns:java


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?

2002-04-28 Thread Juha-P Lindfors

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?

2002-04-28 Thread Juha-P Lindfors


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?

2002-04-28 Thread Juha-P Lindfors

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?

2002-04-28 Thread Juha-P Lindfors

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?

2002-04-28 Thread Juha-P Lindfors

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?

2002-04-28 Thread Juha-P Lindfors

On Sun, 28 Apr 2002, marc fleury wrote:

 2 solutions.
 1- I build a mapper that takes String and returns ObjectName
 2- you build a ObjectName implementation that caches the ObjectName and
 returns the right Object if you pass me exactly the same String.

 Come to think of it we probably need the first one.  Can you expose it at
 the JMX level?

I have an idea for it but (obviously) haven't looked at the details yet.
Might be a deliverable.

Right now I need to take a time out on this. Need to finish the inforIT,
explain our interceptors to EG and then do that finetuning for training
slides.

-- Juha








 I believe the registry idea must be present at the JMX
 level, then you would put the objectname mapped to the String name and that
 is fast enough for me to use and STANDARDIZE on inside the server.

 Bar that, the spirit dies for a spec quirk

 |MBean's do you imagine having in your server, could you create the object
 |names for them on the server side and lookup the same instances from a
 |cache -- I know it sounds ass backwards but given then future plans on
 |JMX it would be best to avoid too much reliance on the JMX classes
 |themselves.

 correct that is what I understand we need that cache. It is the Registry
 idea with more generic mappings.  It is a system level Registry juha.

 In a invoker I want to pass the String and use that to map to the ObjectName
 on the server or maybe expose an invoke that doesn't work with ObjectNames?
 something that makes sense.  Keep exceptions out of the design.

 marcf

 
 I will not watch my people die while
 you discuss this invasion in a commitee
 -- some silly queen in a SF movie--
 



--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Senior Developer, JBoss Group LLC



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?

2002-04-26 Thread Juha-P Lindfors

On Fri, 26 Apr 2002, marc fleury wrote:
 One step at a time, when we finalize 3.x releases i.e. in a couple of weeks,
 I say we move on 4.0 development and the overhaul of the admin with
 persistence through the modelmbeans will require some tweaking of the
 XMBeans (I believe the current implementation lacks) where you put your own

umm,

we dont really have any implementation for persistence at the moment

so yes it does lack :)

-- Juha


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [JL] Is it time for a new enterprise solution?

2002-04-25 Thread Juha-P Lindfors


Critique on JBoss configuration.

http://www.javalobby.org/thread.jsp?forum=61thread=3254

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?

2002-04-22 Thread Juha-P Lindfors

On Mon, 22 Apr 2002, marc fleury wrote:

 *and unreadable XML*

oh my

-- Juha




 just tired of it all,

 marcf

 |-Original Message-
 |From: [EMAIL PROTECTED]
 |[mailto:[EMAIL PROTECTED]]On Behalf Of Larry
 |Sanderson
 |Sent: Sunday, April 21, 2002 3:10 PM
 |To: [EMAIL PROTECTED]
 |Subject: Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
 |
 |
 |I *really* don't like jar1.jar, sar2.sar.  Let's make the naming convention
 |a little less likely to stumbled upon by unknowing users.  I suggest:
 |jar_jb1.jar, sar_jb2.sar, etc...  then the default sorting can look for
 |indexed deployments first, and sort the remainder by type.  This allows a
 |simple, global comparator, but removes the fine-grained support
 |you suggest.
 |So given the following within a directory:
 |
 |jetty.sar
 |my_ejb_ver4.jar
 |jar_jb5.jar
 |sar_jb10.sar
 |
 |This would order them thus:
 |jar_jb5.jar  -- all indexed deployments first
 |sar_jb10.sar
 |jetty.sar   -- all others second, in order of sar,rar,jar,war,ear
 |my_ejb_ver4.jar
 |
 |Hell, if they really need the flexibility you suggest then they
 |can set up a
 |second scanner, but I can't imagine any place where this is not sufficient.
 |
 |-Larry
 |
 | I'm not sure specifying the global sorter for a whole scanner is the way
 |we
 | want to go... on the other hand extensibility is nice... Do we want to
 | encourage people to have lots of scanners?
 |
 | At the risk of making things more complicated than necessary,
 |yet striving
 | for simplicity, how about
 |
 |   mbean code=org.jboss.deployment.scanner.URLDeploymentScanner
 | name=jboss.deployment:type=DeploymentScanner,flavor=URL
 |
 |
 | attribute name=ScanPeriod5000/attribute
 |
 |
 | attribute name=URLs
 |dir name=./deploy/core order=type/
 |dir name=./deploy/app order=lexical/
 |url name=.deploy/other/jar1.jar/
 |url name=.deploy/other/sar2.sar/
 |url name=.deploy/other/war3.war/
 | /attribute
 |
 |
 |
 | !-- Uncomment (and comment/remove version below) to enable usage of
 | the DeploymentCache
 | depends
 |optional-attribute-name=Deployerjboss.deployment:type=Deployment
 |Cache/de
 |pends
 | --
 | depends
 |optional-attribute-name=Deployerjboss.system:service=MainDeploye
 |r/depend
 |s
 |
 |
 |   /mbean
 |
 | mbean code=...
 |name=jboss.deployment:type=DeploymentSorter,order=type/
 | mbean code=...
 |name=jboss.deployment:type=DeploymentSorter,order=lexical/
 |
 | The deployment scanner looks up the requested ordering using the naming
 | pattern on the DeploymentSorter mbeans.
 |
 | I'm not sure if we really need explicit dependencies listed in the
 | DeploymentScanner.
 |
 | Striving towards simplicity (believe it or not;-)
 |
 | david jencks
 |
 |
 | On 2002.04.21 16:37:46 -0400 Larry Sanderson wrote:
 |   As larry said (do you have rw yet?)
 | 
 |  Yup.  I've already checked in at least one bug :-)
 | 
 |   let's not shove it down people's throat
 |   and let's document all of this.  Case closed. Implementation
 |needed :)
 | 
 |  Simple, and not too hacked implementation:
 | 
 |  Add MBean attribute to URLDeploymentScanner: URLComparator
 |  make default comparator point to: org.jboss.deployment.DeploymentSorter
 |  (make this a comparator that does the correct ordering)
 |  in scanDirectory, change: list = sorter.sortURLs(list);
 |   to: if (urlComparator != null) Collections.sort(list, urlComparator);
 | 
 |  This allows users unhappy with the ordering scheme to replace it with
 |  their
 |  own Comparator  (or simply drop it to remove all ordering).  If this
 |  sounds
 |  OK, I am mucking about in that code anyway.  Would you like me to make
 |  these
 |  changes?
 | 
 |  -Larry
 | 
 | 
 | 
 |
 | ___
 | Jboss-development mailing list
 | [EMAIL PROTECTED]
 | https://lists.sourceforge.net/lists/listinfo/jboss-development
 |
 |
 |
 |___
 |Jboss-development mailing list
 |[EMAIL PROTECTED]
 |https://lists.sourceforge.net/lists/listinfo/jboss-development


 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Senior Developer, JBoss Group LLC



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Final 3.0 beta will happen this week

2002-04-11 Thread Juha-P Lindfors



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

2002-04-11 Thread Juha-P Lindfors

On Thu, 11 Apr 2002, Jung , Dr. Christoph wrote:
 Anyone knows how this works? Will they publish the thing not until it
 reviewed, or what?

yeah they'll review it to see if it makes sense, and then assign a bug id
for it at which point you usually get an email about it

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] Re: Scheduled MBeans (Suggested Patch)

2002-04-09 Thread Juha-P Lindfors


looking at the code, I think the timer should override the
sendNotification() to use multiple threads to call listener
handleNotification() methods (threadpool if it seems creating
new Threads per listener call won't perform, which is likely)

however the default behavior in the notificationbroadcaster
support should be left as is imho, iow similar to java event handling

ideally we could just drop in a different nb support implementation but
since the spec forces us to subclass the default implementation instead of
just implementing the notificationbroadcaster interface this seems the way
to go about it

I leave the decision for Adrian though, it is his code :)

-- Juha


On Tue, 9 Apr 2002, Andreas Schaefer wrote:

 Hi Corby

 Thanx for looking into it. Will check with Juha / Adrian to see what they
 think.

  My patch addresses this problem without altering
 NotificationBroadcastSupport. The SchedulerMBean receives the synchronous
 notification, creates a new Thread to actually invoke the MBean, and returns
 the original Thread of control back to the Timer so that it can immediately
 fire the next notification.
 
  Anyway, let me know if you'd like the patch. It might be faster for you to
 just code the fix yourself.

 Currently I don't think we should fix it on the Scheduler level. The problem
 is that even when the Scheduler
 does not delay the call there can be another listener which does not go
 along with this.
 If we can fix this on JMX level then do it this way.

 Andy



 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Senior Developer, JBoss Group LLC



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: AW: [JBoss-dev] JMX HTML... From the Pure Fluff Department...

2002-04-08 Thread Juha-P Lindfors

On Mon, 8 Apr 2002, David Jencks wrote:

 Look into the modelmbean descriptors.  I think they include a priority as
 a standard descriptor, this could be used to determine whether to display
 something.

visibility to determine the granularity of mbeans (spec defines levels
1-4)

presentationString is what the adaptor should look for to
get presentation information an XML string describing the mbean view
layout. Look for W3C XForms (work in progress web forms)  or
just roll your own (quicker). The key is for the components to be able to
specify how to present and modify non-primitive types that are part of the
management interface, e.g if java.net.URL is in the interface how it
should be presented in the management tool (string, validate its a real
URL, etc).

-- Juha


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] JBossMX - Core/Kernel

2002-03-24 Thread Juha-P Lindfors

On Sat, 23 Mar 2002, Adrian Brock wrote:
 If we really wanted to provide a minimal kernel,
 Standard and ModelMBeans are really services
 on top of the DynamicMBean core. But that's probably
 not relevent to most users of JMX

The Model MBean implementation should at least eventually move out of the
kernel jar.

--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Senior Developer, JBoss Group LLC



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] JBossMX 1.0 Beta Release

2002-03-14 Thread Juha-P Lindfors


You can download it from sourceforge
http://prdownloads.sourceforge.net/jboss/JBossMX-1_0_Beta.tgz
http://prdownloads.sourceforge.net/jboss/JBossMX-1_0_Beta.zip

This beta release includes the JMX 1.0 specified functionality -- all
standard services: MLet, Monitoring, Relation and Timer services, queries,
advanced logging, bytecode optimized FAST invocations for Standard MBeans,
etc.

Please take it for a spin and report bugs/omissions.

Special thanks to Trevor and Adrian for their hard work.

--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
Senior Developer, JBoss Group LLC



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] Re: Jboss-development digest, Vol 1 #2686 - 13 msgs

2002-01-28 Thread Juha-P Lindfors



Hmm ok... it's a TODO for the next volunteer ;-)

-- Juha


 --__--__--

 Message: 9
 Date: Mon, 28 Jan 2002 16:44:04 -0500
 From: David Jencks [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] CVS update: jmx/src/main/test/compliance/server 
ServerSUITE.java

 I haven't had a chance to look at your jmx tests but you might consider
 naming them consistently with the jboss testsuite tests and seeing if the
 ant-based test framework can be used also.  In particular I have yet to
 find a use for adding tests explicitly to suites unless I am wrapping them
 in a setup.

 Getting these tests run nightly with the other jboss tests would be really
 nice.

 david jencks



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] CVS update: jmx build.xml

2001-12-12 Thread Juha-P Lindfors


huh?


On Wed, 12 Dec 2001, Jason Dillon wrote:

 Why don't these have vendor directories?

 --jason




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] JBossMX and jboss-all

2001-12-06 Thread Juha-P Lindfors


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)

2001-12-06 Thread Juha-P Lindfors



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

2001-12-06 Thread Juha-P Lindfors


hmm? did I drop my module in the wrong place in the CVS?

-- Juha

On Thu, 6 Dec 2001, Jason Dillon wrote:

 Date: Thu,  6 Dec 2001 16:45:57 -0700 (MST)
 From: Jason Dillon [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] JBossMX and jboss-all

 come to think of it, users will have to checkout again to get the jboss-all/jmx 
directory too.

 we really need to reorganize the repository to avoid this in the future.

 :(

 --jason
 
 View: http://jboss.org/forums/thread.jsp?forum=66thread=4999

 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] JBossMX and jboss-all

2001-12-06 Thread Juha-P Lindfors



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

2001-12-06 Thread Juha-P Lindfors


Thanks for this work, Jason.

-- Juha


On Thu, 6 Dec 2001, Jason Dillon wrote:

 Date: Thu, 06 Dec 2001 16:33:20 -0800
 From: Jason Dillon [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] CVS update: jmx build.bat build.sh build.xml

   User: user57
   Date: 01/12/06 16:33:20

   Added:   .build.bat build.sh build.xml
   Log:
o adding build files

   Revision  ChangesPath
   1.1  jmx/build.bat




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss

2001-12-05 Thread Juha-P Lindfors


And for those of you who want to place preorders for the book:
Amazon:
http://www.amazon.com/exec/obidos/ASIN/0672322889/104-6670791-7933546

BarnesNoble
http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=6AWE6O0GSLmscssid=P8DUDFK1W30T9P49N6M7UG91HXC87KN1isbn=0672322889

Hope you enjoy it :)

-- Juha

sig under construction



On Wed, 5 Dec 2001, marc fleury wrote:

 Date: Wed, 5 Dec 2001 12:27:09 -0500
 From: marc fleury [EMAIL PROTECTED]
 To: Jboss-Development@Lists. Sourceforge. Net
 [EMAIL PROTECTED]
 Subject: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss

 Folks,

 JMX as you know is deep inside our server and the basis for our new
 microkernel architecture.  JBoss when it is born is nothing more than the
 JMX.jar and the ServiceLibraries with it.

 Juha Lindfors has just finished writing the forthcoming JMX book for sams
 publishing and it will hit the market in early 2002, it is an excellent
 book.  From the insights he collected as he was writting it, JBossMX is
 born, a JMX based implementation in JBoss. As you can see as of this morning
 the first imports are already in CVS, the code is alive.

 JBossMX is going to be big, bigger than the server itself methinks, JBoss is
 going to be JBossMX in the new future. That is what we are really working on
 these days, david, scott, rickard, myself, and now juha putting forth the
 base code for it.  It is a first implementation and I expect it to mature
 rapidly.

 So go buy the book and participate in the implementation, JBossMX is a clear
 system vision, one we share and the JMX future is bright, I expect it will
 be in all sorts of embedded and servers as I outlined in the edge/central
 view earlier, it is the common infrastructure for us, the base for the super
 server.  It will leave in its own little jar separate of the rest of JBoss
 and really be, like the RI is today the boot jar of JBoss.

 in fact in the current codebase, JBoss is really JBossMX (today the SUN RI
 to be replaced, just to many problems so far, maybe the upcoming release
 will be better, but getting things fixed has just proved too problematic,
 open source is clearly superior there) but we will focus on providing a
 SMALL and FAST implementation, juha has some ideas on how to do that well,
 and then other services will probably be mbeans themselves ;).  So you will
 have a JBoss that fits in 200k like it does today when it boots, probably
 even less if we strip some of higher services that you don't need
 immediately.  We expect advanced add-ons to be sold like the snmp stacks
 from vendors and whatnot. Then everything including the EJB interceptors,
 the plugins, the services, the webservices invokers all mbeans all on a fast
 bus all on infrastructure we can debug at lightning speed and push in the
 field with wider distribution that even SUN achieves.

 With 500,000 page views a month and 50,000 downloads we are going to push
 our system view of the world we are going to make it real we are going to
 make it a success.

 The guardians are cold, but they are working, they know the flame is coming,
 they are working.

 The sound of the real deal
your mind we heal 
 -- LTJ bukem, Mc conrad --


 
 Marc Fleury
 President
 JBoss Group, LLC
 


 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss

2001-12-05 Thread Juha-P Lindfors


Hi,

end of January, 2002

I don't have an exact date

-- Juha


On Wed, 5 Dec 2001, Dave Bettin wrote:

 Is there an official publication date for the book??

 Thanks,
 Dave
 --- Juha-P Lindfors [EMAIL PROTECTED] wrote:
 
  And for those of you who want to place preorders for
  the book:
  Amazon:
 
 http://www.amazon.com/exec/obidos/ASIN/0672322889/104-6670791-7933546
 
  BarnesNoble
 
 
http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=6AWE6O0GSLmscssid=P8DUDFK1W30T9P49N6M7UG91HXC87KN1isbn=0672322889
 
  Hope you enjoy it :)
 
  -- Juha
 
  sig under construction
 
 




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Subclassing of Remote Interface

2001-12-05 Thread Juha-P Lindfors


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

2001-12-05 Thread Juha-P Lindfors


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

2001-12-05 Thread Juha-P Lindfors


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

2001-12-05 Thread Juha-P Lindfors



On Wed, 5 Dec 2001, marc fleury wrote:
 ONE REQUEST FOR THE USERS OF EMAILS

  PLEASE DO NOT OVERQUOTE ***

and one request for the users of forum:
do quote (not over quote), otherwise your messages make very little sense
when read from the mailing list

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loadingBasicLoaderRepository.java LoaderRepository.java

2001-12-03 Thread Juha-P Lindfors



you're right, thanks


-- Juha


On Mon, 3 Dec 2001, David Jencks wrote:

 Date: Mon, 3 Dec 2001 19:15:34 -0500
 From: David Jencks [EMAIL PROTECTED]
 To: Juha Lindfors [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading
 BasicLoaderRepository.java LoaderRepository.java

 Are you sure you don't mean


 Iterator it = loaders.iterator();
 while (it.hasNext()) {
ClassLoader cl = (ClassLoader)it.next();

if (cl != skipLoader) {
   try {
  clazz = cl.loadClass(className);
  return clazz;
  }
   catch (ClassNotFoundException ignored) {
  // go on and try the next loader
   }
}
 }

 throw new ClassNotFoundException(className);

   }

 at the end of loadClassWithout?

 The original version looks through all classloaders and you get the last
 version that loads, rather than stopping when you find one working version.

 ???

 thanks
 david jencks

 On 2001.12.02 21:13:31 -0500 Juha Lindfors wrote:
User: juhalindfors
Date: 01/12/02 18:13:31
 
Added:   src/main/org/jboss/mx/loading BasicLoaderRepository.java
  LoaderRepository.java
Log:
build fancy loaders here
 
Revision  ChangesPath
1.1  jmx/src/main/org/jboss/mx/loading/BasicLoaderRepository.java
 
Index: BasicLoaderRepository.java
===
/*
 * LGPL
 */
package org.jboss.mx.loading;
 
import java.util.Set;
import java.util.Iterator;
import java.util.HashSet;
 
public class BasicLoaderRepository implements LoaderRepository {
 
   private static LoaderRepository instance = null;
 
   public synchronized static LoaderRepository getInstance() {
  if (instance != null)
 return instance;
  else {
 instance = new BasicLoaderRepository();
 return instance;
  }
   }
 
 
   protected Set loaders = new HashSet();
 
   private BasicLoaderRepository() {
 
 
   }
 
   public Class loadClass(String className) throws
  ClassNotFoundException {
  return loadClassWithout(null, className);
   }
 
   public Class loadClassWithout(ClassLoader skipLoader, String
  className) throws ClassNotFoundException {
 
  Class clazz = null;
 
  // try ctx cl first
  ClassLoader ctxLoader = Thread.currentThread().getContextClassLoader();
 
  if (ctxLoader != skipLoader) {
 try {
clazz = ctxLoader.loadClass(className);
 }
 catch (ClassNotFoundException e) {
// ignore and move on to the loader list
 }
  }
 
  if (clazz != null)
 return clazz;
 
  Iterator it = loaders.iterator();
  while (it.hasNext()) {
 ClassLoader cl = (ClassLoader)it.next();
 
 if (cl != skipLoader) {
try {
   clazz = cl.loadClass(className);
}
catch (ClassNotFoundException ignored) {
   // go on and try the next loader
}
 }
  }
 
  if (clazz == null)
 throw new ClassNotFoundException(className);
 
  return clazz;
   }
 
   public void addClassLoader(ClassLoader cl) {
  loaders.add(cl);
   }
 
   public void removeClassLoader(ClassLoader cl) {
  loaders.remove(cl);
   }
 
 
}
 
 
 
1.1  jmx/src/main/org/jboss/mx/loading/LoaderRepository.java
 
Index: LoaderRepository.java
===
/*
 * LGPL
 */
package org.jboss.mx.loading;
 
public interface LoaderRepository {
 
   public Class loadClass(String className) throws
  ClassNotFoundException;
   public Class loadClassWithout(ClassLoader loader, String className)
  throws ClassNotFoundException;
   public void addClassLoader(ClassLoader cl);
   public void removeClassLoader(ClassLoader cl);
 
}
 
 
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] RequiredModelMBean.java? / general rantings

2001-12-02 Thread Juha-P Lindfors



Hi,

 Marc / everyone,

 When you asked about this Dynamic mbean thing I'm working on, were you
 thinking of me applying it to RequiredModelMBean?

I wrote a ModelMBean implementation for the book and will commit an
implementation based on it (with some other stuff) in the next couple of
days.


 If I read correctly, we are required to supply an implementation of that
 class, no?

Just implementing the ModelMBean interface will be enough.


 1) What are the expectations for determining the MBeanInfo?  Should we
 expect a XYZMBean interface to match the XYZ implementation the user
 provides?  (similar to regular MBeans)

 This would be easy to add.  Since I already have the code that walks the
 methods of any specified interface to compose the operation/attribute
 info structures.

The metadata can be built using introspection on the resource class, read
from a database, read from a file, looked up from the JNDI. The
rules for introspection can follow the standard MBean rules, or you can
create your own naming rules for a specific resource type.


 2) What should be the rules for determining the operations/attributes?
 I have written and re-written this logic in my own code about 15 times,
 never really happy with it.  Example, how to handle:

 int getXYZ();
 void setXYZ(float);

 Do you consider the get to be a RO attribute and one to be an operation?  Or
 throw an exception for non-compliant naming?  I see nothing in the spec
 regarding naming standards on dynamic mbean oper/attr

 or

 int getXYZ();
 void setXYZ(int);
 void setXYZ(float);

 Do we consider get/set(int) to be a RW attr, and set(float) to be an
 operation? Or throw again?

If you are talking about the Standard MBean behaviour, that would cause a
NotCompliantMBeanException to be thrown. However, for ModelMBeans you
could build your own resource types that allow this kind of interface to
be handled differently.

 As for persistence, have you finished rolling on the floor laughing at
 my idea of using EJBs to store?  I have noticed that no other components
 use EJBs for their JDBC based persistence.  Is there a reason for this?

The MMBean persistence can be abstracted behind a
simple PersistenceManager interface with load and store operations. The
persistence implementation may then be file based, direct JDBC, JDO or
EJB.


-- Juha


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] [research] a home/remote generator

2001-11-12 Thread Juha-P Lindfors



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

2001-11-12 Thread Juha-P Lindfors



On Mon, 12 Nov 2001, marc fleury wrote:
 |the problem with glue is we can't distribute the lib with jboss
 |it will require each user to go and download it individually

 ok let's stop this, who said we wanted to distribute the libraries from
 glue?

I would want to, cause its a very good lib. And free (beer). But can't
distribute with an IDE or app server, which sucks :p

anyway... how does AXIS do it differently... and why?

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] RH, Jetty, testsuite, Exceptions...

2001-09-17 Thread Juha-P Lindfors


Hmm.. you sure the auth.conf file is available in your classpath for the
client?

-- Juha

On Mon, 17 Sep 2001, Julian Gosnell wrote:

 Date: Mon, 17 Sep 2001 21:49:05 +0100
 From: Julian Gosnell [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED], [EMAIL PROTECTED],
  [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] RH, Jetty, testsuite, Exceptions...

 Thanks David that's one more cleared up:

 I had to change

 resource-ref
 res-ref-namejms/QueFactory/res-ref-name
 res-typejavax.jms.QueueConnectionFactory/res-type
 jndi-nameConnectionFactory/jndi-name
 /resource-ref

 The JNDI name was wrong.

 I shall check this in soon - so if i am wrong, let me know pronto !


 I only appear to have one problem left, it just repeats a few times. I would
 appreciate any pointers :

 [Jetty] Servlet Exception for /jbosstest/ClientLoginServlet
 java.lang.SecurityException: Unable to locate a login configuration
  at
 com.sun.security.auth.login.ConfigFile.getAppConfigurationEntry(ConfigFile.java:221)

  at javax.security.auth.login.LoginContext.init(Unknown Source)
  at javax.security.auth.login.LoginContext.init(Unknown Source)
  at org.jboss.test.web.servlets.ClientLoginServlet.doLogin(Unknown Source)
  at org.jboss.test.web.servlets.ClientLoginServlet.processRequest(Unknown
 Source)
  at org.jboss.test.web.servlets.ClientLoginServlet.doGet(Unknown Source)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:488)
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
  at org.mortbay.http.HandlerContext.handle(HandlerContext.java:1027)
  at org.mortbay.http.HandlerContext.handle(HandlerContext.java:982)
  at org.mortbay.http.HttpServer.service(HttpServer.java:674)
  at org.mortbay.http.HttpConnection.service(HttpConnection.java:732)
  at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:889)
  at org.mortbay.http.HttpConnection.handle(HttpConnection.java:746)
  at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:146)

  at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287)
  at org.mortbay.util.ThreadPool$PoolThreadRunnable.run(ThreadPool.java:613)
  at java.lang.Thread.run(Thread.java:484)

 If anyone knows anything about this exception, I would appreciate a few
 pointers.


 Cheer,


 Jules


 David Maplesden wrote:

  I don't know anything about this test, but I can see one problem straight
  away, JBossMQ no longer uses the name QueueConnectionFactory in its
  default setup so unless you have changed the MQ configuration (which is
  unlikely, yes?) then the name that should be looked up by the test is just
  ConnectionFactory.
 
  Cheers
  David.
 
   -Original Message-
   From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
   Sent: Tuesday, September 18, 2001 8:18 AM
   To: [EMAIL PROTECTED]
   Subject: [JBoss-dev] RH, Jetty, testsuite, Exceptions...
  
  
  
   It looks like some new tests may have gone into the web test module.
  
   I am trying to get RH/Jetty to pass and have come up against the
   following :
  
   [Jetty] ENCServlet: init
   [Default] ejb/bean0 = ENCBean0Home
   [Default] ejb/bean1 = ENCBean1Home
   [Default] ejb/bean2 = ENCBean1Home
   [Default] ejb/UnsecuredEJB = jbosstest/ejbs/UnsecuredEJBHome
   [Default] ejb/SecuredEJB = jbosstest/ejbs/SecuredEJBHome
   [Default] jdbc/DefaultDS =
   org.jboss.resource.adapter.jdbc.JDBCDataSource@661fd1
   [Default] mail/DefaultMail = javax.mail.Session@4ab2f
   [Default] javax.naming.NameNotFoundException:
   QueueConnectionFactory not
   bound
   [Default]  at org.jnp.server.NamingServer.getBinding(Unknown Source)
   [Default]  at org.jnp.server.NamingServer.getBinding(Unknown Source)
   [Default]  at org.jnp.server.NamingServer.getObject(Unknown Source)
   [Default]  at org.jnp.server.NamingServer.lookup(Unknown Source)
   [Default]  at org.jnp.interfaces.NamingContext.lookup(Unknown Source)
   [Default]  at org.jnp.interfaces.NamingContext.lookup(Unknown Source)
   [Default]  at
   javax.naming.InitialContext.lookup(InitialContext.java:350)
   [Default]  at org.jnp.interfaces.NamingContext.lookup(Unknown Source)
   [Default]  at org.jnp.interfaces.NamingContext.lookup(Unknown Source)
   [Default]  at org.jboss.test.web.servlets.ENCServlet.testJMS(Unknown
   Source)
   [Default]  at org.jboss.test.web.servlets.ENCServlet.testENC(Unknown
   Source)
   [Default]  at
   org.jboss.test.web.servlets.ENCServlet.processRequest(Unknown Source)
   [Default]  at org.jboss.test.web.servlets.ENCServlet.doGet(Unknown
   Source)
   [Default]  at
   javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
   [Default]  at
   javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
   [Default]  at
   

Re: [JBoss-dev] requirements for build

2001-08-31 Thread Juha-P Lindfors



On Fri, 31 Aug 2001, Dan - Blue Lotus Software wrote:

 I'm sorry if this is obvious to everyone on this list.  It wasn't for me,
 though.  The directions for buildmagic say nothing about how to *install*
 it.  And the build script contains the record tag, which is only supported
 in v1.4beta1 and beyond.

I didn't need to install anything... worked fine for me.

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] *.kpx files

2001-08-27 Thread Juha-P Lindfors



On Sun, 26 Aug 2001, Jason Dillon wrote:

 Does anyone still use these?  What are they for?

Kawa IDE Project Files.
Don't really belong to the CVS.

-- Juha


___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] jbossmq selector parser grammer source

2001-08-22 Thread Juha-P Lindfors


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

2001-08-22 Thread Juha-P Lindfors



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

2001-08-22 Thread Juha-P Lindfors


Try http://troi.lincom-asg.com/~rjamison/byacc/
(at the bottom of the page)

it contains a win exe, with byaccj 1.1 (so slightly newer)

yacc -Jclass=parser jms.y

-- Juha


On Wed, 22 Aug 2001, Hiram Chirino wrote:


 I think Byacc.   Can I get a win32 ver of that???

 Regards,
 Hiram

 From: Jason Dillon [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
 Date: Wed, 22 Aug 2001 12:41:33 -0700 (PDT)
 
 Unless s has been toUpperCase() (which I did not explictly check), then
 this
 is not spec compliant.  It needs to check for true and false too.
 
 Do you know what is used to generate parser.java from jms.y?
 
 --jason
 
 
 On Wed, 22 Aug 2001, Juha-P Lindfors wrote:
 
   It's here:
  
 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/spyderMQ/src/java/org/spydermq/selectors/
  
   this is the boolean equal check:
  
   //CST group
   if (s.equals(TRUE)) {
   yylval = new parserval((Object)Boolean.TRUE);
   return CST;
   }
   if (s.equals(FALSE)) {
   yylval = new parserval((Object)Boolean.FALSE);
   return CST;
   }
  
   -- Juha
  
  
  
   On Wed, 22 Aug 2001, Hiram Chirino wrote:
  
   
Can you send it to me???  I'll check it in.
   
Regards,
Hiram
   
From: Juha-P Lindfors [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 13:01:02 +0300 (EET DST)


   I have just fixed (and verified) both of these problems.  Should
 I
commit
   them?  Silly me, of course I should commit them... but where is
 jms.y?

I have the jms.y as part of the old spyderMQ module in
src/java/org/spydermq/selectors.

No idea where it is in the newer modules, or if it was ever
 transferred.
But check the SpyderMQ in CVS.

-- Juha


___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
   
   
_
Get your FREE download of MSN Explorer at
 http://explorer.msn.com/intl.asp
   
   
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
   
  
  
   ___
   Jboss-development mailing list
   [EMAIL PROTECTED]
   http://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development


 _
 Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development




___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] URGENCY? WSDL/UDDI/ebXML

2001-08-16 Thread Juha-P Lindfors



On Wed, 15 Aug 2001, Dan - Blue Lotus Software wrote:

 My opinion of it back 5 months ago was that it was not really even close to
 usable yet.  Have things changed radically since then?

Well, I think the emergence of UDDI/WSDL gave them a boost to speed
up, and all the core specs seem to have gained at least 1.0 status now.

I don't know if anyone has the full platform implemented yet (I think it's
unlikely), but there are parts of it being implemented - prototype ebXML
registries set up, and so forth. Sun has released an ebXML registry for
J2EE (iPlanet) that is available here:

http://www.sun.com/software/xml/developers/regrep/

but I haven't ever tried it.

They're also taking ebXML into consideration when designing the Java XML
Registry and Java XML Messaging API's which should allow you to interface
with ebXML by using a correct service implementation, approach similar to
JNDI I think.


 I know IBM have a UDDI implementation in beta.  Any chance we can convince
 them to donate it to Apache, Jakarta, or JBoss (I figure it's more likely
 they would open-source it to one of the first two, given their currently
 relationship with Apache)?

There are open source UDDI implementations in the works, for example
jUDDI.org and pUDDIng (http://www.opensorcerer.org/).


 What needs to be added to provide WSDL support?  Maybe I'm missing
 something, but it seems like it's merely a description language for
 services--a file you might retrieve from a UDDI registry that describes a
 SOAP service.  In this case, what is needed to provide support for WSDL?
 Anything?

Conversion tools from existing interfaces (ejb?) to the WSDL XML schema,
I suppose. I've always pictured WSDL as an XML IDL (but not 'human
readable' IDL, anyone who says WSDL is more readable than IDL is nuts ;-).
I guess WSDL supports a more webby definition of an interface. And its
XML, which is verry verry important :p

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] URGENCY? WSDL/UDDI/ebXML

2001-08-15 Thread Juha-P Lindfors



On Wed, 15 Aug 2001, marc fleury wrote:

 |Isn't SOAP nothing more than human readable IIOP?  Or is it more?

 yes but not everybody lives in the we see technology for what it really is
 sphere.

And I would like to state for the record that just because it is XML
doesn't necessarily mean its human readable  ;-)

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] how do i

2001-07-19 Thread Juha-P Lindfors


At the end of the page:
To change your subscription (set options like digest and delivery modes,
get a reminder of your password, or unsubscribe from Jboss-development),
enter your subscription email address:


Follow the link :p

-- Juha

 On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote:

 unsubscribe from this list?




___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Mail Delivery Status Notification

2001-07-10 Thread Juha-P Lindfors


I just togged nomail on him.

-- Juha


On Tue, 10 Jul 2001, Scott M Stark wrote:

 How long before this guy gets wacked from the list?

 - Original Message -
 From: Postmaster [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, July 10, 2001 12:22 PM
 Subject: [JBoss-dev] Mail Delivery Status Notification


  MAIL ESSENTIALS SENDER NOTIFICATION



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] CVS update: J2eeGlobalScopeDeployer.java

2001-06-16 Thread Juha-P Lindfors



umm... binary file?  -497 lines?

you sure?

-- Juha


On Fri, 15 Jun 2001 [EMAIL PROTECTED] wrote:

   User: schaefera
   Date: 01/06/15 22:53:38

   Modified:src/main/org/jboss/deployment/scope
 J2eeGlobalScopeDeployer.java
   Log:
   Added the support for classes with a single string as only argument for
   the constructor to the ConfigurationService. Some fixes and additional
   methods for the JBoss management.

   Revision  ChangesPath
   1.8   +0 -497
jboss/src/main/org/jboss/deployment/scope/J2eeGlobalScopeDeployer.java

   Binary file



 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Is Monday still a good 2.4 freeze date

2001-06-15 Thread Juha-P Lindfors


We're not making a new FINAL release on Monday, it's a feature freeze for
2.4 BETA.

AFAIK, Monday is still ok.

-- Juha


On Fri, 15 Jun 2001, Vincent Harcq wrote:

 Hi,
 IMHO, the re-deployment problem (see below) should stop you making a new
 release.

 For my part, I will test/validate the new DTD validation option as some
 elements are still missing from jaws.dtd (cmp-field is not defined).  I will
 take care of dtd corrections.

 Vincent.

 [Container Management Proxy] Destroyed
 [Default] javax.management.InstanceAlreadyExistsException:
 Management:container=bank/Account
 [Default]   at
 com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134
 )
 [Default]
 [Default]   at
 com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja
 va:
 [Default]
 [Default]   at
 com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
 [Default]
 [Default]   at
 org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:716)
 [Default]
 [Default]   at
 org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory.java:7
 00)
 [Default]
 [Default]   at
 org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:599)
 [Default]
 [Default]   at
 org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471)
 [Default]
 [Default]   at
 org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366)
 [Default]
 [Default]   at
 org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305)
 [Default]
 [Default]   at java.lang.reflect.Method.invoke(Native Method)
 [Default]
 [Default]   at
 com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
 [Default]
 [Default]   at
 com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
 [Default]
 [Default]   at
 org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
 [Default]
 [Default]   at
 org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467)
 [Default]
 [Default]   at
 org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
 [Default]
 [Default]   at java.lang.reflect.Method.invoke(Native Method)
 [Default]
 [Default]   at
 com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
 [Default]
 [Default]   at
 com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
 [Default]
 [Default]   at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379)
 [Default]
 [Default]   at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
 [Default]
 [Default]   at java.lang.Thread.run(Unknown Source)
 [Default]

  -Message d'origine-
  De : [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]De la part de
  Scott M Stark
  Envoyé : vendredi 15 juin 2001 2:24
  À : JBoss Dev
  Objet : [JBoss-dev] Is Monday still a good 2.4 freeze date
 
 
  Is Monday still a good 2.4 freeze date for the features that will go into
  the 2.4 release or is more time needed?
 
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-development


 _
 Do You Yahoo!?
 Get your free @yahoo.com address at http://mail.yahoo.com


 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] RabbitHole branch created

2001-06-12 Thread Juha-P Lindfors


hi,

why a branch?  It's easier to work on the main trunk and since most
development effort is going into 3.0 let's just freeze 2.4, branch the 2.4,
release 2.4 BETA and fix 2.4 issues in the branch. Keep main
development in the trunk.

-- Juha


On Mon, 11 Jun 2001, Scott M Stark wrote:

 I created a RabbitHole branch off of the current main line for prototyping
 the 3.0 generation of JBoss. You can access the branch via the command
 line version of cvs using:

 cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co -r 
RabbitHole jboss




 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Verifier Patch

2001-06-07 Thread Juha-P Lindfors


6.10.5 Session beans' remote interface
9.2.7  Entity bean's remote interface

?

-- Juha


On Thu, 7 Jun 2001, K.V. Vinay Menon wrote:

 Juha,
 For the verifier fix what on earth is the spec id .. 9..2.x.x?  Any pointers 
would be much appreciated. Can check in the source once I get the correct value!

 Vinay



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ADMIN] Test

2001-06-06 Thread Juha-P Lindfors


spam warning test




___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] EJB 2.0 DTD LocalResolver

2001-06-04 Thread Juha-P Lindfors


go ahead..

-- Juha


On Mon, 4 Jun 2001, Vincent Harcq wrote:
 Hi,
 Does it bother anybody if I add a LocalResolver of DTD for //Sun
 Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN
 to a local version of http://java.sun.com/dtd/ejb-jar_2_0.dtd ?
 Vincent.



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] JMSContainerInvoker.java

2001-06-01 Thread Juha-P Lindfors



On Fri, 1 Jun 2001, Peter Antman wrote:

 You see what will happen? Yes, the client will send its messages to one
 topic (no automatic creation here), and the MDB will listen on ANOTHER
 topic, namely a to the system unknown destination, since it was not
 correctly spelled.

 What do you other guys say on the list? Hiram?

I agree with you it's not a good change. If the developer has made a
mistake in his code or forgot to add the topic he should be warned during
the deployment, instead of allowing the application to silently fail.

Also, since the created topics are persistent, this requires the developer
to go clean up the jbossmq configuration file from time to time to make
sure resources aren't wasted on topics that never meant to be there in the
first place. I think thats worse than the requirement of having to create
the topic upfront, especially since the developer may not even be aware he is
accidentally creating new topics.

So if the idea was to help the developer to avoid finding out about our
obscure configuration files, I think this change may have made the problem
even worse. Now you HAVE TO go browse them, just to fix your typos that
won't go away.

-- Juha


 
 //Peter

 On 31 Maj, [EMAIL PROTECTED] wrote:
User: thedug
Date: 01/05/31 16:53:44
 
Modified:src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
Log:
Add auto generation for topic/queue if topic/queue doesn't already exist.
Uses the mbean server to create a new topic/queue..
 
Revision  ChangesPath
1.11  +54 -7 
jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
 
Index: JMSContainerInvoker.java
===
RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JMSContainerInvoker.java  2001/05/07 19:19:57 1.10
+++ JMSContainerInvoker.java  2001/05/31 23:53:44 1.11
@@ -45,18 +45,24 @@
 import org.jboss.jms.jndi.JMSProviderAdapter;
 import org.jboss.jms.asf.ServerSessionPoolFactory;
 
+import org.exolab.jms.client.JmsServerSessionPool;
+
 import org.w3c.dom.Element;
 
+import javax.management.MBeanServerFactory;
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+
 /**
  * ContainerInvoker for JMS MessageDrivenBeans, based on JRMPContainerInvoker.
  *  description
- *
+ *
  *  @see related
  *  @author Peter Antman ([EMAIL PROTECTED])
  *  @author Rickard Öberg ([EMAIL PROTECTED])
  *  @author a href=mailto:[EMAIL PROTECTED];Sebastien 
Alborini/a
  *  @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- *  @version $Revision: 1.10 $
+ *  @version $Revision: 1.11 $
  */
 public class JMSContainerInvoker implements
 ContainerInvoker, XmlLoadable
@@ -205,7 +211,24 @@
 
// Set up pool
ServerSessionPoolFactory poolFactory = 
(ServerSessionPoolFactory)jbossContext.lookup(serverSessionPoolFactoryJNDI);
-
+
+   // jndiSuffix is merely the name that the user has given the MDB.
+   // since the jndi name contains the message type I have to split at the 
/
+   // if there is no slash then I use the entire jndi name.
+   String jndiSuffix = ;
+   if(destinationJNDI != null){
+int indexOfSlash = destinationJNDI.indexOf(/);
+if(indexOfSlash != -1){
+  jndiSuffix = destinationJNDI.substring(indexOfSlash+1);
+}else{
+  jndiSuffix = destinationJNDI;
+}
+
+// if the jndi name from jboss.xml is null then lets use the ejbName
+}else{
+jndiSuffix = config.getEjbName();
+}
+   MBeanServer server = 
(MBeanServer)MBeanServerFactory.findMBeanServer(null).iterator().next();
 
if (destinationType.equals(javax.jms.Topic))
 {
@@ -230,7 +253,18 @@
 }
 
 // Lookup destination
-Topic topic = (Topic)context.lookup(destinationJNDI);
+   // First Try a lookup.
+   // If that lookup fails then try to contact the MBeanServer and 
inoke a new...
+   // Then do lookup again..
+String topicJndi = topic/+jndiSuffix;
+Topic topic;
+try{
+   topic = (Topic)context.lookup(topicJndi);
+}catch(NamingException ne){
+   Logger.log(JndiName not found:+topicJndi + ...attempting 
to recover);
+   server.invoke(new ObjectName(JMS,service,JMSServer), 
newTopic, new Object[]{jndiSuffix}, new String[] {java.lang.String});
+   topic = (Topic)context.lookup(topicJndi);
+}
 
 

RE: [JBoss-dev] JMSContainerInvoker.java

2001-06-01 Thread Juha-P Lindfors




On Fri, 1 Jun 2001, Ferguson, Doug wrote:

 It will be trial to remove the topic/queue at undeployment,
 if and only if I added it at deploy time

ok..

 We already display a message at deploytime that says that
 the queue/topic doesn't exist. So it isn't really correct
 that the server hides your fuck ups. It merely deals with them
 in an itelligent fashion.

make it a big and ugly, the size of a stack trace. Anything else will go
unnoticed. We print out too much information anyhow, one liners will drown
in the noise.

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] ConfigurationService buggy

2001-05-07 Thread Juha-P Lindfors



On Mon, 7 May 2001, marc fleury wrote:
 Juha, when we were in London, debugged that to work the right way so we
 could demo how the remote installation worked.  Juju, do you have that fix
 in mind still? care to put it in?

I think Vinay committed the fix on Saturday. Not sure all the cases you're
seeing were covered (only one bytes.available() call was fixed).

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] RFC: Add isolation level attribute in jboss.xml orjaws.xml?

2001-05-05 Thread Juha-P Lindfors



Yes,

please go ahead and implement this

-- Juha

On Sat, 5 May 2001, danch wrote:

 Does anyone have opinions on whether this would be a good feature or
 not? The 1.1 spec does not specify how isolation levels should be
 handled, except for BMT session beans, and by saying/implying that beans
 can call resource manager specific APIs to set it themselves (carefully).

 If this seems like a good idea, should this setting be in jboss.xml (and
 cover BMP and CMP entities as well as sessions), or in jaws.xml
 (covering _only_ CMP entities, since others are free to call the
 resource manager's APIs)?

 thanks,
 danch


 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] NamingAlias: won't compile

2001-04-22 Thread Juha-P Lindfors


Scott,

the current CVS checkout won't compile because ServiceMBean interface is
missing STARTING and STARTED variables which are required by the
NamingAlias class.

-- Juha



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] CVS client/ssh

2001-04-11 Thread Juha-P Lindfors



On Wed, 11 Apr 2001, Peter Braswell wrote:
 I'm using a W2K machine.  I've tried jCVS (no support
 for ssh), winCVS (seems to support ssh, but won't work
 properly) and cygwin's command line CVS from within
 the Unix shell.  Nothing seems to work.

Cygwin pretty much works out of the box for me on NT4. What sort of
problems were you having with it?

export CVS_RSH=ssh
cvs -d :ext:username@cvs.jboss.sourceforge.net:/cvsroot/jboss co jboss

make changes

cvs commit changedfile
type in your pw

press insert
edit log msg in vim
ESC:wq

done

-- Juha


___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



  1   2   >