Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-11 Thread Hiram Chirino
The change is too big for a patch.  I'd rather commit on a branch. 
Another option is to refactor it some more so that it becomes part of
the new module that Nathan is working on.  Either way, please let me
know which way you prefer it.  I have completed most of my clean up and
the jms and mdb unit tests are once again passing with flying colors.

The mailing list does not seem to have received a couple of emails I
sent a few days back.  Is there something wrong with the mailing list?

Regards,
Hiram

On Fri, 2003-07-11 at 13:01, Scott M Stark wrote:
 Hiram, no one sits around for months without interacting with the day 
 to day developers of JBoss
 Group and then decides to commit a large change without it being 
 discussed. Some of
 what you have most likely has merit but it has to be reviewed so either 
 submit it as a patch
 or commit it to a branch off of head so that it can be reviewed for 
 incorporation.
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] Behalf Of 
  Hiram
  Chirino
  Sent: Wednesday, July 09, 2003 12:16 AM
  To: [EMAIL PROTECTED]
  Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
 
 
  Scott,
 
  Why does it matter?  Nathan has not expressed interested in growing 
  from
  the current JMS implementation.  I've been waiting for several months
  for the new general purpose implementation to 'appear' and it has not.
 
  There has been a skeleton since early Jun.
 
 
  So it's time for me to start the engine again and make some needed
  improvements to the current JBossMQ implementation.
 
 
  Where have you been the past year when Adrian and Scott have been 
  fixing
  this buggy MQ implementation?  You failed to keep up the old stuff so 
  please
  don't make it sound like you're coming to the rescue.
 
  I'm not so sure I want a total refactoring of the old JMS in the 
  remoting
  subsystem and the interceptor chains and such.  The current JMS 
  rewrite by
  Nathan, Adrian, and Bela is going quite well and we will be replacing 
  the
  old system in the fall.
 
  What I don't want is a CVS HEAD of the old JMS that doesn't look like 
  the
  3.2 series since it will be much harder to migrate 3.2 fixes to a CVS 
  HEAD
  that has been totally refactored.  The old JMS needs to live a bit 
  beyond
  4.0's release and 4.0 will not be released until the late late fall, 
  between
  Thanksgiving and Christmas.  I guess what I'm saying is that a lot of 
  users
  will still depend on the old JMS for at least another year and we need 
  some
  to have fluidity between 3.2 and 4.0.  We're already experiencing the 
  pain
  of an unnecessary rewrite of the Entity Container that is making it
  difficult to merge fixes in 3.2 to 4.0.  I don't want the same thing to
  happen with a codebase that is going to be retired eventually anyways 
  and
  that needs to live in depracated mode for awhile.
 
 
 
 
 ---
 This SF.Net email sponsored by: Parasoft
 Error proof Web apps, automate testing  more.
 Download  eval WebKing and get a free book.
 www.parasoft.com/bulletproofapps1
 ___
 JBoss-Development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
-- 
/**
  * Hiram Chirino
  * Partner
  * Core Developers Network
  **/



---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing  more.
Download  eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Hiram Chirino

Hi guys,

Over the past two weeks I have started to make a few improvements the
current JBossMQ implementation that is in CVS HEAD.  I would consider a
large porting of what I did refactoring to simplify the current code
base to allow future growth without having to sacrifice current features
or performance. 

I just wanted to give provide an update on the development status of the
original JBossMQ client-server JMS implementation.

Here's a summary of what has changed:

- It exclusively uses the remoting subsystem for client server
communications.  The existing IL subsystem has been removed.  The
'async' remoting protocol allows two way communications solely over
client sockets (this should allow applet/firewalled clients to connect
to the server).  Multiple JMS connections made by the client will also
share a singe pool of sockets to communicate with the server.
- Manually creating JBossMQ ConnectionFactory objects have been
simplified since a remoting URI takes care setting up most of the
connection options.
- The server interceptors have been simplified since they now operate on
a typeless invocations (it now matches the style of the other jboss
interceptors)
- The implementations for the p2p and pub/sub JMS API classes have been
consolidated since that is the direction that the JMS 1.1 API is taking
(being able to mix the us of p2p and pub/sub with in the same session).
- Many (almost all) of the bug fixes/performance enhancements made in
the 3.2 branch have been ported forward.
- All the PMs except JDBC2 have been removed to make it easier to more
quickly make enhancements to the persistence manager interface.  I hope
a cmp/jdo implementation can be created in the future.
- the old org.jboss.mq.xml package that provided a simple xml dom was
removed and all code that was using was changed to use dom4j instead.
- JNDI Reference object handling was simplified (only StringRefs are
used).
- The sources were refactored so that the back-end messing server is
much less coupled the javax.jms.* classes.  The server side is still
importing many of the JMSException classes, this can be cleaned up in
the future.  This might start to lead the way to allow this messaging
server to support other messaging APIs (JavaSpaces?)

Things to watch out for with this new version:
- The jboss API to manually create ConnectionFactory and Destination
objects has changed.  Most users should not be affected since the JMS
spec states that they should be using JNDI to get those objects.
- Previous JBossMQ clients will not be able to connect to this new
server version (since it is using remoting for communications).  Those
clients need to upgrade their jbossmq-client.jar.
- The message format has changed so the new server will not be able to
restore messages saved to persistence storage by the new server.

I hope to commit the changes CVS in the next few days.  I have 3 jms
test cases that I still need to fix and then I still need to run the MDB
test cases.

Regards,
Hiram

-- 
/**
  * Hiram Chirino
  * Partner
  * Core Developers Network
  **/



---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing  more.
Download  eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Hiram Chirino
Scott,

Why does it matter?  Nathan has not expressed interested in growing from
the current JMS implementation.  I've been waiting for several months
for the new general purpose implementation to 'appear' and it has not. 
So it's time for me to start the engine again and make some needed
improvements to the current JBossMQ implementation.

Nathan, 

Your doing great work in the peer based JMS arena.  But have you
formulated a game plan for the rewrite of general purpose
implementation? 

Right now I'm going down the route of simplifying our current c/s
implementation down enough so that we can start taking it apart more
easily if required to add the needed features.


On Tue, 2003-07-08 at 23:00, Scott M Stark wrote:
 And what interaction has there been with Nathan who originally responded to
 the rewrite query?
-- 
/**
  * Hiram Chirino
  * Partner
  * Core Developers Network
  **/



---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing  more.
Download  eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Hiram Chirino
On Tue, 2003-07-08 at 23:41, Nathan Phelps wrote:

In line...

 Hiram, 
 
 As you may know, we are going in a different direction with JMS than the
 original architecture coded by Norbert Lataille.  We are doing a rewrite

I guess I had it good.  Norbert made a good start.  At least basic
pub/sub worked.  That's better than starting from scratch.

 so patches to the old JBossMQ have a limited lifetime.  That means that
 changes made to the old JBossMQ will most likely not be part of HEAD or
 the distribution as we move forward.

You may be right. or wrong.  The current JMS will ship until there is a
better replacement.  Do you plan to replace the current implementation
with the peer based implementation you have been working on?

Regards,
Hiram

 
 Thanks,
 
 Nathan Phelps
 JMS Lead
 JBoss Group, L.L.C.
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:jboss-
  [EMAIL PROTECTED] On Behalf Of Hiram Chirino
  Sent: Tuesday, July 08, 2003 8:41 PM
  To: [EMAIL PROTECTED]
  Subject: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
  
  
  Hi guys,
  
  Over the past two weeks I have started to make a few improvements the
  current JBossMQ implementation that is in CVS HEAD.  I would consider
 a
  large porting of what I did refactoring to simplify the current code
  base to allow future growth without having to sacrifice current
 features
  or performance.
  
  I just wanted to give provide an update on the development status of
 the
  original JBossMQ client-server JMS implementation.
  
  Here's a summary of what has changed:
  
  - It exclusively uses the remoting subsystem for client server
  communications.  The existing IL subsystem has been removed.  The
  'async' remoting protocol allows two way communications solely over
  client sockets (this should allow applet/firewalled clients to connect
  to the server).  Multiple JMS connections made by the client will also
  share a singe pool of sockets to communicate with the server.
  - Manually creating JBossMQ ConnectionFactory objects have been
  simplified since a remoting URI takes care setting up most of the
  connection options.
  - The server interceptors have been simplified since they now operate
 on
  a typeless invocations (it now matches the style of the other jboss
  interceptors)
  - The implementations for the p2p and pub/sub JMS API classes have
 been
  consolidated since that is the direction that the JMS 1.1 API is
 taking
  (being able to mix the us of p2p and pub/sub with in the same
 session).
  - Many (almost all) of the bug fixes/performance enhancements made in
  the 3.2 branch have been ported forward.
  - All the PMs except JDBC2 have been removed to make it easier to more
  quickly make enhancements to the persistence manager interface.  I
 hope
  a cmp/jdo implementation can be created in the future.
  - the old org.jboss.mq.xml package that provided a simple xml dom was
  removed and all code that was using was changed to use dom4j instead.
  - JNDI Reference object handling was simplified (only StringRefs are
  used).
  - The sources were refactored so that the back-end messing server is
  much less coupled the javax.jms.* classes.  The server side is still
  importing many of the JMSException classes, this can be cleaned up in
  the future.  This might start to lead the way to allow this messaging
  server to support other messaging APIs (JavaSpaces?)
  
  Things to watch out for with this new version:
  - The jboss API to manually create ConnectionFactory and Destination
  objects has changed.  Most users should not be affected since the JMS
  spec states that they should be using JNDI to get those objects.
  - Previous JBossMQ clients will not be able to connect to this new
  server version (since it is using remoting for communications).  Those
  clients need to upgrade their jbossmq-client.jar.
  - The message format has changed so the new server will not be able to
  restore messages saved to persistence storage by the new server.
  
  I hope to commit the changes CVS in the next few days.  I have 3 jms
  test cases that I still need to fix and then I still need to run the
 MDB
  test cases.
  
  Regards,
  Hiram
  
  --
  /**
* Hiram Chirino
* Partner
* Core Developers Network
**/
  
  
  
  ---
  This SF.Net email sponsored by: Parasoft
  Error proof Web apps, automate testing  more.
  Download  eval WebKing and get a free book.
  www.parasoft.com/bulletproofapps
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 ---
 This SF.Net email sponsored by: Parasoft
 Error proof Web apps, automate testing  more.
 Download  eval WebKing and get a free book.
 www.parasoft.com/bulletproofapps

Re: [JBoss-dev] Why is JDOM version in JBoss so old

2003-04-04 Thread Hiram Chirino

yes the replacment is dom4j.  Check it out at
dom4j.org

Regards,
Hiram

--- Tom Coleman [EMAIL PROTECTED] wrote:
 
 Is there something that replaces JDOM in 4.x?  
 
 JDOM can make XML experts out of dummies, and if
 you're working with 
 XML-based apps, it's nice to have in the server
 classpath.
 
 Scott Stark wrote:
 
  
  ... On head jdom should be dropped.
  
 
 

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


__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com


---
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] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Hiram Chirino

Bill,

If you use versioning on a POJO that is a the top of
an object graph, will the children objects also be
versions when they are modified???

I assume No.  But I think it would make sense for your
Versioning interceptor to wrap up children objets with
the versioning proxy also when they are accessed. 
That way if you do a:

pojo = (POJO)Versioned.makeVersioned(pojo);
pojo.getAccount().getBalance().add(10.00);

The modification of the Balance object will be
versioned too.  Does that make sense to you??  Do you
do this now??

Regards,
Hiram

--- Bill Burke [EMAIL PROTECTED] wrote:
 
 
  -Original Message-
  From:
 [EMAIL PROTECTED]
 

[mailto:[EMAIL PROTECTED]
 Behalf Of
  Karthik
  Sent: Thursday, March 27, 2003 1:25 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
 
 
  Hi bill,
 The versioning of POJO is very good. I have
 some issues here. If I
  version a object, then I have to maintain all the
 state in the same POJO
 
 How is this not the general case?  All application
 code accesses the POJO
 through the proxy.  I am going to write a
 constructor-pointcut that will
 always return a proxy instead of the real POJO on
 construction.
 
  which is not the general case and will bloat the
 code. The states are
  maintained in the helper classes. Also defining
 each POJO as versioned is
  meaningless. If new proxies are created for each
 transaction with the deep
  copy of all the state or maintain a pool and
 synchronize the state after
  update,  it will become real performance
 bottleneck.How do you tackle this
  problem?
 
 There is only one proxy, but you are correct.  For
 each transaction, a full
 snapshot is taken of the real object.  All access to
 the object is done
 through one proxy.
 
 The performance hit is the full deep copy not the
 synchronization.
 Synchronization is only:
 
 realObject = snapshot;
 
 Remember, we're optimistically locking here. 
 (Although I'd like to
 optionally provide a transactional lock in the near
 future).
 
 The alternative solution is much much more complex. 
 The biggest problem
 being, how do you determine when a POJO's state has
 changed?  For instance:
 
 Pojo.someHashMapField.get().setValue(blah).  You see
 my point?
 
 A full deep copy greatly simplifies the code. 
 Simplicity == robustness.
 Plus I'm not even sure versioned fields would be
 better performing.  Field
 interception is quite expensive and versioned fields
 would need field
 interception.
 
 The code is under: 
 varia/src/main/org/jboss/aop/plugins/Version*.java
 testcase is under

testsuite/src/main/org/jboss/test/aop/bean/Version*.java
 (take a look at the AOP DD under
 testsuite/src/resource/aop/META-INF/jboss-aop.xml
 too).
 
 Bill
 
 
 
 Correct me if I am missing something.
 
 Where or when can get the code from the CVS?
 
  Thanks
 
  Karthi
 
   -Original Message-
   From:
 [EMAIL PROTECTED]
  

[mailto:[EMAIL PROTECTED]
   Behalf Of Bill
   Burke
   Sent: Thursday, March 27, 2003 10:43 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
  
  
  
  
-Original Message-
From:
 [EMAIL PROTECTED]
   

[mailto:[EMAIL PROTECTED]
   Behalf Of Jeff
Haynie
Sent: Wednesday, March 26, 2003 11:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
   
   
   
JBoss Remoting is much more fabulous.  We
 need to get the
   word out on
it...
   
I need to write some darn docs.. Too busy
 trying to get a
   new release
out on our side. Not enough hours in a day.
   
   
 I totally agree.  And yes, a constructor
 pointcut is the
   way to go.
The only downside of constructor pointcuts is
 that
   reflection bypasses
the interception!
 Same thing with field interception.  The
 problem is that unlike
methods, you have to modify the bytecode of
 the calling logic.
   
Could you dynamically do an insertBefore into
 the
   CtConstructor of the
advised class which would do the interception,
 even on reflection?
   
  
   I'm not sure...The problem with Versioning and
 Remoting is
   that a proxy
   object is required.  You have to return a
 different object
   than the one
   actually constructed.  You getting me?  I'm not
 sure if this
   can be done
   within bytecode manipulation.  I'll have to ask
 the Javassist guys.
  
 I will write some testcases that put the
 whole stack together with
constructor pointcuts.

 I'm also working on the concept of an
 abstract Container.
But you got
me thinking that constructor pointcuts may be
 enough...
   
I was just going to email you about the
 Container - just
   looking through
the code. Is this just the ability to create
 an AOP namespace or
something?
   
  
   I guess you could think of it in that way and
 use it in that
   way, but the
   original intent was to handle things like
 

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Hiram Chirino

That might be a problem if you have a big object
graph.  You get a big penalty even if you only modify
a small peice of the object graph.

You could do a shallow copy by getting a snapshot of
the fields of the object.  Then wrap up the children
objects with Versioned.makeVersioned(child) when
they are accessed.  The cool thing is that you would
not have any serialization at all.  I know that there
has to be some down-sides to this approach, help me
figure them out.

Regards,
Hiram


--- Bill Burke [EMAIL PROTECTED] wrote:
 Yes, its a deep copy which is why I require
 Serializable.
 
 new MarshalledObject(obj).get();  
 
 Maybe there is a better way to make copies?
 
  -Original Message-
  From:
 [EMAIL PROTECTED]
 

[mailto:[EMAIL PROTECTED]
 Behalf Of Hiram
  Chirino
  Sent: Thursday, March 27, 2003 10:15 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
  
  
  
  Bill,
  
  If you use versioning on a POJO that is a the top
 of
  an object graph, will the children objects also be
  versions when they are modified???
  
  I assume No.  But I think it would make sense for
 your
  Versioning interceptor to wrap up children objets
 with
  the versioning proxy also when they are accessed. 
  That way if you do a:
  
  pojo = (POJO)Versioned.makeVersioned(pojo);
  pojo.getAccount().getBalance().add(10.00);
  
  The modification of the Balance object will be
  versioned too.  Does that make sense to you??  Do
 you
  do this now??
  
  Regards,
  Hiram
  
  --- Bill Burke [EMAIL PROTECTED] wrote:
   
   
-Original Message-
From:
   [EMAIL PROTECTED]
   
  
 

[mailto:[EMAIL PROTECTED]
   Behalf Of
Karthik
Sent: Thursday, March 27, 2003 1:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID
   objects 1st iteration
   
   
Hi bill,
   The versioning of POJO is very good. I have
   some issues here. If I
version a object, then I have to maintain all
 the
   state in the same POJO
   
   How is this not the general case?  All
 application
   code accesses the POJO
   through the proxy.  I am going to write a
   constructor-pointcut that will
   always return a proxy instead of the real POJO
 on
   construction.
   
which is not the general case and will bloat
 the
   code. The states are
maintained in the helper classes. Also
 defining
   each POJO as versioned is
meaningless. If new proxies are created for
 each
   transaction with the deep
copy of all the state or maintain a pool and
   synchronize the state after
update,  it will become real performance
   bottleneck.How do you tackle this
problem?
   
   There is only one proxy, but you are correct. 
 For
   each transaction, a full
   snapshot is taken of the real object.  All
 access to
   the object is done
   through one proxy.
   
   The performance hit is the full deep copy not
 the
   synchronization.
   Synchronization is only:
   
   realObject = snapshot;
   
   Remember, we're optimistically locking here. 
   (Although I'd like to
   optionally provide a transactional lock in the
 near
   future).
   
   The alternative solution is much much more
 complex. 
   The biggest problem
   being, how do you determine when a POJO's state
 has
   changed?  For instance:
   
   Pojo.someHashMapField.get().setValue(blah).  You
 see
   my point?
   
   A full deep copy greatly simplifies the code. 
   Simplicity == robustness.
   Plus I'm not even sure versioned fields would be
   better performing.  Field
   interception is quite expensive and versioned
 fields
   would need field
   interception.
   
   The code is under: 
  
 varia/src/main/org/jboss/aop/plugins/Version*.java
   testcase is under
  
 

testsuite/src/main/org/jboss/test/aop/bean/Version*.java
   (take a look at the AOP DD under
  
 testsuite/src/resource/aop/META-INF/jboss-aop.xml
   too).
   
   Bill
   
   
   
   Correct me if I am missing something.
   
   Where or when can get the code from the
 CVS?
   
Thanks
   
Karthi
   
 -Original Message-
 From:
   [EMAIL PROTECTED]

  
 

[mailto:[EMAIL PROTECTED]
 Behalf Of Bill
 Burke
 Sent: Thursday, March 27, 2003 10:43 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID
   objects 1st iteration




  -Original Message-
  From:
   [EMAIL PROTECTED]
 
  
 

[mailto:[EMAIL PROTECTED]
 Behalf Of Jeff
  Haynie
  Sent: Wednesday, March 26, 2003 11:51 PM
  To:
 [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned
 ACID
   objects 1st iteration
 
 
 
  JBoss Remoting is much more fabulous.  We
   need to get the
 word out on
  it...
 
 
=== message truncated ===


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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

2003-03-08 Thread Hiram Chirino

The AOP case is even more similar to the DP if you
think of AOP like this:

If the AOP intrumented methods are: 
Interceptors are: []
The original (but renamed) object methods are: (
The object is: O

An AOP stack then is: [](O
Which is almost the same as the DP case: |[](O

Regards,
Hiram

 If an object is 
 
 |(O 
 
 | is the interface 
 ( are the methods to the object
 O is the actual implementation 
 
 or 
 (O for a pojo
 
 then using 
 
 |[](O 
 is the DP approach where the [] interception is like
 the current EJB
 implementation and what Hiram was proposing to do in
 the very beginning
 
 ([]O 
 is the current AOP approach for POJO's.  
 
 
 There shouldn't be a war in these two approaches and
 the interface one
 should systematically use DP
 
 marcf
 


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
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] Eclipse is so amazing...

2003-02-27 Thread Hiram Chirino

Well, if you are willing to shell out some cash, then
you might consider trying webshpere studio.  Since
it's built on eclipse, it has all the eclipse goodies
plus a ton of other stuff like a jsp editor.

Regards,
Hiram

--- Aleksandr Shneyderman [EMAIL PROTECTED]
wrote:
  Hate to say this but netbeans (www.netbeans.org)
 beats eclipse hands down.
 
 Hate to tell you but that thing is just damn slow.
 What amazes me is that no matter how much RAM your 
 machine has NetBeans is just always hungry for it. 
 
  Does all of the below and lots more. Go take a
 look at the module 
  selection
  at www.netbeans.org/devhome and
 

http://www.netbeans.org/devhome/modules/by-module.html
 
 I am not sure about much more, but one thing I miss 
 from there is JSP editor. I have not seen any decent
 eclipse JSP plugin yet.
 
 
 
 

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


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
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] Eclipse is so amazing...

2003-02-26 Thread Hiram Chirino

+1 I use it all them time.  The Refactoring support
and the Quick Assist features rock.

Regards,
Hiram

--- Jason Dillon [EMAIL PROTECTED] wrote:
 I can not believe how fast, intelligent and
 functional this little IDE. 
   I have tears in my eyes I am so pleased.  Okay
 perhaps I need to get 
 out more... but still.  I think I am going to have
 to say goodbye to 
 XEmacs.  Perhaps I am just getting old and lazy...
 
 --jason
 
 
 

---
 This SF.net email is sponsored by: Scholarships for
 Techies!
 Can't afford IT training? All 2003 ictp students
 receive scholarships.
 Get hands-on training in Microsoft, Cisco, Sun,
 Linux/UNIX, and more.
 www.ictp.com/training/sourceforge.asp
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]

https://lists.sourceforge.net/lists/listinfo/jboss-development


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] Eclipse is so amazing...

2003-02-26 Thread Hiram Chirino

I've tried it various ways.. lately I've been doing
the following:

- compile source code manualy.  
- adjust eclipse build path by: adding the source
folders of sub projects that I will be working with as
source folders.  (the default is no good)
- adjust eclipse build path by: adding all the jars in
the build/output/jboss*/lib and 
build/output/jboss*/client and
build/output/jboss*/server/all/lib directories to the
project classpath.

Regards,
Hiram

--- Nathan Phelps [EMAIL PROTECTED] wrote:
 While we're on the subject of Eclipse...
 
 Can anyone give me some tips for working with the
 JBoss source in
 Eclipse via the built-in extssh client?  I can get
 it all checked out,
 but then it gets very confused about the package
 names.  It tries to do
 j2ee.src.main.org.jboss.j2ee,
 messaging.src.main.org.jboss.mq, etc.  I
 guess it wants individual projects for each
 directory?
 
 I was hoping to set it up as a SINGLE project so I
 can just check out
 the source and start working.  I read the The
 Developing JBoss using
 Eclipse HOWTO, but it only explores setting it up
 as multiple projects.
 This question is echoed on the forums as well at

http://www.jboss.org/forums/thread.jsp?forum=162thread=28822.
 
 Up to now I've been using NetBeans, but I'd really
 like to get this up
 and running on Eclipse with the JBoss IDE plug-in
 and all if possible.
 
 Thanks,
 
 Nathan
 
 
 

---
 This SF.net email is sponsored by: Scholarships for
 Techies!
 Can't afford IT training? All 2003 ictp students
 receive scholarships.
 Get hands-on training in Microsoft, Cisco, Sun,
 Linux/UNIX, and more.
 www.ictp.com/training/sourceforge.asp
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]

https://lists.sourceforge.net/lists/listinfo/jboss-development


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Eclipse is so amazing...

2003-02-26 Thread Hiram Chirino

--- Jason Dillon [EMAIL PROTECTED] wrote:
 I think it is better to use the jars from the module
 output directory, 
 cause the exact location under build/output will
 change from version to 
 version.
 

true.. but it's easier to do a multiple selection in 2
or 3 directories rather than going through each
project.

 Is there any way to make Eclipse create jars?  Or
 any way to make it 

I think you can select a set of packages/classes and
then use the export feature to export them to a jar. 
But I don't think this is what you are looking for.

 conditionally compile stuff for 1.3 and others for
 1.4? Or a way to 

not that I know of

 force it to use ant to do all compiles?  Seems like
 that would be best 
 to solve most problems.

I've been able to get it to run our ant build files
directly.  You might have to go into the eclipse
properties and add all the tools/lib/*.jar files to
the ANT runtime classpath.

 
 So far I am pretty happy, but it is by no means
 perfect.
 

I agree.

Regards,
Hiram

 --jason
 
 
 On Thursday, February 27, 2003, at 03:42  AM, Hiram
 Chirino wrote:
 
 
  I've tried it various ways.. lately I've been
 doing
  the following:
 
  - compile source code manualy.
  - adjust eclipse build path by: adding the source
  folders of sub projects that I will be working
 with as
  source folders.  (the default is no good)
  - adjust eclipse build path by: adding all the
 jars in
  the build/output/jboss*/lib and
  build/output/jboss*/client and
  build/output/jboss*/server/all/lib directories to
 the
  project classpath.
 
  Regards,
  Hiram
 
  --- Nathan Phelps [EMAIL PROTECTED] wrote:
  While we're on the subject of Eclipse...
 
  Can anyone give me some tips for working with the
  JBoss source in
  Eclipse via the built-in extssh client?  I can
 get
  it all checked out,
  but then it gets very confused about the package
  names.  It tries to do
  j2ee.src.main.org.jboss.j2ee,
  messaging.src.main.org.jboss.mq, etc.  I
  guess it wants individual projects for each
  directory?
 
  I was hoping to set it up as a SINGLE project so
 I
  can just check out
  the source and start working.  I read the The
  Developing JBoss using
  Eclipse HOWTO, but it only explores setting it
 up
  as multiple projects.
  This question is echoed on the forums as well at
 
 

http://www.jboss.org/forums/thread.jsp?forum=162thread=28822.
 
  Up to now I've been using NetBeans, but I'd
 really
  like to get this up
  and running on Eclipse with the JBoss IDE plug-in
  and all if possible.
 
  Thanks,
 
  Nathan
 
 
 
 
 

---
  This SF.net email is sponsored by: Scholarships
 for
  Techies!
  Can't afford IT training? All 2003 ictp students
  receive scholarships.
  Get hands-on training in Microsoft, Cisco, Sun,
  Linux/UNIX, and more.
  www.ictp.com/training/sourceforge.asp
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
 
 

https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
  __
  Do you Yahoo!?
  Yahoo! Tax Center - forms, calculators, tips, more
  http://taxes.yahoo.com/
 
 
 

---
  This SF.net email is sponsored by: Scholarships
 for Techies!
  Can't afford IT training? All 2003 ictp students
 receive scholarships.
  Get hands-on training in Microsoft, Cisco, Sun,
 Linux/UNIX, and more.
  www.ictp.com/training/sourceforge.asp
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
 

https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 

---
 This SF.net email is sponsored by: Scholarships for
 Techies!
 Can't afford IT training? All 2003 ictp students
 receive scholarships.
 Get hands-on training in Microsoft, Cisco, Sun,
 Linux/UNIX, and more.
 www.ictp.com/training/sourceforge.asp
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]

https://lists.sourceforge.net/lists/listinfo/jboss-development


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread

2003-02-25 Thread Hiram Chirino
How about implementing some kind of seperate interceptor framwork around the client side and server side invocation layers??
David, if yoiu had a configurable way to plug in your tx interceptors at the invocation layer you would be ok right? I think david just needs to avoid duplicating the code that is in the trunk invoker all over the place.
Bill, how doable is that?
Regards,Hiram
Bill Burke [EMAIL PROTECTED] wrote: 
IMHO, CORE client interceptors such as security and tx should be writtensuch that if the client doesn't support interceptors (C++) you don't breakthe server side or put additional configuration requirements on the serverside.BillDo you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more

RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread

2003-02-25 Thread Hiram Chirino
I though what I sugested was KISS.  Tx imporation is
currently done at the invoker level.  I want to keep
it there but make it plugable via interceports at the
invoker level.

I guess it would be more KISS to just duplicate the
code that is in the trunk invoker over to all ther
other java based transports.  But that seems more
error prone to me.

Regards,
Hiram

--- Bill Burke [EMAIL PROTECTED] wrote:
 What I'm saying is, why add this complication?  Do
 we really need it?  KISS.
   -Original Message-
   From:
 [EMAIL PROTECTED]

[mailto:[EMAIL PROTECTED]
 Behalf Of Hiram
 Chirino
   Sent: Tuesday, February 25, 2003 11:23 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] TxInterceptor split is
 still the best thing since
 sliced bread
 
 
   How about implementing some kind of seperate
 interceptor framwork around
 the client side and server side invocation layers??
 
   David, if yoiu had a configurable way to plug in
 your tx interceptors at
 the invocation layer you would be ok right?  I think
 david just needs to
 avoid duplicating the code that is in the trunk
 invoker all over the place.
 
   Bill, how doable is that?
 
   Regards,
   Hiram
 
Bill Burke [EMAIL PROTECTED] wrote:
 
 
 
 IMHO, CORE client interceptors such as security
 and tx should be written
 such that if the client doesn't support
 interceptors (C++) you don't
 break
 the server side or put additional configuration
 requirements on the
 server
 side.
 
 
 Bill
 
 
 
 
 
 
 
 


 --
   Do you Yahoo!?
   Yahoo! Tax Center - forms, calculators, tips, and
 more
 


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
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] TxInterceptor split is really really bad

2003-02-21 Thread Hiram Chirino

I have to disagree.  Take a higher level look at the
basics: All client proxies have a dependency on their
corresponsing server side stub.  You can't mix a
different proxys and stub types.  Therefore it is ok
for a client side interceptor to have a dependency on
the server side interceptor.

Can you describe your AOP problem in more detail.  How
are you going to be remoting POJO with AOP??  With a
proxy?  Who will create the proxy objet?

Regards,
Hiram

--- Bill Burke [EMAIL PROTECTED] wrote:
 Ok, maybe I shouldn't have said fatally flawed. 
 But again, my gut tells
 me that it is bad to have a dependency between
 server and client
 interceptors if it is not absolutely needed.
 
  -Original Message-
  From:
 [EMAIL PROTECTED]
 

[mailto:[EMAIL PROTECTED]
 Behalf Of Bill
  Burke
  Sent: Friday, February 21, 2003 4:12 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] TxInterceptor split is
 really really bad
 
 
  I've been thinking and should have posted this
 before.  Your design is
  fataly flawed when I start applying it to the AOP
 framework.  Your design
  assumes that there is a proxy sitting in front of
 everything.  In AOP this
  is not the case.  If you look at
  varia/src/org/jboss/aop/plugins/TxSupport.java
 you'll see that I had to
  combine the clientInvoke and serverInvoke into one
 method because there is
  no proxy object between the application code and
 the object instance.
 
  Ok...no problem you sayWell, think of what
 happens when the app
  developer decides to remote an AOP'd object.  I
 will have to have
  2 sets of
  interceptor chains and have to figure out whether
 the call is a
  remote call
  or local.  Well, I guess I could insert a flag
 into the Invocation on
  whether the call went through a proxy or not.  But
 do you see where I'm
  going?  I don't think its a good design to rely on
 the client to handle
  transaction semantics.  I don't think its a good
 idea for the server to
  have to rely on client logic unless it really has
 to.
 
  All and all, my gut tells me that the current
 client/tx design will cause
  problems.  I want interceptor designers in general
 to avoid this kind of
  dependency.
 
  Bill
 
   -Original Message-
   From:
 [EMAIL PROTECTED]
  

[mailto:[EMAIL PROTECTED]
 Behalf Of David
   Jencks
   Sent: Wednesday, February 19, 2003 11:02 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] TxInterceptor split is
 really really good
  
  
   On 2003.02.19 09:37 Bill Burke wrote:

 What you implemented is fine. My only
 problem with it is that I
 think it is more logical to let the server
 decide if it needs the
 tx, and that I think the registration
 callback could be avoided
 (with minimal redundant client side
 bookkeeping) even if the
 decision is made on the server side.

 I got the impression that this
 implementation would also be used
 in the other invokers, and that made me
 worry about CORBA
 interoperability. If this approach will not
 be used with the IIOP
 invoker, I have no problem with it.

   
Yes this was my exact worry and still is. 
 That we'll have to have a
different set of interceptors on the server
 side for different
transports.
This is unexceptable because we want each EJB
 to be able to
   listen to and
service calls from different transports at the
 same time.
   
David, I'm not suggesting to redesign your
 code, but is the design
flexible
enough so that we could switch to a
 server-side based design?
   Iteration
is
a fine thing
  
   I don't think we will have problems adapting my
 current design to use
   corba.  Before we continue I think we should get
 a clear
  understanding of
   what is supposed to happen when the corba tx
 policy and the j2ee
   tx support
   disagree.  Does anyone know where this is
 described in specs?
  
   Basically the corba design says if there is a
 transaction in
  the context
   it must always be transmitted and imported on
 the server whereas
   j2ee does
   not always need to import the tx.  The purpose
 of the client side
   interceptor is to not generate tx branches that
 won't be used.  I think
   that any reasonable corba implementation is
 going to follow corba
   semantics
   and always generate a transaction branch on the
 client for the
   remote call,
   since as far as the corba spec goes, if the call
 is made within a tx the
   transaction will in fact be used on the server.
  
   In my view the heaviest part of the process is
 generating a tx branch on
   the client: once it is generated, then it has to
 be prepared and/or
   committed.  The communication overhead on these
 messages is
   likely to dwarf
   any other resource usage.
  
   The choices I can see here are:
  
   1. only generate the branch if it is needed, but
 do it right
   away.  This is
   what I implemented and I think it is simplest
 and the only one that is
   likely to be comprehensible 

RE: [JBoss-dev] TxInterceptor split is really really bad

2003-02-21 Thread Hiram Chirino
  I have to disagree.  Take a higher level look at
 the
  basics: All client proxies have a dependency on
 their
  corresponsing server side stub.  You can't mix a
 
 Yes, obviously, but the old tx client proxy just
 stuffed the tx context in

Orthoganal problem.  The ability to have smarter
client proxies that have highly coupled interations
with a serverside components is a requirment that
everybody will agree with.

 the invocation.  The problem with AOP is that (at
 least for 1st iteration)
 the POJO can be accessed directly and through a
 proxy at the same time.

This might sound a little crazy... but how about
allowing multiple server-side interceptor stacks per
object?  One for local access, one for stuff over IIOP
(that does tx the ots way), one for stuff over JRMP
etc.

 yes, I can work around this by having a flag in the
 Invocation object on
 whether or not the invocation passed through a
 proxy, but IMHO, this is a
 hack.

yes. I am starting to agree.

 
  different proxys and stub types.  Therefore it is
 ok
  for a client side interceptor to have a dependency
 on
  the server side interceptor.
 
  Can you describe your AOP problem in more detail. 
 How
  are you going to be remoting POJO with AOP??  With
 a
  proxy?  Who will create the proxy objet?
 
 
 1st iteration, DynamicProxy.  This is trivial since
 we have already done
 this sort of thing for EJB and how to do AOP (or how
 to do it wrong, depends
 how you look at it), is already there for us to see.
  Remote AOP with DP is
 just an iteration to me from the current EJB stuff.
 
 2nd iteration will be with all java classes.  The
 hard part will be how
 instrumentation works on the client side, how the
 client receives pointcuts
 and such.

In either case, I'm more intersted in WHO will be
responsible creaing proxy objects??  Will it be
automatic done when the object is serialized?  Or will
the application have to make an API call to get a
proxy??

Regards,
Hiram

 
 Bill
 
  Regards,
  Hiram
 
  --- Bill Burke [EMAIL PROTECTED] wrote:
   Ok, maybe I shouldn't have said fatally
 flawed.
   But again, my gut tells
   me that it is bad to have a dependency between
   server and client
   interceptors if it is not absolutely needed.
  
-Original Message-
From:
   [EMAIL PROTECTED]
   
  
 

[mailto:[EMAIL PROTECTED]
   Behalf Of Bill
Burke
Sent: Friday, February 21, 2003 4:12 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split
 is
   really really bad
   
   
I've been thinking and should have posted this
   before.  Your design is
fataly flawed when I start applying it to the
 AOP
   framework.  Your design
assumes that there is a proxy sitting in front
 of
   everything.  In AOP this
is not the case.  If you look at
varia/src/org/jboss/aop/plugins/TxSupport.java
   you'll see that I had to
combine the clientInvoke and serverInvoke into
 one
   method because there is
no proxy object between the application code
 and
   the object instance.
   
Ok...no problem you sayWell, think of what
   happens when the app
developer decides to remote an AOP'd object. 
 I
   will have to have
2 sets of
interceptor chains and have to figure out
 whether
   the call is a
remote call
or local.  Well, I guess I could insert a flag
   into the Invocation on
whether the call went through a proxy or not. 
 But
   do you see where I'm
going?  I don't think its a good design to
 rely on
   the client to handle
transaction semantics.  I don't think its a
 good
   idea for the server to
have to rely on client logic unless it really
 has
   to.
   
All and all, my gut tells me that the current
   client/tx design will cause
problems.  I want interceptor designers in
 general
   to avoid this kind of
dependency.
   
Bill
   
 -Original Message-
 From:
   [EMAIL PROTECTED]

  
 

[mailto:[EMAIL PROTECTED]
   Behalf Of David
 Jencks
 Sent: Wednesday, February 19, 2003 11:02 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] TxInterceptor split
 is
   really really good


 On 2003.02.19 09:37 Bill Burke wrote:
  
   What you implemented is fine. My only
   problem with it is that I
   think it is more logical to let the
 server
   decide if it needs the
   tx, and that I think the registration
   callback could be avoided
   (with minimal redundant client side
   bookkeeping) even if the
   decision is made on the server side.
  
   I got the impression that this
   implementation would also be used
   in the other invokers, and that made me
   worry about CORBA
   interoperability. If this approach will
 not
   be used with the IIOP
   invoker, I have no problem with it.
  
 
  Yes this was my exact worry and still is.
   That we'll have to have a
  different set of interceptors on the
 server
   side for different
  

RE: [JBoss-dev] TxInterceptor split is really really bad

2003-02-21 Thread Hiram Chirino

--- Bill Burke [EMAIL PROTECTED] wrote:
 
 
  I would like to note that my future plans for this
 involve method specific
  interceptor chains with a variety of client side
 and server side tx
  interceptors, each one performing half of the
 TxSupport work.  No maps,
  just different specialized interceptors, with
 different interceptors per
  method depending on the tx support.
 
 
 H...thanks for mentioning this.  The AOP
 framework will have to change
 to support his type of per method intercepiton.
 
 Currently the ClassAdvisor asks the
 InterceptorFactory for an instance of an
 Interceptor and adds it to the interceptor chain. 
 For what you want to do,
 this will have to change.  The InterceptorFactory
 should be responsible for
 adding interceptors to the chain.  Otherwise, my
 isolation and separation of
 metadata, interceptors, and pointcuts will be
 broken.
 

I don't think that you model would be too broken. 
His interceptors should only hav to implement the
org.jboss.aop.InvocationFilterInterceptor interface:
boolean intercepts(Invocation invocation);

The org.jboss.aop.Invocation.invokeNext() will skip
over interceptors that do not interested the
invocation.  Currently invokeNext() interogates the
intercetors on every invocation, but I think that we
should be able to keep a per Invocation interceptor
stack cache so that we can skip the interogation after
the first method call.

 
  I also think you will admit that even in aop you
 could have two
  interceptors even if both were on the server side:
 one to get the tx from
  the context if appropriate or remove it if
 appropriate, one to start a new
  tx if appropriate.
 
 
 Yes, but I still have to figure out whether or not
 the method call went
 through a proxy or was a regular java method call.
 
 Bill
 
 
 
 

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


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
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] TxInterceptor split is really really bad

2003-02-21 Thread Hiram Chirino

--- Bill Burke [EMAIL PROTECTED] wrote:
  
  This might sound a little crazy... but how about
  allowing multiple server-side interceptor stacks
 per
  object?  One for local access, one for stuff over
 IIOP
  (that does tx the ots way), one for stuff over
 JRMP
  etc.
 
 
 In the long run, maybe this can't be avoided, but I
 would like to avoid it.
 

What are the problems related in implementing this??

Regards.
Hiram

__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


---
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] Why are we using this bogus construct

2003-02-13 Thread Hiram Chirino
Looks like you might be digging through some mq code
:)

I don't think that construct is too bogus...  It
provides a copy write hashmap.  Once the hashmap has
been updated, the rest of the read methods can treat
the hashmap as an imutable.  No one will update that
hashmap ever again.  To update it, you have to
generate another copy.

This is very good when you are reading the map 90% of
the time and updating it 10%.  I don't see why this is
not thread safe.

Regards,
Hiram

--- Scott M Stark [EMAIL PROTECTED] wrote:
 I have seen this usage construct in a few places in
 the code and it makes
 no sense to me:
 
 class X
 {
 HashMap clients = new HashMap();
 
 public void someMethod()
 {
synchronized(clients)
 {
 HashMap m = new HashMap(clients);
 m.put(dc, cq);
 clients=m;
}
 ...
 }
 public void someOtherMethod()
 {
 Iterator i = clients.keySet().iterator();
 while( i.hasNext() )
 {
 ...
 }
 }
 }
 
 The unsynchronized clients HashMap is synchronized
 and copied when
 modified and accessed without synchronization in
 other contexts. This is
 not thread safe for the accesses and makes for very
 expensive updates.
 Why isn't the HashMap simply synchronized and used
 without copying?
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 
 

---
 This SF.NET email is sponsored by: FREE  SSL Guide
 from Thawte
 are you planning your Web Server Security? Click
 here to get a FREE
 Thawte SSL guide and find the answers to all your 
 SSL security issues.

http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]

https://lists.sourceforge.net/lists/listinfo/jboss-development


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Why are we using this bogus construct

2003-02-13 Thread Hiram Chirino
Yep.. your way is valid too but you take a
synchronization hit on every read.  The otherway, the
performace hit is on the write.  As I said previously,
if you read the map ALLOT more than you write to it,
then it makes sense to do it backwards.

Regards,
Hiram

--- Dain Sundstrom [EMAIL PROTECTED] wrote:
 This seems backwards to me.  I usually do something
 like this:
 
 class X
 {
  HashMap clients = new HashMap();
 
  public void someMethod()
  {
 synchronized(clients)
 {
  m.put(dc, cq);
 }
  ...
  }
  public void someOtherMethod()
  {
  HashMap clientsCopy = null;
  synchronized(clients)
  {
  clientsCopy = new HashMap(clients);
  }
  Iterator i =
 clientsCopy.keySet().iterator();
  while( i.hasNext() )
  {
  ...
  }
  }
 }
 
 For the insert, you only get a quick synchronized
 around the add, and 
 on iteration you get a single copy in the
 synchronize.  If the 
 iteration very small and quick, I sometimes put the
 entire iteration in 
 the synchronized block, but you need to be careful
 about open calls.
 
 -dain
 
 On Thursday, February 13, 2003, at 11:20 AM, Scott M
 Stark wrote:
 
  I have seen this usage construct in a few places
 in the code and it 
  makes
  no sense to me:
 
  class X
  {
  HashMap clients = new HashMap();
 
  public void someMethod()
  {
 synchronized(clients)
  {
  HashMap m = new HashMap(clients);
  m.put(dc, cq);
  clients=m;
 }
  ...
  }
  public void someOtherMethod()
  {
  Iterator i = clients.keySet().iterator();
  while( i.hasNext() )
  {
  ...
  }
  }
  }
 
  The unsynchronized clients HashMap is synchronized
 and copied when
  modified and accessed without synchronization in
 other contexts. This 
  is
  not thread safe for the accesses and makes for
 very expensive updates.
  Why isn't the HashMap simply synchronized and used
 without copying?
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
 
 

---
  This SF.NET email is sponsored by: FREE  SSL Guide
 from Thawte
  are you planning your Web Server Security? Click
 here to get a FREE
  Thawte SSL guide and find the answers to all your 
 SSL security issues.
 

http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
 

https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 

---
 This SF.NET email is sponsored by: FREE  SSL Guide
 from Thawte
 are you planning your Web Server Security? Click
 here to get a FREE
 Thawte SSL guide and find the answers to all your 
 SSL security issues.

http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]

https://lists.sourceforge.net/lists/listinfo/jboss-development


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Why are we using this bogus construct

2003-02-13 Thread Hiram Chirino
good point.  I'll have to review the code in more
detail.

--- Dain Sundstrom [EMAIL PROTECTED] wrote:
 Hiram,
 
 This type of construct creates some trick code. You
 iterate over the 
 keys, and I assume somewhere in the code you do
 clients.get(key).  Well 
 there is no guarantee the the key is associated.  I
 bet there are a ton 
 of other issues as your iterator in the read phase
 drifts from reality 
 of changing clients HashMap.  Anyway, I hope you
 documented this 
 heavily.
 
 -dain
 
 On Thursday, February 13, 2003, at 12:28 PM, Hiram
 Chirino wrote:
 
  Yep.. your way is valid too but you take a
  synchronization hit on every read.  The otherway,
 the
  performace hit is on the write.  As I said
 previously,
  if you read the map ALLOT more than you write to
 it,
  then it makes sense to do it backwards.
 
  Regards,
  Hiram
 
  --- Dain Sundstrom [EMAIL PROTECTED] wrote:
  This seems backwards to me.  I usually do
 something
  like this:
 
  class X
  {
   HashMap clients = new HashMap();
 
   public void someMethod()
   {
  synchronized(clients)
  {
   m.put(dc, cq);
  }
   ...
   }
   public void someOtherMethod()
   {
   HashMap clientsCopy = null;
   synchronized(clients)
   {
   clientsCopy = new HashMap(clients);
   }
   Iterator i =
  clientsCopy.keySet().iterator();
   while( i.hasNext() )
   {
   ...
   }
   }
  }
 
  For the insert, you only get a quick synchronized
  around the add, and
  on iteration you get a single copy in the
  synchronize.  If the
  iteration very small and quick, I sometimes put
 the
  entire iteration in
  the synchronized block, but you need to be
 careful
  about open calls.
 
  -dain
 
  On Thursday, February 13, 2003, at 11:20 AM,
 Scott M
  Stark wrote:
 
  I have seen this usage construct in a few places
  in the code and it
  makes
  no sense to me:
 
  class X
  {
  HashMap clients = new HashMap();
 
  public void someMethod()
  {
 synchronized(clients)
  {
  HashMap m = new HashMap(clients);
  m.put(dc, cq);
  clients=m;
 }
  ...
  }
  public void someOtherMethod()
  {
  Iterator i =
 clients.keySet().iterator();
  while( i.hasNext() )
  {
  ...
  }
  }
  }
 
  The unsynchronized clients HashMap is
 synchronized
  and copied when
  modified and accessed without synchronization in
  other contexts. This
  is
  not thread safe for the accesses and makes for
  very expensive updates.
  Why isn't the HashMap simply synchronized and
 used
  without copying?
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
 
 
 
 

---
  This SF.NET email is sponsored by: FREE  SSL
 Guide
  from Thawte
  are you planning your Web Server Security? Click
  here to get a FREE
  Thawte SSL guide and find the answers to all
 your
  SSL security issues.
 
 
 

http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
 
 
 

https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 

---
  This SF.NET email is sponsored by: FREE  SSL
 Guide
  from Thawte
  are you planning your Web Server Security? Click
  here to get a FREE
  Thawte SSL guide and find the answers to all your
  SSL security issues.
 
 

http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
 
 

https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
  __
  Do you Yahoo!?
  Yahoo! Shopping - Send Flowers for Valentine's Day
  http://shopping.yahoo.com
 
 
 

---
  This SF.NET email is sponsored by: FREE  SSL Guide
 from Thawte
  are you planning your Web Server Security? Click
 here to get a FREE
  Thawte SSL guide and find the answers to all your 
 SSL security issues.
 

http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
 

https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
=== message truncated ===


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security

Re: [JBoss-dev] JMS and JSR77 stats mismatch

2003-02-13 Thread Hiram Chirino
Arhh...  It would be simpler if the JMX objects were
updated from client side.  But since that is out of
the question for now, I'll just give you a few
sugestions:

- fake the session problem out and say there is
allways 1 session.  
- Try to put the JSR77 code in an interceptor (like
the TracingInterceptor).  
- To count the messages received, monitor message
acks.. they are the confimations that the messages
were processed ok.

Regards,
Hiram

--- Scott M Stark [EMAIL PROTECTED] wrote:
 JSR77 wants to provide a top down view of the JMS
 stats as shown in
 the attached pdf page showing the JMSStats interface
 model:
 
 JMSStats - JMSConnectionStats[] -
 JMSSessionStats[] - {JMSProduerStats[],
 JMSConsumerStats[],
 messageCount, pendingMessageCount,
 expiredMessageCount, messageWaitTime{min, max,
 total},
 durableSubscriptionCount}
 
 JMSProduerStats - {name, messageCount,
 pendingMessageCount, expiredMessageCount,
 messageWaitTime{min, max, total}}
 JMSConsumerStats - {name, messageCount,
 pendingMessageCount, expiredMessageCount,
 messageWaitTime{min, max, total}}
 
 We don't seem to have a real good representation of
 a session on the server.
 I have looked at adding a basic
 connection/{producer/messageCount,
 consumer/messageCount} point
 using the JMSDestinationManager addMessage and
 receive methods using something like:
 
public void addMessage(ConnectionToken dc,
 SpyMessage val, Tx txId) throws JMSException
{
   JMSDestination queue =

(JMSDestination)destinations.get(val.getJMSDestination());
 ...
   // Update the client stats
   String destName =
 queue.getSpyDestination().getName();
   ClientStats stats = (ClientStats)
 clientStats.get(dc);
   if( stats != null )
   {
  stats.incProducerCount(destName);
   }
}
 
public SpyMessage receive(ConnectionToken dc, int
 subscriberId, long wait) throws JMSException
{
   ClientConsumer clientConsumer =
 getClientConsumer(dc);
   SpyMessage msg =
 clientConsumer.receive(subscriberId, wait);
   JMSDestination queue =

(JMSDestination)destinations.get(msg.getJMSDestination());
   // Update the client stats
   String destName =
 queue.getSpyDestination().getName();
   ClientStats stats = (ClientStats)
 clientStats.get(dc);
   if( stats != null )
   {
  stats.incConsumerCount(destName);
   }
   return msg;
}
 
 which might be ok for an initial cut but it leaves a
 lot of seemingly difficult to gather wait
 times. Any better ideas on how to provide more of
 this information?
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 

 ATTACHMENT part 2 application/pdf name=JMSStats.pdf



__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] TxInterceptor split is bad

2003-02-12 Thread Hiram Chirino
--- Bill Burke [EMAIL PROTECTED] wrote:
 What if you don't have java on the client side? 
 What if you're CORBA with
 OTS?  You're making it harder for Non-JBoss/Java
 clients to integrated with
 us.  I think this split should be undone.
 

How des OTS work?  The corba guys tackled the DTM
problem too right??

 BTW, why the split besides code readability?  Is the
 DTM dependent on this
 at all?  Is the TM even accessed on the client side?
 

I think so.  In the case were a client is a server the
local TM is accessed to treat the remote TM like a
XAResource.

 Another problem I see is that the TxMethod map is
 required on the client
 side as well.  Makes proxies even more heavy and
 what do you do about a hot
 deploy?
 

Yes.. but same argument could be made against any
client side interceptor we create.  The proxy on the
client goes stale if a redeploy changes the proxy
config.

 Seems to me this is a bad idea.
 

I agree it is a complex solution.  But the DTM problem
is complex too.  Any simpler sugestions??

Regards,
Hiram

 Bill
 
 
 

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

https://lists.sourceforge.net/lists/listinfo/jboss-development


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


---
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] TxInterceptor split is bad

2003-02-12 Thread Hiram Chirino
 Actually the code is much more readable.  I guess my
 only concern now is
 non-java/jboss clients.  And, do we care?
 

Non java code will have a seperate server-side invoker
and it should deal with the TX stuff as best it can. 
In otherwords, do it the old way if it works better
for corba.

 Another thing about this is that you're requiring
 the client to become
 beafier and beafier.  I've been kinda nervous about
 the whole JMX on the
 client sort of thing and the start of deploying
 services on the client side.
 But maybe it doesn't matter.
 

Ahh.. but that's the future.  Unfortuanly, smarter
clients means beefier clients.  The chalenge will be
to setup the plumbing that will allows us to create
those smart clients without having to worry about
thier size and distribution.  In other words, the
plumbing should take care of the heavy/stale proxy
problem.

 Bill
 
 P.S.  Good to see you around again Hiram.
 

I went back to using an online mail service.  Checking
email only at night would really kill my response
times.

Regards,
Hiram


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


---
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] TxInterceptor split is bad AND broken?

2003-02-12 Thread Hiram Chirino
The transaction is not getting propagated across the
wire.  A new XID is what is getting propagated. 
Remember that an XID != the tx.  The relationship is
that a tx will have multiple XIDs (one ore each
resource that is involved in the tx).

David is treating the remote jboss server like any
other transacted resource.  He enists the XAResource
of the remote server, and gives that XAResource a new
XID.

Since remote tm is providing an XAResource interface
to the remote tx, the local tm can commit/rollback the
remote tx via a 2pc.  

David, I hope that was accurate since I have not
really looked at your code!

Regards,
Hiram
--- Bill Burke [EMAIL PROTECTED] wrote:
 Ok, I'm looking at the code further and I'm pretty
 confused on how a
 Transaction get propagated across the wire now.  Can
 you explain?  I don't
 see any code anywhere that is doing a tm.resume from
 the transaction that is
 past across the wire.  Is this code broken?
 
 Bill
 
 
  -Original Message-
  From: Bill Burke [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, February 12, 2003 5:51 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] TxInterceptor split is
 bad
 
 
  Another thing David,
 
  I don't see you always stuffing the Transaction
 into the
  invocation object.  A few interceptors rely on the
 transaction
  being in the invocation object.  Any objects to
 fixing this?
 
  Bill
 
   -Original Message-
   From:
 [EMAIL PROTECTED]
  

[mailto:[EMAIL PROTECTED]]On
 Behalf Of Bill
   Burke
   Sent: Wednesday, February 12, 2003 5:36 PM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] TxInterceptor split is
 bad
  
  
  
  
-Original Message-
From:
 [EMAIL PROTECTED]
   

[mailto:[EMAIL PROTECTED]]On
  Behalf Of Hiram
Chirino
Sent: Wednesday, February 12, 2003 5:09 PM
To: [EMAIL PROTECTED];
 David Jencks
Subject: Re: [JBoss-dev] TxInterceptor split
 is bad
   
   
--- Bill Burke [EMAIL PROTECTED] wrote:
 What if you don't have java on the client
 side?
 What if you're CORBA with
 OTS?  You're making it harder for
 Non-JBoss/Java
 clients to integrated with
 us.  I think this split should be undone.

   
How des OTS work?  The corba guys tackled the
 DTM
problem too right??
   
  
   They have the concept of a ThreadLocal (Current)
  (My knowledge
   is probably
   outdated and foggy).  In O2K the client side
 interceptor stuffs
  the value
   from the transaction current into the IIOP
 service context,
  much the same
   way we used to do before David's switch.
  
   -1 for refactor
  
 BTW, why the split besides code readability?
  Is the
 DTM dependent on this
 at all?  Is the TM even accessed on the
 client side?

   
I think so.  In the case were a client is a
 server the
local TM is accessed to treat the remote TM
 like a
XAResource.
   
  
   +1 for refactor
  
 Another problem I see is that the TxMethod
 map is
 required on the client
 side as well.  Makes proxies even more heavy
 and
 what do you do about a hot
 deploy?

   
Yes.. but same argument could be made against
 any
client side interceptor we create.  The proxy
 on the
client goes stale if a redeploy changes the
 proxy
config.
   
  
   Ok, you're right. +2 for refactor
  
 Seems to me this is a bad idea.

   
I agree it is a complex solution.  But the DTM
 problem
is complex too.  Any simpler sugestions??
   
  
   Actually the code is much more readable.  I
 guess my only concern now is
   non-java/jboss clients.  And, do we care?
  
   Another thing about this is that you're
 requiring the client to become
   beafier and beafier.  I've been kinda nervous
 about the whole JMX on the
   client sort of thing and the start of deploying
 services on the
   client side.
   But maybe it doesn't matter.
  
   Bill
  
   P.S.  Good to see you around again Hiram.
  
  
  
  

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


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


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

RE: [JBoss-dev] [ jboss-Bugs-672543 ] depends-list does not work according to documentation

2003-01-22 Thread Hiram Chirino
dom4j has a stable 1.3 release.  You can see a comparison of a few doms
here: http://dom4j.org/compare.html

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
 M Stark
 Sent: Wednesday, January 22, 2003 4:37 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] [ jboss-Bugs-672543 ] depends-list does not
 work according to documentation


 I have concerns about a non-standard parser that has not seen a
 release in 9 months
 and is stuck at beta8. Yes its supposed to conform to JSR-102,
 but this was founded
 nearly two years ago and I can't find any status on this.  Is
 this really the best XML
 abstraction we can come up with?

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 

 - Original Message -
 From: David Jencks [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 22, 2003 9:14 AM
 Subject: Re: [JBoss-dev] [ jboss-Bugs-672543 ] depends-list does
 not work according to documentation


  Anyone mind if I rewrite the ServiceConfigurator et al to use JDOM
  instead of DOM?  I think there are too many of these stupid
 problems to
  fix economically using DOM.
 
  Thanks
  david jencks
 



 ---
 This SF.net email is sponsored by: Scholarships for Techies!
 Can't afford IT training? All 2003 ictp students receive scholarships.
 Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
 www.ictp.com/training/sourceforge.asp
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Transaction propagation change

2003-01-16 Thread Hiram Chirino

The original point was that JMS allows you transact the message put.  If the
message put is part of the global unit of work and it has not committed,
then no receiver can pick up the message (the put does not actually occur
till we commit).  This really has VERY little to do with the fact the jms is
asynchronous.

In all other respects you are correct.

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of marc
 fleury
 Sent: Wednesday, January 15, 2003 6:37 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] Transaction propagation change


 one of my favorite topics is coming up again
 One day I will sit down and write a tx spec.

 Ok frankly WHY DO WE CARE THAT MESSAGING IS ASYNCHRONOUS WITH RESPECT TO
 TRANSACTION.  Yeah I know the answer you could have a long running
 transaction and messages and queues and bla bla bla.  BS BS BS.

 So the method returns immediately.  SO WHAT? the listener that will pick
 up the message and act upon it may very well want to synchronize with
 the GLOBAL transaction going on in the web.  And commit or rollback
 according to the outcome.

 The scenario is simple.

 Image A does something and sends messages to n instances with a global
 transaction associated to it.

 n recievers get the message get the TPC and register with the global tx.
 If the global tx is still running then all good 2phi dance starts bla
 bla bla. if the tx is out (too old) then the guy who woke up late just
 says sorry can't register and possibly no one cares or he can notify
 (whatever the app rollback semantics are).

 AT A SYSTEM LEVEL I DONT SEE A REASON FOR THIS BAD IDEA SYNDROME. IN
 fact it always has struck me that there is NO WAY to propagate a TX with
 a message.

 you know what? this is something we can VERY easily do in JBoss.  Adding
 the message in the new rewrite may be the usual 'put an interceptor
 here' deal, once we make progress on the rewrite.

 But the point is simple, the asynchronous nature of the transport
 protocol should not have an impact on the definition of a web
 transaction.

 IN fact it is a requisite for web services (generic way)Tx definitions.

 Many threads TX!

 /water-walking

 marcf

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]] On
  Behalf Of danch
  Sent: Wednesday, January 15, 2003 6:18 PM
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] Transaction propagation change
 
 
  And having a way to do that would probably be a Bad Idea.
  Propogating a
  transaction through asynchronous transports doesn't sound like a good
  idea to me, anyway.
 
  -danch
 
  Hiram Chirino wrote:
   Just a small correction..  your example would have to be in
  at least 2
   units of work.  There is NO WAY to put a JMS message and
  get it again
   in a single transaction.
  
   Regards,
   Hiram
  
  
  Having a distributed transaction context is especially
  important for
  example when you have a EJB from one jboss instance posting
  a message
  to a JMS queue
  on another jboss instance that in turn has a MDB that calls
  another EJB on
  that second instance.  If I want that all to be under one
  transaction and
  thus rollback as one business unit of work, there is no way to do
  that (that
  i'm aware of) with native JBoss in the 3.x series.  I
  know one could use
  Tyrex, but the author doesn't recommend using Tyrex in a production
  environment and so I'm a little leary to use it myself.
  
  
 
 
 
 
  ---
  This SF.NET email is sponsored by: A Thawte Code Signing Certificate
  is essential in establishing user confidence by providing
  assurance of
  authenticity and code integrity. Download our Free Code
  Signing guide:
  http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0028en
 
 
  ___
  Jboss-development mailing list [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 



 ---
 This SF.NET email is sponsored by: A Thawte Code Signing Certificate
 is essential in establishing user confidence by providing assurance of
 authenticity and code integrity. Download our Free Code Signing guide:
 http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JBossMQ

2003-01-15 Thread Hiram Chirino

that sounds right..

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of John
 Fawcett
 Sent: Tuesday, January 14, 2003 8:14 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] JBossMQ
 
 
 Hi,
 
 I want to make sure I understand the asynchronous delivery mechanism.
 I've implemented my MessageConsumer to do the following:
 
 Add self to Connection's message consumer list
 While(consumer is open){
   while(server is delivering synchronously){
   Send Receive Requests until the Server is Drained
   }
   Wait for Asynch Delivery
 }
 
 
 Is this the proper pattern?
 Thanks,
 fawce
 
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of
 Hiram Chirino
 Sent: Friday, January 10, 2003 6:50 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] JBossMQ
 
 
 
 Your kinda right.  the loop is there for the case where the destination
 is queue based (p2p and durable subs).  The polling happens when the
 queue is full.  Now when the queue is not full (or in the pub sub case,
 there is no queue), then the thread goes into asynch mode and it waits
 for the message to get delivered async via the ClientIL.receive method.
 I'll comment the code a little:
 
// gets the next message in queue or registers us for asynch
 delivery if none available.
mes = session.connection.receive( subscription, 0 );
if ( mes == null ) // should always be null for pub-sub case.
{
   // start waiting for the message to get delivered asynch
   waitingForMessage = true;
   while ( ( messages.isEmpty()  !closed ) || (
 !session.running ) )
   {
  try
  {
 // messages gets signaled once ClientIL.receive finishes
 processing the message.
 messages.wait();
  } catch ( InterruptedException e )
  {
  }
   }
   if ( closed )
   {
  waitingForMessage = false;
  break outer;
   }
   // the message sent via ClientIL.receive should now be sitting
 in messages
   mes = ( SpyMessage )messages.removeFirst();
   waitingForMessage = false;
   }
 
 
 I hope that helped!  I think the XIL is great idea!  We might even be
 able to develop a c base API to access mq services (important in the
 integration space).
 
 Regards,
 Hiram
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of 
  John Fawcett
  Sent: Thursday, January 09, 2003 8:09 PM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] JBossMQ
 
 
  Hi,
 
  I am working on a new invocation layer (IL) for JbossMQ that encodes 
  all communication in Xml (XIL). I've got the IL pretty near 
  completion, and I am working on a C# jbossmq client.  I am trying to 
  develop the TopicSubsciber, which is an extension of MessageConsumer. 
  In reviewing the code in the jbossmq java sources, it looks to me like
 
  the client to a topic actually runs a loop sending receive requests to
 
  the server regularly.
 
  Is this really necessary? Once the connection has been established, 
  why can't the server just invoke the ClientIL.receive method (which 
  actually sends the message to the client) when a message arrives at 
  the destination? It looks to me like the current implementation is not
 
  truly asynchronous...
  What am I missing?
 
  Thanks,
  fawce
 
 
  -
  John Fawcett
  CTO, Tamale Software, LLC
  26 Fox Road
  Waltham, MA 02451
 
 
 
  ---
  This SF.NET email is sponsored by:
  SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! 
  http://www.vasoftware.com 
  ___
  Jboss-development mailing list [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 ---
 This SF.NET email is sponsored by:
 SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
 http://www.vasoftware.com
 ___
 Jboss-development mailing list [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 ---
 This SF.NET email is sponsored by: Take your first step towards giving 
 your online business a competitive advantage. Test-drive a Thawte SSL 
 certificate - our easy online guide will show you how. Click here to get 
 started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.NET email is sponsored by: Take your first step towards giving 
your online

RE: [JBoss-dev] Transaction propagation change

2003-01-15 Thread Hiram Chirino

Just a small correction..  your example would have to be in at least 2 units
of work.  There is NO WAY to put a JMS message and get it again in a single
transaction.

Regards,
Hiram

 Having a distributed transaction context is especially important
 for example
 when you have a EJB from one jboss instance posting a message to
 a JMS queue
 on another jboss instance that in turn has a MDB that calls another EJB on
 that second instance.  If I want that all to be under one transaction and
 thus rollback as one business unit of work, there is no way to do
 that (that
 i'm aware of) with native JBoss in the 3.x series.  I know one could use
 Tyrex, but the author doesn't recommend using Tyrex in a production
 environment and so I'm a little leary to use it myself.







---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JBossMQ

2003-01-10 Thread Hiram Chirino

Your kinda right.  the loop is there for the case where the destination is
queue based (p2p and durable subs).  The polling happens when the queue is
full.  Now when the queue is not full (or in the pub sub case, there is no
queue), then the thread goes into asynch mode and it waits for the message
to get delivered async via the ClientIL.receive method.  I'll comment the
code a little:

   // gets the next message in queue or registers us for asynch delivery
if none available.
 mes = session.connection.receive( subscription, 0 );
 if ( mes == null ) // should always be null for pub-sub case.
 {
  // start waiting for the message to get delivered asynch
waitingForMessage = true;
while ( ( messages.isEmpty()  !closed ) || ( !session.running ) )
{
   try
   {
// messages gets signaled once ClientIL.receive finishes
processing the message.
  messages.wait();
   } catch ( InterruptedException e )
   {
   }
}
if ( closed )
{
   waitingForMessage = false;
   break outer;
}
  // the message sent via ClientIL.receive should now be sitting in
messages
mes = ( SpyMessage )messages.removeFirst();
waitingForMessage = false;
}


I hope that helped!  I think the XIL is great idea!  We might even be able
to develop a c base API to access mq services (important in the integration
space).

Regards,
Hiram


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of John
 Fawcett
 Sent: Thursday, January 09, 2003 8:09 PM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] JBossMQ


 Hi,

 I am working on a new invocation layer (IL) for JbossMQ that encodes all
 communication in Xml (XIL). I've got the IL pretty near completion, and
 I am working on a C# jbossmq client.  I am trying to develop the
 TopicSubsciber, which is an extension of MessageConsumer. In reviewing
 the code in the jbossmq java sources, it looks to me like the client to
 a topic actually runs a loop sending receive requests to the server
 regularly.

 Is this really necessary? Once the connection has been established, why
 can't the server just invoke the ClientIL.receive method (which actually
 sends the message to the client) when a message arrives at the
 destination?
 It looks to me like the current implementation is not truly
 asynchronous...
 What am I missing?

 Thanks,
 fawce


 -
 John Fawcett
 CTO, Tamale Software, LLC
 26 Fox Road
 Waltham, MA 02451



 ---
 This SF.NET email is sponsored by:
 SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
 http://www.vasoftware.com
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Good-bye

2002-12-21 Thread Hiram Chirino
Dam..  it could be this new version of eclipse that i'm running does not
play nice with the sf cvs server.  I'm gona have to go back to wincvs.

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Bill
 Burke
 Sent: Saturday, December 21, 2002 7:18 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] Good-bye


 Hiram, you still have access!  We need you man!

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
  Chirino
  Sent: Saturday, December 21, 2002 2:06 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] Good-bye
 
 
  Yep.. i'd like to know the same.  Seems like that same thing has
  happend to
  me too.  Today I tried to do a CVS commit and i got a [server aborted]:
  commit requires write access to the repository
 
  I's this right?  What's the inactivity period before write access is
  revoked??
 
  Regards,
  Hiram
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On Behalf Of
   Darrell
   Sent: Saturday, December 21, 2002 12:47 AM
   To: [EMAIL PROTECTED]
   Subject: Re: [JBoss-dev] Good-bye
  
  
   why did they do that?
  
  
   - Original Message -
   From: Andy [EMAIL PROTECTED]
   To: [EMAIL PROTECTED];
   [EMAIL PROTECTED]
   Sent: Friday, December 20, 2002 6:39 PM
   Subject: [JBoss-dev] Good-bye
  
  
Hi Geeks
   
Yesterday my CVS RW access to JBoss was revoked and therefore
I will not work on the JBoss project at all.
Unfortunately this also means that I cannot update my changes to the
Quick Start Guide and the EJB Timer Service I was working on.
   
Even though that it makes me angry that I spent many hours helping
JBoss become a success I still wish the project all the success it
deserves.
   
Have a nice day
   
Andreas Schaefer
Code or be coded
   
Check out www.madplanet.com
   
   
   
   
---
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
  
  
  
   ---
   This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
   Time is running out!  Thinkgeek.com has the coolest gifts for
   your favorite geek.   Let your fingers do the typing.   Visit Now.
   T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
   ___
   Jboss-development mailing list
   [EMAIL PROTECTED]
   https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
  ---
  This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
  Time is running out!  Thinkgeek.com has the coolest gifts for
  your favorite geek.   Let your fingers do the typing.   Visit Now.
  T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development


 ---
 This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
 Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
 MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
 T H I N K G E E K . C O M   http://www.thinkgeek.com/sf/
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M   http://www.thinkgeek.com/sf/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Good-bye

2002-12-20 Thread Hiram Chirino
Yep.. i'd like to know the same.  Seems like that same thing has happend to
me too.  Today I tried to do a CVS commit and i got a [server aborted]:
commit requires write access to the repository

I's this right?  What's the inactivity period before write access is
revoked??

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of
 Darrell
 Sent: Saturday, December 21, 2002 12:47 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Good-bye


 why did they do that?


 - Original Message -
 From: Andy [EMAIL PROTECTED]
 To: [EMAIL PROTECTED];
 [EMAIL PROTECTED]
 Sent: Friday, December 20, 2002 6:39 PM
 Subject: [JBoss-dev] Good-bye


  Hi Geeks
 
  Yesterday my CVS RW access to JBoss was revoked and therefore
  I will not work on the JBoss project at all.
  Unfortunately this also means that I cannot update my changes to the
  Quick Start Guide and the EJB Timer Service I was working on.
 
  Even though that it makes me angry that I spent many hours helping
  JBoss become a success I still wish the project all the success it
  deserves.
 
  Have a nice day
 
  Andreas Schaefer
  Code or be coded
 
  Check out www.madplanet.com
 
 
 
 
  ---
  This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
  Time is running out!  Thinkgeek.com has the coolest gifts for
  your favorite geek.   Let your fingers do the typing.   Visit Now.
  T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development



 ---
 This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
 Time is running out!  Thinkgeek.com has the coolest gifts for
 your favorite geek.   Let your fingers do the typing.   Visit Now.
 T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] new direction for JBoss AOP

2002-11-26 Thread Hiram Chirino
wow... This will take AOP to the next level (interceptors on fields and and
constructors? WOW.).  I'll checkout your stuff tonight.

Regards,
Hiram

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Tuesday, November 26, 2002 3:39 PM
To: Jboss-Dev
Cc: Bob Lee; Jboss-Group@Jboss. Org
Subject: [JBoss-dev] new direction for JBoss AOP


Code is under jboss-head/aop

It compiles but that's about it.  Its incomplete.

The new direction is shown in the below xml if you can follow along.  Don't
have much time for explanation before Thanksgiving, but the idea is POJOs
and DynamicProxies married into one framework.  Field access, Constructors
and methods interceptable on POJOs.  More funtionality can be inferred if
you read the following XML.

!-- Interceptor definition.  This is just a template
 name is the string reference to the interceptor
 classname is its classname
 scope defines how the interceptor is instantiated
 instance - one interceptor instance per object instance
 class - one instance per class
 global - one instance for entire VM

 config - defines any arbitrary xml to pass to component for
initialization
--
interceptor name=service1 classname= scope=instance,class,global
  config/
/interceptor-service


!-- Extensions are classes that can be attached to an object to provide
 extended APIs.

 name is the string reference to the extention
 classname is its classname
 scope defines how the extension is instantiated
 instance - one extension instance per object instance
 class - one instance per class
 global - one instance for entire VM

 interfaces - are a list of interfaces to extend the aspected object.
  Any methods invoked on the aspect that pertain to these
  interfaces will be delegated directly to the extension class
 config - defines any arbitrary xml to pass to component for
initialization


 i.e.
 Class MyClass {}

 interface api { void doSometing(); }

 Class MyExtension implements api { public void doSomething(){ ... } }


 You could do in code
 {
MyClass instance = new MyClass();
api a = (api)instance;
a.doSomething();
 }
 Even though MyClass doesn't implement the api interface, or has the
code for it
 you can cast and invoke on it anyways.  This is the extension.
--
extension nameextension1 classname= scope=instance,class,global
  interfaces/
  config/
/extension

!-- chain of interceptor definition --
stack name=stack1
  interceptor-ref name=service1/
  interceptor name=int1 classname=
config/
  /interceptor
/stack

!-- interceptor pointcut defines what classes, methods,fields must be
intercepted
 and by what --
interceptor-pointcut name= class=.*pattern*
  method-pointcut expr=*set*/
  !-- Don't intercept method defined in these interfaces --
  method-pointcut
excluded-interfaces/
  /method-pointcut

  !-- Intercept methods defined in all these interfaces --
  method-pointcut
included-interfaces/
  /method-pointcut

  field-pointcut expr=*variable*/
  field-pointcut expr={PUBLIC,PRIVATE,PROTECTED}/

  interceptors
stack-ref name=stack1/
interceptor-ref name=
   config/
/interceptor-ref
  interceptors/
/interceptor-pointcut

!-- Extension pointcut defines what classes should be extended --
extension-pointcut name= class=.*
  extensions
extension-ref name=extension1/
extension/
  /extensions
/extension-pointcut

!--
   A proxy is a template for creating Dynamic Proxies.

--
proxy name=
  interfaces/
  interceptor-pointcuts/
  extensions/
/proxy

!--
Add a pointcut to created proxy
--
interceptor-pointcut name= proxy=
  method-pointcut
included-interfaces/
  /method-pointcut
  interceptors
stack-ref name=stack1/
interceptor-ref name=
   config/
/interceptor-ref
  interceptors/
/interceptor-pointcut







---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] 3 Transactions?

2002-11-26 Thread Hiram Chirino
David,

Is a ThreadLocal lookup more expensive than a hashmap lookup??

Regards,
Hiram

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Tuesday, November 26, 2002 8:23 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] 3 Transactions?


On 2002.11.26 22:26:30 -0500 Dain Sundstrom wrote:
 OK we have a transaction associated with the thread, each invocation 
 and the each context has a transaction (very confusing).  Once we get 
 by the tx interceptor should all of these be the same thing? 
yes (at least the thread and invocation, I don't know about the context,
isn't that a UserTx, which is almost completely unrelated?)

 If we are 
 suspending the transaction for the invocation (Not Supported) should 
 the ctx and invocation tx be null or just a suspended transaction?


Invocation should have null.  You shouldn't be able to tell if there was a
tx associated upstream.

IMO the invocation is the master and the threadlocal is there in case you
can't get to the invocation (such as in the jca stuff).  So the tx
interceptor needs to figure out what the current tx actually is, and make
sure the txManager knows it so it can supply it per thread.

david jencks
 
 -dain
 
 
 
 ---
 This SF.net email is sponsored by: Get the new Palm Tungsten T 
 handheld. Power  Color in a compact size! 
 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 


---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] new PooledInvoker: speeds up invocations

2002-11-19 Thread Hiram Chirino



That's 
the way It kinda works now, but I don't like it because it's not 
generalized. We don't have to do that with RMI proxies today, why do we 
have to do that with trunk proxies? And RMI proxy could be sent down the 
the invocation as an argument and all would be ok. You should be able to 
do the same with a trunk proxy.

Regards,
Hiram

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Bill 
  BurkeSent: Monday, November 18, 2002 11:57 PMTo: 
  [EMAIL PROTECTED]Subject: RE: [JBoss-dev] new 
  PooledInvoker: speeds up invocations
  Why 
  does the proxy object have to setup the callback channel on 
  deserialization? Just stuff the proxy in the invocation object as party 
  of the payload. Invoker pulls this proxy shell out of the invocation and 
  initializes it with the real callback channel..
  
-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of 
Hiram ChirinoSent: Tuesday, November 19, 2002 4:03 
AMTo: [EMAIL PROTECTED]Subject: 
RE: [JBoss-dev] new PooledInvoker: speeds up 
invocations
I 
agree.. same socket bi-directionality is exotic and does not have to be in 
the public interface.

Currently,it's not very nice how the proxy going back client 
gets setup. I won't go into detailsabout the current way I do it 
(it sucks).
Here's the route I 
hope I can change too soon:
1) client sends a proxy object down an 
invocation to the server..
2) server invoker sets either (a) an 
Invocationattribute or (b) and ThreadLocal to identify the socket the 
invocation came over.
3) When the proxy object is 
de-serialized, he looks up the object in (2) to setup the callback channel 
to go through the original socket.

But for this to work in the(a) 
case the proxy object would need to be able to access the Invocation 
object during deserization.
And for it to work in the (b) case the 
proxy object has to be deserialized while in the context of the thread the 
invocation came in.

I don't think I'll be able to do this 
the way invocations are done right now. You think this is a bad 
route? 

Regards,
Hiram

-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of 
Bill BurkeSent: Sunday, November 17, 2002 11:16 
PMTo: [EMAIL PROTECTED]Subject: 
RE: [JBoss-dev] new PooledInvoker: speeds up 
invocations

  I agree Scott (no public interface for bi-directionality). It 
  will be tricky to implement the bi-directional behavior if Invokers don't 
  have a bi-directional public interface. I wonder how you abstract 
  this out now Hiram.
  
  One way to do this would be to use the trick I used with EJBs and 
  multiple-invokers. 
  
  1. Have a proxy factory.
  2. Pass this information with the client 
  request.
  3. Look up the proxy factory whenever you have to create proxies 
  via the tag in the invocation.
  
  Bill
  
-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of 
Scott M StarkSent: Saturday, November 16, 2002 1:49 
PMTo: 
[EMAIL PROTECTED]Subject: Re: 
[JBoss-dev] new PooledInvoker: speeds up 
invocations
It should be possible to route invocations 
over the incoming channel, but it cannot be
a requirement. This does not imply the 
invocation interfaces are bi-directional however.
There simply needs to be the ability to 
compose the invokers such that there is a shared
communications channel.

Scott StarkChief Technology 
OfficerJBoss Group, LLC

  - Original Message - 
  From: 
  Victor Langelo 
  To: [EMAIL PROTECTED] 
  
  Sent: Friday, November 15, 2002 
  7:11 PM
  Subject: Re: [JBoss-dev] new 
  PooledInvoker: speeds up invocations
  Hiram Chirino wrote:
  
Hiram Chirino wrote:  Anyways.  JMS need bi-directional invocations (BADLY).  Should this  become a requirement for the other invokers??I completely disagree.  There is no reason server to clientcommunication has to go over the back channel of a client to serverI might have said this before, but there is one reason it's a nice feature:This allows callback to clients that are sitting behind a firewall.Let 
  me agree with Hiram. I would add it is essential to use the client 
  connection if the client network is using NAT (network address 
  translation). With the advent of new security measures, many of our 
  clients are adding firewalls and NAT. The worst case is when the 
  server has a public IP and the local

RE: [JBoss-dev] new PooledInvoker: speeds up invocations

2002-11-18 Thread Hiram Chirino



I 
agree.. same socket bi-directionality is exotic and does not have to be in the 
public interface.

Currently,it's not very nice how the proxy going back client gets 
setup. I won't go into detailsabout the current way I do it (it 
sucks).
Here's the route I 
hope I can change too soon:
1) client sends a proxy object down an invocation to 
the server..
2) server invoker sets either (a) an 
Invocationattribute or (b) and ThreadLocal to identify the socket the 
invocation came over.
3) When the proxy object is de-serialized, he looks up 
the object in (2) to setup the callback channel to go through the original 
socket.

But for this to work in the(a) case the 
proxy object would need to be able to access the Invocation object during 
deserization.
And for it to work in the (b) case the proxy object has 
to be deserialized while in the context of the thread the invocation came 
in.

I don't think I'll be able to do this the way 
invocations are done right now. You think this is a bad route? 


Regards,
Hiram

-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill 
BurkeSent: Sunday, November 17, 2002 11:16 PMTo: 
[EMAIL PROTECTED]Subject: RE: [JBoss-dev] new 
PooledInvoker: speeds up invocations

  I 
  agree Scott (no public interface for bi-directionality). It will be 
  tricky to implement the bi-directional behavior if Invokers don't have a 
  bi-directional public interface. I wonder how you abstract this out now 
  Hiram.
  
  One 
  way to do this would be to use the trick I used with EJBs and 
  multiple-invokers. 
  
  1. 
  Have a proxy factory.
  2. 
  Pass this information with the client request.
  3. 
  Look up the proxy factory whenever you have to create proxies via the tag in 
  the invocation.
  
  Bill
  
-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of 
Scott M StarkSent: Saturday, November 16, 2002 1:49 
PMTo: [EMAIL PROTECTED]Subject: 
Re: [JBoss-dev] new PooledInvoker: speeds up 
invocations
It should be possible to route invocations over 
the incoming channel, but it cannot be
a requirement. This does not imply the 
invocation interfaces are bi-directional however.
There simply needs to be the ability to compose 
the invokers such that there is a shared
communications channel.

Scott StarkChief Technology 
OfficerJBoss Group, LLC

  - Original Message - 
  From: 
  Victor Langelo 
  To: [EMAIL PROTECTED] 
  
  Sent: Friday, November 15, 2002 7:11 
  PM
  Subject: Re: [JBoss-dev] new 
  PooledInvoker: speeds up invocations
  Hiram Chirino wrote:
  
Hiram Chirino wrote:  Anyways.  JMS need bi-directional invocations (BADLY).  Should this  become a requirement for the other invokers??I completely disagree.  There is no reason server to clientcommunication has to go over the back channel of a client to serverI might have said this before, but there is one reason it's a nice feature:This allows callback to clients that are sitting behind a firewall.Let 
  me agree with Hiram. I would add it is essential to use the client 
  connection if the client network is using NAT (network address 
  translation). With the advent of new security measures, many of our 
  clients are adding firewalls and NAT. The worst case is when the server 
  has a public IP and the local LAN clients are on the otherside of a NAT 
  router.--Victor
  


RE: [JBoss-dev] jboss.net email transport

2002-11-15 Thread Hiram Chirino
The point i was making is that it's easier to the original e-mail than it is
to store the original encripted https post.

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott
 M Stark
 Sent: Friday, November 15, 2002 1:12 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] jboss.net email transport


 So send a signed HTTP post over SSL. A digital sig is a digital sig
 whether by email or post. The only advantange email has is that the
 clients are better setup to manage the keys and perform the signing.

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 

 - Original Message -
 From: Hiram Chirino [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Thursday, November 14, 2002 4:19 PM
 Subject: RE: [JBoss-dev] jboss.net email transport


  The cool thing about a signed secure e-mail message is that you get
  non-repudiation.  If at a later time company B tells company A,
 hey I never
  sent you a Purchase Order for 1 million widgets..  company A
 can show them
  the signed secure e-mail message that they received the PO in.
 It would be
  harder to do something like that over http.
 
  Regards,
  Hiram
 



 ---
 This sf.net email is sponsored by: To learn the basics of securing
 your web site with SSL, click here to get a FREE TRIAL of a Thawte
 Server Certificate: http://www.gothawte.com/rd524.html
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] new PooledInvoker: speeds up invocations

2002-11-15 Thread Hiram Chirino
  Could a InvocationResponse object be used instead?  Or, if you
 had detyped
  invocations, couldn't you just pass a callback object along with
  the request
  via a client-side interceptor?  Just curious...why do you need
  bi-directional invocations?  Acknowledgements?  Callbacks?  Is
 David using
  the bi-directional capability for Distributed Trans callbacks?
 The whole
  point of the Invoker architecture is to detach the transport
  layer from the
  actual service.

 I guess it is for the asynchronous push of JMS messages from the server to
 the client.


yes.



---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] new PooledInvoker: speeds up invocations

2002-11-15 Thread Hiram Chirino
  - Thread pooling (same as the PooledInvoker).

 When I looked at code it looked like there still was a thread
 being spawned
 for each invocation.  Sure, when you hand off the message, there is a pool
 there, but there seemed to be a thread spawn before this.  This
 needs to be
 avoided.


Perhaps..  I've not double checked the pool code.  The first time an
invocation comes though shure, but the second time, the pooled thread should
get reused.

  - Connection sharing.  Multiple invocations can be sent to the
  server at the
  same time.  Sending an invocation down the socket does not stop other
  invocation from going down the pipe.

 Is this possible?  Doesn't the socket get synchronized (and thus
 serialized
 invocations) when a lot of threads hit it?


Yep.. But this is good, if servicing requests has a delay in it..  You can
sqeeze more requests into one socket.  I need to make the connections pooled
also so that a single socket does not get over-used.

  - Uses NIO if running under java 1.4, normal blocking IO if on 1.3
 
  My performance testing did not show it was better than RMI.
 Perhaps I was
  running a bad test, perhaps I need to add connection pooling so
 that more
  than one socket is established from the client to the server.
 Perhaps all
  this functionality is just adding too much overhead.
 

 I'll add the benchmark to the pooled test in the testsuite.  It already
 benchmarks RMI vs. Pooled.


thanks.

  Anyways.  JMS need bi-directional invocations (BADLY).  Should
  this become a
  requirement for the other invokers??
 

 Could a InvocationResponse object be used instead?  Or, if you had detyped
 invocations, couldn't you just pass a callback object along with
 the request
 via a client-side interceptor?  Just curious...why do you need
 bi-directional invocations?  Acknowledgements?  Callbacks?  Is David using
 the bi-directional capability for Distributed Trans callbacks?  The whole
 point of the Invoker architecture is to detach the transport
 layer from the
 actual service.


The JMS server uses callbacks.  Thats how it drives asynchronous message
delivery.  A normal RMI callback object cannot allways be used since the
client may be behind a firewall.  I want to be able to communicate with the
client over the same socket that he established with the server.  Make
sense??

Regards,
Hiram

 Bill



 ---
 This sf.net email is sponsored by: To learn the basics of securing
 your web site with SSL, click here to get a FREE TRIAL of a Thawte
 Server Certificate: http://www.gothawte.com/rd524.html
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] new PooledInvoker: speeds up invocations

2002-11-15 Thread Hiram Chirino
 Hiram Chirino wrote:
   Anyways.  JMS need bi-directional invocations (BADLY).  Should this
   become a requirement for the other invokers??

 I completely disagree.  There is no reason server to client
 communication has to go over the back channel of a client to server

I might have said this before, but there is one reason it's a nice feature:
This allows callback to clients that are sitting behind a firewall.

 invoker.  It is a nice feature but should not be a requirement.  For
 example, I may want a system that uses RMI for client to server and
 Juxta for server to client.  To me it is just another RPC.  This is why
 I want JMX on the client side, so I can reuse any invoker for the server
 to client (or client to client) communication.

Yep.. I guess that's what I'm complaining about.  I want to have invokers on
the client side too.  I want JMS call backs to go via an invoker too.  I
can't do that today because we don't do client side invokers.

Regards,
Hiram


 -dain



---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] new PooledInvoker: speeds up invocations

2002-11-15 Thread Hiram Chirino

  Perhaps..  I've not double checked the pool code.  The first time an
  invocation comes though shure, but the second time, the pooled
  thread should
  get reused.
 

 Please make sure.  It didn't read that way when I looked at it last.


I'll double check.

 
  Yep.. But this is good, if servicing requests has a delay in
 it..  You can
  sqeeze more requests into one socket.  I need to make the
  connections pooled
  also so that a single socket does not get over-used.
 

 Yeah, maybe good for your design, but not good for performance.  BTW, with
 the PooledInvoker vs. RMI tests, I'm pretty sure that RMI caches the
 connection.  If I re-use the the same RMI proxy then Pooled is only 30%
 faster.  Also, BTW, I borrowed your marshalling code at first and it was
 significantly slower than straight ObjectStreams. (Don't remember
 percentages.)


Ok..  I'll test the differences..  Where are your performances tests
located?  I might go back to the drawing board and Re-implement my taking
your PoolInovker as the base and adding the 1 feature I want
(client-callback).

 
  The JMS server uses callbacks.  Thats how it drives asynchronous message
  delivery.  A normal RMI callback object cannot allways be used since the
  client may be behind a firewall.  I want to be able to
  communicate with the
  client over the same socket that he established with the server.  Make
  sense??
 

 Are the callbacks both for subscribers and Acks?  Or are acks
 delivered as a
 response.


The server delivers asynch messages via the clients back-channel.
The client then acks the message via his normal ivocation channel.

Regards,
Hiram



---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Metadata Service

2002-11-15 Thread Hiram Chirino
Peter.. why doesn't this have a JMS interface into it?? any ideas.  1600
message/second is GREAT number!

Regards,
HIram


 On 14 Nov, Bill Burke wrote:
  Wow Peter!  This is exactly what I was thinking of.  Any JMX
 guys have any
  ideas how we could integrate this?

 The server is already integrated:

 http://www.xmlBlaster.org/xmlBlaster/doc/requirements/j2ee.jmx.html

 There is also an JCA RA adaper if one want's to use it.

 http://www.xmlBlaster.org/xmlBlaster/doc/requirements/j2ee.k2.html

 Both developed by yours truly ;-)

 I also have a connection/subscriber pool MBean thingy, where you add
 subscribers through the MBean interface and get the callback/messages
 through JMX notifications.

 If someone is interested to take a look at it, fine. It uses some stuff
 I can not release, but the pool stuff and concepts around it I could
 share, if you will continue to like XmlBlaster after som more looks into
 it.

 I must say I have personally had verry good experiences from it. I have
 been woring with it for almost 2 years now, on and of, and it has worked
 great. It has high throughput (1600 XML messages/second), and has been
 running fine in a production environment for the last 6 month.

 A real gem.

 //Peter
 
  Bill
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On
 Behalf Of Peter
  Antman
  Sent: Thursday, November 14, 2002 4:12 AM
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] Metadata Service
 
 
  Hi,
  have any one of you looked at XmlBlaster? (www.xmlBlaster.org).
 
  I guess it could really work as a central XmlRepository. XmlBlaster is
  an XML based MOM. You publish your XML to it and it will save it in an
  Xml DOM tree, even persist it a RDMB or Xincice.
 
  You can then subscribe to event with an XPath expression (or do a
  synchronous get (with an XPath).
 
  Ok. You can not just subsribe to one element, thats true, but you can
  subscribe on a domain or config, say MyMessageDrivenBean
 and get any
  update notifications for that XML config. Or you could do a
  get(//x/y/port) (pseudocode!) and get all configs wich contains that
  element. There are a lot more to XmlBlaster (I have done the JBoss
  integration thats currently is available in XmlBlaster ;.))
 
  Well, just a thought.
 
  //Peter
 
  On 13 Nov, Bill Burke wrote:
   1. I'm not talking about a central config file...Components
  register their
   XML with this service.  MBean, EJB, whatever...
  
   2. You know what XPATHs are right?  If not, look them up.  They
  are really
   cool.  Xerces/Xalan (forget which) support looking up Elements
  via XPATHS.
   What's not supported, which we would have to write, would be
  the ability to
   register for change notifications via an XPATH.
  
   Other ideas:
   - A redeployed bean, updates the Centralized (in-memory)
 Xerces XML Doc.
   Services/components registered as listening for changes, recieve
   notification.
  
   - JMX console needs an additional XML editor for MBean
  attributes that are
   XML elements.
  
   - This sort of centralized service allows you to query, via
  XPATHS, for all
   components that have a port attribute for instance.
 Allows you to do
   global things on configuration when you don't know the
 actual components
   that have that type of attribute
  
   Another thing about configuration I wanted to have is the concept of
   Configuration Domains.  A component would get configuration by
  searching a
   set of chained configuration domains.
  
   invocation domain-instance domain-component domain-app server
   domain-cluster domain etc...
  
   So, when a component needs config information, it looks it up
  via the chain.
   Any domain in the chain can override a config value.  As the chain is
   traversed, if the config info is not there, it searches
 farther up the
   chain.
  
   This would allow us to have a layered way of obtaining default config
   information, or overriding existing configuration at
 different levels at
   different times.
  
   Bill
  
  
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On
 Behalf Of Matt
   Munz
   Sent: Wednesday, November 13, 2002 1:26 PM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] Metadata Service
  
  
   Dain,
  
Meta data for an invocation.
  
 I assume you refer here to EJB/servlet invocations.
  
 Just out of curiosity, how is that metadata currently stored?
  
 - Matt
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On
 Behalf Of Dain
   Sundstrom
   Sent: Wednesday, November 13, 2002 1:13 PM
   To: [EMAIL PROTECTED]
   Subject: Re: [JBoss-dev] Metadata Service
  
  
   Meta data for an invocation.  What are the tx attributes?
 What is the
   security manager?  What are the required roles?  What is
 the readahead
   configuration?  That kind of data.
  
   -dain
  
   Matt Munz wrote:
Dain/Bill/Scott,
   
  Could you clarify this?  Metadata 

RE: [JBoss-dev] jboss.net email transport

2002-11-14 Thread Hiram Chirino
The cool thing about a signed secure e-mail message is that you get
non-repudiation.  If at a later time company B tells company A, hey I never
sent you a Purchase Order for 1 million widgets..  company A can show them
the signed secure e-mail message that they received the PO in.  It would be
harder to do something like that over http.

Regards,
Hiram



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt
 Munz
 Sent: Thursday, November 14, 2002 10:55 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] jboss.net email transport


 Jason,

   Well, you've peaked my interest...

  This method(with digital signatures/encryption) would be more secure
  than the Http(s) transport,

 Really?  Any articles on the subject?

  Authentication would be near definite
  (rather hard to fake),

 Is there something in the mail protocol that facilitates this?
 I'd love to
 see a strong argument for email is more secure than https...

  the server would not be exposed to the big bad
  internet,

 Hmmm.  Email attacks are fairly common.  Email is, by definition,
 a part of
 the internet.  I'm not sure where you're going with this...

  and the company's IT guys don't have to set up a VPN to every
  outside source that needs to update data in the server.

 VPNs are bad ;)  What's wrong with the tried and true poking a
 hole in the
 firewall technique?  What about https?

 Is the idea that they have to have email anyway, so let's just
 tunnel over
 that?  Wasn't this same argument used for HTTP tunnelling?

   - Matt

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Jason
 Essington
 Sent: Thursday, November 14, 2002 10:33 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] jboss.net email transport


 Hi Matt,

 Given an instance where a company would place a server on its intranet
 (behind a firewall that does not allow incoming connections from the
 internet).

 Now, If this company wanted to receive periodic updates to some
 semi-static data (iso country codes for instance) from a source on the
 internet. This source would need a VPN to get through the companies
 firewall (major hassle if this source has to update many servers, or if
 the company needs data updated from many different sources) or it could
 send a Signed and possibly Encrypted email to a mail account the
 company has set up for the server. The server checks it's email at a
 configured interval and processes any soap messages it finds there. The
 digital signature is used for message verification and authentication,
 while encryption could be used to protect sensitive parts of the
 message. The message is processed and it's response (or fault) is
 returned to the original sender via the mail server.

 This method(with digital signatures/encryption) would be more secure
 than the Http(s) transport, Authentication would be near definite
 (rather hard to fake), the server would not be exposed to the big bad
 internet, and the company's IT guys don't have to set up a VPN to every
 outside source that needs to update data in the server.

 All in all, and email transport with digital signatures and encryption
 has quite a bit of promise as a secure way to allow data to pass
 through/around a firewall without too much extra hassle. There would
 need to be a mechanism for key exchange, but no work on the part of IT.

 -jason

 On Thursday, November 14, 2002, at 07:21  AM, Matt Munz wrote:

  Jason,
 
Just out of curiosity, what would you use this for?
 
- Matt
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of
  Jason
  Essington
  Sent: Wednesday, November 13, 2002 5:48 PM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] jboss.net email transport
 
 
  Hi all
 
  I have managed to get a fairly crude email transport working in
  jboss.net (It is lurking in head). I would appreciate any comments /
  design ideas from folks who are interested.
 
  Check the javadocs in org.jboss.net.axis.mail.MailTransportService to
  see how to set it up.
 
  It will currently process emails with simple soap messages (no
  attachments). It requires the content type to be application/soap+xml
  with the action attribute set to the desired service.
 
  i.e. content-type: application/soap+xml; action=SomeService
 
  The response message is returned to the sender via email.
 
  Since email doesn't really have any type of authentication framework
  the transport will only work with ejb's / ejb methods's that have
  unchecked permissions.
 
  I have been able to sign (DSA) a soap message using apache's
  xml-security library and have jboss.net verify the signature (I haven't
  submitted this handler yet, as it depends on the apache xml-security
  library that would have to be added to the thirdparty libs).
 
  I think this is the first step to some sort of 

RE: [JBoss-dev] Metadata Service

2002-11-13 Thread Hiram Chirino
   IMHO, JMX is limiting.  MBeans are declarations of object instances.
   standardjboss.xml, standardcmp-jdbc.xml, the new aspect configs,
   etc... are templates/defaultconfigs for object
   creations/instantiations.  A major difference.
  
   Sometimes config is just config and there's really no object you can
   attach it to.

 This is one of the big problems I see with Jboss today.  Jorg came to me
 a few months ago and said I want to use a database for the cmp mapping
 info... a data dictionary and I had to say can't be done.  We need the
 physical storage abstracted away from the server use.  We need metadata
 to be more configurable at runtime.


I like that.  If it was more configurable at runtime, the JBossMQ would be
able to CMP 2.0 for it's message persistence.  It would configure CMP engine
via API calls.

Regards,
Hiram



---
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] MetaDataRepository Proposal

2002-11-13 Thread Hiram Chirino

 David,

 Actually it simplifies the code.  If you take a look at our interceptor
 stack most have a ton of code just to load and maintain the metadata,

Yes there is alot of Metadata now.  1/2 the ton of code that we have there
is just taking XML and creating a metadata objects.  I think that something
like Jelly (http://jakarta.apache.org/commons/sandbox/jelly/) should be able
eliminate that code.  A tool that will take XML config and generate the
Metadata objects that our interceptors can use directly.

 and the worst part is we have no control over it at runtime.  It is way
 simpler.  You'll see.


I agree there.  But wouldn't it be simpler if we just exposed an API to the
client that would allow him to modify the metadata (thus turning something
that is static now, into something dynamic)?

For example.  Say you have a CMP bean x, and the configuration API is
exposed via an aspect, then on the client side you would do:

CMPConfiguration c = (CMPConfiguration)x;
c.setReadAhead( 500 );

And the would in turn create a Invocation with method=setReadAhead that the
CMP interceptor would handle by updating the metadata configuration for the
bean.

Does this make sense?  Are you trying to achieve something similar but in a
more automated way?

Regards,
Hiram

 The easiest case for me the read ahead configuration in entity beans.
 There is no reason for this to be static.  In fact it should be
 manageable at runtime, and if I'm luck I'll be able to pull it off for
 4.0.  Scott tells me there is a similar need to manage security at
 runtime.  There really is no need to shut down an application in
 production just to change some configuration data.

 Even if there is no real need the code is simpler.

 -dain



---
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JMX on the client side?

2002-11-11 Thread Hiram Chirino
What do you mean by the micokernel?

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott
 M Stark
 Sent: Monday, November 11, 2002 3:36 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] JMX on the client side?


 JMX is not what is important, its the microkernel and services on
 top of it.

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 

 - Original Message -
 From: Hiram Chirino [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Sunday, November 10, 2002 8:25 PM
 Subject: RE: [JBoss-dev] JMX on the client side?


  
   Hiram, I think you missed the point.  Of course we could do this with
   out requiring JMX; anything is possible.  The point is if we
 agree that
   JMX is always on the client side then entire system is simplified.
  
 
  I guess the disconnect is happening right here.  IMO JMX does not always
  make things easier.  What do you think JMX provides that would
 simplify the
  entire system?  Is it:
  (1) Runtime server administration
  (2) Service creation/configuration/lookup.
 
  Even though those are super important on the server side, I
 just don't see
  how important those would be on the client side.  Am I missing something
  else?
 
  Regards,
  Hiram



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



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



RE: [JBoss-dev] JMX on the client side?

2002-11-10 Thread Hiram Chirino
 +1. This all came about because I was thinking about client side caches
 with server invalidation.  Without the JMX kernel it is a pain because
 we have invent a totally new architecture to handle server to client
 invocations.  If we have the kernel, we quickly prototype this by
 reusing the server invokers.  Of course our existing invokers won't work
 for a real deployment with clients behind a firewall, but it is a good
 start.

 -dain


What I would like to know, is: what are the features that JMX provides that
you need on the client side??
(1) Is it the interceptor architecture built around JMX?
(2) Is it the ability to look up other services via JMX?

I want to know because I think that we can provide client side container
without having to use JMX.  I think that stuff will actually get simpler if
we do not FORCE jmx on the client side.  Our Aspect API is all about that.
It's about providing at least #1 in a clean generic fashion.  But for it
successfully use for client side containers, I need to understand what all
the requirements will be.

Bill, I know you started doing some work on client side interceptors using
the aspect stuff.  What JMX features were you wishing you had on the client
side??

Regards,
Hiram



---
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] JMX on the client side?

2002-11-10 Thread Hiram Chirino
   JMX on the client side and JBoss on the client side are two different
   things, right?  AFAIK, MBeanServerFactory.createMBeanServer() doesn't
   require the service deployer.  If it does, that's another thing...
 
  Agreed.  All I am talking about is an MBean server.  If someone wants
  more JBoss services on the client side they can do that, but it
  shouldn't be required.

 Conceptually I like this, but...

 Are you thinking that these mbeans won't have any attributes?  Or do you
 plan to set them hardcoded in code?  Or where does the configuration come
 from?  Can we serialize a prototype from the server and register the
 deserialized copy on the client? Is there some way to use the new remote
 jmx stuff for something like this?

 david


Could all of this MBean server configuration happen in a client-side
interceptor??
So the first client-side interceptor might initialize the MBean server.
Then the rest of the interceptors in the client chain can use the
interceptor (register services or lookup other services).

This approach would allow you to choose if you use JMX on the client or not.

Regards,
Hiram



---
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] JMX on the client side?

2002-11-10 Thread Hiram Chirino

 Hiram, I think you missed the point.  Of course we could do this with
 out requiring JMX; anything is possible.  The point is if we agree that
 JMX is always on the client side then entire system is simplified.


I guess the disconnect is happening right here.  IMO JMX does not always
make things easier.  What do you think JMX provides that would simplify the
entire system?  Is it:
(1) Runtime server administration
(2) Service creation/configuration/lookup.

Even though those are super important on the server side, I just don't see
how important those would be on the client side.  Am I missing something
else?

Regards,
Hiram



---
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] JMX on the client side?

2002-11-10 Thread Hiram Chirino

Ok..  i buy into that.

I think running a JMX server on the client side should be a piece of cake.
The hard part is figuring out how the client-side deployment system going to
work.


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of David
 Jencks
 Sent: Monday, November 11, 2002 12:45 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] JMX on the client side?


 Let me give you my example of why I want it.

 I worked over the trunk invoker so it would do distributed transactions.
 This requires at least a source of xid's on the calling side, and
 preferably a TransactionManager.  Well, they are already there if the
 calling side is a jboss instance.  If it's a client, the only way you will
 be propagating  a transaction is if you have a UserTransaction.  So, I'd
 like to implement the client-side UserTransaction to use the same
 mechanism, based on at least an XidFactory and perhaps a
 TransactionManager.  These are pretty much dependent on the jmx
 framework.
 If the jmx framework is on the client, I just register the mbeans and I'm
 done.  If not, I have to rewrite a bunch of the code to be independent of
 the jmx framework.  Incidently, I think the client end of the
 trunk invoker
 would also be simpler if it were an mbean: in fact I think there
 could be a
 lot more code sharing between the two ends.

 david jencks




---
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] JMS - priority queueing

2002-10-30 Thread Hiram Chirino
You are not using the JMS API correctly.  Read the JMS spec or post this
message to the user forums.

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of T.
 Subramanian
 Sent: Wednesday, October 30, 2002 11:54 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] JMS - priority queueing


 Hi All,
   I am using JBoss 3.0.0 version. When I tried with JMS
 examples that uses
 the priority , it doesn't work as expected.

 Following are the steps I have done. In a class used to send JMS messages
 to a queue I set the priority ranging from 0 -9.  I used
 setJMSPriority(int) method in TextMessage object. But in the
 receiving end
 when I received the messages I always the get the priority as 4. Method I
 used to get the priority is getJMSPriority() method in TextMessage object.

   I am using the JMS implementation that comes with JBoss 3.0.0.

   Can any one using the priority feature of JMS ?. Any
 pointers will be of
 great help to me

 Thanks,
 Subramanian T



 ---
 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: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JBoss 4.0 Entity Redesign

2002-10-20 Thread Hiram Chirino
 Previously we were on opposite sides of this debate:-)

 I think for simplicity we should have only stateless interceptors, any
 interceptor can store per-stack state in a the stack top in a hashmap.


This was the way I created the aspect stuff initially.  The interceptors
were tottaly statless.  Even intercetor config was not stored in the
interceptor.  The config was put at the top of the stack.

Advantage:
1 interceptor instance could be used for all stack instances. (less memory
usage?? not really, the config objects are created and put at the top of the
stack)

Disadvantages:
Hard to develop the interceptors and I think it lead to worse perfomance.  I
had to do a hashmap look up of the config every time it had to handle an
invocation.





---
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Eclipse and JBoss Howto posted.

2002-10-15 Thread Hiram Chirino

 I like project/output/eclipse-classses.

ok i'll change this soon.

 
 One more thing. I have JBoss launch configuration, so you can run/debug 
 JBoss right from within Eclipse. What would be the best place to put it? 
 Do you thing build/etc/eclipse/jboss-4.0.0alpha.launch is appropriate?
 

sounds good to me.



---
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Eclipse and JBoss Howto posted.

2002-10-15 Thread Hiram Chirino

 Hiram,
 
 great news!
 
 Two things though,
 
 a) does this explain how to get servlet, jsp and ejb debugging 
 working with 
 jboss? Some of the other help files explain how to do this with 
 independent 
 versions of jboss and tomcat, but not for the integrated version.
 

No.  What I have setup is for the development of JBoss it self.  

 b) if the website isn't going to be rebuilt soon, can you tell us 
 where to 
 find the file in the meantime?
 

IF your are still interested, the JBoss website is in CVS.

Regards,
Hiram

 
 cheers,
 
 Bruce



---
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Eclipse and JBoss Howto posted.

2002-10-14 Thread Hiram Chirino

Thanks for pointing that problem out.  We could also adjust the
project/.cvsignore file so that the directory that eclipse uses for building
gets ignored.

I don't want eclipse building to the same directory that ant builds to
because it that will throw ant's timestamps off.  I've noticed some weird
things in the past like:
- You edit somefile.java and save it and save it with an error.
- Eclipse generates somefile.class ( even though it has a compile error )
- You run the ant build and it builds OK (because somfile.class is older
than somefile.java)
- You run your program and you get a runtime exception saying the
somefile.class file is screwed.

But It might be worth moving the eclipse build directory to something like:
project/output/eclipse-classses
Since the would match what the ant build does a little better.

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Igor
 Fedorenko
 Sent: Monday, October 14, 2002 9:31 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Eclipse and JBoss Howto posted.


 Hiram Chirino wrote:
  A thread concerning how to use Eclipse to develop Jboss was
 started a while
  back..  I finally got the time to put together a little howto
 to explain how
  to use eclipse to develop JBoss.
 
  You will find it in the Developer Guides section of the Jboss
 website the
  next time the website gets rebuilt.
 

 Thank you very much, Hiram! I have one cosmetic improvement I would like
 to check in if you do not mind. All projects except jboss.net have
 output dir set to project/bin (i.e. not to project/output/classes). This
 makes Eclipse think that project/bin is a Local addition not under CVS
 control and mark all these projects as having outgoing changes.
 Changing projects' output dir to project/output/classes fixes this
 problem. What do you think?

 --
 Igor Fedorenko
 Think smart. Think automated. Think Dynamics.
 www.thinkdynamics.com



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



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



[JBoss-dev] Eclipse and JBoss Howto posted.

2002-10-12 Thread Hiram Chirino
A thread concerning how to use Eclipse to develop Jboss was started a while
back..  I finally got the time to put together a little howto to explain how
to use eclipse to develop JBoss.

You will find it in the Developer Guides section of the Jboss website the
next time the website gets rebuilt.

Regards,
Hiram



---
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] jbossmq and jca 1.5

2002-10-05 Thread Hiram Chirino

Hey David..  I want to see If I can start working on this.

I know like amost zero about jca but I know quite a bit about the XA stuff
and how jbossmq txs work with the MDB.

anyways..  I guess what I need to know is how is the contianer going to
initialize
the jms stuff so that it can deliver the container it's messages.


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of David
 Jencks
 Sent: Friday, August 30, 2002 1:35 PM
 To: jboss-dev
 Subject: [JBoss-dev] jbossmq and jca 1.5


 I started looking at modifying jbossmq and/or the jmsra adapter to work
 with the j2ee connector architecture 1.5 facilities.  I am
 definitely not a
 jms expert so a lot of what I say may not make sense.

 Here's what the new spec provides that I think is relevant:

 thread pooling through the WorkManager interface.  You submit Work
 instances to be done in other threads.  The app server controls the thread
 pooling.

 message inflow through the MessageEndpoint interfaces.  In particular, I
 think we should use Option B which involves the jms system calling, on a
 MessageEndpoint supplied from the app server,

 beforeDelivery([the onMessage method]); //this starts the jta tx and
 informs the adapter via an XAResource the adapter supplied earlier.

 onMessage(message); //actual message delivery to MessageListener

 afterDelivery(); //ends the tx, again the adapter is informed via the
 XAResource.

 

 I keep getting lost looking at the jms code.  My impression so far is that
 although the jca 1 jmsra adapter appears to work ok without modifying
 jbossmq, using the contracts mentioned above will require additional code
 in jbossmq itself, namely an additional way of delivering
 messages within a
 transaction.

 Does this make sense?  Do any of the jbossmq experts want to work on this?

 There are very simple examples of using the work and message endpoint
 interfaces in the testsuite in .../jca/inflow.

 I haven't written the deployment portion of the connector 1.5
 support yet:
 I'm hoping for a real adapter example that can be used to test it.
 However, I think for now everything needed can be set up without
 a deployer
 as explicit mbeans: this is what I did in the tests.

 Thanks
 david jencks


 ---
 This sf.net email is sponsored by: OSDN - Tired of that same old
 cell phone?  Get a new here for FREE!
 https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



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



RE: [JBoss-dev] Proxy generator broken

2002-09-20 Thread Hiram Chirino

I'll look into it right away.
Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
 M Stark
 Sent: Friday, September 20, 2002 7:10 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Proxy generator broken


 I fixed the immeadiate problem which was causing the NPE, but
 these recent changes
 still need to be validated against the full testsuite.

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 

 - Original Message -
 From: Scott M Stark [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Friday, September 20, 2002 3:41 AM
 Subject: Re: [JBoss-dev] Proxy generator broken


  There have been a number of changes to the proxy compiler code
 in the past
  7 days by Hiram. Were these changes tested against the full
 testsuite? Also,
  the formatting of these changes is screwed up. Please test and
 fix both the
  problem and the formatting.
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
  - Original Message -
  From: Dain Sundstrom [EMAIL PROTECTED]
  To: JBoss-dev [EMAIL PROTECTED]
  Sent: Thursday, September 19, 2002 9:24 PM
  Subject: [JBoss-dev] Proxy generator broken
 
 
   Does anyone know how the proxy generator works?
  
   It looks like it it totally broken in head.  When I deploy
 any cmp2 bean
   I get the following exception:
  
   22:27:28,336 ERROR [EntityContainer] Starting failed:
   org.jboss.util.NestedRuntimeException: Failed to create new proxy
   target; - nested throwable: (java.lang.N
   ullPointerException)
   22:27:28,341 WARN  [ServiceController] Problem starting service
   jboss.j2ee:jndiName=cmp2/readonly/Book,service=EJB
   org.jboss.util.NestedRuntimeException: Failed to create new proxy
   target; - nested throwable: (java.lang.NullPointerException)
   snip/
 + nested throwable:
   java.lang.NullPointerException
at
   org.jboss.proxy.compiler.ProxyCompiler.getCode(ProxyCompiler.java:174)
at
 org.jboss.proxy.compiler.Runtime.makeProxyType(Runtime.java:66)
at
   org.jboss.proxy.compiler.ProxyCompiler.init(ProxyCompiler.java:87)
at
   org.jboss.proxy.compiler.Proxies$Impl.newTarget(Proxies.java:594)
at
 org.jboss.proxy.compiler.Proxies.newTarget(Proxies.java:77)
at
 org.jboss.proxy.compiler.Proxy.newProxyInstance(Proxy.java:49)
at
  
 org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand.
 init(JDBCCreateBeanClassInstanceCommand.java:52)
at
  
 org.jboss.ejb.plugins.cmp.jdbc.JDBCCommandFactory.createCreateBean
 ClassInstanceCommand(JDBCCommandFactory.java:107)
at
  
 org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.startStoreManager(
 JDBCStoreManager.java:436)
at
  
 org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreMan
 ager.java:369)
  
   I'm going to look at this, but if someone knows what is going on, I
   would appreciate the help.
  
   --
   
   Dain Sundstrom
   Chief Architect JBossCMP
   JBoss Group, LLC
   



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



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



RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed

2002-09-17 Thread Hiram Chirino

sorry..  forgot to add my renamed file.  Should be fixed now.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of
 [EMAIL PROTECTED]
 Sent: Tuesday, September 17, 2002 7:45 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
 
 
 
 =
 ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
 =
 
 JAVA VERSION DETAILS
 java version 1.3.1_03
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
 Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode)
 
 =
 
 HERE ARE THE LAST 50 LINES OF THE LOG FILE
 
 /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss
 /aspect/AspectClassLoader.java:165: cannot resolve symbol
 symbol  : class AspectDefinition  
 location: class org.jboss.aspect.AspectClassLoader
   return (AspectDefinition) aspectDefinitions.get(clazz);
 ^



---
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source  Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: FW: [JBoss-dev] configuration of interceptors

2002-09-12 Thread Hiram Chirino


Ok I imagine a client invocation chain will look like:

clientproxy - client-interceptor-stack -
serverproxy - server-interceptor-stack - targetMbean

Would doing some think like this satisfy you client-server requirments? :

serverproxy = factory.createAspect(server-interceptor-stack, targetMbean);
clientproxy = factory.createAspect(client-interceptor-stack, serverproxy 
);

Please note: that server-interceptor-stack in essence will resolve to
a set of { server-interfaces[], server-interceptors[], 
server-configurations[] }

On another note, right now the factory that generates the proxys for say the 
server-interceptor-stack, is configured through static xml files.  If we 
provide a JMX interface to the factory so that you can view/update stack 
configurations, would that satisfy your requirement to have these puppies 
manageable.

Regards,
Hiram


From: marc fleury [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: FW: [JBoss-dev] configuration of interceptors
Date: Thu, 12 Sep 2002 13:44:03 -0400



  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]] On
  Behalf Of marc fleury
  Sent: Thursday, September 12, 2002 1:23 PM
  To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
  Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
  Subject: [JBoss-dev] configuration of interceptors
 
 
  Ok
 
  just had an interesting IM with hiram.  He essentially has
  implemented the proxy factory we were talking about.  I think
  he is missing the client/server side of it but we can very
  simply add these.
 
  Essentially it would revolve around a central
  proxyFactory.createProxy(Interfaces[], client-interceptors[],
  client-configurations[], server-interceptors[],
  serverconfigurations[] targetMbean);
 
  that returns a Dynamic Proxy, hooked up for remote/local
  calls with client and server side interceptors.  If you are
  in one vm you can safely assume client=server and only
  configure one or the other. (meaning if one is null then
  don't configure transport it will be invm
  only)
 
  In the case of hiram he has only one aspect of it (and he
  calls it aspect everywhere) but that construct is really what
  we need.  I also think we should have the MBean in there,
  even though we are talking about a POJO.
 
  I believe he has solid code for it and I am really interested
  in adding this to the base.  I am not sure it is a JMX level
  construct (due to the pojo nature) but having the JMX base
  manage these configurations and associations between target
  and interceptors/configuration is the only sane way I can
  imagine to have these puppies manageable.  I want visibility
  on that configuration for a given mbean (the generalized
  mbean againg being just a pojo or target).  This is our generalized
  proxy factory.
 
  The AOP framework of the future is staring us in the eye...
  we got it.
 
  marc f
 
 
  xx
  Marc Fleury, Ph.D.
  President, Founder
  JBoss Group, LLC
  xx
 
 
 
  ---
  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
 




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



---
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: FW: [JBoss-dev] configuration of interceptors

2002-09-12 Thread Hiram Chirino

 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of David
 Jencks
 Sent: Thursday, September 12, 2002 3:24 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Re: FW: [JBoss-dev] configuration of interceptors


 I'm a little confused about one part of this...

 I thought the plan was to turn our current ejb interceptors into mbean
 interceptors and the Containers into fancy MBeanInvokers (If I remember
 correctly, anyway the top thing on the mbean interceptor stack).  If this
 is correct, the ServerInterceptors would be behind the target
 MBean and not
 part of this new factory.

 This would look more like
 clientproxy - client-interceptor-stack -
  serverproxy -  targetMbean - mbean-interceptor-stack


ya i think this is a better picture..


 In any case, I think all the stack factories should be mbeans as Hiram
 mentions.

 david jencks


 On 2002.09.12 14:25:25 -0400 Hiram Chirino wrote:
 
  Ok I imagine a client invocation chain will look like:
 
  clientproxy - client-interceptor-stack -
  serverproxy - server-interceptor-stack - targetMbean
 
  Would doing some think like this satisfy you client-server
 requirments? :
 
  serverproxy = factory.createAspect(server-interceptor-stack,
  targetMbean);
  clientproxy = factory.createAspect(client-interceptor-stack,
  serverproxy
  );
 
  Please note: that server-interceptor-stack in essence will resolve to
  a set of { server-interfaces[], server-interceptors[],
  server-configurations[] }
 
  On another note, right now the factory that generates the proxys for say
  the
  server-interceptor-stack, is configured through static xml files.  If
  we
  provide a JMX interface to the factory so that you can
 view/update stack
  configurations, would that satisfy your requirement to have these
  puppies
  manageable.
 
  Regards,
  Hiram
 
 
  From: marc fleury [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: FW: [JBoss-dev] configuration of interceptors
  Date: Thu, 12 Sep 2002 13:44:03 -0400
  
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of marc fleury
Sent: Thursday, September 12, 2002 1:23 PM
To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
Subject: [JBoss-dev] configuration of interceptors
   
   
Ok
   
just had an interesting IM with hiram.  He essentially has
implemented the proxy factory we were talking about.  I think
he is missing the client/server side of it but we can very
simply add these.
   
Essentially it would revolve around a central
proxyFactory.createProxy(Interfaces[], client-interceptors[],
client-configurations[], server-interceptors[],
serverconfigurations[] targetMbean);
   
that returns a Dynamic Proxy, hooked up for remote/local
calls with client and server side interceptors.  If you are
in one vm you can safely assume client=server and only
configure one or the other. (meaning if one is null then
don't configure transport it will be invm
only)
   
In the case of hiram he has only one aspect of it (and he
calls it aspect everywhere) but that construct is really what
we need.  I also think we should have the MBean in there,
even though we are talking about a POJO.
   
I believe he has solid code for it and I am really interested
in adding this to the base.  I am not sure it is a JMX level
construct (due to the pojo nature) but having the JMX base
manage these configurations and associations between target
and interceptors/configuration is the only sane way I can
imagine to have these puppies manageable.  I want visibility
on that configuration for a given mbean (the generalized
mbean againg being just a pojo or target).  This is our generalized
proxy factory.
   
The AOP framework of the future is staring us in the eye...
we got it.
   
marc f
   
   
xx
Marc Fleury, Ph.D.
President, Founder
JBoss Group, LLC
xx
   
   
   
---
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
   
 
 
 
 
  _
  Join the world’s largest e-mail service with MSN Hotmail.
  http://www.hotmail.com
 
 
 
  ---
  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: FW: [JBoss-dev] configuration of interceptors

2002-09-12 Thread Hiram Chirino

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of marc
 fleury
 Sent: Thursday, September 12, 2002 3:55 PM
 To: 'Hiram Chirino'
 Cc: [EMAIL PROTECTED]
 Subject: RE: FW: [JBoss-dev] configuration of interceptors


  Ok I imagine a client invocation chain will look like:
 
  clientproxy - client-interceptor-stack -
  serverproxy - server-interceptor-stack - targetMbean

 not quite there is no typed serverproxy in the middle just a straight
 invoke() stack.

 The server/client nature just appear do to a invoker in the JBoss sense.


Yeah. I forgot..  David reminded me in his email.


 so...

  Would doing some think like this satisfy you client-server
  requirments? :
 
  serverproxy =
  factory.createAspect(server-interceptor-stack,
  targetMbean); clientproxy =
  factory.createAspect(client-interceptor-stack, serverproxy
  );
 

 so... no that would be overkill as you introduce an additional Dynamic
 Proxy in the middle.  Right now there are straight invoke().


right again.

 The point of the separation is that you may want travelling proxies and
 you may want inVM proxies all the time.  While our client/server
 separation works today as inVM proxies (we have the EJB proxies working
 this way).

 It needs to be a construct in the factory whether you want distributable
 proxies or standalone.  Note that the full client/server merged with no
 distribution would cover both cases however.

  files.  If we
  provide a JMX interface to the factory so that you can
  view/update stack
  configurations, would that satisfy your requirement to have
  these puppies
  manageable.

 It is a bit more deep than that. I am really looking for a central
 repository of that name- configuration mapping and a way to interact
 with it, clearly JMX is the way to go and it needs to be centralized.

I thought thats kinda what I said.  The Factory right now manages the
name-configuration mapping.  We need and uber cool JMX MBean that allows us
to manipulate those configurations.

 Don't worry about it for now.  Bill and I are thinking about that
 centralization.  There also needs to be a callback in the interceptors
 for configuration changes.  This dynamicity of configuration is
 completely missing from the current codebase and the EJB spec in
 general.  This would take care of that.

You need to expand on this a little.. a small use case maybe.

 Gents I really think we got it this time. This is the end of our
 journey... the real AOP framework in JBoss. 10 years of industry
 dominance... a monopoly in the making


wow that gives me the tingles..

 marc f
 
  Regards,
  Hiram
 
 
  From: marc fleury [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: FW: [JBoss-dev] configuration of interceptors
  Date: Thu, 12 Sep 2002 13:44:03 -0400
  
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
  Behalf Of
marc fleury
Sent: Thursday, September 12, 2002 1:23 PM
To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
Subject: [JBoss-dev] configuration of interceptors
   
   
Ok
   
just had an interesting IM with hiram.  He essentially has
implemented the proxy factory we were talking about.  I
  think he is
missing the client/server side of it but we can very simply add
these.
   
Essentially it would revolve around a central
proxyFactory.createProxy(Interfaces[], client-interceptors[],
client-configurations[], server-interceptors[],
serverconfigurations[] targetMbean);
   
that returns a Dynamic Proxy, hooked up for remote/local
  calls with
client and server side interceptors.  If you are in one
  vm you can
safely assume client=server and only configure one or the other.
(meaning if one is null then don't configure transport it will be
invm
only)
   
In the case of hiram he has only one aspect of it (and he
  calls it
aspect everywhere) but that construct is really what we need.  I
also think we should have the MBean in there, even
  though we are
talking about a POJO.
   
I believe he has solid code for it and I am really interested in
adding this to the base.  I am not sure it is a JMX level
  construct
(due to the pojo nature) but having the JMX base manage these
configurations and associations between target and
interceptors/configuration is the only sane way I can imagine to
have these puppies manageable.  I want visibility on that
configuration for a given mbean (the generalized mbean
  againg being
just a pojo or target).  This is our generalized proxy factory.
   
The AOP framework of the future is staring us in the
  eye... we got
it.
   
marc f
   
   
xx
Marc Fleury, Ph.D.
President, Founder
JBoss Group, LLC
xx

RE: FW: [JBoss-dev] configuration of interceptors

2002-09-12 Thread Hiram Chirino



  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
  Chirino
  Sent: Thursday, September 12, 2002 2:25 PM
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Subject: Re: FW: [JBoss-dev] configuration of interceptors
 
 
 
  Ok I imagine a client invocation chain will look like:
 
  clientproxy - client-interceptor-stack -
  serverproxy - server-interceptor-stack - targetMbean
 
  Would doing some think like this satisfy you client-server
 requirments? :
 
  serverproxy = factory.createAspect(server-interceptor-stack,
  targetMbean);
  clientproxy = factory.createAspect(client-interceptor-stack,
  serverproxy
  );
 
  Please note: that server-interceptor-stack in essence will resolve to
  a set of { server-interfaces[], server-interceptors[],
  server-configurations[] }
 
  On another note, right now the factory that generates the proxys
  for say the
  server-interceptor-stack, is configured through static xml
  files.  If we
  provide a JMX interface to the factory so that you can view/update stack
  configurations, would that satisfy your requirement to have
  these puppies
  manageable.
 
  Regards,
  Hiram
 
 
  From: marc fleury [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: FW: [JBoss-dev] configuration of interceptors
  Date: Thu, 12 Sep 2002 13:44:03 -0400
  
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of marc fleury
Sent: Thursday, September 12, 2002 1:23 PM
To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
Subject: [JBoss-dev] configuration of interceptors
   
   
Ok
   
just had an interesting IM with hiram.  He essentially has
implemented the proxy factory we were talking about.  I think
he is missing the client/server side of it but we can very
simply add these.
   
Essentially it would revolve around a central
proxyFactory.createProxy(Interfaces[], client-interceptors[],
client-configurations[], server-interceptors[],
serverconfigurations[] targetMbean);
   
that returns a Dynamic Proxy, hooked up for remote/local
calls with client and server side interceptors.  If you are
in one vm you can safely assume client=server and only
configure one or the other. (meaning if one is null then
don't configure transport it will be invm
only)
   
In the case of hiram he has only one aspect of it (and he
calls it aspect everywhere) but that construct is really what
we need.  I also think we should have the MBean in there,
even though we are talking about a POJO.
   
I believe he has solid code for it and I am really interested
in adding this to the base.  I am not sure it is a JMX level
construct (due to the pojo nature) but having the JMX base
manage these configurations and associations between target
and interceptors/configuration is the only sane way I can
imagine to have these puppies manageable.  I want visibility
on that configuration for a given mbean (the generalized
mbean againg being just a pojo or target).  This is our generalized
proxy factory.
   
The AOP framework of the future is staring us in the eye...
we got it.
   
marc f
   
   
xx
Marc Fleury, Ph.D.
President, Founder
JBoss Group, LLC
xx
   
   
   
---
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
   
 
 
 
 
  _
  Join the world’s largest e-mail service with MSN Hotmail.
  http://www.hotmail.com
 
 
 
  ---
  This sf.net email is sponsored by:ThinkGeek
  Welcome to geek heaven.
  http://thinkgeek.com/sf
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development



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



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



RE: [JBoss-dev] Unwrapping exceptions in client proxy

2002-09-11 Thread Hiram Chirino


  This is just another reason to get rid of the lame Sun RMI
  implementation (JBoss 4.0).  In the meantime, I agree that we

 we are not there yet,

You guys talking about replacing RMI for the remote EJB invocations??  Isn't
that what we have the JBoss.IIOP and JBoss.Net projects??

Regards,
Hiram


  (you) will
  need to make patched to the unwrapping code.

 let's do the workaround

 marc f




 ---
 In remembrance
 www.osdn.com/911/
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JBoss monitoring: Thread-Pool

2002-08-29 Thread Hiram Chirino

yes.. please..  jboss-mq would benefit also.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
 Sundstrom
 Sent: Thursday, August 29, 2002 10:56 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] JBoss monitoring: Thread-Pool


 I agree, but all of our stuff can use it.  This would make it much
 easier to debug thread problems (like the interrupted bug).

 -dain

 Scott M Stark wrote:
  Its a good idea to have such a service available, but using it cannot
  be a requirement for integration at this point as in general we cannot
  get a third party to use our thread pool. The pool component should
  really just fall out of the JCA work.
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
  - Original Message -
  From: Dain Sundstrom [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Thursday, August 29, 2002 7:21 AM
  Subject: Re: [JBoss-dev] JBoss monitoring: Thread-Pool
 
 
 
 I think it would be cool to have a centralized thread pool mbean that
 anyone that needs a worker thread goes to.  The pool would need to be
 partitioned, but that is fairly simple.
 
 What do you think?
 
 -dain
 
 Sacha Labourey wrote:
 
 Cool. But do you mean that each part/module of JBoss consuming threads
 should hood in JCA? Isn't that overkill?
 
 For example, the invokers, great consumers of threads, will
 they need to
 hook in JCA? How do you see that?
 
 
 
 
 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]De la part de
 David Jencks
 Envoyé : jeudi, 29 août 2002 15:49
 À : [EMAIL PROTECTED]
 Objet : Re: [JBoss-dev] JBoss monitoring: Thread-Pool
 
 
 One of the parts of jca 1.5 is a thread pool with transaction import
 capabilities. (Work contracts)  I hope to get this committed
 in the next
 couple of days, it's written and somewhat tested.
 
 david jencks
 
 On 2002.08.29 09:21:01 -0400 Sacha Labourey wrote:
 
 
 Hello,
 
 As part of JBoss monitoring, the thread usage is a very interesting
 indication. Furthermore, for performance reasons, having a
 thread pool
 would
 be a good thing (TM).
 
 What do you think about integrating a thread pool in JBoss?
 
 Parts such as
 
 
 JavaGroups would also need to be integrated in this
 framework (JG is a
 big
 thread consumer)
 
 David, Mr. Pool ;), what do you think about it?
 
 Cheers,
 
 
 
 Sacha
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 --
 
 Dain Sundstrom
 Chief Architect JBossCMP
 JBoss Group, LLC
 
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 
  ---
  This sf.net email is sponsored by:ThinkGeek
  Welcome to geek heaven.
  http://thinkgeek.com/sf
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development


 --
 
 Dain Sundstrom
 Chief Architect JBossCMP
 JBoss Group, LLC
 



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



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



RE: [JBoss-dev] jboss modules as eclipse projects

2002-08-27 Thread Hiram Chirino

I do my JBoss development with eclipse..  but it is not easy to setup :(
If you are REALY interested, I can exand on how I do it, but it's not all
that nice.

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Igor
 Fedorenko
 Sent: Saturday, August 17, 2002 10:23 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] jboss modules as eclipse projects


 Marius Kotsbak wrote:
   On Sat, 2002-08-17 at 16:00, Igor Fedorenko wrote:
  
   Hi,
  
   I have setup eclipse project for most of jboss modules. It required
   some changes to one of build.xml files but now I can use eclipse as
   a convenient jboss source code browser or
  
  
   (theoretically) start jboss under eclipse debugger. Anyone
   interested?
  
   It works almost 100% using EASIE-plugin, or by simlpy adding all jars
   of jboss manually.
  
 Are you talking about debugging applications (ejbs for instance)
 deployed into jboss or about debugging jboss itself? I am talking
 *jboss* source code and debugging *jboss*. I do not remember it was
 possible to do anything like that with easie.

 --
 Igor Fedorenko
 Think smart. Think automated. Think Dynamics.
 www.thinkdynamics.com



 ---
 This sf.net email is sponsored by: OSDN - Tired of that same old
 cell phone?  Get a new here for FREE!
 https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JMS 1.1

2002-08-27 Thread Hiram Chirino

Good job!

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of
 Andreas Schaefer
 Sent: Saturday, August 17, 2002 10:16 PM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] JMS 1.1
 
 
 Hi Geeks
 
 JMS 1.1 is in (it compiles and most test runs trough except one).
 I will remove some redundant classes next week to make the
 implementation clearer and then adjust the JUnit tests to cover
 JMS 1.1.
 
 Please note that this step only covers the necessary steps to
 implement the common interfaces for PTP and P/S models
 but I did not implement behind the scene changes.
 
 Have fun
 
 x
 Andreas Schaefer
 Senior Consultant
 JBoss Group, LLC
 x
 
 
 
 
 ---
 This sf.net email is sponsored by: OSDN - Tired of that same old
 cell phone?  Get a new here for FREE!
 https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] what does trunk mean in the context of an invoker?

2002-08-08 Thread Hiram Chirino

Why not..  Right not It creates a byte[] of the invocation before it puts it
on the wire.  If it's greater than a certain size, we could do the
compression.

The current status of the trunk invoker is that it seems to have better
throughput than RMI, but worse latency.  In otherwords, We can push out
allot of concurrent requests out to the server but the response times of
those requests seems to blow.

Still need to figure where my latency bottle neck is comming from.

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
 Dillon
 Sent: Thursday, August 08, 2002 5:10 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] what does trunk mean in the context of an
 invoker?


 Coo, just curious.  This is a replacement for remote invocation which is
 optimized for connections and data transfer?  Do you know if the data is
 very large that gets passed back and forth?  If so, might want to add
 optional compression.  I have found that the time/cpu to compress (on
 the fly) to a remote server is negligible compared to the time it would
 take to upload uncompressed.  Anyways, just a though.

 --jason


  -Original Message-
  From: [EMAIL PROTECTED] [mailto:jboss-
  [EMAIL PROTECTED]] On Behalf Of Hiram Chirino
  Sent: Wednesday, August 07, 2002 8:33 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] what does trunk mean in the context of an
  invoker?
 
 
  It kinda describes the way this invoker works.  It setup up a single
  trunk
  socket connection to the server which all client threads share.  I
 know,
  the
  name sucks..  I'm open to sugestions.
 
  What I'm trying to provide with this trunk invoker is provide an
 invoker
  that will allow the server scale to a higher number of client
 connections.
  Still not ready for prime time use but I wantted to add it in before
 my
  CVS
  snapshot got too out of date with the current stuff.
 
  Regards,
  Hiram
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On Behalf Of
 Jason
   Dillon
   Sent: Wednesday, August 07, 2002 10:12 PM
   To: 'Jboss-Development@Lists. Sourceforge. Net'
   Subject: [JBoss-dev] what does trunk mean in the context of an
 invoker?
  
  
   Just curious,
  
   --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



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



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



RE: [JBoss-dev] InvocationLayerStressTestCase timing out

2002-07-31 Thread Hiram Chirino


Are those multi-processor machines??  I've got a feeling that I have a
deadlock happening and those machines you run them on just makes the
deadlock show up quicker than on my machine.

I also did not intend this testcase to be run as part of the normal testcase
runs... It's just mainly for for peformance comparisons.

Regards,
Hiram


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
 M Stark
 Sent: Wednesday, July 31, 2002 11:52 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] InvocationLayerStressTestCase timing out


 I see the same timeout problems on OSX. The nightly emails sent
 by Chris are periodically showing timeouts and he is running JDK
 1.3.1_03 on linux:

   Java Version 1.3.1_03
   Java Vendor Sun Microsystems Inc.
   Java VM Name Java HotSpot(TM) Server VM
   Java VM Version 1.3.1_03-b03
   Java VM Info mixed mode
   OS Name Linux
   OS Version 2.4.9-34
   OS Arch i386


 See http://www.lubega.com/testarchive/?M=D

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 - Original Message -
 From: Seth Sites [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, July 31, 2002 8:07 AM
 Subject: Re: [JBoss-dev] InvocationLayerStressTestCase timing out


  I have tested with 1.4.0 and 1.3.1_01 jdks on win2k.  The timeout only
  occurs in the OIL2 IL.  I can even double the number of workers and
  messages being pushed through the other ILs without a problem.
 
  The OIL2 IL test seems to run fine on Linux.  I have not tested
 any other
  platforms yet.
 
  -Seth




 ---
 This sf.net email is sponsored by: Dice - The leading online job board
 for high-tech professionals. Search and apply for tech jobs today!
 http://seeker.dice.com/seeker.epl?rel_code=31
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] InvocationLayerStressTestCase timing out

2002-07-31 Thread Hiram Chirino

OK..  working on it..  I can recreate under heavy load..

Regards,
Hiram

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
 M Stark
 Sent: Wednesday, July 31, 2002 7:42 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] InvocationLayerStressTestCase timing out
 
 
 Yes, both my win32 and OSX box are dual processor boxes.
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 - Original Message -
 From: Hiram Chirino [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, July 31, 2002 4:14 PM
 Subject: RE: [JBoss-dev] InvocationLayerStressTestCase timing out
 
 
 
  Are those multi-processor machines??  I've got a feeling that I have a
  deadlock happening and those machines you run them on just makes the
  deadlock show up quicker than on my machine.
 
  I also did not intend this testcase to be run as part of the normal
 testcase
  runs... It's just mainly for for peformance comparisons.
 
  Regards,
  Hiram
 
 
 
 
 ---
 This sf.net email is sponsored by: Dice - The leading online job board
 for high-tech professionals. Search and apply for tech jobs today!
 http://seeker.dice.com/seeker.epl?rel_code=31
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed

2002-07-22 Thread Hiram Chirino

Should be fixed now.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of
 [EMAIL PROTECTED]
 Sent: Monday, July 22, 2002 8:19 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed



 =
 ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
 =

 JAVA VERSION DETAILS
 java version 1.4.0_01
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
 Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

 =

 HERE ARE THE LAST 50 LINES OF THE LOG FILE

[javacc] Copyright (c) 1997-2000 Metamata, Inc.
[javacc] (type javacc with no arguments for help)
[javacc] Reading from file
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
 oss/mq/selectors/SelectorParser.jj . . .
[javacc] Warning: Lookahead adequacy checking not being
 performed since option LOOKAHEAD is more than 1.  Set option
 FORCE_LA_CHECK to true to force checking.
[javacc] File TokenMgrError.java does not exist.  Will create one.
[javacc] File ParseException.java does not exist.  Will create one.
[javacc] File Token.java does not exist.  Will create one.
[javacc] File ASCII_CharStream.java does not exist.  Will create one.
[javacc] Parser generated with 0 errors and 1 warnings.
 [mkdir] Created dir:
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/output/classes
 [javac] Compiling 8 source files to
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/output/classes

 compile-classes:
 [javac] Compiling 165 source files to
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/output/classes
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
 oss/mq/server/jmx/DestinationManager.java:44: cannot resolve symbol
 symbol  : class DestinationManagerMBean
 location: class org.jboss.mq.server.jmx.DestinationManager
implements DestinationManagerMBean
   ^
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
 oss/mq/server/jmx/InterceptorLoader.java:25: cannot resolve symbol
 symbol  : class InterceptorLoaderMBean
 location: class org.jboss.mq.server.jmx.InterceptorLoader
implements InterceptorLoaderMBean
   ^
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
 oss/mq/server/jmx/Invoker.java:25: cannot resolve symbol
 symbol  : class InvokerMBean
 location: class org.jboss.mq.server.jmx.Invoker
implements InvokerMBean
   ^
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
 oss/mq/server/jmx/Queue.java:29: cannot resolve symbol
 symbol  : class QueueMBean
 location: class org.jboss.mq.server.jmx.Queue
implements QueueMBean
   ^
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
 oss/mq/server/jmx/Topic.java:33: cannot resolve symbol
 symbol  : class TopicMBean
 location: class org.jboss.mq.server.jmx.Topic
implements TopicMBean
   ^
 /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
 oss/mq/server/jmx/DelayInterceptor.java:42: cannot resolve symbol
 symbol  : class DelayInterceptorMBean
 location: class org.jboss.mq.server.jmx.DelayInterceptor
implements DelayInterceptorMBean {
   ^
 6 errors

 BUILD FAILED
 file:/disk/orig/home/lubega/jbossro/jboss-all/messaging/build.xml:
390: Compile failed; see the compiler error output for details.

Total time: 4 minutes 12 seconds


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



---
This sf.net email 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] current cvs version can't be built

2002-07-22 Thread Hiram Chirino

try it again..  I forgot to check something in.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Alex
 Loubyansky
 Sent: Monday, July 22, 2002 2:54 AM
 To: JBoss-Dev
 Subject: [JBoss-dev] current cvs version can't be built
 
 
 Hello guys,
 
 just have checked out cvs for jboss-3.1.0alpha and couldn't build it.
 
 compile-classes:
 [javac] Compiling 165 source files to 
 C:\CVSROOT\jboss-all\messaging\output\classes
 C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\De
 layInterceptor.java:42: cannot resolve symbol
 symbol  : class DelayInterceptorMBean  
 location: class org.jboss.mq.server.jmx.DelayInterceptor
implements DelayInterceptorMBean {
   ^
 C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\De
 stinationManager.java:44: cannot resolve symbol
 symbol  : class DestinationManagerMBean  
 location: class org.jboss.mq.server.jmx.DestinationManager
implements DestinationManagerMBean
   ^
 C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\In
 terceptorLoader.java:25: cannot resolve symbol
 symbol  : class InterceptorLoaderMBean  
 location: class org.jboss.mq.server.jmx.InterceptorLoader
implements InterceptorLoaderMBean
   ^
 C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\In
 voker.java:25: cannot resolve symbol
 symbol  : class InvokerMBean  
 location: class org.jboss.mq.server.jmx.Invoker
implements InvokerMBean
   ^
 C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\Qu
 eue.java:29: cannot resolve symbol
 symbol  : class QueueMBean  
 location: class org.jboss.mq.server.jmx.Queue
implements QueueMBean
   ^
 C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\To
 pic.java:33: cannot resolve symbol
 symbol  : class TopicMBean  
 location: class org.jboss.mq.server.jmx.Topic
implements TopicMBean
   ^
 6 errors
 
 BUILD FAILED
 
 file:C:/CVSROOT/jboss-all/messaging/build.xml:390: Compile 
 failed; see the compiler error output for details.
 at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842)
 at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)
 at org.apache.tools.ant.Task.perform(Task.java:317)
 at org.apache.tools.ant.Target.execute(Target.java:309)
 at org.apache.tools.ant.Target.performTasks(Target.java:334)
 at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
 at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261)
 at 
 org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModul
 e(ExecuteModules.java:292)
 at 
 org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(Exec
 uteModules.java:194)
 at org.apache.tools.ant.Task.perform(Task.java:317)
 at org.apache.tools.ant.Target.execute(Target.java:309)
 at org.apache.tools.ant.Target.performTasks(Target.java:334)
 at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
 at org.apache.tools.ant.Project.executeTargets(Project.java:1250)
 at org.apache.tools.ant.Main.runBuild(Main.java:610)
 at org.apache.tools.ant.Main.start(Main.java:196)
 at org.apache.tools.ant.Main.main(Main.java:235)
 
 
 -- 
 Best regards,
  Alex Loubyansky
 
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


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



[JBoss-dev] New JBossMQ IL : OIL2

2002-07-22 Thread Hiram Chirino

Hi guys,

Just wanted to let you guys know about a new Invocation Layer for JBossMQ.
It's called OIL2 because it's closest relative is the current OIL Invocation
Layer.

I'm very exited about this new IL because it has some very nice performance
features.  It has low serialization over-head like the old OIL used to have,
but it only uses one socket like the UIL.  Furthermore, when multiple client
threads share the connection, the connection will be multiplexed between the
sockets.

The OIL and UIL ILs used to suffer severely when multiple client threads
shared the connection.  I've added a new test to the test suite which can be
used to view the performance of the different ILs when multiple threads are
sharing a single connection.  The results for test case which uses 20
threads sending and receiving 200 messages are:

testcase
name=testOILMutliSessionOneConnection(org.jboss.test.jbossmq.perf.Invocatio
nLayerStressTestCase) time=45.255/testcase
testcase
name=testOIL2MutliSessionOneConnection(org.jboss.test.jbossmq.perf.Invocati
onLayerStressTestCase) time=7.511/testcase
testcase
name=testUILMutliSessionOneConnection(org.jboss.test.jbossmq.perf.Invocatio
nLayerStressTestCase) time=50.683/testcase
testcase
name=testRMIMutliSessionOneConnection(org.jboss.test.jbossmq.perf.Invocatio
nLayerStressTestCase) time=21.951/testcase

As you can see the OIL2 IL did nicely.  Hopefully we can make this the
default IL soon.

Regards,
Hiram



---
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] is x++ an atomic operation??

2002-07-18 Thread Hiram Chirino


Quick question for you Java Language Gurus out there, I heard one that the
post increment operator was an atomic operation.  For example, if you have a
multi-threaded application with:

  id=lastRequestId++;

You would not need to put this in a synchronized block be cause the ++ would
be atomic and thus you would not get 2 duplicate ids.  I was wondering if
this is true or not.  Can anybody confirm this for me??


Regards,
Hiram



---
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] Obvious JMS Bug that I need fixed right away. -other possiblebug

2002-06-09 Thread Hiram Chirino


yes.. typo.  fixed now in CVS.

Regards,
Hiram

From: Marius Kotsbak [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Obvious JMS Bug that I need fixed right away. 
-other possible bug
Date: 09 Jun 2002 10:01:23 +0200

From login-config.xml for jbossmq:

 application-policy name = jbossmq
authentication

   login-module code = org.jboss.mq.sm.file.DynamicLoginModule
  flag = sufficient
  module-option name =
unauthenticatedIdentityguest/module-option
  module-option name =
sm.objectnamjboss.mq:service=StateManager/module-option
 
   /login-module


Is sm.objectnam a typing error? Shoudn't it be sm.objectname ?

Marius K
Boostcom


On søn, 2002-06-09 at 02:47, Hiram Chirino wrote:
  Post a patch to sourceforge and I'll bring it into the code base.
 
  Regards,
  Hiram
 
 
  From: Joshua D. Cough [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
  Date: Fri, 7 Jun 2002 12:28:50 -0400
  
  It is impossible to call recover in SpySession.java
  
  here is why:
  
  
  if ( transacted ) {
throw new IllegalStateException( The session is transacted 
);
 }
  if ( !transacted ) {
   throw new IllegalStateException( The session is not
  transacted
  );
}
  
  This obviously doesnt make sense. I need to call recover from a
  nontransacted session and have my unacknowledged messages redelivered. 
Here
  is the code that needs to be fixed:
  
  
 
  =
  
 //Rollback a transacted session
  public synchronized void rollback()
 throws JMSException {
  
 synchronized ( runLock ) {
  
if ( spyXAResource != null ) {
   throw new javax.jms.TransactionInProgressException( 
Should
  not
  be call from a XASession );
}
if ( closed ) {
   throw new IllegalStateException( The session is closed 
);
}
if ( !transacted ) {
   throw new IllegalStateException( The session is not
  transacted
  );
}
  
// rollback transaction
try {
   connection.spyXAResourceManager.endTx( 
currentTransactionId,
  true );
   connection.spyXAResourceManager.rollback( 
currentTransactionId
  );
} catch ( javax.transaction.xa.XAException e ) {
   throw new SpyJMSException( Could not rollback, e );
} finally {
   try {
  currentTransactionId =
  connection.spyXAResourceManager.startTx();
   } catch ( Exception ignore ) {
   }
}
  
 }
  }
  
  
  public synchronized void recover()
 throws JMSException {
 if ( closed ) {
throw new IllegalStateException( The session is closed );
 }
 if ( transacted ) {
throw new IllegalStateException( The session is transacted 
);
 }
  
 rollback();
  
  }
  
  
  ___
  
  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
 
 
 
  _
  Get your FREE download of MSN Explorer at 
http://explorer.msn.com/intl.asp.
 
 
  ___
 
  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



___

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




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


___

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

Re: [JBoss-dev] Obvious JMS Bug that I need fixed right away.

2002-06-08 Thread Hiram Chirino

Post a patch to sourceforge and I'll bring it into the code base.

Regards,
Hiram


From: Joshua D. Cough [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
Date: Fri, 7 Jun 2002 12:28:50 -0400

It is impossible to call recover in SpySession.java

here is why:


if ( transacted ) {
  throw new IllegalStateException( The session is transacted );
   }
if ( !transacted ) {
 throw new IllegalStateException( The session is not 
transacted
);
  }

This obviously doesnt make sense. I need to call recover from a
nontransacted session and have my unacknowledged messages redelivered. Here
is the code that needs to be fixed:


=

   //Rollback a transacted session
public synchronized void rollback()
   throws JMSException {

   synchronized ( runLock ) {

  if ( spyXAResource != null ) {
 throw new javax.jms.TransactionInProgressException( Should 
not
be call from a XASession );
  }
  if ( closed ) {
 throw new IllegalStateException( The session is closed );
  }
  if ( !transacted ) {
 throw new IllegalStateException( The session is not 
transacted
);
  }

  // rollback transaction
  try {
 connection.spyXAResourceManager.endTx( currentTransactionId,
true );
 connection.spyXAResourceManager.rollback( currentTransactionId
);
  } catch ( javax.transaction.xa.XAException e ) {
 throw new SpyJMSException( Could not rollback, e );
  } finally {
 try {
currentTransactionId =
connection.spyXAResourceManager.startTx();
 } catch ( Exception ignore ) {
 }
  }

   }
}


public synchronized void recover()
   throws JMSException {
   if ( closed ) {
  throw new IllegalStateException( The session is closed );
   }
   if ( transacted ) {
  throw new IllegalStateException( The session is transacted );
   }

   rollback();

}


___

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



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


___

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] [ jboss-Bugs-561683 ] Remove log4j dependency on client side

2002-05-29 Thread Hiram Chirino


Log4j on the client side is the only way to trace/debug problems with client 
side code.  In the case of JBossMQ, 1/2 of all the work is done on the 
client side!  It's super important to keep the ability to trace client side 
code.

Regards,
Hiram

From: Sacha Labourey [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: Jason Dillon [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on 
client side
Date: Wed, 29 May 2002 12:26:20 +0200

Jason,

Which is the part you don't understand?

Cheers,


   Sacha

  Um... what?
 
  --jason


___

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




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


___

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] CCEs make jbossmq.perf and jbossmq.test fail

2002-05-27 Thread Hiram Chirino

This should be fixed now.  Thanks for pointing it out.

Regards,
Hiram

From: Giorgio42 [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CCEs make jbossmq.perf and jbossmq.test fail
Date: Sat, 25 May 2002 18:25:32 -0500

I'm running the test suite for CVS head (200205252357)
on W2K / Sun JDK 1.4.

The exceptions in the report say that a message could not
be removed due to not being able to delete the record in the database (0 
rows affected), but the log shows that
a CCE occured:

2002-05-26 00:26:51,234 WARN  [org.jboss.mq.il.oil.OILServerILService] 
Client request resulted in a server exception:
org.jboss.mq.SpyJMSException: Could not delete the message from the 
database: delete affected 0 rows
   at 
org.jboss.mq.pm.jdbc2.PersistenceManager.remove(PersistenceManager.java:801)
   at org.jboss.mq.server.BasicQueue.acknowledge(BasicQueue.java:306)
   at org.jboss.mq.server.JMSQueue.acknowledge(JMSQueue.java:97)
   at org.jboss.mq.server.ClientConsumer.acknowledge(ClientConsumer.java:323)
   at 
org.jboss.mq.server.JMSDestinationManager.acknowledge(JMSDestinationManager.java:522)
   at 
org.jboss.mq.server.JMSDestinationManager.acknowledge(JMSDestinationManager.java:506)
   at 
org.jboss.mq.server.JMSServerInterceptorSupport.acknowledge(JMSServerInterceptorSupport.java:197)
   at 
org.jboss.mq.server.TracingInterceptor.acknowledge(TracingInterceptor.java:351)
   at 
org.jboss.mq.server.JMSServerInvoker.acknowledge(JMSServerInvoker.java:199)
   at 
org.jboss.mq.il.oil.OILServerILService$Client.run(OILServerILService.java:229)
   at java.lang.Thread.run(Thread.java:536)
2002-05-26 00:26:51,234 ERROR [STDERR] 
[b]java.lang.ClassCircularityError:[/b] sun/reflect/ConstructorAccessorImpl
2002-05-26 00:26:51,265 ERROR [STDERR] at 
sun.misc.Unsafe.defineClass(Native Method)
2002-05-26 00:26:51,265 ERROR [STDERR] at 
sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
2002-05-26 00:26:51,265 ERROR [STDERR] at 
sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
2002-05-26 00:26:51,265 ERROR [STDERR] at 
java.security.AccessController.doPrivileged(Native Method)
2002-05-26 00:26:51,468 ERROR [STDERR] at 
sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
2002-05-26 00:26:51,468 ERROR [STDERR] at 
sun.reflect.MethodAccessorGenerator.generateConstructor(MethodAccessorGenerator.java:76)
2002-05-26 00:26:51,468 ERROR [STDERR] at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:30)
2002-05-26 00:26:51,468 ERROR [STDERR] at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
2002-05-26 00:26:51,500 ERROR [STDERR] at 
java.lang.reflect.Constructor.newInstance(Constructor.java:274)
2002-05-26 00:26:51,500 ERROR [STDERR] at 
java.lang.Class.newInstance0(Class.java:296)
2002-05-26 00:26:51,500 ERROR [STDERR] at 
java.lang.Class.newInstance(Class.java:249)
2002-05-26 00:26:51,500 ERROR [STDERR] at 
org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.createBeanClassInstance(JAWSPersistenceManager.java:163)
2002-05-26 00:26:51,500 ERROR [STDERR] at 
org.jboss.ejb.plugins.CMPPersistenceManager.createBeanClassInstance(CMPPersistenceManager.java:165)
2002-05-26 00:26:51,531 ERROR [STDERR] at 
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createBeanClassInstance(CachedConnectionInterceptor.java:251)
2002-05-26 00:26:51,531 ERROR [STDERR] at 
org.jboss.ejb.EntityContainer.createBeanClassInstance(EntityContainer.java:273)
2002-05-26 00:26:51,531 ERROR [STDERR] at 
org.jboss.ejb.plugins.AbstractInstancePool.add(AbstractInstancePool.java:148)
2002-05-26 00:26:51,531 ERROR [STDERR] at 
org.jboss.ejb.plugins.TimedInstancePoolFeeder.run(TimedInstancePoolFeeder.java:61)
2002-05-26 00:26:51,546 ERROR [STDERR] at 
java.util.TimerThread.mainLoop(Timer.java:432)
2002-05-26 00:26:51,546 ERROR [STDERR] at 
java.util.TimerThread.run(Timer.java:382)

Is JBossMQ OK in CVS head (usable for production)?
Any similar problem known with 3.0 RC3?

Thanks.
Georg

* * *

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

___

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




_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


___

Don't miss the 

Re: [JBoss-dev] HEAD JBossMQ failures

2002-05-27 Thread Hiram Chirino


Mucked up jdbc PM.  Fixed now.

Regards,
Hiram

From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] HEAD  JBossMQ failures
Date: Sun, 26 May 2002 16:32:51 -0700

I am seeing lots of these for various JBossMQ and other JMS related tests:

snip
org.jboss.mq.SpyJMSException: Cannot acknowlege a message
...

Any idea what is up with this?

--jason

-
This mail sent through IMP: http://horde.org/imp/

___

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




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


___

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] Seeing occasional Invalid tx id with JMS RA

2002-05-24 Thread Hiram Chirino


I think that would be safer.  That will also allow the session to go back 
into the session pool thus you will share your resources better.

Regards,
Hiram

From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED],   Scott M Stark 
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Date: Fri, 24 May 2002 00:41:03 -0700

Or perhaps I am not using the JMS resource propertly within the bean...

Should I be able to save a QueueSession and QueueSender as fields and use 
them
over multipule calls inside of a SFSB?  Or do I need to recreate the 
session
and sender each time?

If that is the case it rather sucks... what a pain...

--jason


On Friday 24 May 2002 12:22 am, Jason Dillon wrote:
  After thinking about this somemore, and enabling thread info in 
server.log
  I realize now that the timer is not an issue, there is never an instance
  where the timer thread attempts to use the wrapper over the SFSB... the
  work completes too fast.
 
  And due to the fact that I sync'd the wrapper methods it appears that 
this
  problem happens simply because the invoke happened in a seperate thread.
 
  Unfortunatly it does not really narrow the problem space to debug.  The 
JMS
  RA does not function with out a TX, it does not attempt to start one if
  there isn't one already... so it just fails.
 
  Is it possible that there is something a miss with the bits which setup 
the
  tx for the SFSB?  Or would I see other problems when the SFSB commits... 
I
  think this is the case, but I am not sure.
 
  If that is true, and the SFSB does have a TX, then it must be the JMS RA 
or
  JBossMQ which is at fault... and I don't really know how to isolate 
which
  it is at this point.  If I don't use the JMS RA, then I have to 
implement
  all of the XA stuff myself, which I am sure to mess up.
 
  Any clue on how I could narrow the problem space any?
 
  I am running the same test again with trace enabled for org.jboss.mq and
  org.jboss.resource.adapter.jms.  With the added log messages for the JMS 
RA
  I might be able to see a problem... but who knows.
 
  --jason
 
  On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote:
   If the only cause of this can be use by multiple threads, then 
updating
   the error message to indicate incorrect usage would be good.
  
   
   Scott Stark
   Chief Technology Officer
   JBoss Group, LLC
   
   - Original Message -
   From: Jason Dillon [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]; Scott M Stark
   [EMAIL PROTECTED]
   Sent: Thursday, May 23, 2002 8:18 PM
   Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
  
  
   Does this mean we should not try to produce more meaningful error
   messages when this does happen... or just leave it as is?
  
   --jason
  
   On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote:
I don't see sufficient justification to go beyond the spec here so
let's just leave it.
   

Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Hiram Chirino [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 23, 2002 7:45 PM
Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
   
 He who codes wins the vote.  This issue does not bother me enough 
to
   
change
   
 anything.

 Regards,
 Hiram

 From: David Maplesden [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: '[EMAIL PROTECTED]'
 [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS 
RA
 Date: Fri, 24 May 2002 14:35:21 +1200
 
 I understand the pros and cons, I am just saying what I feel.  
You
  can outvote me if you wish.
 
 David
 
   -Original Message-
   From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
   Sent: Friday, May 24, 2002 2:14 PM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with 
JMS
   RA
  
  
  
   Think about it this way...  somebody creates a simple servlet
   that creates a
   unit of work by sending 2 messages and then commits the work.
Somebody that
   does not know the spec to will might cache that session in a
  
   instance
  
   variable.  If 2 requests come in at the same time, they will
   screw each
   other up seriously.  The first request might commit his 2
   messages and some
   of the messages the 2nd thread was creating.
  
   So the question is, should we try to make the session
   thread-safe for the
   power users out there that MIGHT know how stuff is working
   under the covers.
 Or should we make the session check conncurent access better 
to
  
   let
  
   beginer user know when he has potentialy made a semantical

Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA

2002-05-23 Thread Hiram Chirino


From: Jason Dillon [EMAIL PROTECTED]
...
And is there any reason why SpySession.sendMessage() should NOT be
synchronized?


If anything SpySession.sendMessage() should try to detect the concurrent 
access from 2 threads and throw an exception stating that the JMS spec is 
being violated by the fact that 2 threads are trying to access a single 
session object simulatiously.

Regards,
Hiram

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


___

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] Seeing occasional Invalid tx id with JMS RA

2002-05-23 Thread Hiram Chirino


Think about it this way...  somebody creates a simple servlet that creates a 
unit of work by sending 2 messages and then commits the work.  Somebody that 
does not know the spec to will might cache that session in a instance 
variable.  If 2 requests come in at the same time, they will screw each 
other up seriously.  The first request might commit his 2 messages and some 
of the messages the 2nd thread was creating.

So the question is, should we try to make the session thread-safe for the 
power users out there that MIGHT know how stuff is working under the covers. 
  Or should we make the session check conncurent access better to let 
beginer user know when he has potentialy made a semantical error.

Regards,
Hiram

From: David Maplesden [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' 
[EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Date: Fri, 24 May 2002 13:36:43 +1200

I hate to disagree with Scott and Hiram but I feel that just because the
spec says Sessions should only be used in 1 thread does not neccessarily
mean that we should restrict their usage as such.

I know a Session only makes sense in the context of a single process, but
this might still entail the usage of a couple of different threads.  I 
don't
think we should place any restrictions on the usage of Sessions as long as
they work, and I believe making sendMessage() synchronized will do the
trick.

This can be just one more area where JBoss goes Beyond the Spec but hey I
leave the final decision up to someone else.

David.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002


___

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




_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


___

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] JMS related; not sure if this is a problem, but it is odd...

2002-05-23 Thread Hiram Chirino


It's ok.  The message was being displayed before the message was added.

From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]'  
[EMAIL PROTECTED]
Subject: [JBoss-dev] JMS related; not sure if this is a problem, but it is 
odd...
Date: Thu, 23 May 2002 19:10:48 -0700

I enabled DEBUG for org.jboss.mq, and I see logs like:

Andy, a message just got queued in 
org.jboss.mq.server.PersistentQueue@c7e8a7,
queue size is: 0

I have not even looked at the code, but after you add something to a queue,
the size should be  0 right?

--jason

___

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




_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


___

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



[JBoss-dev] Re: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems Deploying Similarejb-jars in Different EARs

2002-05-17 Thread Hiram Chirino

Yes I agree it should be configurable.

Regards,
Hiram

From: Dain Sundstrom [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
Subject: Re: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems 
Deploying Similar ejb-jars in Different EARs
Date: Fri, 17 May 2002 00:40:00 -0500

Then you loose optimized calls between two deployments if they contain 
copies of the same classes.

We could offer an option like we do with wars, where it could (if the user 
chooses) return to the default ejb behavior.

-dain

Hiram Chirino wrote:

Marc,

I've got to side with scott here.  Maybe I'm being academic but you seem 
to loose the class isolation benefits just to make it easier get 
classpaths right.

How hard would it be to do something like:  You create a UCL Repository 
for each Deployment Unit.  Make every deployment unit have an identifier.  
When a deployment unit B depends on the classes of deployment unit A, he 
just specifies that he needs to import the classes of the deployment unit 
A.  Then a cross UCL Repository association would be setup so that the 
Repository of B would use Repository A to load classes also.

For bonus you might even allow configuring a UCL Repository to not allow 
some classes to be exported to other UCL Repositories..

So, what do you think, have I been smoking too long tonight??

Regards,
HIram

From: Scott M Stark [EMAIL PROTECTED]
Reply-To: Scott M Stark [EMAIL PROTECTED]
To: JBoss Group [EMAIL PROTECTED]
Subject: Re: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems 
Deploying Similar ejb-jars in Different EARs
Date: Thu, 16 May 2002 19:11:29 -0700

That's absurd. So he also has to setup a port redirector to map from the
well know ports such as 1099, 80 onto the individual JBoss instances. 
This
in general is not possible if each client does not have a unique virtual
host.
We need more flexibility in defining repository domains.

- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]; JBoss Group
[EMAIL PROTECTED]
Sent: Thursday, May 16, 2002 6:56 PM
Subject: RE: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems
Deploying Similar ejb-jars in Different EARs


  |
  |So what does an ISP with 100 independent client ears who may very 
well
all
  |be
  |using the same package names do? Setup 100 instances of JBoss with
  |each running seperate ports...
 
  yup
 
  marcf
 
 
  ___
  jboss-group mailing list
  [EMAIL PROTECTED]
  https://secure.jboss.org/mailman/listinfo/jboss-group
 

___
jboss-group mailing list
[EMAIL PROTECTED]
https://secure.jboss.org/mailman/listinfo/jboss-group





_
Chat with friends online, try MSN Messenger: http://messenger.msn.com

___
jboss-group mailing list
[EMAIL PROTECTED]
https://secure.jboss.org/mailman/listinfo/jboss-group




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


___

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] XDoclet and C# style metadata

2002-05-17 Thread Hiram Chirino


Unless the getClassMetaData() loaded up the config info from a resource xml 
file.  The XDoclet stuff would just generate the getClassMetaData() method 
(that just loads the data from the xml file) and the .xml that holds the 
class metadata.

If getClassMetaData() returned a really generic object like a xml dom, then 
you would never have to change getClassMetaData().

Regards,
Hiram

From: Dain Sundstrom [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] XDoclet and C# style metadata
Date: Fri, 17 May 2002 14:12:53 -0500

Ok, I'm responding to my own email.  Sometimes I get to excited.

This is technique will only be useful in some circumstances because it
requires changing your source code to change a simple configuration.  In
my case this is acceptable, because I'm talking about test cases.  It
would also be useful for many EJB programmers, as they use XDoclet to
set TX attributes (although they can still change the dd, they are not
editing the source of truth).

I still think it would be very useful, but it is not as ungodly powerful
as I first thought.

-dain

Dain Sundstrom wrote:

I was just thinking how cool it would be to generically associate xml
with a method declaration.

Back story:

I am working on unit test cases for JBossCMP using JUnitEJB and it would
be really useful to mark a test method with a tx attribute.  Now this
test code is not an EJB or an XMBean, so I don't have a descriptor file
(this is not important; I just wanted to avoid the lame make it an ejb
emails).

Idea (I only know a little about XDoclet an less about C#)

Mark up the code with XDoclet tags that contain generic xml.  Then run
XDoclet to preprocess the java file and generate a new java file with an
additional method getClassMetaData.  This class would work like the
getClass stuff, but would add additional methods to return the extra
metadata specified in the class.

Use:

In my case, the server side tester would get the metadata, check for a
tx tag and would start a tx if required by the tag.  We could use the
same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything.
This is something (I think) C# has and is unbelievably powerful.

What do you think?

-dain


___

Hundreds of nodes, one monster rendering program.
Now that's a super model! Visit http://clustering.foundries.sf.net/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



___

Hundreds of nodes, one monster rendering program.
Now that’s a super model! Visit http://clustering.foundries.sf.net/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


___

Hundreds of nodes, one monster rendering program.
Now that’s a super model! Visit http://clustering.foundries.sf.net/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] JMX RMI Adapter JNDI binding

2002-05-13 Thread Hiram Chirino


I think that you can just default it to jmx:rmi and give allow the location 
of the bind to be configurable.

So when you have 2 jmx servers using the same JNDI service, then that 
problem is solved by having second jmx server can bind to something like 
server2/jmx:rmi

Regards,
Hiram


From: Andreas Schaefer [EMAIL PROTECTED]
To: Jason Dillon [EMAIL PROTECTED],   
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX RMI Adapter  JNDI binding
Date: Mon, 13 May 2002 07:33:57 -0700

Hi Jason

  Can someone point me to the spec where it states where in JNDI the JMX 
RMI
  adapter should be bound to.

Because otherwise no client can find the JMX RMI-Adapter except for the
local
client.

  Currently we are binding to jmx:hostname:rmi which is fine when you
are
  working with the localhost, but will start to cause problems once used 
in
a
  multi-host environment.
 
  For example, consider a situation where a machine has more than one
resolvable
  name (via DNS CNAMES or similar).  Lets say that the localhost name is 
set
to
  myhost.mydomain.com, and there us a CNAME www.mydomain.com.  The JMX
RMI
  adapter will be bound to jmx:myhost.mydomain.com:rmi.
 
  Now consider the deployer.sh|bat scripts run from a seperate machine.
There
  is a --server option, which is the hostname bit from
jmx:hostname:rmi.
  This is currently only used to lookup the RMIAdapter from JNDI but not
used to
  setup the Context.URL.  This means that a client could not:
 
  ./deployer.sh --server www.mydomain.com --deploy someurl

Aggreed that is a problem. The reason to do so is that I wanted a way to
bind
multiple JMX-RMI Adaptor on the JNDI server.
The REAL problem pops up when we have two JVMs with a JMX RMI Adaptor
running !!!

  Assuming that deployer.sh did make up a Context.URL from --server (which
it does
  not) this would not work due to a lookup failure, as there will be no
  jmx:www.mydomain.com:rmi bound.

The client is supposed to look up the right JNDI name but I created a
pattern he
can easier guess the right name.

  The point is that we can not reliably use any resolvable address.

As I said the bigger problem is with two JVMs.

  So, I don't know what the spec says.  If the spec wants us to use the
hostname
  fine, but lets also bind the local adapter to a common name, like
  jmx:localhost:rmi or perhaps jmx::rmi or whatever I don't really 
care,
as
  long as the name is not specific to the local host configuration.

The current spec. says nothing and the current JNDI name was my idea. We
could
add a second name called jmx:localhost:rmi which does not help when we
have
2 JVMs. Assuming that the JNDI server is running on another box this name
has
not meaning anymore.

Have fun - Andy



___

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




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


___

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] JMX RMI Adapter JNDI binding

2002-05-13 Thread Hiram Chirino




From: Andreas Schaefer [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED], [EMAIL PROTECTED],   
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX RMI Adapter  JNDI binding
Date: Mon, 13 May 2002 08:26:36 -0700

Hi Hiram

  I think that you can just default it to jmx:rmi and give allow the
location
  of the bind to be configurable.
 
  So when you have 2 jmx servers using the same JNDI service, then that
  problem is solved by having second jmx server can bind to something like
  server2/jmx:rmi

But how to you know which JVM you need ? Let us assume that it would
be possible to run more than one JBoss instances on the same box. Now
you want to deploy on a particular server. How you know which JVM/Server
you have to talk to ?

Andy




If the 2 JBoss instances are using different JNDI servers then the you pick 
the server by setting up the InitialContext correctly.

If the 2 JBoss instances are using the same JNDI server, then you pick the 
correct server by looking up the correct JNDI key jmx:rmi vs. 
server2/jmx:rmi

Regards,
Hiram


_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


___

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] Bug: Dynamic Topic not being destroyed in all cases

2002-05-07 Thread Hiram Chirino


Please log a bug report at http://sf.net/projects/jboss

From: mary [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Bug: Dynamic Topic not being destroyed in all cases
Date: Mon, 6 May 2002 17:58:43 -0500

What I'm seeing appears to be a bug:

I have a message listener listening on a dynamically created topic, a MDB 
publishing to that same topic, and a session bean that comes along and 
deletes the topic. When the session bean tries to delete the dynamically 
created topic however, the topic is only removed from JNDI and NOT 
destroyed. This exception is thrown when deleting the topic fails: 
Stopping failed: javax.jms.JMSException: The destination is being used.

Further messages in the server log say the topics been destroyed, but 
listing the topics from the jmx web viewer verifies it has not been.

I found this because I was trying to recreate the topic. JNDI lookups 
failed, but createTopic() gave an InstanceAlreadyExistsException.

Do I need to log this bug somewhere, or is this post good enough?

Thanks,
Mary

* * *

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

___

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




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


___

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] dynamically adding/removing queues/topics

2002-05-03 Thread Hiram Chirino

That feature might have been broken in the 3.0 RC1, but I know for a FACT 
that it is working in the CVS head now.  We now have some automated junit 
tests the create/destroy destinations via jmx on ever testcase.

Regards,
Hiram


From: Joel Boehland [EMAIL PROTECTED]
To: JBoss Dev [EMAIL PROTECTED]
Subject: [JBoss-dev] dynamically adding/removing queues/topics
Date: Fri, 03 May 2002 15:39:43 -0700

Hi,
Someone posted a message on the old
spydermq list that looks like it belongs
on this list. I am putting the original
message and my response below. If
someone finds something wrong with the
facts in my response please correct me.
Thanks,
Joel

***
***Mary wrote:
***
Hi Joel,
I have rc1 of JBoss 3.0.0 and have been
testing your interface for
topic creation/deletion both
programmaticaly and from the JMX web
interface.

What I'm seeing is that topics are
getting created successfully, and
I can delete them successfully. If I try
to create a topic again
after having destroyed it however, I get
this exception:

javax.jms.JMSException: This destination
has allready been added to
the server!
at
org.jboss.mq.server.JMSServer.addDestination
(JMSServer.java:830)
 at
org.jboss.mq.server.TopicManager.startService
(TopicManager.java:56)
 at
org.jboss.system.ServiceMBeanSupport.start
(ServiceMBeanSupport.java:162)
 at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
 at
java.lang.reflect.Method.invoke(Method.java:324)
 at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke
(ReflectedMBeanDispatcher.java:284)
...

If I do a JNDI lookup of the topic, it
doesn't exist, and the server
log file says it was successfully
destroyed, so I think this is a
bug.
I really need this feature so I will try
to see if I can find
anything debugging in to it. Please let
me know if you've encountered
this or fixed it. And thanks by the way
for contributing this feature
to JBoss for us all!

Thanks,
Mary



My reply:

Hi Mary,
Its been a Long time since I added
the add/destroy queue/topic methods to
the JMSServer class in the jbossmq
module. I just checked out the most
recent version from cvs, and everything
I added is gone. This is a fast moving
code-base!  I believe they moved all the
functionality of those methods into the
org.jboss.mq.server.DestinationManager
class. From what I can see, it *should*
be working. The stopService method is
what I believe gets invoked
automagically when you call
destroyTopic/destroyQueue on the
JMSServer MBean. This in turn invokes
closeDestination() on the JMSServer
class, and this method removes the
topic/queue from the internal
destinations HashMap. Unfortunately, it
looks like somehow that destination
isn't really being removed from the
HashMap.

I don't have time to debug this right
now, but I did, these are probably the
steps I would follow:
1. Using debug logging or a debugger,
trace the chain of invokers involved in
a destroyTopic/queue call. From a quick
glance, I think it goes something like
(all classes in the org.jboss.mq.server
package):
JBossMQService.destroyDestination()
--DestinationManager.stopService()
--JMSServer.closeDestination()

At the end of that chain, the
topic/queue should be gone from jndi,
and removed from the destinations
HashMap in JMSServer. Maybe the end of
the closeDestination() method in
JMSServer would be a good time to
iterate thru the hashmap and print out
the names of the destinations it
contains to be sure that is the case. If
you find this isn't the case, and you
can't find the cause, It would be a good
time to post a bug report from jboss's
sourceforge project page:
(http://sourceforge.net/projects/jboss/ )

I will post this message to jboss-dev
(which is where you should post/follow
bugs. Spydermq on yahoo groups is pretty
much a dead list) and someone there may
have more info on this. If I get time
this weekend or later next week I may be
able to delve a little deeper into this
as well. Good luck,
Joel


___

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




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


___

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]

[JBoss-dev] JBossMQ JMX Interface change

2002-05-03 Thread Hiram Chirino


Hi guys,

I just finished commiting some major refactoring of the JBossMQ server.  It 
just involved formaizing the interceptor pattern that peter started with the 
security manager addition.  I also refactored some of the JMX MBeans to 
thier own package.  So this is your notice:

THE JMX INTERFACE TO JBOSSMQ CHANGED.

Ok, it didn't change that much but, it changed.  I hope this does not break 
too many things.

I'll be commiting these changes to Branch_3_0 soon.

Regards,
Hiram

_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


___

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



[JBoss-dev] JBoss Most Active this Week

2002-05-02 Thread Hiram Chirino


Check out http://sourceforge.net right now!!  JBoss is at the top of the 
Most Active this Week

Regards,
HIram

_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


___

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] Running testsuite twice almost works now.(Branch_3_0)

2002-05-02 Thread Hiram Chirino


I feel like ripping that code out of the JMSContainerInvoker!  It ties the 
JMSContainerInvoker down tightly to JBossMQ and there are other providers 
out there that are complaining about that.

If somebody wants the auto-create feature that badly, they can implement it 
more elegently at the org.jboss.jms.jndi.JMSProviderAdapter level.

Does anybody oppose?

Regards,
Hiram

From: Adrian Brock [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Running testsuite twice almost works 
now.(Branch_3_0)
Date: Thu, 2 May 2002 12:06:20 -0500

Yes,

It creates the Queue if it doesn't exist.
Look in org.jboss.ejb.plugins.jms.JMSContainerInvoker
at createDestination(...)

Regards,
Adrian

  I've lost track of where this destination is being
  created.  Is it
  automatic from the jndi lookup?
 
  david jencks
 
 
  On 2002.05.01 15:00:52 -0400 Adrian Brock wrote:
   Well done David.
  
   The JBossMQ problem is because it creates a
  Destination
   MBean directly in the ServiceController without
   specifying any dependencies. It gets destroyed
   with the ServiceController, after the service it
   requires has gone.
  
   Anybody know what the dependency should be?
   jboss.mq:service=server?
  
   Regards,
   Adrian
  
With the changes I checked in this morning last
  night
I got only 3 errors
running the testsuite 6 times for Branch_3_0
   
2 of these are from jrmp CustomSockets tests, so
  I
think they might have
the same problem the security tests with custom
sockets had.
   
The remaining failure is jsr-77 notification
delivery.  I think this may be
broken even on a first run.
   
jdk 1.4, linux 2.4.16.
   
I usually get some exceptions from jbossmq stuff
  when
shutting down after
running the testsuite.  Anyone looking into this?
   
david jencks
  
  
   * * *
  
   View thread online:
  http://jboss.org/forums/thread.jsp?forum=66thread=145
  6
  
  
  __
  
  
   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=14576

___

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




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


___

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



[JBoss-dev] getContextClassLoader() vs. Class.forName(x,y,z)

2002-05-02 Thread Hiram Chirino

Question for you classloading feaks out there, what is the difference 
between:

x = some.class.name;
Thread.currentThread().getContextClassLoader().loadClass(x);

and

x = some.class.name;
Class.forName(x, false,
 Thread.currentThread().getContextClassLoader());

Peter Levart, submitted a patch that replaces a statment like the first with 
a statment like the seconds.   It's supposed to allow loading
array class for a base class that hasn't been loaded yet.

My thing is, it seems like they do the same thing.  What's the difference?

Regards,
Hiram

_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


___

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



[JBoss-dev] JBossMQ JavaCC Problem

2002-04-29 Thread Hiram Chirino

To all JavaCC Gurus,

The javacc grammar that JBossMQ is using has a problem.  It can't detect 
that the selector: definitely not a message selector! is an invalid 
selector.  It just parses the first itentifier, definitely and then skips 
over the rest of the selector.

Is there an easy way for javacc to pick up that there are some excess tokens 
and spit out an error???

Regards,
Hiram


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


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



[JBoss-dev] Re: JBossMQ Questions

2002-04-28 Thread Hiram Chirino

From: Andreas Schaefer [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: JBossMQ Questions
Date: Sat, 27 Apr 2002 22:19:22 -0700

Hi Hiram

Hi Andreas,


Just started to implement JSR-77 performance
monitoring on JBossMQ (was just in the flow
after the recent events). I came up with some
questions but let me explain what JSR-77 spec.
contains:
a JMS stats contains:
- list of connections
- which contains a list of sesssions
   - which contains a list of consumers and producers

I started adding JBoss MQ code in JMSServer
because this seems to be the central component
of JBossMQ.
Now I need to find out what connections exists
and retrieve informations from them inclusive the
list of sessions and from this the list of sender/receivers
or list of publisher/subscribers. All this seems not
to be a problem.
But I don't see the connnection between JMSServer
and SpyConnection. Is there a way to get there inclusive
going over JNDI or JMX ?


I think you might be confused because the JMSServer supports stateless 
connection protocols such as RMI.  So, this means is that the JMSServer does 
not keep track of the connections that are established with him. Once a 
client establishes a connection with the server, he passes a ConnectionToken 
object allong with every request he makes to the server.  The 
ConnectionToken holds enough info for the server to identify from which 
connection the request is comming from and how to send send data 
asynchronously to that connection.

Now in the case of the stateful transport protocols, such as the OIL and 
UIL, it would be possible to keep track of the connections since we have to 
manage the thread the reads input from the sockets.  I can see us creating 
registing a new MBean for each connection that is accecpted.

I hope that made sense.

Regards,
HIram

Thanx

x
Andreas Schaefer
Senior Consultant
JBoss Group, LLC
x






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


___
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 Hiram Chirino

Juha,

Using a set of properties to identify an object just seems werid to me.  WHY 
did the JMX spec do this???  Why not just use a unique string to identify an 
object???  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??

Regards,
Hiram

From: Juha-P Lindfors [EMAIL PROTECTED]
To: marc fleury [EMAIL PROTECTED]
CC: Jboss-Development@Lists. Sourceforge. Net 
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Why is new ObjectName() so slow?
Date: Sun, 28 Apr 2002 21:39:26 +0300 (EET DST)


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


_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


___
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 Hiram Chirino

From: marc fleury [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: Jboss-Development@Lists. Sourceforge. Net 
[EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Why is new ObjectName() so slow?
Date: Sun, 28 Apr 2002 11:49:46 -0700

|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?

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?


I've go a feeling that the order of the properties does not matter, so 
DefaultDomain:service=XADataSource,name=DefaultDS would be the same object 
as DefaultDomain:name=DefaultDS,service=XADataSource.
I think that's whey he has to parse it early.

Regards,
Hiram


_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


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



Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems

2002-04-24 Thread Hiram Chirino

From: Peter Antman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Date: Wed, 24 Apr 2002 10:35:29 +0200 (CEST)

On 23 Apr, Jason Dillon wrote:
  Hey, I have just started integrating SwiftMQ for use in my production
  environment at work and by doing so I have notice d that we might have
  some issues with the JMS RA.
 
  Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums
  with a document he wrote about getting it to work:
 
  http://culture.iridio.com/~csw/jboss-swiftmq/
 
  I was hoping that the JMS folks (probably Peter since he wrote it, or
  really anyone else familar with this stuff) could take a look at the
  document and see if we can nail down some of the issues (like
  connection.close() not closing sessions and finally drop the queue/ and
  topic/ prefixes from being requirements of the system).

Hi, I am currently under sever time contraints, so unfortunately I do
not have the time to do the testing that is rquired to check new stuff
in. Just yesterday I integrated SonicMQ into 2.4.3 and I have also seen
a couple of things that needs to be done to ease integration.

- JMS ContainerInvoker and DLQHandler need to be easier to subclass.
- We must probably factor out the ConnectionConsumer stuff.
-  We must also see to it that StdServerSession and Pool are easy to
sublcass, and at least factor out creation of StdServerSession


I have a feeling that the DLQHandler can be implemented as an interceptor.  
So before the message gets delivered to the bean, the interceptor checks to 
see if it has been redelivered to many times.  This should help decouple the 
the DLQ from the ContainerInvoker.

- The DLQHandler must be configurable with a connectionfactory (JBossMQ
   only handles Messages from foraign provider if they are Serializable,
   wich is not part of the Message API.

- topic and queue stuff from ContainerInvoker should be removed. This
   was added by the one who implemented automatic creation of
   destinations (which I oposed to). One way of doing this would be
   moving creation of destination out into the PrividerAdapter to make it
   possible to let also foraign providers create destinations on the fly
   (if the can handle this).


Yes!!! I agree 102%!!

As for the JMS RA. This is basically a hack. Not in the meaning bad code
(I hope ;-)) but in that the spec for JCA is not designed for JMS. The
stuff you take from the pool, is the stuff that is transacted. This
works nice for db but not for JMS, since in JMS it is the session that
is transacted and that should be pooled in the JCA adapter, but it is
not a common idiom to directly get a session in JMS (which you can with
the JCA adapter). The connection is just a cover up class, which
basically do no JCA intercation. It's the session that do it.


So are you saying that every JMS provider should provider thier own RA 
implementation since that way they can cope with the architecture by using 
provider specific calls in the RA??

I could not come up with a good solution on this problem, except
documenting  how to use it. If someone can find a solution, pleas commit
it.

//Peter
 
  Anyone have some time to check this out and look over what needs to be 
done?
 
  Thanks,
 
  --jason
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development

--

Peter Antman   Chief Systems Architect, Business Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: [EMAIL PROTECTED]
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942



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




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


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



Re: [JBoss-dev] SAR... Sucky ARchive ?

2002-04-22 Thread Hiram Chirino


So then you did like the way jboss-auto.jcml worked.  I did not.

Regards,
Hiram

From: Jason Dillon [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED],   
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
Date: Sun, 21 Apr 2002 22:18:08 -0700

I don't think that merging two sets of config is that much trouble, if you
start out with the xml, use them as defualts, then invoke the mbean 
setBLAH()
an interceptor checks a attrib store for a preconfigued value, if there is 
one
then it is used, else the provided value is used and that value is not 
stored
in the attrib store.

The only complicated part that I can think of is providing a way to 
invalidate
the stored values.

If there was an AttributeStore for each MBean which you could get a handle 
on
the, the bits that know the last modified date of the input source can 
compare
it to the last modified of the stored values.  If input config is newer 
then
AttributeStore.invalidate() then go on with setBLAH()

But, all of this should be optional... like uncomment this MBeanAttributePM
from jboss-service.xml and it will work, but otherwise leave it as the xml 
is
the only input.  This way advanced users can enable this easily but we 
don't
confuse users with it up front.

--jason


Quoting Hiram Chirino [EMAIL PROTECTED]:

 
  The problems with auto-jcml stuff was that it tried to merge two sets of
  configuation data, one set that user maintained and another that was
  application maintained.  Maintain both sets of data was tricky and error
  prone.
 
  So my thoughts are, we need to be able to support:
  1. manual service configuration system (what we have today)
  2. automatic configuration system (Modified by a config-tool, JMX??)
 
  And for a given service, you can't mix the options.  So if we had a 
jboss
  that supported both of these options, this is what I image the config 
would
 
  look like:
 
  /conf/jboss-service.xml : Same as today except that in addition to the
  URLDeploymentScanner it would have a Scanner that would deploy the 
services
 
  setup by the config-tool.
  /db/config-tool : would hold a database of the config-tool managed
  services.
  /deploy : would hold *-service.xml files like it does today.
 
 
  This config-tool thing would need to be able to import existing
  *-service.xml files into it's database.  It would need to be able to
  transparently update it's database when MBean attributes are changed.
  And there's probably a ton of other things this config-tool based 
service
  configutation system needs to do.  What I just wanted point out is that 
it
  should be able to co-exist with the current system, and that giving 
users
  raw access to the data file should not be allowed.
 
  Regards,
  Hiram
 
 
  From: David Jencks [EMAIL PROTECTED]
  To: Jules Gosnell [EMAIL PROTECTED]
  CC: Jason Dillon [EMAIL PROTECTED],
  [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
  Date: Sun, 21 Apr 2002 20:35:32 -0400
  
  On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
   
So :
   
persist any SPECIFIC settings made through the JMX agent and overlay
them on top of the DEFAULT settings contained in
.sar/META-INF/jboss-service.xml.
  
  This might be doable if we are really careful however in the bad 
old
  days of jboss-auto.jcml there were frequent problems of mbeans that
  wouldn't die -- their configuration had been saved at some point, then 
the
  user removed the mbean conf from jboss.jcml, but the mbean came back to
  life-- it was in jboss-auto.jcml.
  
  We have to be careful about the semantics we intend for the system.  I 
am
  starting to think that if we say that only explicit changes made while 
the
  system is running work properly we may be ok.  So if you want to change 
a
  mbean config, you can either change it in the running mbean, or 
undeploy
  and redeploy the config file while the server is running.  Stopping the
  server, changing the file, and restarting the server won't work.
  
  This seems a little weird right now, but I think it possible that it is
  the
  only way to get consistent semantics.
  
  Of course you also need to be able to completely clear the 
configuration
  store and start over.
  
  david jencks
  
   
but desist from the 'it's such a pain to unpack/repack' argument,
because, as we have shown, there is no need to repack.
   
   
Jules
   
   
   
Jason Dillon wrote:
But we don't do this... Jetty is part of the release, it is not a
seperate

component which users download and configure.

until the next release/important-bug-fix of Jetty.
I thought your whole point was that they DO configure it ?


 My point was much larger than Jetty, with respect to the concept 
of a
service
 archice and service instance configuration... which I detailed 
more
  in
my
 response to Marc.


If Jetty 4.1 comes out with some new

[JBoss-dev] JORAM JMS testsuite integrated

2002-04-21 Thread Hiram Chirino

I've integrated the Joram JMS testsuite into our testsuite.

I've added the target 'tests-objectweb-jms' to the /testsuite/build.xml to 
execuite it.

It's still not executing 100% error free, but it's close.
We have some selector problems and the other problem is that our default 
secutity restrictions do not allow the creatation of durablsubscriptions by 
guests.

Regards,
Hiram

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


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



  1   2   3   4   5   6   7   >