Re: [JBoss-dev] Re: JBossMQ PM XAResource interface

[Peter Antman]

Just my 2c.

I think that an XML/HTTP integration of JBossMQ should be done by making
a JAXM personality of JBossMQ. I had a quite lengty mail conversation
with a guy a couple of month ago where we sort of tried to interpret the
spec in a JMS way. He said he was going to implement the stuff, but then
just disapeared.

If this is the way to go, what should actually be added as a message
type is a SOAPMessage with attachement, I think.

Unfortunately I do not have the time jsut not to implement JAXM on top
of JBossMQ. But if anyone else is prepared to do it I might be able to
help out (I have read the the fckn spec a number of times).

//Peter


On 13 Nov, Hiram Chirino wrote:
From: Charles Chan [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
Subject: Re: JBossMQ PM XAResource interface
Date: Tue, 13 Nov 2001 18:29:40 -0800 (PST)

My initial idea with XML is simple... Just create an
XMLMessage type (extended from TextMessage). Create a
new Session interface that exposes the factory method
to create this type of message. We could also provide
a proprietary message selector based on XPath. That's
what BEA WebLogic basically do.

 
 That would be cool.
 
However, after much thought, I think what you've
suggested made more sense. HTTP is becoming important.
We need a solid messaging framework over HTTP if we
want reliable web services.

 
 I agree.
 
I am not sure if JBossSOAP uses JBossMQ as its
transport but it can't unless JBossMQ supports HTTP
and HTTPS.

 
 JBoss SOAP aka JBoss.Net will use the apache Axis server for HTTP and HTTPS. 
   What I want to do is be able either deploy a web service or a plain 
 servlet that would allow JBossMQ clients come in over HTTP/S
 
 So what I think we need is an IL that kinda goes like this:
 HTTPServerIL - (uses HTTP) - MQHTTPServlet - (JVM-IL) - Server
 
 The hard part of this IL is going to be that the server can't directly 
 invoke methods on the client.  The client is going to have to poll for 
 asynch message from the client by some thing like:
 
 1. (Data structure accessible via the servlet) - (JVM-IL) - Server
 2. Client pool - (uses HTTP) - MQHTTPServlet - (Data structure accessible 
 via the servlet)
 
 This approach would also let us run the web server in a different process as 
 the MQ server since the JVM-IL in my example could be replaced with any of 
 the other ILs.
 
 
 What do you think??
 
 Regards,
 Hiram
 
Any discussion on this issue yet? I would like to look
deeper into this. :)

Thanks
Charles


--- Hiram Chirino [EMAIL PROTECTED] wrote:
 
  What were your ideas with XML??
 
  A feature request that seemed interesting never had
  been implemented was a
  JMS over HTTP.  Alot of companys only want to expose
  port 80 at thier
  firewall, and nothing else.
 
  Regards,
  Hiram
 
  From: Charles Chan [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
  To: Hiram Chirino [EMAIL PROTECTED]
  Subject: Re: JBossMQ PM XAResource interface
  Date: Tue, 13 Nov 2001 16:15:50 -0800 (PST)
  
  
  --- Hiram Chirino [EMAIL PROTECTED] wrote:
  
I don't think this a huge priority, since the
  stuff
kinda works.  But if
your intrested, go for it!
  
  I don't think it's a high priority either. The
  clustering work, however, is still rather unstable
  at
  this point (I can't even run a JBoss cluster). I am
  now looking into using XML with JMS and hope to add
  something to our framework. Other suggestions?
  
  Charles
  
  
  
   
Regards,
Hiram
   
Any thoughts?

Charles



--- David Jencks
  [EMAIL PROTECTED]
wrote:
  On 2001.11.11 22:23:58 -0500 Charles Chan
  wrote:
   HI, David,
  
   I replied your message on the list. To
  tell
you
  the
   truth, I found the JDBC PM stuffs a bit
  convoluted...
 
  That's an understatement;-)
   (I admit I am totally new to this
  framework)
  
   I was thinking of helping Hiram to get
  some
  clustering
   work done. Tell me some of your ideas,
  maybe
they
  will
   fit into the clustering work too.
 
  Mostly I was thinking it would be a good
  idea to
  change the pm interface to
  expose an XAResource for transaction
  management.
  This would make using a
  jca-wrapped xa datasource pretty easy for a
  jdbc
pm.
   The jca spec mentions
  the possibility of a caching layer on top of
  a
jca
  connector: in this case
  the caching layer registers a
  synchronization
  interface with the tm, and
  flushes it's cached changes to the connector
  on
the
  before completion
  notification.  I'm wondering if it would be
possible
  to treat the jms stuff
  as such a caching layer, thus allowing us to
expose
  the pm's XAResource as
  the jms implementation's XAResource.  This
  would
  allow 1phase optimization
  if you are using the same db for jms and
  regular
db
  

Re: [JBoss-dev] JBbossMQ XML, was JBossMQ PM XAResource interface

[Peter Antman]

On 14 Nov, Till: [EMAIL PROTECTED] wrote:
 Just my 2c.
 
 I think that an XML/HTTP integration of JBossMQ should be done by making
 a JAXM personality of JBossMQ. I had a quite lengty mail conversation
 with a guy a couple of month ago where we sort of tried to interpret the
 spec in a JMS way. He said he was going to implement the stuff, but then
 just disapeared.
 
 If this is the way to go, what should actually be added as a message
 type is a SOAPMessage with attachement, I think.
 
 Unfortunately I do not have the time jsut not to implement JAXM on top
 of JBossMQ. But if anyone else is prepared to do it I might be able to
 help out (I have read the the fckn spec a number of times).
 
 //Peter
 

Hi again, just saw that the JAXM has gone throug a ballot. If I
understand it correct it was approved, but several heavy instances voted
against it, among them apache, bea, ibm and compaq. I thing the reason
from compaq gets the essence of the negative votes:

Compaq agrees with the issues raised by BEA concerning JSR 67 - JAXM.  
The JAXM specification has too much overlap with JMS.  
In addition, we have issues with the maturity and directions of the 
specification.  We believe there are better approaches for delivering 
the capabilities that JAXM has tried to address.

We believe the needs of the Java community would be better served by 
using JAX-RPC for synchronous XML/SOAP communication, and by extending 
JMS to handle XML/SOAP payloads for asynchronous messaging.   
The APIs for SOAP (with attachments) should be standardized as part
f the JAX-RPC JSR (JSR 101).  An additional effort should be undertaken
to add XML/SOAP payloads to JMS.  This should be an easy task, as proven 
by the large number of applications that are already doing so.  
This would create a much more unified approach to messaging that will 
be easier for the Java community to use and program against.

A difficult aspect of this vote is the all or nothing nature of the 
outcome.  A lot of good work has been done as a part of this JSR.  
In particular, the APIs for accessing and manipulating the SOAP portion of 
a message are an important byproduct of the JAXM specification that are 
useful for the JAX-RPC and JMS-SOAP.  We encourage the JAX-RPC JSR  
effort to include this portion of the JAXM JSR and assume responsibility 
for its standardization without major redesign or significantly delay. 
We cannot vote for the JAXM JSR simply to get the SOAP manipulation APIs 
advanced to standardization.  This would be the tail wagging the dog.

If these big gyues get what they want it will mean that the JMS spec
will eventually be agumented with a SOAP API, probably based on the SOAP
with atachment specifyed in JSR 101.

Any work done on this in JBossMQ should probably be based on that
assumption.

Just to have a SOAP with attachments would be neat. Ad to that an HTTP
SOAP invikation layer and content based routing. Really, really neat.

//Peter



 
 On 13 Nov, Hiram Chirino wrote:
From: Charles Chan [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
Subject: Re: JBossMQ PM XAResource interface
Date: Tue, 13 Nov 2001 18:29:40 -0800 (PST)

My initial idea with XML is simple... Just create an
XMLMessage type (extended from TextMessage). Create a
new Session interface that exposes the factory method
to create this type of message. We could also provide
a proprietary message selector based on XPath. That's
what BEA WebLogic basically do.

 
 That would be cool.
 
However, after much thought, I think what you've
suggested made more sense. HTTP is becoming important.
We need a solid messaging framework over HTTP if we
want reliable web services.

 
 I agree.
 
I am not sure if JBossSOAP uses JBossMQ as its
transport but it can't unless JBossMQ supports HTTP
and HTTPS.

 
 JBoss SOAP aka JBoss.Net will use the apache Axis server for HTTP and HTTPS. 
   What I want to do is be able either deploy a web service or a plain 
 servlet that would allow JBossMQ clients come in over HTTP/S
 
 So what I think we need is an IL that kinda goes like this:
 HTTPServerIL - (uses HTTP) - MQHTTPServlet - (JVM-IL) - Server
 
 The hard part of this IL is going to be that the server can't directly 
 invoke methods on the client.  The client is going to have to poll for 
 asynch message from the client by some thing like:
 
 1. (Data structure accessible via the servlet) - (JVM-IL) - Server
 2. Client pool - (uses HTTP) - MQHTTPServlet - (Data structure accessible 
 via the servlet)
 
 This approach would also let us run the web server in a different process as 
 the MQ server since the JVM-IL in my example could be replaced with any of 
 the other ILs.
 
 
 What do you think??
 
 Regards,
 Hiram
 
Any discussion on this issue yet? I would like to look
deeper into this. :)

Thanks
Charles

 

-- 
Jobba hos oss: http://www.tim.se/weblab

Peter Antman Technology in 

[JBoss-dev] [ jboss-Bugs-481645 ] setRollbackOnly in beforeCompletion

[noreply]

Bugs item #481645, was opened at 2001-11-14 03:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=481645group_id=22866

Category: JBossTX
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Bartmann (bartmann_d)
Assigned to: Nobody/Anonymous (nobody)
Summary: setRollbackOnly in beforeCompletion

Initial Comment:
A call to the setRollbackOnly method of a stateful 
session bean's session context within the 
beforeCompletion method (SessionSynchronization 
interface) has in some cases no effect. However 
according to the EJB spec (section 7.5.3 EJBv2.0, 
section 6.5.3 EJBv1.1) this should cause the 
transaction to roll back. For an example see the 
attached file.

[Info] Java version: 1.3.1,Sun Microsystems Inc.
[Info] Java VM: Java HotSpot(TM) Client VM 1.3.1-
b24,Sun Microsystems Inc.
[Info] System: Windows NT 4.0,x86
...
[TransactionManagerService] Starting
[TransactionManagerService] Using Xid 
class 'oracle.jdbc.xa.OracleXid'
[TransactionManagerService] Started
[ClientUserTransactionService] Starting
[ClientUserTransactionService] Started
...
[Default] JBoss 2.4.3 Started in 0m:10s



--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=481645group_id=22866

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCDefinedFinderCommand.java

[Lennart Petersson]

  User: lepe
  Date: 01/11/14 03:56:44

  Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCDefinedFinderCommand.java
  Log:
  [ #422247 ] CMP finder command case-sensitive
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.14.2.6  +6 -3  
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java
  
  Index: JDBCDefinedFinderCommand.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java,v
  retrieving revision 1.14.2.5
  retrieving revision 1.14.2.6
  diff -u -r1.14.2.5 -r1.14.2.6
  --- JDBCDefinedFinderCommand.java 2001/10/29 00:03:06 1.14.2.5
  +++ JDBCDefinedFinderCommand.java 2001/11/14 11:56:42 1.14.2.6
  @@ -28,7 +28,8 @@
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
* @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
  - * @version $Revision: 1.14.2.5 $
  + * @author a href=mailto:[EMAIL PROTECTED];Lennart Petersson/a
  + * @version $Revision: 1.14.2.6 $
*/
   public class JDBCDefinedFinderCommand extends JDBCFinderCommand
   {
  @@ -207,7 +208,8 @@
   Set setOfPkTokens = new HashSet(pkTokens.countTokens());
   while(pkTokens.hasMoreTokens())
   {
  -  setOfPkTokens.add(pkTokens.nextToken().trim());
  +  // We will compare lowercase /lepe 2001-11-14
  +  setOfPkTokens.add(pkTokens.nextToken().trim().toLowerCase());
   }
   
   //Now is the time to check for duplicates between pk and order tokens
  @@ -215,7 +217,8 @@
   while(i  checkedOrderTokens.length)
   {
 //If duplicate token, null it away
  -  if(setOfPkTokens.contains(checkedOrderTokens[i]))
  +  // We will compare lowercase /lepe 2001-11-14
  +  if(setOfPkTokens.contains(checkedOrderTokens[i].toLowerCase()))
 {
   checkedOrderTokens[i]=null;
 }
  
  
  

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCDefinedFinderCommand.java

[Lennart Petersson]

  User: lepe
  Date: 01/11/14 04:18:19

  Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCDefinedFinderCommand.java
  Log:
  [ #422247 ] CMP finder command case-sensitive
  
  Revision  ChangesPath
  1.20  +4 -3  
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java
  
  Index: JDBCDefinedFinderCommand.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- JDBCDefinedFinderCommand.java 2001/08/12 10:46:22 1.19
  +++ JDBCDefinedFinderCommand.java 2001/11/14 12:18:19 1.20
  @@ -31,7 +31,8 @@
* @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
  - * @version $Revision: 1.19 $
  + * @author a href=mailto:[EMAIL PROTECTED];Lennart Petersson/a
  + * @version $Revision: 1.20 $
*
*   pbRevisions:/b
*
  @@ -226,7 +227,7 @@
   Set setOfPkTokens = new HashSet(pkTokens.countTokens());
   while(pkTokens.hasMoreTokens())
   {
  -  setOfPkTokens.add(pkTokens.nextToken().trim());
  +  setOfPkTokens.add(pkTokens.nextToken().trim().toLowerCase());
   }
   
   //Now is the time to check for duplicates between pk and order tokens
  @@ -234,7 +235,7 @@
   while(i  checkedOrderTokens.length)
   {
 //If duplicate token, null it away
  -  if(setOfPkTokens.contains(checkedOrderTokens[i]))
  +  if(setOfPkTokens.contains(checkedOrderTokens[i].toLowerCase()))
 {
   checkedOrderTokens[i]=null;
 }
  
  
  

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

RE: [JBoss-dev] CacheKey copy semantics and speed

[Bill Burke]

Sorry to chime in so lateBut hasn't my CacheKey change been in since
2.4.0?

Also remember why I added the copying to the CacheKey in the first place.
What I was doing in my application code was reusing a fat-primary key so I
didn't have to reallocate one.  Thus the entity cache was getting corrupted
because I kept on changing the shared primary key instance.  I guess if
you're stupid enough to re-use an instance of a primary key, you deserve to
spend days trying to track down this problem.

So, if you're going to get rid of the MarshalledObject and all the copying,
why not just get rid of CacheKey all together?

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of marc
 fleury
 Sent: Tuesday, November 13, 2001 8:54 PM
 To: Scott M Stark; Jboss-Development@Lists. Sourceforge. Net
 Subject: RE: [JBoss-dev] CacheKey copy semantics and speed


 well,

 then you don't win,

 but I don't win either

 today is a crappy day

 but the fix is relevant

 marcf

 |-Original Message-
 |From: [EMAIL PROTECTED]
 |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
 |M Stark
 |Sent: Tuesday, November 13, 2001 8:55 PM
 |To: Jboss-Development@Lists. Sourceforge. Net
 |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed
 |
 |
 |Ok, but all of that time was really due to the removal of the
 |MarshalledObject.get(). Running with the CacheKey implementation
 |pre the copy gives basically the same time as the non-MarshalledObject
 |version:
 |
 |1 minute 48 seconds
 |
 |- Original Message -
 |From: Scott M Stark [EMAIL PROTECTED]
 |To: Jboss-Development@Lists. Sourceforge. Net
 |[EMAIL PROTECTED]
 |Sent: Tuesday, November 13, 2001 5:43 PM
 |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed
 |
 |
 |
 | Yes it does use byte[] comparisons in a for loop. Let me give you
 | a push in my direction. We know there is a performance drop in 2.4.4
 | that has yet to be resolved, but profiling shows it is related to
 | interaction
 | with the entity cache and that the CacheKey ctor ends up being
 |the largest
 | hotspot. By simply changing the CacheKey to use the input id directly
 | rather than MarshalledObject, the timing of the bank unit test
 goes from:
 |
 | 2 minutes 43 seconds
 |
 | to:
 |
 | 1 minute 46 seconds
 |
 | Pretty big improvement for a trival change. That's the 80/20 rule in
 |action
 | big time.
 |
 |
 |
 |
 |___
 |Jboss-development mailing list
 |[EMAIL PROTECTED]
 |https://lists.sourceforge.net/lists/listinfo/jboss-development


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




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

Re: [JBoss-dev] CacheKey copy semantics and speed

[Rickard Öberg]

Bill Burke wrote:

 Also remember why I added the copying to the CacheKey in the first place.
 What I was doing in my application code was reusing a fat-primary key so I
 didn't have to reallocate one.  Thus the entity cache was getting corrupted
 because I kept on changing the shared primary key instance.  I guess if
 you're stupid enough to re-use an instance of a primary key, you deserve to
 spend days trying to track down this problem.
 
 So, if you're going to get rid of the MarshalledObject and all the copying,
 why not just get rid of CacheKey all together?


Hehe... if it is removed I have only one thing to say: told you so... :-)

/Rickard

-- 
Rickard Öberg


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

RE: [JBoss-dev] CacheKey copy semantics and speed

[Bordet, Simone]

Hey,

  So, if you're going to get rid of the MarshalledObject and 
 all the copying,
  why not just get rid of CacheKey all together?
 
 
 Hehe... if it is removed I have only one thing to say: told 
 you so... :-)
 
 /Rickard

eee, man this guy seem to *always* be right. Ah well, pure alien
category. 
Rickard, ehrm, who will win the football league this year ? :-))

Simon :)

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

Re: [JBoss-dev] CacheKey copy semantics and speed

[Rickard Öberg]

Bordet, Simone wrote:

 eee, man this guy seem to *always* be right. Ah well, pure alien
 category. 
 Rickard, ehrm, who will win the football league this year ? :-))


I *could* tell, but that'd spoil the fun ;-)

/Rickard


-- 
Rickard Öberg


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

[JBoss-dev] [PATCH] JDBCCommand.java

[Holger Engels]

On Wed, 14 Nov 2001, Scott M Stark wrote:


 Yes, this change has been in since the start of 2.4, and people have
 complained about CacheKey showing up as a bottleneck since its
 release. It started showing up even more dramtically in the pending
 2.4.4 codebase due to some other change that is banging on its
 ctor.
 

.. you're talking about a 2.4.4 ..

I sent in a patch some weeks ago, that fixed a bug in jaws regarding 
cmpfields of type byte[]. The problem was, that jaws tried to deserialize 
an object, because the jdbcType was considered to be a binary type.


if( bytes == null ) {
result = null;
} else {
   // We should really reuse these guys


should be:

if( bytes == null ) {
result = null;
} else if (destination.getName().equals([B)) {
return bytes;
} else {
   // We should really reuse these guys


I just noticed, that it still has not been applied.

Thanks,

Holger



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

Re: [JBoss-dev] RH: tools.jar (javac)...

[philipborlin]

Maybe I am missing something, but isn't this whole issue about distributing
a compiler with JBoss so the user doesn't have to download the JDK and edit
a configuration file to point to it?

If that is the case, can't we distribute jikes?

-Phil



   
  
Scott M Stark
  
[EMAIL PROTECTED]To: JBossDev 
\(E-mail\) 
Sent by:   
[EMAIL PROTECTED] 
[EMAIL PROTECTED]cc: 
  
eforge.net Subject: Re: 
[JBoss-dev] RH: tools.jar
   (javac)...  
  
   
  
11/13/2001 05:37 PM
  
Please respond to Scott M Stark  
  
   
  
   
  




That is how both the bundled tomcat and standalone tomcat handles this.
You have to have the JDK tools.jar, or jikes, or some other compiler
configured
as part of the installation. Since we can't bundle tools.jar and javac.jar
is
just a black box we don't want to include since it source for it can't be
obtained,
there is nothing we can do to make this a platform independent zero
configuration issue as far as I know.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: David Maplesden [EMAIL PROTECTED]
To: JBossDev (E-mail) [EMAIL PROTECTED]
Sent: Tuesday, November 13, 2001 4:14 PM
Subject: RE: [JBoss-dev] RH: tools.jar (javac)...


 No I haven't and I see now what you mean, I didn't read what you put
 carefully enough.  Still you might be able to do it this way, IIRC we
used
 to distribute javac in a javac.jar that was distributed with JBoss to
 different platforms and it seemed to work OK.

 I thought the only reason we weren't distributing tools.jar in the same
way
 is because of licensing issues with Sun.

 That of course brings up a problem with 1) you can't distribute any
package
 you create that contains tools.jar (I think).

 Perhaps the easiest thing to do for the Jetty dist is to reference
tools.jar
 as if it exists in the lib/ext dir and simply include a README telling
 people what is going on, then they can supply their own (platform
specific
 if neccessary) jar.

 David

  -Original Message-
  From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, November 14, 2001 1:02 PM
  To: David Maplesden; [EMAIL PROTECTED];
  [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
 
 
  David Maplesden wrote:
 
   1) worked fine for me...
 
  Have you tried it on different architectures?
 
  My concern is that if I do the build on Linux, the tools.jar
  from my 1.3.1
  distrib may not work on e.g. a Mac etc...
 
  Jules



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





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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/invocation - New directory

[marc fleury]

  User: mnf999  
  Date: 01/11/14 08:37:04

  jboss/src/main/org/jboss/invocation - New directory

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/invocation Invocation.java

[marc fleury]

  User: mnf999  
  Date: 01/11/14 08:43:19

  Added:   src/main/org/jboss/invocation Invocation.java
  Log:
  The new Invocation object, it is just a generalized invocation that carries 
Transaction and security with it.  Then we keep some variables directly but it should 
really work through the payload. The payload is just a map of objects that the 
invocation carries around.  The old MethodInvocation is now an extension of this guy.  
The Invocation also carries a list of mbeans that he is supposed to go through.  This 
will be interesting when we move to the router view of the JMX base and the 
Invocations are just stand-alone objects that travel through the base.  The EJB view 
here is secondary.  Note: I have left funky constructors to provide backward 
compatibility with the old codebase and way of doing things.
  
  Revision  ChangesPath
  1.1  jboss/src/main/org/jboss/invocation/Invocation.java
  
  Index: Invocation.java
  ===
  /*
  * JBoss, the OpenSource J2EE webOS
  *
  * Distributable under LGPL license.
  * See terms of license at gnu.org.
  */
  package org.jboss.invocation;
  
  import java.util.Map;
  import java.util.HashMap;
  import java.lang.reflect.Method;
  import java.security.Principal;
  
  import javax.transaction.Transaction;
  
  
  /**
  *   The Invocation object is the generic object flowing through our interceptors
  *
  *
  *   @see related
  *   @author  a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
  *   @version $Revision: 1.1 $
  *   Revisions:
  *
  *   pbRevisions:/b
  *
  *   pb20211002 marc fleury:/b
  *   ul
  *   li Initial check-in
  *   /ul
  */
  
  public class Invocation
  {
  
 // Attributes 
  
 /**
  *  The transaction of this invocation.
  */
 public Transaction tx;
  
 /**
  *  The security identity of this invocation.
  */
 public Principal identity;
  
 /**
  *  The security credentials of this invocation.
  */
 public Object credential;
  
  
 /**
 * The linked list of object names, in String form, that the invocation must go 
through
 * Should move to a real linked list in the future (so we don't have to update the 
full
 * variable to include new interceptor flows
 * We could keep track of the mbeans to see in this object with an incremented 
index
 * there would be no central intelligence but this invocation that knows where 
to go next
 */
 public String[] mbeans;
 
 
 /**
  * The payload is a repository of everything associated with the invocation
  * with the exception of the generic transaction and security information above.
  */
 public Map payload;
 
   
 
 // Static 
  
  
 /*
 * We are using the generic payload to store some of our data, we define the 
integer entries.
 */
 public static final Integer
METHOD = new Integer(new String(METHOD).hashCode()), 
ARGUMENTS = new Integer(new String(ARGUMENTS).hashCode());
   
 // Constructors --
  
 /**
  * Invocation creation
  */
 public Invocation(Transaction tx, 
   Principal identity, 
   Object credential,
   String[] mbeans,
   Method method,
   Object[] arguments)
 {

//The generic variables
this.tx = tx;
this.identity = identity;
this.credential = credential;

// The generic payload
this.payload = new HashMap();

// The invocation
setMBeans(mbeans);
setMethod(method);
setArguments(arguments);

 }
  
  
 // Public 
  
 /**
  * set and get on transaction
  */
 public void setTransaction(Transaction tx) { this.tx = tx; }
  
 public Transaction getTransaction() { return tx; }
  
 
 /**
  *  Change the security identity of this invocation.
  */
 public void setPrincipal(Principal identity) { this.identity = identity; }
  
 public Principal getPrincipal() { return identity;}
  
 
 /**
  *  Change the security credentials of this invocation.
  */
 public void setCredential(Object credential) { this.credential = credential; }
  
 public Object getCredential() { return credential; }
 
 
 /* 
 * The mbeans this invocation must go through (most cases will be one until we 
mbeanify all interceptors
 *
 * marcf fixme: I suspect it is the way to go but am open to should the 
interceptors all be mbeans 
 * discussions
 */
 public void setMBeans(String[] mbeans) { this.mbeans = mbeans; }
 
 public 

Re: [JBoss-dev] RH: tools.jar (javac)...

[Andreas Schaefer]

Yes, you are missing the fact that tools.jar is plattform/vendor dependant.
Therefore you would have to distribute one for each plattform.

Andy

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 8:14 AM
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...



 Maybe I am missing something, but isn't this whole issue about
distributing
 a compiler with JBoss so the user doesn't have to download the JDK and
edit
 a configuration file to point to it?

 If that is the case, can't we distribute jikes?

 -Phil




 Scott M Stark
 [EMAIL PROTECTED]To:
JBossDev \(E-mail\)
 Sent by:
[EMAIL PROTECTED]
 [EMAIL PROTECTED]cc:
 eforge.net Subject:
Re: [JBoss-dev] RH: tools.jar
(javac)...

 11/13/2001 05:37 PM
 Please respond to Scott M Stark






 That is how both the bundled tomcat and standalone tomcat handles this.
 You have to have the JDK tools.jar, or jikes, or some other compiler
 configured
 as part of the installation. Since we can't bundle tools.jar and javac.jar
 is
 just a black box we don't want to include since it source for it can't be
 obtained,
 there is nothing we can do to make this a platform independent zero
 configuration issue as far as I know.

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 - Original Message -
 From: David Maplesden [EMAIL PROTECTED]
 To: JBossDev (E-mail) [EMAIL PROTECTED]
 Sent: Tuesday, November 13, 2001 4:14 PM
 Subject: RE: [JBoss-dev] RH: tools.jar (javac)...


  No I haven't and I see now what you mean, I didn't read what you put
  carefully enough.  Still you might be able to do it this way, IIRC we
 used
  to distribute javac in a javac.jar that was distributed with JBoss to
  different platforms and it seemed to work OK.
 
  I thought the only reason we weren't distributing tools.jar in the same
 way
  is because of licensing issues with Sun.
 
  That of course brings up a problem with 1) you can't distribute any
 package
  you create that contains tools.jar (I think).
 
  Perhaps the easiest thing to do for the Jetty dist is to reference
 tools.jar
  as if it exists in the lib/ext dir and simply include a README telling
  people what is going on, then they can supply their own (platform
 specific
  if neccessary) jar.
 
  David
 
   -Original Message-
   From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
   Sent: Wednesday, November 14, 2001 1:02 PM
   To: David Maplesden; [EMAIL PROTECTED];
   [EMAIL PROTECTED]
   Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
  
  
   David Maplesden wrote:
  
1) worked fine for me...
  
   Have you tried it on different architectures?
  
   My concern is that if I do the build on Linux, the tools.jar
   from my 1.3.1
   distrib may not work on e.g. a Mac etc...
  
   Jules



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





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



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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Scott M Stark]

Jikes is not a Java program and you have to use a binary suitable for
the target platform. I'm not interested in getting into supporting mutiple
platform binaries.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 8:14 AM
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...



 Maybe I am missing something, but isn't this whole issue about
distributing
 a compiler with JBoss so the user doesn't have to download the JDK and
edit
 a configuration file to point to it?

 If that is the case, can't we distribute jikes?

 -Phil




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

RE: [JBoss-dev] RH: tools.jar (javac)...

[marc fleury]

amen

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Wednesday, November 14, 2001 11:51 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
|
|
|Jikes is not a Java program and you have to use a binary suitable for
|the target platform. I'm not interested in getting into supporting mutiple
|platform binaries.
|
|
|Scott Stark
|Chief Technology Officer
|JBoss Group, LLC
|
|- Original Message -
|From: [EMAIL PROTECTED]
|To: [EMAIL PROTECTED]
|Sent: Wednesday, November 14, 2001 8:14 AM
|Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
|
|
|
| Maybe I am missing something, but isn't this whole issue about
|distributing
| a compiler with JBoss so the user doesn't have to download the JDK and
|edit
| a configuration file to point to it?
|
| If that is the case, can't we distribute jikes?
|
| -Phil
|
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb MethodInvocation.java

[marc fleury]

  User: mnf999  
  Date: 01/11/14 08:43:19

  Modified:src/main/org/jboss/ejb MethodInvocation.java
  Log:
  The new Invocation object, it is just a generalized invocation that carries 
Transaction and security with it.  Then we keep some variables directly but it should 
really work through the payload. The payload is just a map of objects that the 
invocation carries around.  The old MethodInvocation is now an extension of this guy.  
The Invocation also carries a list of mbeans that he is supposed to go through.  This 
will be interesting when we move to the router view of the JMX base and the 
Invocations are just stand-alone objects that travel through the base.  The EJB view 
here is secondary.  Note: I have left funky constructors to provide backward 
compatibility with the old codebase and way of doing things.
  
  Revision  ChangesPath
  1.15  +49 -160   jboss/src/main/org/jboss/ejb/MethodInvocation.java
  
  Index: MethodInvocation.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/MethodInvocation.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- MethodInvocation.java 2001/09/01 19:50:30 1.14
  +++ MethodInvocation.java 2001/11/14 16:43:19 1.15
  @@ -11,6 +11,7 @@
   import java.security.Principal;
   import javax.transaction.Transaction;
   
  +import org.jboss.invocation.Invocation;
   
   /**
*  MethodInvocation
  @@ -21,16 +22,29 @@
*  @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
*  @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a.
*  @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
  - *  @version $Revision: 1.14 $
  + *  @version $Revision: 1.15 $
*/
  -public class MethodInvocation
  +public class MethodInvocation extends Invocation
   {
  // Constants -
   
  // Attributes 
   
  -   // Static 
  +   // Private ---
  +
  +   /**
  +*  The internal ID of the enterprise bean who is the target
  +*  of this invocation.
  +*/
  +   private Object id;
  +
   
  +   // Static 
  +   public static final Integer
  +  //For legacy reasons only
  +  TARGET_ID = new Integer(new String(TARGET_ID).hashCode()),
  +  ENTERPRISE_CONTEXT = new Integer(new String(ENTERPRISE_CONTEXT).hashCode());
  +   
  // Constructors --
   
  /**
  @@ -50,106 +64,43 @@
   *  @param credential
   *The security credentials to use in this invocation.
   */
  -   public MethodInvocation(Object id, Method m, Object[] args, Transaction tx,
  -   Principal identity, Object credential)
  -   {
  -  this.id = id;
  -  this.m = m;
  -  this.args = args;
  -  this.tx = tx;
  -  this.identity = identity;
  -  this.credential = credential;
  -   }
  +   public MethodInvocation(Transaction tx,
  +   Principal identity, 
  +   Object credential,
  +   String[] mbeans, 
  +   Object id, 
  +   Method m, 
  +   Object[] args)
  +   {
  +
  +  super(tx, identity, credential, mbeans, m, args);
  +  
  +  setId(id);
  +   }
  +
  +   public MethodInvocation(Object id, 
  +   Method m, 
  +   Object[] arguments, 
  +   Transaction tx, 
  +   Principal identity, 
  +   Object credential)
  +   {
  +  super(tx, identity, credential, null, m, arguments);
  +  
  +  setId(id);
  +   }   
   
  -
  // Public 
   
  /**
   *  Return the invocation target ID.
   *  This is the internal ID of the invoked enterprise bean.
  -*/
  -   public Object getId()
  -   {
  -  return id;
  -   }
  -
  -   /**
  -*  Return the invocation method.
   */
  -   public Method getMethod()
  -   {
  -  return m;
  -   }
  +   public void setId(Object id) { payload.put(TARGET_ID, id);}
  +   public Object getId() { return payload.get(TARGET_ID);}
   
  +   
  /**
  -*  Return the invocation argument list.
  -*/
  -   public Object[] getArguments()
  -   {
  -  return args;
  -   }
  -
  -   /**
  -*  This method sets the transaction associated with the method.
  -*  Note that this doesn't mean that the transaction is associated
  -*  with the thread.  In fact this is the only place it exists until
  -*  the TxInterceptor logic.  Notably 

[JBoss-dev] Invocation and MethodInvocation

[marc fleury]

Ok,

[FOR RECORD, ARCH CHANGE]

we discussed some time ago the possible extension of the MethodInvocation
to be a more generic and powerful entity.

Basically I have added the invocation directory and the Invocation.java, as
well as changed the MethodInvocation.

The 10,000 ft is that the new RH JMX view puts the mbeans in front.  The
entity that travels inside our JMX bus is the Invocation that I just
introduced.  The invocation basically takes the transaction and security
information as its basis.  You are always doing stuff as part of transaction
context (maybe empty meaning no transaction) and as someone authenticated
(if you set it up) but these are the building blocks.  Then everything else
is in a payload of possibly serialized byte[] data that we can carry
around as such (avoiding cl madness).  We extend this for the
methodinvocation which is more EJB'ish in that it knows about the
EnterpriseContext (more on that later).

The other new thing in there is the presence of the mbean list of objects
this Invocation is supposed to go through.  It will identify the MBean
interface of the Container for the EJBs, thereby really finalizing the
detaching of the invokers from the invocation, both from the bus (which is
already done) and the rmi impl (to be done next).

The Invocation is not using the mbean list as yet, but possibly will, since
what would come next is a self standing invocation in our JMX base, going
through the bus from mbean to mbean, which would really give us a possibly
dynamic way of maintaining the path that our invocation takes in the base.
The stuff is there, will use a little bit to hook up the EJB container, we
will see.

I will also probably don't externalize the interceptors as yet, no good
reason except it would be less disruptive a view from what we have now and
it would be lindfors recommendation.

I was going to talk about the EnterpriseContext thing but this is already
a long mail. I will do so in a forthcoming email.

Finally I will say that for legacy reasons I have kept the old constructors
and allowed the Invocation to carry no MBean association.  The 2 legacy are
1- the invocation chain is not fully generic yet, it knows the target, this
is detached already (going JMX bus) but will move next 2- the CMR stuff from
Dain that uses the invocation chain to invoke stuff on itself, this assumes
that you know the container (which it does) and calls it directly (which it
does) withouth the intermission of the JMX bus (which is ok), so this is
likely to remain as is for now. Moving it to the bus would be trivial but
not a priority right now.

The testsuite testbean runs fine afaict, so this should not disrupt the
existing RH codebase, fully backward compatible (again afaict)

just warming up

marcf

Marc Fleury
President
JBoss Group, LLC



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

[JBoss-dev] Separating JMX/EJB

[marc fleury]

kids,

we are hearing a lot of talk about EJB and not EJB and blabla bla.  Well I
will say that I am a big fan of the framework, for reasons that even our
favorite aliens are missing ;-) but that is another thread.

The reason I want EJB to take a backseat in the LAYOUT OF THE CODE is that
I believe we need to separate what is spec derived, spec dependent and what
is good software in general.  Most notably there are very large project
out there (Las Vegas IGT for example) that at first were using the JMX base
and management of JBoss to build complex systems and the RH JBoss3.0 view is
clearly targeted at these folks, large ISV shops using JBoss in high end
complex applications.  The JMX view and what we do with it, needs to be
clearly expressed as independent of the EJB spec. Interceptors and the
packaging/distribution that we do, the microkernel view, all that is
knowledge that is not EJB specific.

Right now everythign seems to be under org/jboss/ejb and
org/jboss/ejb/plugins when really we are largely BEYOND the ejb spec and it
applies to a wider and more generic category of problems than just EJB.  In
fact I am starting to suspect that the EJB part of our code, the really
dependent part is 20% of the total code today.  Which is really
negligeable.  The smart ones in you will see where I am going with this.  If
not you will see.

BOTTOM LINE: I want you guys to start wiring what is not EJB specific into
more generic packages. Ex: the Invocation I just commited, the
MethodINvocation should be outside it is just dependent on the
EnterpriseContext and teh EC is just a wrapper for instances in Cache.  what
is really EJB dependent should at the end of the day be seen in the imports
at once and it should be factored out.  Meaning if it isn't dependent on the
spec but derived from largely known computing practices (heck the state
machine view of JMX was first put forth by Alan Turing :)

Again, this is not a reflexion on the value of EJB, I will start seriously
evangelizing my love of EJB as system construct which is something I cover
in the trainings already, JMX is just generic and independent of this, the
microkernel view is generic and independent, the packaging we do is generic
and independent...

You get it.

marcf


Marc Fleury
President
JBoss Group, LLC



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

[JBoss-dev] [ jboss-Bugs-422247 ] CMP finder command case-sensitive

[noreply]

Bugs item #422247, was opened at 2001-05-08 03:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=422247group_id=22866

Category: JBossCMP
Group: v2.3 (unstable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Lennart Petersson (lepe)
Assigned to: Andreas Schaefer (schaefera)
Summary: CMP finder command case-sensitive

Initial Comment:
In 
org.jboss.ejb.plugins.jaws.jdbc.JDBCDefinedFinderComman
d.java i added sometimes ago a fix to handle ASC/DESC 
in order by and to avoid ambigious fields in select 
clause when ordering on a pk field.

I know see that the check for ambigious fields is case 
sensitive. So if your jaws column-name tag is in 
lower case and your finder tag has order columns in 
upper case, then my previous fix want do - there will 
still be ambigious fields.

Easy to fix - but i still can't commit since i've not 
solved the ssh/firewall problem :-(

--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=422247group_id=22866

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

Re: [JBoss-dev] Separating JMX/EJB

[Scott M Stark]

Definitely.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 9:21 AM
Subject: [JBoss-dev] Separating JMX/EJB


 kids,

 we are hearing a lot of talk about EJB and not EJB and blabla bla.  Well I
 will say that I am a big fan of the framework, for reasons that even our
 favorite aliens are missing ;-) but that is another thread.

 The reason I want EJB to take a backseat in the LAYOUT OF THE CODE is
that
 I believe we need to separate what is spec derived, spec dependent and
what
 is good software in general.  Most notably there are very large project
 out there (Las Vegas IGT for example) that at first were using the JMX
base
 and management of JBoss to build complex systems and the RH JBoss3.0 view
is
 clearly targeted at these folks, large ISV shops using JBoss in high end
 complex applications.  The JMX view and what we do with it, needs to be
 clearly expressed as independent of the EJB spec. Interceptors and the
 packaging/distribution that we do, the microkernel view, all that is
 knowledge that is not EJB specific.

 Right now everythign seems to be under org/jboss/ejb and
 org/jboss/ejb/plugins when really we are largely BEYOND the ejb spec and
it
 applies to a wider and more generic category of problems than just EJB.
In
 fact I am starting to suspect that the EJB part of our code, the really
 dependent part is 20% of the total code today.  Which is really
 negligeable.  The smart ones in you will see where I am going with this.
If
 not you will see.

 BOTTOM LINE: I want you guys to start wiring what is not EJB specific into
 more generic packages. Ex: the Invocation I just commited, the
 MethodINvocation should be outside it is just dependent on the
 EnterpriseContext and teh EC is just a wrapper for instances in Cache.
what
 is really EJB dependent should at the end of the day be seen in the
imports
 at once and it should be factored out.  Meaning if it isn't dependent on
the
 spec but derived from largely known computing practices (heck the state
 machine view of JMX was first put forth by Alan Turing :)

 Again, this is not a reflexion on the value of EJB, I will start seriously
 evangelizing my love of EJB as system construct which is something I cover
 in the trainings already, JMX is just generic and independent of this, the
 microkernel view is generic and independent, the packaging we do is
generic
 and independent...

 You get it.

 marcf

 
 Marc Fleury
 President
 JBoss Group, LLC
 


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



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

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

wowowo,

I realize I forgot to say what this is good for :)

you can now attach ANY PAYLOAD to an invocation, not just the stuff
generated at the client, so that you can pass information down the chain,
have interceptors talking to each other and pass arbitrary data around the
JMX base, VERY VERY VERY useful for your custom advanced interceptors.

(was it the motorola kids in the Las Vegas training that mentioned they
needed this?)

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc
|fleury
|Sent: Wednesday, November 14, 2001 12:08 PM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: [JBoss-dev] Invocation and MethodInvocation
|
|
|Ok,
|
|[FOR RECORD, ARCH CHANGE]
|
|we discussed some time ago the possible extension of the MethodInvocation
|to be a more generic and powerful entity.
|
|Basically I have added the invocation directory and the Invocation.java, as
|well as changed the MethodInvocation.
|
|The 10,000 ft is that the new RH JMX view puts the mbeans in front.  The
|entity that travels inside our JMX bus is the Invocation that I just
|introduced.  The invocation basically takes the transaction and security
|information as its basis.  You are always doing stuff as part of
|transaction
|context (maybe empty meaning no transaction) and as someone authenticated
|(if you set it up) but these are the building blocks.  Then everything else
|is in a payload of possibly serialized byte[] data that we can carry
|around as such (avoiding cl madness).  We extend this for the
|methodinvocation which is more EJB'ish in that it knows about the
|EnterpriseContext (more on that later).
|
|The other new thing in there is the presence of the mbean list of objects
|this Invocation is supposed to go through.  It will identify the MBean
|interface of the Container for the EJBs, thereby really finalizing the
|detaching of the invokers from the invocation, both from the bus (which is
|already done) and the rmi impl (to be done next).
|
|The Invocation is not using the mbean list as yet, but possibly will, since
|what would come next is a self standing invocation in our JMX base, going
|through the bus from mbean to mbean, which would really give us a possibly
|dynamic way of maintaining the path that our invocation takes in the base.
|The stuff is there, will use a little bit to hook up the EJB container, we
|will see.
|
|I will also probably don't externalize the interceptors as yet, no good
|reason except it would be less disruptive a view from what we have now and
|it would be lindfors recommendation.
|
|I was going to talk about the EnterpriseContext thing but this is already
|a long mail. I will do so in a forthcoming email.
|
|Finally I will say that for legacy reasons I have kept the old constructors
|and allowed the Invocation to carry no MBean association.  The 2 legacy are
|1- the invocation chain is not fully generic yet, it knows the target, this
|is detached already (going JMX bus) but will move next 2- the CMR
|stuff from
|Dain that uses the invocation chain to invoke stuff on itself, this assumes
|that you know the container (which it does) and calls it directly (which it
|does) withouth the intermission of the JMX bus (which is ok), so this is
|likely to remain as is for now. Moving it to the bus would be trivial but
|not a priority right now.
|
|The testsuite testbean runs fine afaict, so this should not disrupt the
|existing RH codebase, fully backward compatible (again afaict)
|
|just warming up
|
|marcf
|
|Marc Fleury
|President
|JBoss Group, LLC
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Adam Heath]

On Wed, 14 Nov 2001, Scott M Stark wrote:

 Jikes is not a Java program and you have to use a binary suitable for
 the target platform. I'm not interested in getting into supporting mutiple
 platform binaries.

Well, I guess now is as good a time as any to bring up a problem I have with
the current source tarball for 2.4.3.

The 2.4.3 tarball contains precompiled jars.  Some of these jars are
precompiled jboss jars(ick, but forgivable, see below(1)).  Some of these jars
are non-free, and should NOT be redistributed.

I understand the desire to provide a one-stop-shop for getting jboss to work.
But then there should be a pristince source package, that does not have all
this bundled code inside it.

What I am requesting is such a pristine source package.  Otherwise, I have to
go to great lengths when making a Debian(www.debian.org) package of this
software.  There is also the point that I can not upload this package to the
Debian archive, because it includes non-free code into its source package.  I
would greatly like to be able to upload this to Debian.

list of packages included with jboss, followed by their homepage, then license
type:

castor: http://castor.exolab.org/  
 (BSD-like)
hsql:   http://hsqldb.sf.net/  
 (BSD)
jetty-server:   http://jetty.mortbay.org   
 (artistic-like)
oswego: 
http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html  
(public domain)
tyrex:  http://tyrex.exolab.org/   
 (BSD-like)

activation: http://java.sun.com/products/javabeans/glasgow/jaf.html
 (sun)
jaxp:   http://java.sun.com/xml/jaxp/  
 (sun)
jcert:  http://java.sun.com/products/jsse/(or j2se/1.4)
 (sun/export restrictions)
jpl-util:   http://www.gjt.org/
 (unspecified)
mail:   http://java.sun.com/products/javamail/ 
 (sun)
ots-jts:http://java.sun.com/j2se/1.3/  
 (sun)


1:
Additionally, the precompiled jboss jars that are in the source tarball
get rebuilt during a build.  This means a diff generation sees them as
changed, and dpkg-source complains.  Would it not be proper, to have
proper compile ordering, and have each sub-package use what was just
previously built?


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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Scott M Stark]

2.4.x is based on the archaic and fragmented build policy from the
early days of JBoss and its not likely to change(at least by me).
The build process has been totally reorganized in the main branch for the
3.0 release so focus on getting a source ball that suits your purpose
using it.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Adam Heath [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 9:48 AM
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...


 On Wed, 14 Nov 2001, Scott M Stark wrote:

  Jikes is not a Java program and you have to use a binary suitable for
  the target platform. I'm not interested in getting into supporting
mutiple
  platform binaries.

 Well, I guess now is as good a time as any to bring up a problem I have
with
 the current source tarball for 2.4.3.

 The 2.4.3 tarball contains precompiled jars.  Some of these jars are
 precompiled jboss jars(ick, but forgivable, see below(1)).  Some of these
jars
 are non-free, and should NOT be redistributed.

 I understand the desire to provide a one-stop-shop for getting jboss to
work.
 But then there should be a pristince source package, that does not have
all
 this bundled code inside it.

 What I am requesting is such a pristine source package.  Otherwise, I have
to
 go to great lengths when making a Debian(www.debian.org) package of this
 software.  There is also the point that I can not upload this package to
the
 Debian archive, because it includes non-free code into its source package.
I
 would greatly like to be able to upload this to Debian.

 list of packages included with jboss, followed by their homepage, then
license
 type:

 castor: http://castor.exolab.org/
(BSD-like)
 hsql:   http://hsqldb.sf.net/
(BSD)
 jetty-server:   http://jetty.mortbay.org
(artistic-like)
 oswego:
http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
(public domain)
 tyrex:  http://tyrex.exolab.org/
(BSD-like)

 activation: http://java.sun.com/products/javabeans/glasgow/jaf.html
(sun)
 jaxp:   http://java.sun.com/xml/jaxp/
(sun)
 jcert:  http://java.sun.com/products/jsse/(or j2se/1.4)
(sun/export restrictions)
 jpl-util:   http://www.gjt.org/
(unspecified)
 mail:   http://java.sun.com/products/javamail/
(sun)
 ots-jts:http://java.sun.com/j2se/1.3/
(sun)


 1:
 Additionally, the precompiled jboss jars that are in the source
tarball
 get rebuilt during a build.  This means a diff generation sees them as
 changed, and dpkg-source complains.  Would it not be proper, to have
 proper compile ordering, and have each sub-package use what was just
 previously built?




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

[JBoss-dev] [ jboss-Feature Requests-481711 ] JetSpeed( Apache EIP Framework)

[noreply]

Feature Requests item #481711, was opened at 2001-11-14 07:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376688aid=481711group_id=22866

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: JetSpeed( Apache EIP Framework)

Initial Comment:

Hi All ...

Is there any EIP framework is already embeded inside 
JBOSS? If not any plans to integrate with Jetspeed 
which is using by IBM inWebSpear...

--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376688aid=481711group_id=22866

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

[JBoss-dev] CVS update: newsite/src/docs petstore_frames_user.html

[Tom Coleman]

  User: tmcsys  
  Date: 01/11/14 10:24:10

  Added:   src/docs petstore_frames_user.html
  Log:
  Match 'user' pages color scheme
  
  Revision  ChangesPath
  1.1  newsite/src/docs/petstore_frames_user.html
  
  Index: petstore_frames_user.html
  ===
  !-- $Id: petstore_frames_user.html,v 1.1 2001/11/14 18:24:09 tmcsys Exp $ --
  html
  head
  titleJBoss Pet Store/title
  /head
  
  frameset frameborder=0 rows=230,* cols=1
frame noresize scrolling=no src=head.jsp
frame noresize src=/estore
  /frameset
  noframes
  a href=/estoreRun the Java Pet Store using JBoss/a
  /noframes
  /html
  
  
  

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

Re: [JBoss-dev] Separating JMX/EJB

[David Jencks]

Amen.

FWIW, I think the major advantage of the EJB framework over e.g. using JDO
is that, especially in the jboss environment, it is very simple to do
(limited) meta-class programming. The EJB spec uses this for transactions
and security, Scott uses it for Security Proxies, I have used it to apply
rules to method invocations.  The possibilities for this have barely begun
to be scratched.  On the other hand this is what you get with any
interceptor based invocation architecture-- so why _are_ ejbs so good
anyway?

david jencks

On 2001.11.14 12:21:16 -0500 marc fleury wrote:
 kids,
 
 we are hearing a lot of talk about EJB and not EJB and blabla bla.  Well
 I
 will say that I am a big fan of the framework, for reasons that even our
 favorite aliens are missing ;-) but that is another thread.
 
 The reason I want EJB to take a backseat in the LAYOUT OF THE CODE is
 that
 I believe we need to separate what is spec derived, spec dependent and
 what
 is good software in general.  Most notably there are very large project
 out there (Las Vegas IGT for example) that at first were using the JMX
 base
 and management of JBoss to build complex systems and the RH JBoss3.0 view
 is
 clearly targeted at these folks, large ISV shops using JBoss in high end
 complex applications.  The JMX view and what we do with it, needs to be
 clearly expressed as independent of the EJB spec. Interceptors and the
 packaging/distribution that we do, the microkernel view, all that is
 knowledge that is not EJB specific.
 
 Right now everythign seems to be under org/jboss/ejb and
 org/jboss/ejb/plugins when really we are largely BEYOND the ejb spec and
 it
 applies to a wider and more generic category of problems than just EJB. 
 In
 fact I am starting to suspect that the EJB part of our code, the really
 dependent part is 20% of the total code today.  Which is really
 negligeable.  The smart ones in you will see where I am going with this. 
 If
 not you will see.
 
 BOTTOM LINE: I want you guys to start wiring what is not EJB specific
 into
 more generic packages. Ex: the Invocation I just commited, the
 MethodINvocation should be outside it is just dependent on the
 EnterpriseContext and teh EC is just a wrapper for instances in Cache. 
 what
 is really EJB dependent should at the end of the day be seen in the
 imports
 at once and it should be factored out.  Meaning if it isn't dependent on
 the
 spec but derived from largely known computing practices (heck the state
 machine view of JMX was first put forth by Alan Turing :)
 
 Again, this is not a reflexion on the value of EJB, I will start
 seriously
 evangelizing my love of EJB as system construct which is something I
 cover
 in the trainings already, JMX is just generic and independent of this,
 the
 microkernel view is generic and independent, the packaging we do is
 generic
 and independent...
 
 You get it.
 
 marcf
 
 
 Marc Fleury
 President
 JBoss Group, LLC
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|Although I originally thought including an mbean-iterator in the method
|invocation, as you have done, was the way to go, after discussion with
|Scott and some experiments I changed my mind to think an approach using
|interceptor factories and interceptor chain factories (both mbeans) is a
|better idea.

The mbean is there to identify the target MBean for now.  Whether or not we
go to the fully stateless design might be down the road.

Reread my email, for now (today's todo) it is going to point to the
container. The String[] could be a String (no []) this is how I am going to
use it this afternoon with the detaching of the connector (see if it works
well).

|There are 2 problems I know of with the mbean-iterator approach.
|1. It requires the interceptors to be stateless.  All state info has to be
|carried in the invocation object.  Any setup information the interceptor

You are mixing 2 issues, one is making the chain of interceptors fully
stateless (which they are afaict I still have to see the example you are
refering to).  The other is list of mbeans you go through, since the
interceptors AREN'T MBEANS yet, we would have to make that first wouldn't
we?

|may need has to be stored in the head-of-the-chain object and sent with
|each MI.  IMHO this is _really_ not where this info belongs.  The head

??? the invocation is the only one that uses the information.

|should not need to know or store the interceptor-specific state info for
|its chain.  IMHO using a catch-all (or cache-all) map is a bit of a hack.
|In particular, this conflicts directly with the security proxy interceptor.
|
|2. (possibly an implementation issue, but real at the moment).  Calling
|mbeanserver.invoke is _wa_ slower than a direct method call.  On my
|machine, 100,000 iterations in 10 sec compared with 0 sec.  I think this
|will be a significant performance problem.

are you benching dynamic mbeans or standard mbeans? the dynamic mbean *is* a
direct method call (plus a lookup in a map, big deal).  The standard mbean
is a reflection call which is slow but we aren't using that as the bus.

|The interceptor chain methodology I cureently think will work best involves
|2 mbeans:

We are NOT TOUCHING THE INTERCEPTOR CHAIN YET... we are talking about a list
of MBeans. right now the only mbean is the container that was added by Scott
and I wired the other day...

|Interceptor factories:
|
|takes Interceptor class name as an attribute, has an mbean method
|newInterceptor returning a copy of the Interceptor.
|
|This is a dynamic mbean, it could be made to expose the get/set properties
|of the interceptor as attributes in the InterceptorFactory mbean.
|
|InterceptorChainFactory:
|takes an mbean-ref-list of the mbeans you want in the chain.  Has a
|newInterceptorChain method taking the head and tail of the chain as
|parameters, returns a new chain with the interceptors specified in the
|list.  Calls init(head) on each interceptor. (the head is an object that is
|assumed to contain the info needed for initialization, such as the info for
|the SecurityProxy setup.)  The supplied tail is setup as the last element.
|
|I have this much written.
|
|I have been wondering how to fit this into the ContainerFactory: I think
|one approach might be to make the Containers into MBeans that can be
|configured as any other mbeans in a service-xml file, and include an

I prefer the lindfors/oberg approach to this with model mbeans.  The beans
will probably point to an ejb that has a persistence engine that reads xml
files like the ones we have.  With that you have clustered mbean
configurations.

I am going back to my linux box, over and out, will read stuff
tomorrow/tonight, give me some time with this, we will deal with the
interceptor chain when we really need to... down the road, one step at a
time, professor, one step at a time.

marcf

|mbean-ref to the InterceptorChainFactory needed.  The ContainerFactory
|could have mbean-refs to the default chains for each type of bean.  I
|haven't looked into this extensively yet.
|
|Thanks
|david jencks
|
|On 2001.11.14 12:08:00 -0500 marc fleury wrote:
| Ok,
|
| [FOR RECORD, ARCH CHANGE]
|
| we discussed some time ago the possible extension of the
| MethodInvocation
| to be a more generic and powerful entity.
|
| Basically I have added the invocation directory and the Invocation.java,
| as
| well as changed the MethodInvocation.
|
| The 10,000 ft is that the new RH JMX view puts the mbeans in front.  The
| entity that travels inside our JMX bus is the Invocation that I just
| introduced.  The invocation basically takes the transaction and security
| information as its basis.  You are always doing stuff as part of
| transaction
| context (maybe empty meaning no transaction) and as someone authenticated
| (if you set it up) but these are the building blocks.  Then everything
| else
| is in a payload of possibly serialized byte[] data that we can carry
| around as such (avoiding cl madness).  We extend this for 

RE: [JBoss-dev] Separating JMX/EJB

[marc fleury]

|Amen.
|
|FWIW, I think the major advantage of the EJB framework over e.g. using JDO
|is that, especially in the jboss environment, it is very simple to do
|(limited) meta-class programming. The EJB spec uses this for transactions
|and security, Scott uses it for Security Proxies, I have used it to apply
|rules to method invocations.  The possibilities for this have barely begun
|to be scratched.  On the other hand this is what you get with any
|interceptor based invocation architecture-- so why _are_ ejbs so good
|anyway?

we agree on the metaprogramming, we are going to make it dynamic too,

some other day I will publish a white paper :) Let Rickard fire first

marcf


|
|david jencks
|
|On 2001.11.14 12:21:16 -0500 marc fleury wrote:
| kids,
|
| we are hearing a lot of talk about EJB and not EJB and blabla bla.  Well
| I
| will say that I am a big fan of the framework, for reasons that even our
| favorite aliens are missing ;-) but that is another thread.
|
| The reason I want EJB to take a backseat in the LAYOUT OF THE CODE is
| that
| I believe we need to separate what is spec derived, spec dependent and
| what
| is good software in general.  Most notably there are very large project
| out there (Las Vegas IGT for example) that at first were using the JMX
| base
| and management of JBoss to build complex systems and the RH JBoss3.0 view
| is
| clearly targeted at these folks, large ISV shops using JBoss in high end
| complex applications.  The JMX view and what we do with it, needs to be
| clearly expressed as independent of the EJB spec. Interceptors and the
| packaging/distribution that we do, the microkernel view, all that is
| knowledge that is not EJB specific.
|
| Right now everythign seems to be under org/jboss/ejb and
| org/jboss/ejb/plugins when really we are largely BEYOND the ejb spec and
| it
| applies to a wider and more generic category of problems than just EJB.
| In
| fact I am starting to suspect that the EJB part of our code, the really
| dependent part is 20% of the total code today.  Which is really
| negligeable.  The smart ones in you will see where I am going with this.
| If
| not you will see.
|
| BOTTOM LINE: I want you guys to start wiring what is not EJB specific
| into
| more generic packages. Ex: the Invocation I just commited, the
| MethodINvocation should be outside it is just dependent on the
| EnterpriseContext and teh EC is just a wrapper for instances in Cache.
| what
| is really EJB dependent should at the end of the day be seen in the
| imports
| at once and it should be factored out.  Meaning if it isn't dependent on
| the
| spec but derived from largely known computing practices (heck the state
| machine view of JMX was first put forth by Alan Turing :)
|
| Again, this is not a reflexion on the value of EJB, I will start
| seriously
| evangelizing my love of EJB as system construct which is something I
| cover
| in the trainings already, JMX is just generic and independent of this,
| the
| microkernel view is generic and independent, the packaging we do is
| generic
| and independent...
|
| You get it.
|
| marcf
|
| 
| Marc Fleury
| President
| JBoss Group, LLC
| 
|
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


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

RE: [JBoss-dev] RH: tools.jar (javac)...

[Ignacio Coloma]

I'm preparing a patch (my humble contribution, snif!) for run.bat/run.jar.
It includes:

1.- Support for tools.jar 'a la' Tomcat: you should define a JAVA_HOME
environment variable that points to your java instalation directory. It
checks if tools.jar is where it should. If not, it doesn't let you start
JBoss.
2.- Moves all the JAXP env variables into run.jar, cleaning the bat file.
3.- Document into run.bat a bit what's happening.
4.- Include commented lines to start jboss in debug mode (JPDA), both by
socket and by shared memory. There are docs out there about how to connect
to an already started app. I use this one a lot.

Ignacio.

 -Mensaje original-
 De: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]En nombre de
 Andreas Schaefer
 Enviado el: miércoles, 14 de noviembre de 2001 16:46
 Para: [EMAIL PROTECTED];
 [EMAIL PROTECTED]
 Asunto: Re: [JBoss-dev] RH: tools.jar (javac)...


 Yes, you are missing the fact that tools.jar is plattform/vendor
 dependant.
 Therefore you would have to distribute one for each plattform.

 Andy

 - Original Message -
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, November 14, 2001 8:14 AM
 Subject: Re: [JBoss-dev] RH: tools.jar (javac)...


 
  Maybe I am missing something, but isn't this whole issue about
 distributing
  a compiler with JBoss so the user doesn't have to download the JDK and
 edit
  a configuration file to point to it?
 
  If that is the case, can't we distribute jikes?
 
  -Phil
 
 
 
 
  Scott M Stark
  [EMAIL PROTECTED]To:
 JBossDev \(E-mail\)
  Sent by:
 [EMAIL PROTECTED]
  [EMAIL PROTECTED]cc:
  eforge.net Subject:
 Re: [JBoss-dev] RH: tools.jar
 
 (javac)...
 
  11/13/2001 05:37 PM
  Please respond to Scott M Stark
 
 
 
 
 
 
  That is how both the bundled tomcat and standalone tomcat handles this.
  You have to have the JDK tools.jar, or jikes, or some other compiler
  configured
  as part of the installation. Since we can't bundle tools.jar
 and javac.jar
  is
  just a black box we don't want to include since it source for
 it can't be
  obtained,
  there is nothing we can do to make this a platform independent zero
  configuration issue as far as I know.
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
  - Original Message -
  From: David Maplesden [EMAIL PROTECTED]
  To: JBossDev (E-mail) [EMAIL PROTECTED]
  Sent: Tuesday, November 13, 2001 4:14 PM
  Subject: RE: [JBoss-dev] RH: tools.jar (javac)...
 
 
   No I haven't and I see now what you mean, I didn't read what you put
   carefully enough.  Still you might be able to do it this way, IIRC we
  used
   to distribute javac in a javac.jar that was distributed with JBoss to
   different platforms and it seemed to work OK.
  
   I thought the only reason we weren't distributing tools.jar
 in the same
  way
   is because of licensing issues with Sun.
  
   That of course brings up a problem with 1) you can't distribute any
  package
   you create that contains tools.jar (I think).
  
   Perhaps the easiest thing to do for the Jetty dist is to reference
  tools.jar
   as if it exists in the lib/ext dir and simply include a README telling
   people what is going on, then they can supply their own (platform
  specific
   if neccessary) jar.
  
   David
  
-Original Message-
From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 1:02 PM
To: David Maplesden; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
   
   
David Maplesden wrote:
   
 1) worked fine for me...
   
Have you tried it on different architectures?
   
My concern is that if I do the build on Linux, the tools.jar
from my 1.3.1
distrib may not work on e.g. a Mac etc...
   
Jules
 
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 


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




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

RE: [JBoss-dev] RH: tools.jar (javac)...

[Ignacio Coloma]

How about removing the code and leaving a comment in the run.bat file?

It's easy to modify the required of JAVA_HOME to add tools.jar if
JAVA_HOME is available

 -Mensaje original-
 De: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]En nombre de David
 Maplesden
 Enviado el: miércoles, 14 de noviembre de 2001 19:38
 Para: [EMAIL PROTECTED]
 Asunto: RE: [JBoss-dev] RH: tools.jar (javac)...


 You might be jumping the gun a bit with this one.  tools.jar is
 only needed
 afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp
 pages.  Not
 everyone will want this, indeed many people will probably run
 JBoss without
 a servlet engine, and so they won't need tools.jar.

 David

  -Original Message-
  From: Ignacio Coloma [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, November 15, 2001 7:57 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] RH: tools.jar (javac)...
 
 
  I'm preparing a patch (my humble contribution, snif!) for
  run.bat/run.jar.
  It includes:
 
  1.- Support for tools.jar 'a la' Tomcat: you should define a JAVA_HOME
  environment variable that points to your java instalation
  directory. It
  checks if tools.jar is where it should. If not, it doesn't
  let you start
  JBoss.
  2.- Moves all the JAXP env variables into run.jar, cleaning
  the bat file.
  3.- Document into run.bat a bit what's happening.
  4.- Include commented lines to start jboss in debug mode
  (JPDA), both by
  socket and by shared memory. There are docs out there about
  how to connect
  to an already started app. I use this one a lot.
 
  Ignacio.
 
   -Mensaje original-
   De: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]En nombre de
   Andreas Schaefer
   Enviado el: miércoles, 14 de noviembre de 2001 16:46
   Para: [EMAIL PROTECTED];
   [EMAIL PROTECTED]
   Asunto: Re: [JBoss-dev] RH: tools.jar (javac)...
  
  
   Yes, you are missing the fact that tools.jar is plattform/vendor
   dependant.
   Therefore you would have to distribute one for each plattform.
  
   Andy
  
   - Original Message -
   From: [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Sent: Wednesday, November 14, 2001 8:14 AM
   Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
  
  
   
Maybe I am missing something, but isn't this whole issue about
   distributing
a compiler with JBoss so the user doesn't have to
  download the JDK and
   edit
a configuration file to point to it?
   
If that is the case, can't we distribute jikes?
   
-Phil
   
   
   
   
Scott M Stark
[EMAIL PROTECTED]To:
   JBossDev \(E-mail\)
Sent by:
   [EMAIL PROTECTED]
[EMAIL PROTECTED]cc:
eforge.net
   Subject:
   Re: [JBoss-dev] RH: tools.jar
   
   (javac)...
   
11/13/2001 05:37 PM
Please respond to Scott M Stark
   
   
   
   
   
   
That is how both the bundled tomcat and standalone tomcat
  handles this.
You have to have the JDK tools.jar, or jikes, or some
  other compiler
configured
as part of the installation. Since we can't bundle tools.jar
   and javac.jar
is
just a black box we don't want to include since it source for
   it can't be
obtained,
there is nothing we can do to make this a platform
  independent zero
configuration issue as far as I know.
   

Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: David Maplesden [EMAIL PROTECTED]
To: JBossDev (E-mail) [EMAIL PROTECTED]
Sent: Tuesday, November 13, 2001 4:14 PM
Subject: RE: [JBoss-dev] RH: tools.jar (javac)...
   
   
 No I haven't and I see now what you mean, I didn't read
  what you put
 carefully enough.  Still you might be able to do it
  this way, IIRC we
used
 to distribute javac in a javac.jar that was distributed
  with JBoss to
 different platforms and it seemed to work OK.

 I thought the only reason we weren't distributing tools.jar
   in the same
way
 is because of licensing issues with Sun.

 That of course brings up a problem with 1) you can't
  distribute any
package
 you create that contains tools.jar (I think).

 Perhaps the easiest thing to do for the Jetty dist is
  to reference
tools.jar
 as if it exists in the lib/ext dir and simply include a
  README telling
 people what is going on, then they can supply their own
  (platform
specific
 if neccessary) jar.

 David

  -Original Message-
  From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, November 14, 2001 1:02 PM
  To: David Maplesden; [EMAIL PROTECTED];
  [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
 
 
  David Maplesden wrote:
 
   1) 

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

actually scratch all this discussion,

I think I have a better idea for the MI/Invocation

I will keep the payload and just put different readers on it, the basic
one will be the Invocation, the extended one will be the MI but essentially
we can create a MI and set the payload from the incoming invocation and
then read a typed invocation (ejb in this case) only when we reach the
valid stacks, this allows for something truly powerful: byte[] messages
until we reach the stack that knows how to read them, but the fact that they
are serialized or not is transparent to the MI, which is truly not the case
...

the basic invocation is thus the payload, the readers are just typed
conveniences in the stacks.

Will make sense when I commit this.



|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc
|fleury
|Sent: Wednesday, November 14, 2001 1:54 PM
|To: David Jencks; [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|
|
||Although I originally thought including an mbean-iterator in the method
||invocation, as you have done, was the way to go, after discussion with
||Scott and some experiments I changed my mind to think an approach using
||interceptor factories and interceptor chain factories (both mbeans) is a
||better idea.
|
|The mbean is there to identify the target MBean for now.  Whether or not we
|go to the fully stateless design might be down the road.
|
|Reread my email, for now (today's todo) it is going to point to the
|container. The String[] could be a String (no []) this is how I am going to
|use it this afternoon with the detaching of the connector (see if it works
|well).
|
||There are 2 problems I know of with the mbean-iterator approach.
||1. It requires the interceptors to be stateless.  All state info has to be
||carried in the invocation object.  Any setup information the interceptor
|
|You are mixing 2 issues, one is making the chain of interceptors fully
|stateless (which they are afaict I still have to see the example you are
|refering to).  The other is list of mbeans you go through, since the
|interceptors AREN'T MBEANS yet, we would have to make that first wouldn't
|we?
|
||may need has to be stored in the head-of-the-chain object and sent with
||each MI.  IMHO this is _really_ not where this info belongs.  The head
|
|??? the invocation is the only one that uses the information.
|
||should not need to know or store the interceptor-specific state info for
||its chain.  IMHO using a catch-all (or cache-all) map is a bit of a hack.
||In particular, this conflicts directly with the security proxy
|interceptor.
||
||2. (possibly an implementation issue, but real at the moment).  Calling
||mbeanserver.invoke is _wa_ slower than a direct method call.  On my
||machine, 100,000 iterations in 10 sec compared with 0 sec.  I think this
||will be a significant performance problem.
|
|are you benching dynamic mbeans or standard mbeans? the dynamic
|mbean *is* a
|direct method call (plus a lookup in a map, big deal).  The standard mbean
|is a reflection call which is slow but we aren't using that as the bus.
|
||The interceptor chain methodology I cureently think will work
|best involves
||2 mbeans:
|
|We are NOT TOUCHING THE INTERCEPTOR CHAIN YET... we are talking
|about a list
|of MBeans. right now the only mbean is the container that was
|added by Scott
|and I wired the other day...
|
||Interceptor factories:
||
||takes Interceptor class name as an attribute, has an mbean method
||newInterceptor returning a copy of the Interceptor.
||
||This is a dynamic mbean, it could be made to expose the get/set properties
||of the interceptor as attributes in the InterceptorFactory mbean.
||
||InterceptorChainFactory:
||takes an mbean-ref-list of the mbeans you want in the chain.  Has a
||newInterceptorChain method taking the head and tail of the chain as
||parameters, returns a new chain with the interceptors specified in the
||list.  Calls init(head) on each interceptor. (the head is an
|object that is
||assumed to contain the info needed for initialization, such as
|the info for
||the SecurityProxy setup.)  The supplied tail is setup as the last element.
||
||I have this much written.
||
||I have been wondering how to fit this into the ContainerFactory: I think
||one approach might be to make the Containers into MBeans that can be
||configured as any other mbeans in a service-xml file, and include an
|
|I prefer the lindfors/oberg approach to this with model mbeans.  The beans
|will probably point to an ejb that has a persistence engine that reads xml
|files like the ones we have.  With that you have clustered mbean
|configurations.
|
|I am going back to my linux box, over and out, will read stuff
|tomorrow/tonight, give me some time with this, we will deal with the
|interceptor chain when we really need to... down the road, one step at a
|time, professor, one step at a time.
|
|marcf
|
||mbean-ref to the InterceptorChainFactory 

RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[David Maplesden]

Looks good Hiram,

Can I make one suggestion.  When I was profiling and improving JBossMQ's
performance I implemented a couple of static methods
SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of the
standard writeObject and readObject methods.  I think you should use them
here.

They work fine, you get back exactly the same object you write out, and they
are used by all the persistence and communication mechanisms currently
because they are many times quicker than the standard object serialization
(which is horribly slow).

Oh, and if we are talking about performance, I would appreciate everyone
being very careful about placing debug statements inside any code that is
executed for every message through the system.  Several of these have been
introduced with the advent of the message caching and David J's new stuff.

The cost of constructing all the message strings, even if they aren't used,
can add considerable overhead to the system (if you don't believe me then
create a test and see).  Remember I managed to get somewhere between a 10 to
20 times speed improvement by improving the serialisation code and removing
these debug statements from inside the inner loop.  If you really, really
want them then place them behind a static final boolean flag i.e.

if(DEBUG) log.debug(a message);
 
so that we can easily set the flag to false and recompile a higher
performance version of the engine.  With the static flag set to false the
compiler removes the line completely, so there is no performance hit at all.

Thanks David.

 -Original Message-
 From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 14, 2001 5:24 PM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file
 CacheStore.java CacheStoreMBean.java
 
 
   User: chirino 
   Date: 01/11/13 20:24:08
 
   Added:   src/main/org/jboss/mq/pm/file CacheStore.java
 CacheStoreMBean.java
   Log:
   Factored out a CacheStore object from the message store.  
 This should lay the
   ground work needed so that the MessageCache can use a PM 
 for saving and loading
   messages.
   
   Also fixed a small bug in the file PM.  It was not properly 
 restoring the message
   after a server restart.
   
   Revision  ChangesPath
   1.1  
 jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
   
   Index: CacheStore.java
   ===
   /*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
   package org.jboss.mq.pm.file;
   
   import java.io.BufferedInputStream;
   import java.io.BufferedOutputStream;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.FileOutputStream;
   import java.io.IOException;
   import java.io.ObjectInputStream;
   import java.io.ObjectOutputStream;
   
   import javax.jms.JMSException;
   import org.jboss.mq.SpyJMSException;
   import org.jboss.mq.SpyMessage;
   import org.jboss.mq.server.MessageReference;
   import org.jboss.system.ServiceMBeanSupport;
   
   /**
*  This class manages the persistence needs of the MessageCache
*
* @author Hiram Chirino 
* @version$Revision: 1.1 $
*/
   public class CacheStore extends ServiceMBeanSupport 
 implements org.jboss.mq.pm.CacheStore, CacheStoreMBean {
  String dataDirectory;
  File dataFile;
   
  /**
   * @see ServiceMBeanSupport#getName()
   */
  public String getName() {
 return JBossMQ-CacheStore;
  }
   
  /**
   * @see CacheStore#loadFromStorage(MessageReference)
   */
  public SpyMessage loadFromStorage(MessageReference mh) 
 throws JMSException {
 try {
File f = new File(dataFile, Message- + mh.referenceId);
ObjectInputStream is = new ObjectInputStream(new 
 BufferedInputStream(new FileInputStream(f)));
Object rc = is.readObject();
is.close();
return (SpyMessage) rc;
 } catch (ClassNotFoundException e) {
throw new SpyJMSException(Could not load message 
 from secondary storage: , e);
 } catch (IOException e) {
throw new SpyJMSException(Could not load message 
 from secondary storage: , e);
 }
  }
   
  /**
   * @see CacheStore#saveToStorage(MessageReference, SpyMessage)
   */
  public void saveToStorage(MessageReference mh, 
 SpyMessage message) throws JMSException {
 try {
File f = new File(dataFile, Message- + mh.referenceId);
ObjectOutputStream os = new ObjectOutputStream(new 
 BufferedOutputStream(new FileOutputStream(f)));
os.writeObject(message);
os.close();
 } catch (IOException e) {
throw new SpyJMSException(Could not load message 
 from secondary storage: , e);
 }
  }
   
  /**
   * @see 

RE: [JBoss-dev] RH: tools.jar (javac)...

[David Maplesden]

yeah sounds good, add it if you can find it, if you can't print a warning
and carry on

 -Original Message-
 From: Ignacio Coloma [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, November 15, 2001 8:48 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] RH: tools.jar (javac)...
 
 
 How about removing the code and leaving a comment in the run.bat file?
 
 It's easy to modify the required of JAVA_HOME to add tools.jar if
 JAVA_HOME is available
 
  -Mensaje original-
  De: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]En 
 nombre de David
  Maplesden
  Enviado el: miércoles, 14 de noviembre de 2001 19:38
  Para: [EMAIL PROTECTED]
  Asunto: RE: [JBoss-dev] RH: tools.jar (javac)...
 
 
  You might be jumping the gun a bit with this one.  tools.jar is
  only needed
  afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp
  pages.  Not
  everyone will want this, indeed many people will probably run
  JBoss without
  a servlet engine, and so they won't need tools.jar.
 
  David
 
   -Original Message-
   From: Ignacio Coloma [mailto:[EMAIL PROTECTED]]
   Sent: Thursday, November 15, 2001 7:57 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] RH: tools.jar (javac)...
  
  
   I'm preparing a patch (my humble contribution, snif!) for
   run.bat/run.jar.
   It includes:
  
   1.- Support for tools.jar 'a la' Tomcat: you should 
 define a JAVA_HOME
   environment variable that points to your java instalation
   directory. It
   checks if tools.jar is where it should. If not, it doesn't
   let you start
   JBoss.
   2.- Moves all the JAXP env variables into run.jar, cleaning
   the bat file.
   3.- Document into run.bat a bit what's happening.
   4.- Include commented lines to start jboss in debug mode
   (JPDA), both by
   socket and by shared memory. There are docs out there about
   how to connect
   to an already started app. I use this one a lot.
  
   Ignacio.
  
-Mensaje original-
De: [EMAIL PROTECTED]

 [mailto:[EMAIL PROTECTED]]En nombre de
Andreas Schaefer
Enviado el: miércoles, 14 de noviembre de 2001 16:46
Para: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Asunto: Re: [JBoss-dev] RH: tools.jar (javac)...
   
   
Yes, you are missing the fact that tools.jar is plattform/vendor
dependant.
Therefore you would have to distribute one for each plattform.
   
Andy
   
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 8:14 AM
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
   
   

 Maybe I am missing something, but isn't this whole issue about
distributing
 a compiler with JBoss so the user doesn't have to
   download the JDK and
edit
 a configuration file to point to it?

 If that is the case, can't we distribute jikes?

 -Phil




 Scott M Stark
 [EMAIL PROTECTED]   
  To:
JBossDev \(E-mail\)
 Sent by:
[EMAIL PROTECTED]
 
 [EMAIL PROTECTED]cc:
 eforge.net
Subject:
Re: [JBoss-dev] RH: tools.jar

(javac)...

 11/13/2001 05:37 PM
 Please respond to Scott M Stark






 That is how both the bundled tomcat and standalone tomcat
   handles this.
 You have to have the JDK tools.jar, or jikes, or some
   other compiler
 configured
 as part of the installation. Since we can't bundle tools.jar
and javac.jar
 is
 just a black box we don't want to include since it source for
it can't be
 obtained,
 there is nothing we can do to make this a platform
   independent zero
 configuration issue as far as I know.

 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 - Original Message -
 From: David Maplesden [EMAIL PROTECTED]
 To: JBossDev (E-mail) 
 [EMAIL PROTECTED]
 Sent: Tuesday, November 13, 2001 4:14 PM
 Subject: RE: [JBoss-dev] RH: tools.jar (javac)...


  No I haven't and I see now what you mean, I didn't read
   what you put
  carefully enough.  Still you might be able to do it
   this way, IIRC we
 used
  to distribute javac in a javac.jar that was distributed
   with JBoss to
  different platforms and it seemed to work OK.
 
  I thought the only reason we weren't distributing tools.jar
in the same
 way
  is because of licensing issues with Sun.
 
  That of course brings up a problem with 1) you can't
   distribute any
 package
  you create that contains tools.jar (I think).
 
  Perhaps the easiest thing to do for the Jetty dist is
   to reference
 tools.jar
  as if it exists in the lib/ext dir and simply include a
   README 

[JBoss-dev] [ jboss-Patches-481803 ] run.jar/run.bat improvements

[noreply]

Patches item #481803, was opened at 2001-11-14 11:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376687aid=481803group_id=22866

Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Ignacio Coloma (alu1344)
Assigned to: Nobody/Anonymous (nobody)
Summary: run.jar/run.bat improvements

Initial Comment:
Modifications for run.bat/run.jar. What comes included:

1.- Support for tools.jar 'a la' Tomcat: you should 
define a JAVA_HOME environment variable that points to 
your java instalation directory. It checks if 
tools.jar is where it should. If not, it doesn't let 
you start JBoss.
2.- Moved all the JAXP env variables into run.jar, 
cleaning the bat file.
3.- Documented into run.bat a bit what's happening.
4.- Included commented lines to start jboss in debug 
mode (JPDA), both by socket and by shared memory. 
There are docs out there about how to connect to an 
already started app. 

Extra work neccesary:

1.- remove lib/jaxp.jar and lib/crimson.jar. This 
crimson library (1.1.1) is old and reported to have 
bugs (not many, anyway). Current version is 1.1.3. 
Bugs were corrected for 1.1.2.
2.- add lib/xerces.jar

I prefer Xerces over crimson. Anyway, it's easy to 
change the patch to keep using crimson.

I have not included an equivalent shell script, but 
should be obvious. The shell script has the extra 
advantage that they can guess the JAVA_HOME directory.

--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376687aid=481803group_id=22866

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

Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[Scott M Stark]

This is the purpose of the Logger.isXXXEnabled() call. Any debugging
that is executed on a per message basis should be a trace level message
that is enclosed inside of a test for that priority level being active. This
allows for enabling tracing with very fine control at runtime and one of
the primary reasons for basing logging on log4j. This incurs a minimal
overhead. The current Logger class is a subclass of the log4j Category
and this will be changed next week, but that will not change the usage
pattern which is as follows:

import org.jboss.logging.Logger;

public abstract class SomeClass
{
   protected Logger log = Logger.create(Some.class or whatever category
name);

   protected void register(EntityEnterpriseContext ctx, Transaction tx)
   {
  boolean trace = log.isTraceEnabled();
  if( trace )
 log.trace(register, ctx=+ctx+, tx=+tx);
   }
}

 The cost of constructing all the message strings, even if they aren't
used,
 can add considerable overhead to the system (if you don't believe me then
 create a test and see).  Remember I managed to get somewhere between a 10
to
 20 times speed improvement by improving the serialisation code and
removing
 these debug statements from inside the inner loop.  If you really, really
 want them then place them behind a static final boolean flag i.e.

 if(DEBUG) log.debug(a message);

 so that we can easily set the flag to false and recompile a higher
 performance version of the engine.  With the static flag set to false the
 compiler removes the line completely, so there is no performance hit at
all.

 Thanks David.




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

RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[David Maplesden]

Thanks, that's good to know.  The amount and level of logging in JBossMQ
needs to be looked at, its not completely hopeless, but its far from
consistent (mainly because of my changes I guess).

 -Original Message-
 From: Scott M Stark [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, November 15, 2001 9:46 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] CVS update:
 jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java
 CacheStoreMBean.java
 
 
 This is the purpose of the Logger.isXXXEnabled() call. Any debugging
 that is executed on a per message basis should be a trace 
 level message
 that is enclosed inside of a test for that priority level 
 being active. This
 allows for enabling tracing with very fine control at runtime 
 and one of
 the primary reasons for basing logging on log4j. This incurs a minimal
 overhead. The current Logger class is a subclass of the log4j Category
 and this will be changed next week, but that will not change the usage
 pattern which is as follows:
 
 import org.jboss.logging.Logger;
 
 public abstract class SomeClass
 {
protected Logger log = Logger.create(Some.class or 
 whatever category
 name);
 
protected void register(EntityEnterpriseContext ctx, 
 Transaction tx)
{
   boolean trace = log.isTraceEnabled();
   if( trace )
  log.trace(register, ctx=+ctx+, tx=+tx);
}
 }
 
  The cost of constructing all the message strings, even if 
 they aren't
 used,
  can add considerable overhead to the system (if you don't 
 believe me then
  create a test and see).  Remember I managed to get 
 somewhere between a 10
 to
  20 times speed improvement by improving the serialisation code and
 removing
  these debug statements from inside the inner loop.  If you 
 really, really
  want them then place them behind a static final boolean flag i.e.
 
  if(DEBUG) log.debug(a message);
 
  so that we can easily set the flag to false and recompile a higher
  performance version of the engine.  With the static flag 
 set to false the
  compiler removes the line completely, so there is no 
 performance hit at
 all.
 
  Thanks David.
 
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 

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

RE: [JBoss-dev] RH: tools.jar (javac)...

[Adam Heath]

On Thu, 15 Nov 2001, David Maplesden wrote:

 You might be jumping the gun a bit with this one.  tools.jar is only needed
 afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp pages.  Not
 everyone will want this, indeed many people will probably run JBoss without
 a servlet engine, and so they won't need tools.jar.

The way I did the packaging for debian, is I made a separate
jboss-tomcat-service.deb, which doesn't always have to be installed, and have
this do the nescessary setup in the init script(/etc/init.d/jboss-server).

Of course, I'm not quite ready to make these available yet(they are still only
alpha quality, and have debian packaging issues that may only be fixable by
someone who knows the internals of debian).


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

RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[Adam Heath]

On Thu, 15 Nov 2001, David Maplesden wrote:

 if(DEBUG) log.debug(a message);

 so that we can easily set the flag to false and recompile a higher
 performance version of the engine.  With the static flag set to false the
 compiler removes the line completely, so there is no performance hit at all.

I doubt this is fully true.  I once did a decompile of a .class(a bad rm
removed the .java), and it gave me mostly functioning code.  However, I can't
recall if there was any use of static finals.

The compiler probably just has a goto that jumps over it.



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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Adam Heath]

On Wed, 14 Nov 2001, Scott M Stark wrote:

 2.4.x is based on the archaic and fragmented build policy from the
 early days of JBoss and its not likely to change(at least by me).
 The build process has been totally reorganized in the main branch for the
 3.0 release so focus on getting a source ball that suits your purpose
 using it.

Ok, I can understand that.

I am reluctant to make debs from something that only exists in cvs(it has been
done before, I just don't want to do it in this case).  Is there an estimate
to when even an alpha might be made available?



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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Scott M Stark]

Next week.

- Original Message -
From: Adam Heath [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 12:55 PM
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...


 On Wed, 14 Nov 2001, Scott M Stark wrote:

  2.4.x is based on the archaic and fragmented build policy from the
  early days of JBoss and its not likely to change(at least by me).
  The build process has been totally reorganized in the main branch for
the
  3.0 release so focus on getting a source ball that suits your purpose
  using it.

 Ok, I can understand that.

 I am reluctant to make debs from something that only exists in cvs(it has
been
 done before, I just don't want to do it in this case).  Is there an
estimate
 to when even an alpha might be made available?





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

RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[Jason Dillon]

 Oh, and if we are talking about performance, I would appreciate everyone
 being very careful about placing debug statements inside any code that is
 executed for every message through the system.  Several of these have been
 introduced with the advent of the message caching and David J's new stuff.
 
 The cost of constructing all the message strings, even if they aren't used,
 can add considerable overhead to the system (if you don't believe me then
 create a test and see).  Remember I managed to get somewhere between a 10 to
 20 times speed improvement by improving the serialisation code and removing
 these debug statements from inside the inner loop.  If you really, really
 want them then place them behind a static final boolean flag i.e.
 
 if(DEBUG) log.debug(a message);

Please don't do this.  Use something more like this:

if (log.isDebugEnabled()) {
   log.debug(some msg);
   log.debug(some other msg);
}

If you are really trying to trim down execution costs and you have lots of 
spread out debugs in a method, then something like this:

boolean debug = log.isDebugEnabled();
// ...
if (debug) {
   log.debug(foo);
}
// ...
if (debug) {
   log.debug(bar);
}

The cost of this is minor and allows for dynamic contol over the processing 
of these log messages.

--jason


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

RE: [JBoss-dev] Separating JMX/EJB

[Dain Sundstrom]

I couldn't agree more.

When I first started reading the code, It was hard to sperate the EJB
sepecific stuff from the rest. I think this will help up out alot.

-dain

 -Original Message-
 From: marc fleury [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 14, 2001 11:21 AM
 To: Jboss-Development@Lists. Sourceforge. Net
 Subject: [JBoss-dev] Separating JMX/EJB
 
 
 kids,
 
 we are hearing a lot of talk about EJB and not EJB and blabla 
 bla.  Well I
 will say that I am a big fan of the framework, for reasons 
 that even our
 favorite aliens are missing ;-) but that is another thread.
 
 The reason I want EJB to take a backseat in the LAYOUT OF 
 THE CODE is that
 I believe we need to separate what is spec derived, spec 
 dependent and what
 is good software in general.  Most notably there are very 
 large project
 out there (Las Vegas IGT for example) that at first were 
 using the JMX base
 and management of JBoss to build complex systems and the RH 
 JBoss3.0 view is
 clearly targeted at these folks, large ISV shops using JBoss 
 in high end
 complex applications.  The JMX view and what we do with it, 
 needs to be
 clearly expressed as independent of the EJB spec. Interceptors and the
 packaging/distribution that we do, the microkernel view, all that is
 knowledge that is not EJB specific.
 
 Right now everythign seems to be under org/jboss/ejb and
 org/jboss/ejb/plugins when really we are largely BEYOND the 
 ejb spec and it
 applies to a wider and more generic category of problems than 
 just EJB.  In
 fact I am starting to suspect that the EJB part of our code, 
 the really
 dependent part is 20% of the total code today.  Which is really
 negligeable.  The smart ones in you will see where I am going 
 with this.  If
 not you will see.
 
 BOTTOM LINE: I want you guys to start wiring what is not EJB 
 specific into
 more generic packages. Ex: the Invocation I just commited, the
 MethodINvocation should be outside it is just dependent on the
 EnterpriseContext and teh EC is just a wrapper for instances 
 in Cache.  what
 is really EJB dependent should at the end of the day be seen 
 in the imports
 at once and it should be factored out.  Meaning if it isn't 
 dependent on the
 spec but derived from largely known computing practices (heck 
 the state
 machine view of JMX was first put forth by Alan Turing :)
 
 Again, this is not a reflexion on the value of EJB, I will 
 start seriously
 evangelizing my love of EJB as system construct which is 
 something I cover
 in the trainings already, JMX is just generic and independent 
 of this, the
 microkernel view is generic and independent, the packaging we 
 do is generic
 and independent...
 
 You get it.
 
 marcf
 
 
 Marc Fleury
 President
 JBoss Group, LLC
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 

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

RE: [JBoss-dev] Invocation and MethodInvocation

[Dain Sundstrom]

This is great.

This is what I wanted to do when I wrote my message passing hack.  I think
one problem is the current interceptors will be expecting a Method object,
so when they are changed to handle an Invocation with out a Method object, I
will definitely switch over.

-dain

 -Original Message-
 From: marc fleury [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 14, 2001 11:44 AM
 To: marc fleury; Jboss-Development@Lists. Sourceforge. Net
 Subject: RE: [JBoss-dev] Invocation and MethodInvocation
 
 
 wowowo,
 
 I realize I forgot to say what this is good for :)
 
 you can now attach ANY PAYLOAD to an invocation, not just the stuff
 generated at the client, so that you can pass information 
 down the chain,
 have interceptors talking to each other and pass arbitrary 
 data around the
 JMX base, VERY VERY VERY useful for your custom advanced interceptors.
 
 (was it the motorola kids in the Las Vegas training that 
 mentioned they
 needed this?)
 
 marcf
 
 |-Original Message-
 |From: [EMAIL PROTECTED]
 |[mailto:[EMAIL PROTECTED]]On 
 Behalf Of marc
 |fleury
 |Sent: Wednesday, November 14, 2001 12:08 PM
 |To: Jboss-Development@Lists. Sourceforge. Net
 |Subject: [JBoss-dev] Invocation and MethodInvocation
 |
 |
 |Ok,
 |
 |[FOR RECORD, ARCH CHANGE]
 |
 |we discussed some time ago the possible extension of the 
 MethodInvocation
 |to be a more generic and powerful entity.
 |
 |Basically I have added the invocation directory and the 
 Invocation.java, as
 |well as changed the MethodInvocation.
 |
 |The 10,000 ft is that the new RH JMX view puts the mbeans in 
 front.  The
 |entity that travels inside our JMX bus is the Invocation 
 that I just
 |introduced.  The invocation basically takes the transaction 
 and security
 |information as its basis.  You are always doing stuff as part of
 |transaction
 |context (maybe empty meaning no transaction) and as someone 
 authenticated
 |(if you set it up) but these are the building blocks.  Then 
 everything else
 |is in a payload of possibly serialized byte[] data that we 
 can carry
 |around as such (avoiding cl madness).  We extend this for the
 |methodinvocation which is more EJB'ish in that it knows about the
 |EnterpriseContext (more on that later).
 |
 |The other new thing in there is the presence of the mbean 
 list of objects
 |this Invocation is supposed to go through.  It will identify 
 the MBean
 |interface of the Container for the EJBs, thereby really 
 finalizing the
 |detaching of the invokers from the invocation, both from the 
 bus (which is
 |already done) and the rmi impl (to be done next).
 |
 |The Invocation is not using the mbean list as yet, but 
 possibly will, since
 |what would come next is a self standing invocation in our 
 JMX base, going
 |through the bus from mbean to mbean, which would really give 
 us a possibly
 |dynamic way of maintaining the path that our invocation 
 takes in the base.
 |The stuff is there, will use a little bit to hook up the EJB 
 container, we
 |will see.
 |
 |I will also probably don't externalize the interceptors as 
 yet, no good
 |reason except it would be less disruptive a view from what 
 we have now and
 |it would be lindfors recommendation.
 |
 |I was going to talk about the EnterpriseContext thing but 
 this is already
 |a long mail. I will do so in a forthcoming email.
 |
 |Finally I will say that for legacy reasons I have kept the 
 old constructors
 |and allowed the Invocation to carry no MBean association.  
 The 2 legacy are
 |1- the invocation chain is not fully generic yet, it knows 
 the target, this
 |is detached already (going JMX bus) but will move next 2- the CMR
 |stuff from
 |Dain that uses the invocation chain to invoke stuff on 
 itself, this assumes
 |that you know the container (which it does) and calls it 
 directly (which it
 |does) withouth the intermission of the JMX bus (which is 
 ok), so this is
 |likely to remain as is for now. Moving it to the bus would 
 be trivial but
 |not a priority right now.
 |
 |The testsuite testbean runs fine afaict, so this should not 
 disrupt the
 |existing RH codebase, fully backward compatible (again afaict)
 |
 |just warming up
 |
 |marcf
 |
 |Marc Fleury
 |President
 |JBoss Group, LLC
 |
 |
 |
 |___
 |Jboss-development mailing list
 |[EMAIL PROTECTED]
 |https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 

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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Adam Heath]

On Wed, 14 Nov 2001, Scott M Stark wrote:

 Next week.

Ooh!  I can't wait.


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

Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[Scott M Stark]

In general the logging in Main is way overboard as not everyone is upto
speed with the trace level logging support. This is the first thing I will
address when I get back to working on Main next week.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: David Maplesden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 12:52 PM
Subject: RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file
CacheStore.java CacheStoreMBean.java


 Thanks, that's good to know.  The amount and level of logging in JBossMQ
 needs to be looked at, its not completely hopeless, but its far from
 consistent (mainly because of my changes I guess).

  -Original Message-
  From: Scott M Stark [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, November 15, 2001 9:46 AM
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] CVS update:
  jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java
  CacheStoreMBean.java
 
 
  This is the purpose of the Logger.isXXXEnabled() call. Any debugging
  that is executed on a per message basis should be a trace
  level message
  that is enclosed inside of a test for that priority level
  being active. This
  allows for enabling tracing with very fine control at runtime
  and one of
  the primary reasons for basing logging on log4j. This incurs a minimal
  overhead. The current Logger class is a subclass of the log4j Category
  and this will be changed next week, but that will not change the usage
  pattern which is as follows:
 
  import org.jboss.logging.Logger;
 
  public abstract class SomeClass
  {
 protected Logger log = Logger.create(Some.class or
  whatever category
  name);
 
 protected void register(EntityEnterpriseContext ctx,
  Transaction tx)
 {
boolean trace = log.isTraceEnabled();
if( trace )
   log.trace(register, ctx=+ctx+, tx=+tx);
 }
  }
 



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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Jason Dillon]

Can we automate .deb building with the new build system?

--jason


On Wed, 14 Nov 2001, Adam Heath wrote:

 On Wed, 14 Nov 2001, Scott M Stark wrote:
 
  2.4.x is based on the archaic and fragmented build policy from the
  early days of JBoss and its not likely to change(at least by me).
  The build process has been totally reorganized in the main branch for the
  3.0 release so focus on getting a source ball that suits your purpose
  using it.
 
 Ok, I can understand that.
 
 I am reluctant to make debs from something that only exists in cvs(it has been
 done before, I just don't want to do it in this case).  Is there an estimate
 to when even an alpha might be made available?
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


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

Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[David Jencks]

Oops, did you remove the excess debug statements I put in or can you point
a bit to where they might be? I'm not at all sure I could recognize such
places..

David Jencks

On 2001.11.14 14:56:29 -0500 David Maplesden wrote:
 Looks good Hiram,
 
 Can I make one suggestion.  When I was profiling and improving JBossMQ's
 performance I implemented a couple of static methods
 SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of
 the
 standard writeObject and readObject methods.  I think you should use them
 here.
 
 They work fine, you get back exactly the same object you write out, and
 they
 are used by all the persistence and communication mechanisms currently
 because they are many times quicker than the standard object
 serialization
 (which is horribly slow).
 
 Oh, and if we are talking about performance, I would appreciate everyone
 being very careful about placing debug statements inside any code that is
 executed for every message through the system.  Several of these have
 been
 introduced with the advent of the message caching and David J's new
 stuff.
 
 The cost of constructing all the message strings, even if they aren't
 used,
 can add considerable overhead to the system (if you don't believe me then
 create a test and see).  Remember I managed to get somewhere between a 10
 to
 20 times speed improvement by improving the serialisation code and
 removing
 these debug statements from inside the inner loop.  If you really, really
 want them then place them behind a static final boolean flag i.e.
 
 if(DEBUG) log.debug(a message);
  
 so that we can easily set the flag to false and recompile a higher
 performance version of the engine.  With the static flag set to false the
 compiler removes the line completely, so there is no performance hit at
 all.
 
 Thanks David.
 
  -Original Message-
  From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, November 14, 2001 5:24 PM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file
  CacheStore.java CacheStoreMBean.java
  
  
User: chirino 
Date: 01/11/13 20:24:08
  
Added:   src/main/org/jboss/mq/pm/file CacheStore.java
  CacheStoreMBean.java
Log:
Factored out a CacheStore object from the message store.  
  This should lay the
ground work needed so that the MessageCache can use a PM 
  for saving and loading
messages.

Also fixed a small bug in the file PM.  It was not properly 
  restoring the message
after a server restart.

Revision  ChangesPath
1.1  
  jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java

Index: CacheStore.java
===
/*
 * JBoss, the OpenSource J2EE webOS
 *
 * Distributable under LGPL license.
 * See terms of license at gnu.org.
 */
package org.jboss.mq.pm.file;

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

import javax.jms.JMSException;
import org.jboss.mq.SpyJMSException;
import org.jboss.mq.SpyMessage;
import org.jboss.mq.server.MessageReference;
import org.jboss.system.ServiceMBeanSupport;

/**
 *  This class manages the persistence needs of the MessageCache
 *
 * @author Hiram Chirino 
 * @version$Revision: 1.1 $
 */
public class CacheStore extends ServiceMBeanSupport 
  implements org.jboss.mq.pm.CacheStore, CacheStoreMBean {
   String dataDirectory;
   File dataFile;

   /**
* @see ServiceMBeanSupport#getName()
*/
   public String getName() {
  return JBossMQ-CacheStore;
   }

   /**
* @see CacheStore#loadFromStorage(MessageReference)
*/
   public SpyMessage loadFromStorage(MessageReference mh) 
  throws JMSException {
  try {
 File f = new File(dataFile, Message- + mh.referenceId);
 ObjectInputStream is = new ObjectInputStream(new 
  BufferedInputStream(new FileInputStream(f)));
 Object rc = is.readObject();
 is.close();
 return (SpyMessage) rc;
  } catch (ClassNotFoundException e) {
 throw new SpyJMSException(Could not load message 
  from secondary storage: , e);
  } catch (IOException e) {
 throw new SpyJMSException(Could not load message 
  from secondary storage: , e);
  }
   }

   /**
* @see CacheStore#saveToStorage(MessageReference, SpyMessage)
*/
   public void saveToStorage(MessageReference mh, 
  SpyMessage message) throws JMSException {
  try {
 File f = new File(dataFile, Message- + 

Re: [JBoss-dev] RH: tools.jar (javac)...

[Adam Heath]

yOn Wed, 14 Nov 2001, Jason Dillon wrote:

 Can we automate .deb building with the new build system?

Possibly.  The whole point of debian is automation.  We have lots of build
daemons setup(for all the architectures we support), that demand this sort of
feature.

I have just checked out the cvs stuff, and perusing it now.  I'm thinking of
redoing how I did the debification.


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

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|-Original Message-
|From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
|Sent: Wednesday, November 14, 2001 4:13 PM
|To: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|
|
|This is great.
|
|This is what I wanted to do when I wrote my message passing
|hack.  I think
|one problem is the current interceptors will be expecting a Method object,
|so when they are changed to handle an Invocation with out a Method
|object, I
|will definitely switch over.

it is already done, the new MI walking down supports the addvalue and
getvalue... go ahead use it!

marcf

|
|-dain
|
| -Original Message-
| From: marc fleury [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, November 14, 2001 11:44 AM
| To: marc fleury; Jboss-Development@Lists. Sourceforge. Net
| Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|
|
| wowowo,
|
| I realize I forgot to say what this is good for :)
|
| you can now attach ANY PAYLOAD to an invocation, not just the stuff
| generated at the client, so that you can pass information
| down the chain,
| have interceptors talking to each other and pass arbitrary
| data around the
| JMX base, VERY VERY VERY useful for your custom advanced interceptors.
|
| (was it the motorola kids in the Las Vegas training that
| mentioned they
| needed this?)
|
| marcf
|
| |-Original Message-
| |From: [EMAIL PROTECTED]
| |[mailto:[EMAIL PROTECTED]]On
| Behalf Of marc
| |fleury
| |Sent: Wednesday, November 14, 2001 12:08 PM
| |To: Jboss-Development@Lists. Sourceforge. Net
| |Subject: [JBoss-dev] Invocation and MethodInvocation
| |
| |
| |Ok,
| |
| |[FOR RECORD, ARCH CHANGE]
| |
| |we discussed some time ago the possible extension of the
| MethodInvocation
| |to be a more generic and powerful entity.
| |
| |Basically I have added the invocation directory and the
| Invocation.java, as
| |well as changed the MethodInvocation.
| |
| |The 10,000 ft is that the new RH JMX view puts the mbeans in
| front.  The
| |entity that travels inside our JMX bus is the Invocation
| that I just
| |introduced.  The invocation basically takes the transaction
| and security
| |information as its basis.  You are always doing stuff as part of
| |transaction
| |context (maybe empty meaning no transaction) and as someone
| authenticated
| |(if you set it up) but these are the building blocks.  Then
| everything else
| |is in a payload of possibly serialized byte[] data that we
| can carry
| |around as such (avoiding cl madness).  We extend this for the
| |methodinvocation which is more EJB'ish in that it knows about the
| |EnterpriseContext (more on that later).
| |
| |The other new thing in there is the presence of the mbean
| list of objects
| |this Invocation is supposed to go through.  It will identify
| the MBean
| |interface of the Container for the EJBs, thereby really
| finalizing the
| |detaching of the invokers from the invocation, both from the
| bus (which is
| |already done) and the rmi impl (to be done next).
| |
| |The Invocation is not using the mbean list as yet, but
| possibly will, since
| |what would come next is a self standing invocation in our
| JMX base, going
| |through the bus from mbean to mbean, which would really give
| us a possibly
| |dynamic way of maintaining the path that our invocation
| takes in the base.
| |The stuff is there, will use a little bit to hook up the EJB
| container, we
| |will see.
| |
| |I will also probably don't externalize the interceptors as
| yet, no good
| |reason except it would be less disruptive a view from what
| we have now and
| |it would be lindfors recommendation.
| |
| |I was going to talk about the EnterpriseContext thing but
| this is already
| |a long mail. I will do so in a forthcoming email.
| |
| |Finally I will say that for legacy reasons I have kept the
| old constructors
| |and allowed the Invocation to carry no MBean association.
| The 2 legacy are
| |1- the invocation chain is not fully generic yet, it knows
| the target, this
| |is detached already (going JMX bus) but will move next 2- the CMR
| |stuff from
| |Dain that uses the invocation chain to invoke stuff on
| itself, this assumes
| |that you know the container (which it does) and calls it
| directly (which it
| |does) withouth the intermission of the JMX bus (which is
| ok), so this is
| |likely to remain as is for now. Moving it to the bus would
| be trivial but
| |not a priority right now.
| |
| |The testsuite testbean runs fine afaict, so this should not
| disrupt the
| |existing RH codebase, fully backward compatible (again afaict)
| |
| |just warming up
| |
| |marcf
| |
| |Marc Fleury
| |President
| |JBoss Group, LLC
| |
| |
| |
| |___
| |Jboss-development mailing list
| |[EMAIL PROTECTED]
| |https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
| ___
| Jboss-development mailing 

RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java

[David Maplesden]

I haven't removed any debug statements since I did my initial big
contribution some months ago, I thought people might be using them trying to
track down a particular bug.

Now that we are so close to 3.0 coming out I thought I would mention it in
passing so people where aware of the performance hit they impose, of course
all we need to do is change them from log.debug() to
if(log.isTraceEnabled()) log.trace() and we should be fine.

The critical parts of the code are the areas that get executed for every
message under normal conditions, anything to do with the basic send,
receive, commit methods + the corresponding areas of the various PM's and
now the message cache.

I don't think many of the changes you have made recently have really been in
these areas so you are probably fine.  One off things like the restore
method and initialisation stuff we can log as much as we like.

David

 -Original Message-
 From: David Jencks [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, November 15, 2001 10:30 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] CVS update:
 jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java
 CacheStoreMBean.java
 
 
 Oops, did you remove the excess debug statements I put in or 
 can you point
 a bit to where they might be? I'm not at all sure I could 
 recognize such
 places..
 
 David Jencks
 
 On 2001.11.14 14:56:29 -0500 David Maplesden wrote:
  Looks good Hiram,
  
  Can I make one suggestion.  When I was profiling and 
 improving JBossMQ's
  performance I implemented a couple of static methods
  SpyMessage.writeMessage() and SpyMessage.readMessage() to 
 use instead of
  the
  standard writeObject and readObject methods.  I think you 
 should use them
  here.
  
  They work fine, you get back exactly the same object you 
 write out, and
  they
  are used by all the persistence and communication 
 mechanisms currently
  because they are many times quicker than the standard object
  serialization
  (which is horribly slow).
  
  Oh, and if we are talking about performance, I would 
 appreciate everyone
  being very careful about placing debug statements inside 
 any code that is
  executed for every message through the system.  Several of 
 these have
  been
  introduced with the advent of the message caching and David J's new
  stuff.
  
  The cost of constructing all the message strings, even if 
 they aren't
  used,
  can add considerable overhead to the system (if you don't 
 believe me then
  create a test and see).  Remember I managed to get 
 somewhere between a 10
  to
  20 times speed improvement by improving the serialisation code and
  removing
  these debug statements from inside the inner loop.  If you 
 really, really
  want them then place them behind a static final boolean flag i.e.
  
  if(DEBUG) log.debug(a message);
   
  so that we can easily set the flag to false and recompile a higher
  performance version of the engine.  With the static flag 
 set to false the
  compiler removes the line completely, so there is no 
 performance hit at
  all.
  
  Thanks David.
  
   -Original Message-
   From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
   Sent: Wednesday, November 14, 2001 5:24 PM
   To: [EMAIL PROTECTED]
   Subject: [JBoss-dev] CVS update: 
 jbossmq/src/main/org/jboss/mq/pm/file
   CacheStore.java CacheStoreMBean.java
   
   
 User: chirino 
 Date: 01/11/13 20:24:08
   
 Added:   src/main/org/jboss/mq/pm/file CacheStore.java
   CacheStoreMBean.java
 Log:
 Factored out a CacheStore object from the message store.  
   This should lay the
 ground work needed so that the MessageCache can use a PM 
   for saving and loading
 messages.
 
 Also fixed a small bug in the file PM.  It was not properly 
   restoring the message
 after a server restart.
 
 Revision  ChangesPath
 1.1  
   jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
 
 Index: CacheStore.java
 
 ===
 /*
  * JBoss, the OpenSource J2EE webOS
  *
  * Distributable under LGPL license.
  * See terms of license at gnu.org.
  */
 package org.jboss.mq.pm.file;
 
 import java.io.BufferedInputStream;
 import java.io.BufferedOutputStream;
 import java.io.File;
 import java.io.FileInputStream;
 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.ObjectInputStream;
 import java.io.ObjectOutputStream;
 
 import javax.jms.JMSException;
 import org.jboss.mq.SpyJMSException;
 import org.jboss.mq.SpyMessage;
 import org.jboss.mq.server.MessageReference;
 import org.jboss.system.ServiceMBeanSupport;
 
 /**
  *  This class manages the persistence needs of the MessageCache
  *
  * @author Hiram Chirino 
  * @version$Revision: 1.1 $
  */
 public class CacheStore extends 

[JBoss-dev] can't build jboss from cvs

[Adam Heath]

adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
Buildfile: build.xml
  [taskdef] Could not load definitions from resource 
planet57/tools/buildmagic/task/autoload.properties. It could not be found.

BUILD FAILED

/home/adam/brainfood/jboss/cvs/jboss/build.xml:23: taskdef class 
planet57.tools.buildmagic.task.Property cannot be found

Total time: 2 seconds

Where does the planet57 stuff come from?  The following  url looks
interesting, but since it's in the Attic, I doubt it has the correct data.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/thirdparty/planet57/buildmagic/lib/Attic/


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

[JBoss-dev] MBean init/start change broke CMR

[Dain Sundstrom]

Hi all,

I think that the merging of init and start has broken the CMR code.  The CMR
code depends on having a complete two-phase startup.  In the phase 1 (init)
all of the relation ships are connected, and in phase 2 (start) these
relationships are used to create the entity tables with fks, relation
tables, and parse ejb-ql queries.  I think that merging the two has changed
the system to call init and then start for each bean instead of init for
each bean and then start for each bean.

I wasn't following the discussion about this, because I didn't think it
applied to the CMR code (and the messages were very long).  I'm going to go
back and read the messages, but if anyone has a suggestion or can tell me
the resolution, I would appreciate it.

-dain

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

Re: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

yOn Wed, 14 Nov 2001, Adam Heath wrote:

 adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
 Buildfile: build.xml
   [taskdef] Could not load definitions from resource 
planet57/tools/buildmagic/task/autoload.properties. It could not be found.

 BUILD FAILED

 /home/adam/brainfood/jboss/cvs/jboss/build.xml:23: taskdef class 
planet57.tools.buildmagic.task.Property cannot be found

 Total time: 2 seconds

 Where does the planet57 stuff come from?  The following  url looks
 interesting, but since it's in the Attic, I doubt it has the correct data.

Er, nevermind.  Found it, got it compiled.  I guess I'll have to make a deb of
planet57 stuff as well.


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

RE: [JBoss-dev] MBean init/start change broke CMR

[marc fleury]

Ok look,

the invoker stuff also depends on a init/start, I think that init/start
isn't really an important thing to clean at this point (but I could be
wrong, I have been proven wrong in the past).

I didn't really fully follow the discussion either but can we put it back
for the time being.

We can clean down the road (if possible)

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
|Sundstrom
|Sent: Wednesday, November 14, 2001 5:12 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] MBean init/start change broke CMR
|
|
|Hi all,
|
|I think that the merging of init and start has broken the CMR
|code.  The CMR
|code depends on having a complete two-phase startup.  In the phase 1 (init)
|all of the relation ships are connected, and in phase 2 (start) these
|relationships are used to create the entity tables with fks, relation
|tables, and parse ejb-ql queries.  I think that merging the two has changed
|the system to call init and then start for each bean instead of init for
|each bean and then start for each bean.
|
|I wasn't following the discussion about this, because I didn't think it
|applied to the CMR code (and the messages were very long).  I'm going to go
|back and read the messages, but if anyone has a suggestion or can tell me
|the resolution, I would appreciate it.
|
|-dain
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


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

RE: [JBoss-dev] MBean init/start change broke CMR

[Dain Sundstrom]

I read the mail on the problems with clustering, and I didn't see any thing
will help me.  Here is what I need for the CMR code:

ejb1.init();
ejb2.init();
ejb3.init();
ejb4.init();

ejb1.start();
ejb2.start();
ejb3.start();
ejb4.start();

but I am getting is:

ejb1.init();
ejb1.start();

ejb2.init();
ejb2.start();

ejb3.init();
ejb3.start();

ejb4.init();
ejb4.start();

-dain
 -Original Message-
 From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 14, 2001 4:12 PM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] MBean init/start change broke CMR
 
 
 Hi all,
 
 I think that the merging of init and start has broken the CMR 
 code.  The CMR
 code depends on having a complete two-phase startup.  In the 
 phase 1 (init)
 all of the relation ships are connected, and in phase 2 (start) these
 relationships are used to create the entity tables with fks, relation
 tables, and parse ejb-ql queries.  I think that merging the 
 two has changed
 the system to call init and then start for each bean instead 
 of init for
 each bean and then start for each bean.
 
 I wasn't following the discussion about this, because I 
 didn't think it
 applied to the CMR code (and the messages were very long).  
 I'm going to go
 back and read the messages, but if anyone has a suggestion or 
 can tell me
 the resolution, I would appreciate it.
 
 -dain
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 

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

RE: [JBoss-dev] MBean init/start change broke CMR

[Bill Burke]

I think this makes a case for rolling back to the 2 phase initialization
since clustering has the same problem.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
 Sundstrom
 Sent: Wednesday, November 14, 2001 5:12 PM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] MBean init/start change broke CMR


 Hi all,

 I think that the merging of init and start has broken the CMR
 code.  The CMR
 code depends on having a complete two-phase startup.  In the
 phase 1 (init)
 all of the relation ships are connected, and in phase 2 (start) these
 relationships are used to create the entity tables with fks, relation
 tables, and parse ejb-ql queries.  I think that merging the two
 has changed
 the system to call init and then start for each bean instead of init for
 each bean and then start for each bean.

 I wasn't following the discussion about this, because I didn't think it
 applied to the CMR code (and the messages were very long).  I'm
 going to go
 back and read the messages, but if anyone has a suggestion or can tell me
 the resolution, I would appreciate it.

 -dain

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




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

Re: [JBoss-dev] MBean init/start change broke CMR

[David Jencks]

On 2001.11.14 17:11:52 -0500 Dain Sundstrom wrote:
 Hi all,
 
 I think that the merging of init and start has broken the CMR code.  The
 CMR
 code depends on having a complete two-phase startup.  In the phase 1
 (init)
 all of the relation ships are connected, and in phase 2 (start) these
 relationships are used to create the entity tables with fks, relation
 tables, and parse ejb-ql queries.  I think that merging the two has
 changed
 the system to call init and then start for each bean instead of init for
 each bean and then start for each bean.

This is correct.
 
 I wasn't following the discussion about this, because I didn't think it
 applied to the CMR code (and the messages were very long). 

The first one wasn't, asking if it would break anything.

 I'm going to
 go
 back and read the messages, but if anyone has a suggestion or can tell me
 the resolution, I would appreciate it.

How can I tell if it is broken? Is there a test case?  What are the beans
you mention, mbeans from a *service.xml or ejbs or generated mbeans from
ContainerFactory or what? What is calling the init and start?  I might
simply have done something stupid in ContainerFactory.

If the problem is due to unexpressed dependencies between mbeans, generally
the solution is to explicitly state those dependencies using mbean-ref and
mbean-ref-list elements.

For instance, if you have mbeans A and B that registered with C on init,
and C did something with A and B in its start, put a mbean-ref-list element
in C containing A and B's object names: in C's start, first iterate through
the list, calling the new registerWithC(C) method (formerly init()), and
then the previous start code.

I'm happy to help with fixing this if you can give me some clues about what
is going on and where.

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

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

RE: [JBoss-dev] MBean init/start change broke CMR

[Dain Sundstrom]

I don't really understand the MBean deployment ref stuff, but I'll comment
on it anyway :)

I think we need some sort of concept of a deployment unit, in my case an
ejb-jar.  After reading the discussion on this change, I think I understand
the reason for the change.  The problem is that we can't use a declared
dependancy system, because the entity dependance information is in the
ejb-jar.xml file. 

I could be easly wrong.

-dain


 -Original Message-
 From: Bill Burke [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 14, 2001 4:56 PM
 To: Dain Sundstrom; [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] MBean init/start change broke CMR
 
 
 I think this makes a case for rolling back to the 2 phase 
 initialization
 since clustering has the same problem.
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On 
 Behalf Of Dain
  Sundstrom
  Sent: Wednesday, November 14, 2001 5:12 PM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-dev] MBean init/start change broke CMR
 
 
  Hi all,
 
  I think that the merging of init and start has broken the CMR
  code.  The CMR
  code depends on having a complete two-phase startup.  In the
  phase 1 (init)
  all of the relation ships are connected, and in phase 2 
 (start) these
  relationships are used to create the entity tables with 
 fks, relation
  tables, and parse ejb-ql queries.  I think that merging the two
  has changed
  the system to call init and then start for each bean 
 instead of init for
  each bean and then start for each bean.
 
  I wasn't following the discussion about this, because I 
 didn't think it
  applied to the CMR code (and the messages were very long).  I'm
  going to go
  back and read the messages, but if anyone has a suggestion 
 or can tell me
  the resolution, I would appreciate it.
 
  -dain
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 

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

Re: [JBoss-dev] MBean init/start change broke CMR

[David Jencks]

As I have pointed out repeatedly in the past few days it is not possible to
have non-trivial mbean init-start with mbean-ref style dependencies,
whereas it is pretty easy to fix these problems by explicitly noting the
dependencies.

Note that the stuff I did only applies to mbeans: I did not remove the
init/destroy from the Service interface because it was being used so
heavily by the invokers, which are not currently mbeans as far as I can
tell.  I think that the ContainerFactory is still calling init and start on
the interceptors (now both from the start() method), although it is
possible I messed up the order.  I suspect very little in the test suite
would have worked if the interceptor setup was broken.

david jencks

On 2001.11.14 17:48:03 -0500 marc fleury wrote:
 Ok look,
 
 the invoker stuff also depends on a init/start, I think that init/start
 isn't really an important thing to clean at this point (but I could be
 wrong, I have been proven wrong in the past).
 
 I didn't really fully follow the discussion either but can we put it back
 for the time being.
 
 We can clean down the road (if possible)
 
 marcf
 
 |-Original Message-
 |From: [EMAIL PROTECTED]
 |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
 |Sundstrom
 |Sent: Wednesday, November 14, 2001 5:12 PM
 |To: [EMAIL PROTECTED]
 |Subject: [JBoss-dev] MBean init/start change broke CMR
 |
 |
 |Hi all,
 |
 |I think that the merging of init and start has broken the CMR
 |code.  The CMR
 |code depends on having a complete two-phase startup.  In the phase 1
 (init)
 |all of the relation ships are connected, and in phase 2 (start) these
 |relationships are used to create the entity tables with fks, relation
 |tables, and parse ejb-ql queries.  I think that merging the two has
 changed
 |the system to call init and then start for each bean instead of init for
 |each bean and then start for each bean.
 |
 |I wasn't following the discussion about this, because I didn't think it
 |applied to the CMR code (and the messages were very long).  I'm going to
 go
 |back and read the messages, but if anyone has a suggestion or can tell
 me
 |the resolution, I would appreciate it.
 |
 |-dain
 |
 |___
 |Jboss-development mailing list
 |[EMAIL PROTECTED]
 |https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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

RE: [JBoss-dev] MBean init/start change broke CMR

[marc fleury]

Don't worry about it, I am actually looking at the SAR dependency stuff and
that is really cool stuff.  I really like it.  So we will need to find a way
to solve the problem down the road.

Don't worry about it for now, some other time, leave the init()/start() as
we are building the functionality.

Once it is stable we will deal with the complex dependency cases, but don't
worry about it for right now.

FYI I am actually rewritting the invokers as we speak, it is simpler, but I
still need more time and yes, you are correct they are MBeans in the new
version :) you will be able to deploy an invoker to the JMX node by simply
dropping the xml/sar in the deploy and voila it will be JMX manageable and
what not. The same beans will be invocable with any new invoker you add (say
.net style etc etc).

p... one thing at a time, professor, one thing at a time...

We are already juggling 20 balls,

marcf

|-Original Message-
|From: David Jencks [mailto:[EMAIL PROTECTED]]
|Sent: Wednesday, November 14, 2001 6:12 PM
|To: marc fleury
|Cc: Dain Sundstrom; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] MBean init/start change broke CMR
|
|
|As I have pointed out repeatedly in the past few days it is not possible to
|have non-trivial mbean init-start with mbean-ref style dependencies,
|whereas it is pretty easy to fix these problems by explicitly noting the
|dependencies.
|
|Note that the stuff I did only applies to mbeans: I did not remove the
|init/destroy from the Service interface because it was being used so
|heavily by the invokers, which are not currently mbeans as far as I can
|tell.  I think that the ContainerFactory is still calling init and start on
|the interceptors (now both from the start() method), although it is
|possible I messed up the order.  I suspect very little in the test suite
|would have worked if the interceptor setup was broken.
|
|david jencks
|
|On 2001.11.14 17:48:03 -0500 marc fleury wrote:
| Ok look,
|
| the invoker stuff also depends on a init/start, I think that init/start
| isn't really an important thing to clean at this point (but I could be
| wrong, I have been proven wrong in the past).
|
| I didn't really fully follow the discussion either but can we put it back
| for the time being.
|
| We can clean down the road (if possible)
|
| marcf
|
| |-Original Message-
| |From: [EMAIL PROTECTED]
| |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
| |Sundstrom
| |Sent: Wednesday, November 14, 2001 5:12 PM
| |To: [EMAIL PROTECTED]
| |Subject: [JBoss-dev] MBean init/start change broke CMR
| |
| |
| |Hi all,
| |
| |I think that the merging of init and start has broken the CMR
| |code.  The CMR
| |code depends on having a complete two-phase startup.  In the phase 1
| (init)
| |all of the relation ships are connected, and in phase 2 (start) these
| |relationships are used to create the entity tables with fks, relation
| |tables, and parse ejb-ql queries.  I think that merging the two has
| changed
| |the system to call init and then start for each bean instead of init for
| |each bean and then start for each bean.
| |
| |I wasn't following the discussion about this, because I didn't think it
| |applied to the CMR code (and the messages were very long).  I'm going to
| go
| |back and read the messages, but if anyone has a suggestion or can tell
| me
| |the resolution, I would appreciate it.
| |
| |-dain
| |
| |___
| |Jboss-development mailing list
| |[EMAIL PROTECTED]
| |https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|


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

RE: [JBoss-dev] MBean init/start change broke CMR

[Dain Sundstrom]

 -Original Message-
 From: David Jencks [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 14, 2001 4:58 PM
 To: Dain Sundstrom
 Cc: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] MBean init/start change broke CMR
 
 
 On 2001.11.14 17:11:52 -0500 Dain Sundstrom wrote:
  Hi all,
  
  I think that the merging of init and start has broken the 
 CMR code.  The
  CMR
  code depends on having a complete two-phase startup.  In the phase 1
  (init)
  all of the relation ships are connected, and in phase 2 
 (start) these
  relationships are used to create the entity tables with 
 fks, relation
  tables, and parse ejb-ql queries.  I think that merging the two has
  changed
  the system to call init and then start for each bean 
 instead of init for
  each bean and then start for each bean.
 
 This is correct.

Yep, I added some code to verify the order.  I am getting:
ejb1.init();
ejb1.start();

ejb2.init();
ejb2.start();

ejb3.init();
ejb3.start();

ejb4.init();
ejb4.start();

  
  I wasn't following the discussion about this, because I 
 didn't think it
  applied to the CMR code (and the messages were very long). 
 
 The first one wasn't, asking if it would break anything.

I know, but I thought the ejb-jar was one unit.  So the order wouldn't
change.

  I'm going to
  go
  back and read the messages, but if anyone has a suggestion 
 or can tell me
  the resolution, I would appreciate it.
 
 How can I tell if it is broken? Is there a test case?  

I know. There are test cases. I just haven't added them to the source tree.
 
 What are the beans
 you mention, mbeans from a *service.xml or ejbs or generated 
 mbeans from
 ContainerFactory or what? What is calling the init and start?  I might
 simply have done something stupid in ContainerFactory.

I am talking about ejbs.  And the container init() and start methods, which
are passed through to my JDBCStoreManager class.

 If the problem is due to unexpressed dependencies between 
 mbeans, generally
 the solution is to explicitly state those dependencies using 
 mbean-ref and
 mbean-ref-list elements.

It is an expressed dependency between entities, but it is expressed in the
ejb-jar.xml file.

 For instance, if you have mbeans A and B that registered with 
 C on init,
 and C did something with A and B in its start, put a 
 mbean-ref-list element
 in C containing A and B's object names: in C's start, first 
 iterate through
 the list, calling the new registerWithC(C) method (formerly 
 init()), and
 then the previous start code.

I don't have that level of control all the way down at the StoreManager.

 I'm happy to help with fixing this if you can give me some 
 clues about what
 is going on and where.

 Thanks
 david jencks

I still putting all the pieces together my self.  

The way my code works is in the init each entity creates a set of objects
that represent the cmp-fields, cmr-fields, and queries for that entity.  As
each cmr-field is created it checks to see if the related entity's cmr-field
has been created.  If it has not been created, it does nothing.  If it has
then it creates a reference to the related cmr-field object, and gives a
reference to the related entity. Only at the end of the init phase is it
guaranteed that all relationships are full setup.

In the start phase, tables are created for each entity, that may contain fks
for the related entity, or an additional table is created for the
relationship.  In this phase the ejb-ql is cross compiled to SQL, and this
process requires that any referenced relationships be fully connected.

Hope that helps.

-dain

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

Re: [JBoss-dev] MBean init/start change broke CMR

[David Jencks]

Ok, the ejb-jar should still be one deployment unit.  The init/start
shouldn't affect anything except mbeans in a *service.xml file.  Almost
certainly I broke something like ContainerFactory. Could you send me your
test cases and I will see if I can figure this out?


Thanks
david jencks

On 2001.11.14 18:12:36 -0500 Dain Sundstrom wrote:
 
 
  -Original Message-
  From: David Jencks [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, November 14, 2001 4:58 PM
  To: Dain Sundstrom
  Cc: [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] MBean init/start change broke CMR
  
  
  On 2001.11.14 17:11:52 -0500 Dain Sundstrom wrote:
   Hi all,
   
   I think that the merging of init and start has broken the 
  CMR code.  The
   CMR
   code depends on having a complete two-phase startup.  In the phase 1
   (init)
   all of the relation ships are connected, and in phase 2 
  (start) these
   relationships are used to create the entity tables with 
  fks, relation
   tables, and parse ejb-ql queries.  I think that merging the two has
   changed
   the system to call init and then start for each bean 
  instead of init for
   each bean and then start for each bean.
  
  This is correct.
 
 Yep, I added some code to verify the order.  I am getting:
 ejb1.init();
 ejb1.start();
 
 ejb2.init();
 ejb2.start();
 
 ejb3.init();
 ejb3.start();
 
 ejb4.init();
 ejb4.start();
 
   
   I wasn't following the discussion about this, because I 
  didn't think it
   applied to the CMR code (and the messages were very long). 
  
  The first one wasn't, asking if it would break anything.
 
 I know, but I thought the ejb-jar was one unit.  So the order wouldn't
 change.
 
   I'm going to
   go
   back and read the messages, but if anyone has a suggestion 
  or can tell me
   the resolution, I would appreciate it.
  
  How can I tell if it is broken? Is there a test case?  
 
 I know. There are test cases. I just haven't added them to the source
 tree.
  
  What are the beans
  you mention, mbeans from a *service.xml or ejbs or generated 
  mbeans from
  ContainerFactory or what? What is calling the init and start?  I might
  simply have done something stupid in ContainerFactory.
 
 I am talking about ejbs.  And the container init() and start methods,
 which
 are passed through to my JDBCStoreManager class.
 
  If the problem is due to unexpressed dependencies between 
  mbeans, generally
  the solution is to explicitly state those dependencies using 
  mbean-ref and
  mbean-ref-list elements.
 
 It is an expressed dependency between entities, but it is expressed in
 the
 ejb-jar.xml file.
 
  For instance, if you have mbeans A and B that registered with 
  C on init,
  and C did something with A and B in its start, put a 
  mbean-ref-list element
  in C containing A and B's object names: in C's start, first 
  iterate through
  the list, calling the new registerWithC(C) method (formerly 
  init()), and
  then the previous start code.
 
 I don't have that level of control all the way down at the StoreManager.
 
  I'm happy to help with fixing this if you can give me some 
  clues about what
  is going on and where.
 
  Thanks
  david jencks
 
 I still putting all the pieces together my self.  
 
 The way my code works is in the init each entity creates a set of objects
 that represent the cmp-fields, cmr-fields, and queries for that entity. 
 As
 each cmr-field is created it checks to see if the related entity's
 cmr-field
 has been created.  If it has not been created, it does nothing.  If it
 has
 then it creates a reference to the related cmr-field object, and gives a
 reference to the related entity. Only at the end of the init phase is it
 guaranteed that all relationships are full setup.
 
 In the start phase, tables are created for each entity, that may contain
 fks
 for the related entity, or an additional table is created for the
 relationship.  In this phase the ejb-ql is cross compiled to SQL, and
 this
 process requires that any referenced relationships be fully connected.
 
 Hope that helps.
 
 -dain
 
 

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

Re: [JBoss-dev] can't build jboss from cvs

[Jason Dillon]

Use the build.sh script.

--jason


On Wed, 14 Nov 2001, Adam Heath wrote:

 adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
 Buildfile: build.xml
   [taskdef] Could not load definitions from resource 
planet57/tools/buildmagic/task/autoload.properties. It could not be found.
 
 BUILD FAILED
 
 /home/adam/brainfood/jboss/cvs/jboss/build.xml:23: taskdef class 
planet57.tools.buildmagic.task.Property cannot be found
 
 Total time: 2 seconds
 
 Where does the planet57 stuff come from?  The following  url looks
 interesting, but since it's in the Attic, I doubt it has the correct data.
 
 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/thirdparty/planet57/buildmagic/lib/Attic/
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


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

Re: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Wed, 14 Nov 2001, Jason Dillon wrote:

 Why do you need a planet57 .deb ?

A package in debian needs to be able to build with software in debian.  Since
planet57 does not exist in debian, I'm making a deb of it.

This way, debian/control can contain a Build-Depends on
planet57-buildmagic.deb.  This is the automated building I told about.

Additionally, having it all available as a deb, and only using free software,
allows it to go into debian main, which allows for more wide distribution,
then if it were to go into contrib or non-free.


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

Re: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Wed, 14 Nov 2001, Jason Dillon wrote:

 Use the build.sh script.

That wouldn't help, since there is no planet57 code at all on my system.  In
fact, build.sh makes no attempt at finding planet57 code, and assumes it is
just in the classpath.

It also assumes that ant will use $CLASSPATH.


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

RE: [JBoss-dev] MBean init/start change broke CMR

[Dain Sundstrom]

David,

I've done some reasearch on ContainerFactory, and I think I have a solution.

From the logs I've seen that you removed the app.init() method, which should
be ok. All we need to do is add back an init method to the Container class,
which I think is below the level you care about.  Then we change
Application.start() to:

public void start() throws Exception
{
   Iterator enum = containers.values().iterator();
   while(enum.hasNext()) 
   {
  Container con = (Container)enum.next();
  con.init();
   }

   enum = containers.values().iterator();
   while(enum.hasNext()) 
   {
  Container con = (Container)enum.next();
  con.start();
   }
}

This change would assume that you don't care if Conatiner has an init
method.

-dain

 -Original Message-
 From: David Jencks [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 14, 2001 5:28 PM
 To: Dain Sundstrom
 Cc: 'David Jencks'; Dain Sundstrom;
 [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] MBean init/start change broke CMR
 
 
 Ok, the ejb-jar should still be one deployment unit.  The init/start
 shouldn't affect anything except mbeans in a *service.xml 
 file.  Almost
 certainly I broke something like ContainerFactory. Could you 
 send me your
 test cases and I will see if I can figure this out?
 
 
 Thanks
 david jencks
 
 On 2001.11.14 18:12:36 -0500 Dain Sundstrom wrote:
  
  
   -Original Message-
   From: David Jencks [mailto:[EMAIL PROTECTED]]
   Sent: Wednesday, November 14, 2001 4:58 PM
   To: Dain Sundstrom
   Cc: [EMAIL PROTECTED]
   Subject: Re: [JBoss-dev] MBean init/start change broke CMR
   
   
   On 2001.11.14 17:11:52 -0500 Dain Sundstrom wrote:
Hi all,

I think that the merging of init and start has broken the 
   CMR code.  The
CMR
code depends on having a complete two-phase startup.  
 In the phase 1
(init)
all of the relation ships are connected, and in phase 2 
   (start) these
relationships are used to create the entity tables with 
   fks, relation
tables, and parse ejb-ql queries.  I think that merging 
 the two has
changed
the system to call init and then start for each bean 
   instead of init for
each bean and then start for each bean.
   
   This is correct.
  
  Yep, I added some code to verify the order.  I am getting:
  ejb1.init();
  ejb1.start();
  
  ejb2.init();
  ejb2.start();
  
  ejb3.init();
  ejb3.start();
  
  ejb4.init();
  ejb4.start();
  

I wasn't following the discussion about this, because I 
   didn't think it
applied to the CMR code (and the messages were very long). 
   
   The first one wasn't, asking if it would break anything.
  
  I know, but I thought the ejb-jar was one unit.  So the 
 order wouldn't
  change.
  
I'm going to
go
back and read the messages, but if anyone has a suggestion 
   or can tell me
the resolution, I would appreciate it.
   
   How can I tell if it is broken? Is there a test case?  
  
  I know. There are test cases. I just haven't added them to 
 the source
  tree.
   
   What are the beans
   you mention, mbeans from a *service.xml or ejbs or generated 
   mbeans from
   ContainerFactory or what? What is calling the init and 
 start?  I might
   simply have done something stupid in ContainerFactory.
  
  I am talking about ejbs.  And the container init() and 
 start methods,
  which
  are passed through to my JDBCStoreManager class.
  
   If the problem is due to unexpressed dependencies between 
   mbeans, generally
   the solution is to explicitly state those dependencies using 
   mbean-ref and
   mbean-ref-list elements.
  
  It is an expressed dependency between entities, but it is 
 expressed in
  the
  ejb-jar.xml file.
  
   For instance, if you have mbeans A and B that registered with 
   C on init,
   and C did something with A and B in its start, put a 
   mbean-ref-list element
   in C containing A and B's object names: in C's start, first 
   iterate through
   the list, calling the new registerWithC(C) method (formerly 
   init()), and
   then the previous start code.
  
  I don't have that level of control all the way down at the 
 StoreManager.
  
   I'm happy to help with fixing this if you can give me some 
   clues about what
   is going on and where.
  
   Thanks
   david jencks
  
  I still putting all the pieces together my self.  
  
  The way my code works is in the init each entity creates a 
 set of objects
  that represent the cmp-fields, cmr-fields, and queries for 
 that entity. 
  As
  each cmr-field is created it checks to see if the related entity's
  cmr-field
  has been created.  If it has not been created, it does 
 nothing.  If it
  has
  then it creates a reference to the related cmr-field 
 object, and gives a
  reference to the related entity. Only at the end of the 
 init phase is it
  guaranteed that all relationships are full setup.
  
  In the start phase, tables are created for each entity, 
 that may contain
  fks
  for the 

Re: [JBoss-dev] can't build jboss from cvs

[David Budworth]

Can you put a package in debian main that depends on a non-free software?

Remember, JBoss 3.0 DEPENDS on jdk 1.3.x, and there is no free version of 
that.

Nor is there a .deb for it at all in non-free/contrib.

I don't believe IBM has a 1.3x .deb, and kaffe definately doesn't support it.

As much as I'd like to see JBoss in debian, I can't see how you can put a 
dependancy on a JDK that doesn't exist as far as debian is concerned.

Or are you somehow putting sun/blackdown in the contrib/non-free tree?  


On Wednesday 14 November 2001 03:43pm, Adam Heath wrote:
 On Wed, 14 Nov 2001, Jason Dillon wrote:
  Why do you need a planet57 .deb ?

 A package in debian needs to be able to build with software in debian. 
 Since planet57 does not exist in debian, I'm making a deb of it.

 This way, debian/control can contain a Build-Depends on
 planet57-buildmagic.deb.  This is the automated building I told about.

 Additionally, having it all available as a deb, and only using free
 software, allows it to go into debian main, which allows for more wide
 distribution, then if it were to go into contrib or non-free.


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

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

Re: [JBoss-dev] MBean init/start change broke CMR

[David Jencks]

Yes, thats about it, except I changed quite a few files below that too. 
I'm sorting them all out.

Thanks
david jencks

On 2001.11.14 19:32:29 -0500 Dain Sundstrom wrote:
 David,
 
 I've done some reasearch on ContainerFactory, and I think I have a
 solution.
 
 From the logs I've seen that you removed the app.init() method, which
 should
 be ok. All we need to do is add back an init method to the Container
 class,
 which I think is below the level you care about.  Then we change
 Application.start() to:
 
 public void start() throws Exception
 {
Iterator enum = containers.values().iterator();
while(enum.hasNext()) 
{
   Container con = (Container)enum.next();
   con.init();
}
 
enum = containers.values().iterator();
while(enum.hasNext()) 
{
   Container con = (Container)enum.next();
   con.start();
}
 }
 
 This change would assume that you don't care if Conatiner has an init
 method.
 
 -dain
 
  -Original Message-
  From: David Jencks [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, November 14, 2001 5:28 PM
  To: Dain Sundstrom
  Cc: 'David Jencks'; Dain Sundstrom;
  [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] MBean init/start change broke CMR
  
  
  Ok, the ejb-jar should still be one deployment unit.  The init/start
  shouldn't affect anything except mbeans in a *service.xml 
  file.  Almost
  certainly I broke something like ContainerFactory. Could you 
  send me your
  test cases and I will see if I can figure this out?
  
  
  Thanks
  david jencks
  
  On 2001.11.14 18:12:36 -0500 Dain Sundstrom wrote:
   
   
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 4:58 PM
To: Dain Sundstrom
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] MBean init/start change broke CMR


On 2001.11.14 17:11:52 -0500 Dain Sundstrom wrote:
 Hi all,
 
 I think that the merging of init and start has broken the 
CMR code.  The
 CMR
 code depends on having a complete two-phase startup.  
  In the phase 1
 (init)
 all of the relation ships are connected, and in phase 2 
(start) these
 relationships are used to create the entity tables with 
fks, relation
 tables, and parse ejb-ql queries.  I think that merging 
  the two has
 changed
 the system to call init and then start for each bean 
instead of init for
 each bean and then start for each bean.

This is correct.
   
   Yep, I added some code to verify the order.  I am getting:
   ejb1.init();
   ejb1.start();
   
   ejb2.init();
   ejb2.start();
   
   ejb3.init();
   ejb3.start();
   
   ejb4.init();
   ejb4.start();
   
 
 I wasn't following the discussion about this, because I 
didn't think it
 applied to the CMR code (and the messages were very long). 

The first one wasn't, asking if it would break anything.
   
   I know, but I thought the ejb-jar was one unit.  So the 
  order wouldn't
   change.
   
 I'm going to
 go
 back and read the messages, but if anyone has a suggestion 
or can tell me
 the resolution, I would appreciate it.

How can I tell if it is broken? Is there a test case?  
   
   I know. There are test cases. I just haven't added them to 
  the source
   tree.

What are the beans
you mention, mbeans from a *service.xml or ejbs or generated 
mbeans from
ContainerFactory or what? What is calling the init and 
  start?  I might
simply have done something stupid in ContainerFactory.
   
   I am talking about ejbs.  And the container init() and 
  start methods,
   which
   are passed through to my JDBCStoreManager class.
   
If the problem is due to unexpressed dependencies between 
mbeans, generally
the solution is to explicitly state those dependencies using 
mbean-ref and
mbean-ref-list elements.
   
   It is an expressed dependency between entities, but it is 
  expressed in
   the
   ejb-jar.xml file.
   
For instance, if you have mbeans A and B that registered with 
C on init,
and C did something with A and B in its start, put a 
mbean-ref-list element
in C containing A and B's object names: in C's start, first 
iterate through
the list, calling the new registerWithC(C) method (formerly 
init()), and
then the previous start code.
   
   I don't have that level of control all the way down at the 
  StoreManager.
   
I'm happy to help with fixing this if you can give me some 
clues about what
is going on and where.
   
Thanks
david jencks
   
   I still putting all the pieces together my self.  
   
   The way my code works is in the init each entity creates a 
  set of objects
   that represent the cmp-fields, cmr-fields, and queries for 
  that entity. 
   As
   each cmr-field is created it checks to see if the related entity's
   cmr-field
   has been created.  If it has not 

Re: [JBoss-dev] can't build jboss from cvs

[Jason Dillon]

Why do you need to know anything about buildmagic to build JBoss?  All you 
do is `cvs get jboss-all` and `build/build.sh` that is it.  Why would it be 
any different to build a debian package (or any package for that matter).

If you are setting up a seprate environment that does not use build.sh or 
build.bat then you are bound to run into problems, or at least maintenece 
when those change.

Perhaps you can explain a bit more about how you are building the .deb to 
clear things up for me.

--jason


On Wed, 14 Nov 2001, Adam Heath wrote:

 On Wed, 14 Nov 2001, Jason Dillon wrote:
 
  Why do you need a planet57 .deb ?
 
 A package in debian needs to be able to build with software in debian.  Since
 planet57 does not exist in debian, I'm making a deb of it.
 
 This way, debian/control can contain a Build-Depends on
 planet57-buildmagic.deb.  This is the automated building I told about.
 
 Additionally, having it all available as a deb, and only using free software,
 allows it to go into debian main, which allows for more wide distribution,
 then if it were to go into contrib or non-free.
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


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

Re: [JBoss-dev] can't build jboss from cvs

[Jason Dillon]

What are you talking about?  build.sh makes no assumptions about the users 
classpath and sets it up correctly to use the jars from tools/lib.

If you are trying to build JBoss from MAIN the onl;y supported method is 
using either build.sh or build.bat.  Direct usage of ant is NOT supported.

--jason


On Wed, 14 Nov 2001, Adam Heath wrote:

 On Wed, 14 Nov 2001, Jason Dillon wrote:
 
  Use the build.sh script.
 
 That wouldn't help, since there is no planet57 code at all on my system.  In
 fact, build.sh makes no attempt at finding planet57 code, and assumes it is
 just in the classpath.
 
 It also assumes that ant will use $CLASSPATH.
 


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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Jason Dillon]

We are not planning on re-adding tools.jar to the package are we?

Perhaps we could setup an InstallAnywhere installer which could have some 
custom tasks to install a tools.jar from the target JDK for those users who 
might have trouble doing this by hand.

--jason


On Wed, 14 Nov 2001, Adam Heath wrote:

 On Wed, 14 Nov 2001, Scott M Stark wrote:
 
  Next week.
 
 Ooh!  I can't wait.
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


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

Re: [JBoss-dev] can't build jboss from cvs

[Jason Dillon]

Further more, there are a slew of other .jars which a JBoss build depends 
on.  I don't understand why you need a buildmagic deb, nor am I sure what 
that deb would even consist of.

If this is going to be released to the mass of debian users I would like to 
know the full details of the package and how it will be maintained with 
respect to version updates.

I don't object to the package, but I question its usage and usefulness.

--jason


On Wed, 14 Nov 2001, David Budworth wrote:

 Can you put a package in debian main that depends on a non-free software?
 
 Remember, JBoss 3.0 DEPENDS on jdk 1.3.x, and there is no free version of 
 that.
 
 Nor is there a .deb for it at all in non-free/contrib.
 
 I don't believe IBM has a 1.3x .deb, and kaffe definately doesn't support it.
 
 As much as I'd like to see JBoss in debian, I can't see how you can put a 
 dependancy on a JDK that doesn't exist as far as debian is concerned.
 
 Or are you somehow putting sun/blackdown in the contrib/non-free tree?  
 
 
 On Wednesday 14 November 2001 03:43pm, Adam Heath wrote:
  On Wed, 14 Nov 2001, Jason Dillon wrote:
   Why do you need a planet57 .deb ?
 
  A package in debian needs to be able to build with software in debian. 
  Since planet57 does not exist in debian, I'm making a deb of it.
 
  This way, debian/control can contain a Build-Depends on
  planet57-buildmagic.deb.  This is the automated building I told about.
 
  Additionally, having it all available as a deb, and only using free
  software, allows it to go into debian main, which allows for more wide
  distribution, then if it were to go into contrib or non-free.
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


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

Re: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Wed, 14 Nov 2001, Jason Dillon wrote:

 What are you talking about?  build.sh makes no assumptions about the users
 classpath and sets it up correctly to use the jars from tools/lib.

There are no jars whatsoever in jboss cvs.  Please, don't just assume
something.

 If you are trying to build JBoss from MAIN the onl;y supported method is
 using either build.sh or build.bat.  Direct usage of ant is NOT supported.

 --jason

build.sh does NOT handle the planet57 stuff.  Please read what I said, again,
3 times, then read it again.

Running build.sh WILL fail.  Period.  No attempt is made by it to handle ALL
external dependencies that jboss has.  And I don't think there should be an
attempt.  There are already systems that exist that handle that(debian has
one).  There exist people(debian maintainers) that excel in this kind of
distribution packaging.


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

Re: [JBoss-dev] RH: tools.jar (javac)...

[Scott M Stark]

No were not.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: Adam Heath [EMAIL PROTECTED]
Cc: Scott M Stark [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 5:57 PM
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...


 We are not planning on re-adding tools.jar to the package are we?

 Perhaps we could setup an InstallAnywhere installer which could have some
 custom tasks to install a tools.jar from the target JDK for those users
who
 might have trouble doing this by hand.

 --jason


 On Wed, 14 Nov 2001, Adam Heath wrote:

  On Wed, 14 Nov 2001, Scott M Stark wrote:
 
   Next week.
 
  Ooh!  I can't wait.
 



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

Re: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Wed, 14 Nov 2001, Jason Dillon wrote:

 Why do you need to know anything about buildmagic to build JBoss?  All you
 do is `cvs get jboss-all` and `build/build.sh` that is it.  Why would it be
 any different to build a debian package (or any package for that matter).

When making a source package for debian, the source package should have NO
external files.  This is called 'redistribution', and can keep the package
from being accepted into debian.

So, a debian developer then goes about finding what debs already exist that
have these external files, and making the new package use those debs, during
the build process.

If an external file is not packaged already, the developer may take it upon
himself to make a package for that file, or may ask on one of the debian
mailing lists for someone else to do so.

If an external file has a license that keeps debian from making a deb of
it(see http://www.debian.org/social_contract#guidelines), then the new package
goes into what is called contrib, and will be BROKEN upon installation(because
of this missing file).

 If you are setting up a seprate environment that does not use build.sh or
 build.bat then you are bound to run into problems, or at least maintenece
 when those change.

debian/control is a text file, that contains meta information describing the
software.  Included in this information is a list of debian packages that have
to be installed before building the current package.  debian/rules(a makefile)
can then be assured that these packages are installed, and use the files that
the packages contain(ie, adding files from /usr/share/java/ into the
classpath).

There is no need, lots of times, for autodetection of anything during a debian
build, and in some cases autodetection is actually disabled.  When building a
debian package, it must be repeatable.  Always.  This means that the package
can't be built different ways, depending upon what happens to be installed(or
not installed) at build time.



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

Re: [JBoss-dev] can't build jboss from cvs

[David Jencks]

On 2001.11.14 21:02:53 -0500 Adam Heath wrote:
 On Wed, 14 Nov 2001, Jason Dillon wrote:
 
  What are you talking about?  build.sh makes no assumptions about the
 users
  classpath and sets it up correctly to use the jars from tools/lib.
 
 There are no jars whatsoever in jboss cvs.  Please, don't just assume
 something.

???
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/tools/lib/
!!!

did you checkout jboss-all?

david jencks
 
  If you are trying to build JBoss from MAIN the onl;y supported method
 is
  using either build.sh or build.bat.  Direct usage of ant is NOT
 supported.
 
  --jason
 
 build.sh does NOT handle the planet57 stuff.  Please read what I said,
 again,
 3 times, then read it again.
 
 Running build.sh WILL fail.  Period.  No attempt is made by it to handle
 ALL
 external dependencies that jboss has.  And I don't think there should be
 an
 attempt.  There are already systems that exist that handle that(debian
 has
 one).  There exist people(debian maintainers) that excel in this kind of
 distribution packaging.
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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

Re: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

yOn Wed, 14 Nov 2001, Jason Dillon wrote:

  On Wed, 14 Nov 2001, Jason Dillon wrote:
 
   What are you talking about?  build.sh makes no assumptions about the users
   classpath and sets it up correctly to use the jars from tools/lib.
 
  There are no jars whatsoever in jboss cvs.  Please, don't just assume
  something.

 Ok, now I am really confused.  There are .jar files in the 2.4 and MAIN cvs
 modules for jboss, jboss-all/thirdparty and jboss-all/tools.  They are
 required to build the sources and produce a runnable JBoss distribution.

adam@gradall:~/brainfood/jboss/cvs/jboss$ find -name '*.jar'
./src/bin/BeanCacheMonitorJMS.jar
./src/bin/BeanCacheMonitorJMX.jar

  build.sh does NOT handle the planet57 stuff.  Please read what I said, again,
  3 times, then read it again.

 Of course it does.  That is what it does; it sets up the environment so that
 the build will have the correct classpath and environment variables to run
 correctly.

Ok.  This is fucking annoying.  Are you stupid, or moronic?

===
adam@gradall:~/brainfood/jboss/cvs/jboss$ cat build.sh
#!/bin/sh
### == ###
##  ##
##  This is the main entry point for the build system.  ##
##  ##
##  Users should be sure to execute this file rather than 'ant' to ensure   ##
##  the correct version is being used with the correct configuration.   ##
##  ##
### == ###

# $Id: build.sh,v 1.8 2001/09/12 00:49:55 user57 Exp $

PROGNAME=`basename $0`
DIRNAME=`dirname $0`
GREP=grep
ROOT=/

# Ignore user's ANT_HOME if it is set
ANT_HOME=

# the default search path for ant
ANT_SEARCH_PATH=\
tools
tools/ant \
tools/apache/ant \
ant

# the default build file name
ANT_BUILD_FILE=build.xml

# the default arguments
ANT_OPTIONS=-find $ANT_BUILD_FILE

# the jaxp parser to use
if [ x$JAXP = x ]; then
# Default to crimson
JAXP=crimson
fi

#
# Helper to complain.
#
die() {
echo ${PROGNAME}: $*
exit 1
}

#
# Helper to source a file if it exists.
#
maybe_source() {
for file in $*; do
if [ -f $file ]; then
. $file
fi
done
}

search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}

#
# Main function.
#
main() {
# if there is a build config file. then source it
maybe_source $DIRNAME/build.conf $HOME/.build.conf

# try the search path
ANT_HOME=`search $ANT_SEARCH_PATH`

# try looking up to root
if [ x$ANT_HOME = x ]; then
target=build
_cwd=`pwd`

while [ x$ANT_HOME = x ]  [ $cwd != $ROOT ]; do
cd ..
cwd=`pwd`
ANT_HOME=`search $ANT_SEARCH_PATH`
done

# make sure we get back
cd $_cwd

if [ $cwd != $ROOT ]; then
found=true
fi

# complain if we did not find anything
if [ $found != true ]; then
die Could not locate Ant; check \$ANT or \$ANT_HOME.
fi
fi

# make sure we have one
ANT=$ANT_HOME/bin/ant
if [ ! -x $ANT ]; then
die Ant file is not executable: $ANT
fi

# specify the jaxp parser impls to use
case $JAXP in
crimson)
JAXP_DOM_FACTORY=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
JAXP_SAX_FACTORY=org.apache.crimson.jaxp.SAXParserFactoryImpl
;;

xerces)
JAXP_DOM_FACTORY=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
JAXP_SAX_FACTORY=org.apache.xerces.jaxp.SAXParserFactoryImpl
;;
esac

if [ x$JAXP_DOM_FACTORY != x ]; then
ANT_OPTS=$ANT_OPTS 
-Djavax.xml.parsers.DocumentBuilderFactory=$JAXP_DOM_FACTORY
fi
if [ x$JAXP_SAX_FACTORY != x ]; then
ANT_OPTS=$ANT_OPTS -Djavax.xml.parsers.SAXParserFactory=$JAXP_SAX_FACTORY
fi

# change to the directory where the script lives so users are not forced
# to be in the same directory as build.xml
cd $DIRNAME

export ANT ANT_HOME ANT_OPTS
exec $ANT $ANT_OPTIONS $@
}

##
## Bootstrap
##

main $@
===

 What?  Last I checked build.sh works fine.  How are you building?  Where did
 you get your sources from?  What platform/os version are you using?  What
 version of the JDK are you using?

anonymous checkout of module jboss.  ./build.sh fails.

Debian linux unstable.  j2sdk1.3.


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

RE: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Thu, 15 Nov 2001, David Maplesden wrote:

 Settle down, it was very apparent to anyone following your conversation that
 you guys were talking about different cvs modules.

It's not apparent to me(who is new with jboss), and not apparent to Jason(who
is not).  So, you can imagine my excasperation, when someone who knows enough
to make me believe he knows about jboss, actually doesn't know about it.

 Jason's excellent build system works perfectly for the jboss-all module (not
 the jboss module which is deprecated).

Why can't jboss/build.sh do the same thing?  What is so wrong with having that
also look for the appropriate depends for just the jboss module, and setup the
environment for ant?

 I don't know what debian is, if you can get it working fine but don't
 criticise the current build system too much.

http://www.debian.org

Its a distribution of linux.


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

Re: [JBoss-dev] can't build jboss from cvs

[Jason Dillon]

This is not an appropriate response my friend... especially from a newcomer.  
I certainly am not motivated to help by such comments... though I will 
persist anyways.

--jason


On Wed, 14 Nov 2001, Adam Heath wrote:

 yOn Wed, 14 Nov 2001, Jason Dillon wrote:
 
   On Wed, 14 Nov 2001, Jason Dillon wrote:
  
What are you talking about?  build.sh makes no assumptions about the users
classpath and sets it up correctly to use the jars from tools/lib.
  
   There are no jars whatsoever in jboss cvs.  Please, don't just assume
   something.
 
  Ok, now I am really confused.  There are .jar files in the 2.4 and MAIN cvs
  modules for jboss, jboss-all/thirdparty and jboss-all/tools.  They are
  required to build the sources and produce a runnable JBoss distribution.
 
 adam@gradall:~/brainfood/jboss/cvs/jboss$ find -name '*.jar'
 ./src/bin/BeanCacheMonitorJMS.jar
 ./src/bin/BeanCacheMonitorJMX.jar
 
   build.sh does NOT handle the planet57 stuff.  Please read what I said, again,
   3 times, then read it again.
 
  Of course it does.  That is what it does; it sets up the environment so that
  the build will have the correct classpath and environment variables to run
  correctly.
 
 Ok.  This is fucking annoying.  Are you stupid, or moronic?
 
 ===
 adam@gradall:~/brainfood/jboss/cvs/jboss$ cat build.sh
 #!/bin/sh
 ### == ###
 ##  ##
 ##  This is the main entry point for the build system.  ##
 ##  ##
 ##  Users should be sure to execute this file rather than 'ant' to ensure   ##
 ##  the correct version is being used with the correct configuration.   ##
 ##  ##
 ### == ###
 
 # $Id: build.sh,v 1.8 2001/09/12 00:49:55 user57 Exp $
 
 PROGNAME=`basename $0`
 DIRNAME=`dirname $0`
 GREP=grep
 ROOT=/
 
 # Ignore user's ANT_HOME if it is set
 ANT_HOME=
 
 # the default search path for ant
 ANT_SEARCH_PATH=\
 tools
 tools/ant \
 tools/apache/ant \
 ant
 
 # the default build file name
 ANT_BUILD_FILE=build.xml
 
 # the default arguments
 ANT_OPTIONS=-find $ANT_BUILD_FILE
 
 # the jaxp parser to use
 if [ x$JAXP = x ]; then
 # Default to crimson
 JAXP=crimson
 fi
 
 #
 # Helper to complain.
 #
 die() {
 echo ${PROGNAME}: $*
 exit 1
 }
 
 #
 # Helper to source a file if it exists.
 #
 maybe_source() {
 for file in $*; do
   if [ -f $file ]; then
   . $file
   fi
 done
 }
 
 search() {
 search=$*
 for d in $search; do
   ANT_HOME=`pwd`/$d
   ANT=$ANT_HOME/bin/ant
   if [ -x $ANT ]; then
   # found one
   echo $ANT_HOME
   break
   fi
 done
 }
 
 #
 # Main function.
 #
 main() {
 # if there is a build config file. then source it
 maybe_source $DIRNAME/build.conf $HOME/.build.conf
 
 # try the search path
 ANT_HOME=`search $ANT_SEARCH_PATH`
 
 # try looking up to root
 if [ x$ANT_HOME = x ]; then
   target=build
   _cwd=`pwd`
 
   while [ x$ANT_HOME = x ]  [ $cwd != $ROOT ]; do
   cd ..
   cwd=`pwd`
   ANT_HOME=`search $ANT_SEARCH_PATH`
   done
 
   # make sure we get back
   cd $_cwd
 
   if [ $cwd != $ROOT ]; then
   found=true
   fi
 
   # complain if we did not find anything
   if [ $found != true ]; then
   die Could not locate Ant; check \$ANT or \$ANT_HOME.
   fi
 fi
 
 # make sure we have one
 ANT=$ANT_HOME/bin/ant
 if [ ! -x $ANT ]; then
   die Ant file is not executable: $ANT
 fi
 
 # specify the jaxp parser impls to use
 case $JAXP in
   crimson)
   JAXP_DOM_FACTORY=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
   JAXP_SAX_FACTORY=org.apache.crimson.jaxp.SAXParserFactoryImpl
   ;;
 
   xerces)
   JAXP_DOM_FACTORY=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
   JAXP_SAX_FACTORY=org.apache.xerces.jaxp.SAXParserFactoryImpl
   ;;
 esac
 
 if [ x$JAXP_DOM_FACTORY != x ]; then
   ANT_OPTS=$ANT_OPTS 
-Djavax.xml.parsers.DocumentBuilderFactory=$JAXP_DOM_FACTORY
 fi
 if [ x$JAXP_SAX_FACTORY != x ]; then
   ANT_OPTS=$ANT_OPTS -Djavax.xml.parsers.SAXParserFactory=$JAXP_SAX_FACTORY
 fi
 
 # change to the directory where the script lives so users are not forced
 # to be in the same directory as build.xml
 cd $DIRNAME
 
 export ANT ANT_HOME ANT_OPTS
 exec $ANT $ANT_OPTIONS $@
 }
 
 ##
 ## Bootstrap
 ##
 
 main $@
 ===
 
  What?  Last I checked build.sh works fine.  How are you building?  Where did
  you get your sources from?  What platform/os version are you using?  What
  version of the JDK 

Re: [JBoss-dev] can't build jboss from cvs

[David Jencks]

On 2001.11.14 23:54:00 -0500 Adam Heath wrote:
 On Wed, 14 Nov 2001, David Jencks wrote:
 
  On 2001.11.14 21:02:53 -0500 Adam Heath wrote:
   On Wed, 14 Nov 2001, Jason Dillon wrote:
  
What are you talking about?  build.sh makes no assumptions about
 the
   users
classpath and sets it up correctly to use the jars from tools/lib.
  
   There are no jars whatsoever in jboss cvs.  Please, don't just assume
   something.
 
  ???
  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/tools/lib/
  !!!
 
  did you checkout jboss-all?
 
 No, and I will not.
 
 jboss-all tries to build a unified, easy to install jboss *suite*. 
 Debian
 does the same thing.

Then you are insisting on wasting your time and the time of everyone on
this list.  You will only get the correct cvs versions of the entire jboss
server by checking out jboss-all.  The server (looks like jboss in cvs) is
only a small part of jboss and will not build or be of any use to anyone,
even debian fanatics, by itself.  

Checking out jboss-all is different from using the build system.  I can't
imagine why you want to duplicate the work done to put together the current
build system, and doubt anyone will want to maintain it separately if you
do.

The relationship between the build.xml file in build and those in the other
modules is similar to the system of makefiles in which each directory has
its own makefile and calls those in subdirectories.  Do you rewrite make
systems to avoid this kind of unified, easy to use packaging?

david jencks
 
 I will only look at the separate modules, and make Debian packages based
 on
 the separate modules.
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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

RE: [JBoss-dev] can't build jboss from cvs

[Jason Dillon]

First off you are using the wrong cvs module to build a functional JBoss 3.0 
release.  The build system and cvs organization has changed drammatically 
from 2.x

I know there are not any docs to point this out directly, which I am going 
to fix.  http://jboss.org/developers/cvs.jsp has been updated to reflect the 
current list of supported modules.

I assumed that you had checked out jboss-all, which is why I responded with 
the questions about your cvs acess and such... which I did not see an answer 
too.

I will now assume that you have checked out 'jboss', which is just the 
jboss-all/server module in MAIN, but is the entire server environment for 
2.4.

You can not simply build this module by itself.  It depends on the 
jboss-all/j2ee and jboss-all/naming modules as well as the thirdparty and 
tools modules.

If you are trying to build a 3.0 .deb then please use the 'jboss-all' module 
from cvs and use 'build/build.sh release' to create a release suitable for 
stuffing into the package.  The files will be inder 'build/output/jboss-*/

If you are trying to build a 2.4.x .deb, then checkout the 'jboss' module 
under the Branch_2_4 (I think that is correct, check with scott for the 
definitive).

I will eventually get to the docs... really I will.  In the mean time take 
some deep breaths and keep the email polite... at least when you have issues 
with the build systems, cause I tend to take it a bit personal.

--jason


On Wed, 14 Nov 2001, Adam Heath wrote:

 On Thu, 15 Nov 2001, David Maplesden wrote:
 
  Settle down, it was very apparent to anyone following your conversation that
  you guys were talking about different cvs modules.
 
 It's not apparent to me(who is new with jboss), and not apparent to Jason(who
 is not).  So, you can imagine my excasperation, when someone who knows enough
 to make me believe he knows about jboss, actually doesn't know about it.
 
  Jason's excellent build system works perfectly for the jboss-all module (not
  the jboss module which is deprecated).
 
 Why can't jboss/build.sh do the same thing?  What is so wrong with having that
 also look for the appropriate depends for just the jboss module, and setup the
 environment for ant?
 
  I don't know what debian is, if you can get it working fine but don't
  criticise the current build system too much.
 
 http://www.debian.org
 
 Its a distribution of linux.
 


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

[JBoss-dev] Automated JBoss Testsuite Results

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   172



Successful tests:  135

Errors:23

Failures:  14





[time of test: 15 November 2001 5:26 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1-FCS]
[java.vm.name: Classic VM]
[java.vm.info: green threads, nojit]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-12]

See http://lubega.com for full details

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.  Its easy, just run the target 
'run-basic-testsuite' from the main build.xml.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/local BaseLocalContainerInvoker.java

[David Jencks]

  User: d_jencks
  Date: 01/11/14 21:30:55

  Modified:src/main/org/jboss/ejb/plugins/local
BaseLocalContainerInvoker.java
  Log:
  Fixed Application and rolled back changes on Container, EntityContainer, 
MessageDrivenContainer, StatefulSessionContainer, StatelessSessionContainer, and 
plugins/local/BaseLocalContainerInvoker. cmp 2 appears to work again.
  
  Revision  ChangesPath
  1.13  +4 -27 
jboss/src/main/org/jboss/ejb/plugins/local/BaseLocalContainerInvoker.java
  
  Index: BaseLocalContainerInvoker.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/local/BaseLocalContainerInvoker.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- BaseLocalContainerInvoker.java2001/11/12 06:52:16 1.12
  +++ BaseLocalContainerInvoker.java2001/11/15 05:30:55 1.13
  @@ -107,7 +107,7 @@
  {
 this.container = con;
  }
  -   /*   
  +   
  public void init()
  throws Exception
  {
  @@ -133,33 +133,10 @@
 for (int i = 0; i  methods.length; i++)
homeMethodInvokerMap.put(new 
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
  }
  -*/   
  -   public void init() throws Exception {throw new Exception(don't call init);}
  -   public void destroy(){}
  +   
  public void start()
  throws Exception
  {
  -  if (((ContainerInvokerContainer)container).getLocalClass() == null)
  - return;
  -  
  -  Context ctx = new InitialContext();
  -  
  -  jndiName = container.getBeanMetaData().getJndiName();
  -  
  -  // Set the transaction manager and transaction propagation
  -  // context factory of the GenericProxy class
  -  transactionManager = 
((TransactionManager)ctx.lookup(java:/TransactionManager));
  -  
  -  // Create method mappings for container invoker
  -  Method[] methods = 
((ContainerInvokerContainer)container).getLocalClass().getMethods();
  -  beanMethodInvokerMap = new HashMap();
  -  for (int i = 0; i  methods.length; i++)
  - beanMethodInvokerMap.put(new 
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
  -  
  -  methods = 
((ContainerInvokerContainer)container).getLocalHomeClass().getMethods();
  -  homeMethodInvokerMap = new HashMap();
  -  for (int i = 0; i  methods.length; i++)
  - homeMethodInvokerMap.put(new 
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
 Class localHome = ((ContainerInvokerContainer)container).getLocalHomeClass();
 if(localHome == null)
 {
  @@ -209,11 +186,11 @@
// ignore.
 }
  }
  -   /*   
  +   
  public void destroy()
  {
  }
  -   */
  +   
  
  // ContainerInvoker implementation ---
  public EJBLocalHome getEJBLocalHome()
  
  
  

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

[JBoss-dev] CVS update: newsite/src/docs bm-usersguide.pdf

[Jason Dillon]

  User: user57  
  Date: 01/11/14 21:35:15

  Removed: src/docs bm-usersguide.pdf
  Log:
  removed to avoid confusion

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

[JBoss-dev] CVS update: newsite/src/docs/developers cvs.jsp

[Jason Dillon]

  User: user57  
  Date: 01/11/14 21:35:15

  Modified:src/docs/developers cvs.jsp
  Log:
  removed to avoid confusion
  
  Revision  ChangesPath
  1.6   +0 -17 newsite/src/docs/developers/cvs.jsp
  
  Index: cvs.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/developers/cvs.jsp,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- cvs.jsp   2001/11/07 19:55:37 1.5
  +++ cvs.jsp   2001/11/15 05:35:15 1.6
  @@ -123,23 +123,6 @@
/ul
  /p
   
  -   p class=headWhat is Buildmagic/p
  -
  -   p class=text
  -  Buildmagic is a collection of extension tasks for Ant v1.3/1.4 and 
  -  a general methodology for organization of build control files.
  -  It was designed to allow aggregation of one or more source modules 
  -  into one logical project, yet still retain each modules individuality
  -  (so that the same module could be incorporated into another project 
  -  or worked on independently of a project).
  -
  -   p class=text
  - ul class=text
  -   liBuildmagic User's Guide 
  - a class=link href=bm-usersguide.pdf[pdf]/a
  - /ul
  -   /p
  -
  p class=text
 The build system is currently being stabilized, but has changed 
 since the writting of this user's guide document.
  
  
  

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

[JBoss-dev] crimson.jar ref in server/src/etc/run.mf

[Jason Dillon]

Is there any reason why crimson.jar is referenced in server/src/etc/run.mf?

Won't this make it hard to switch jaxp compliant parsers?

--jason


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

RE: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Wed, 14 Nov 2001, Jason Dillon wrote:

 First off you are using the wrong cvs module to build a functional JBoss 3.0
 release.  The build system and cvs organization has changed drammatically
 from 2.x

 I know there are not any docs to point this out directly, which I am going
 to fix.  http://jboss.org/developers/cvs.jsp has been updated to reflect the
 current list of supported modules.

I hope the doc situation is taking care of by the time a beta release of 3.0
comes out(this is similiar to the way tomcat work(s/ed)).

 I assumed that you had checked out jboss-all, which is why I responded with
 the questions about your cvs acess and such... which I did not see an answer
 too.

Look in the mail where I included the build.sh.

 I will now assume that you have checked out 'jboss', which is just the
 jboss-all/server module in MAIN, but is the entire server environment for
 2.4.

 You can not simply build this module by itself.  It depends on the
 jboss-all/j2ee and jboss-all/naming modules as well as the thirdparty and
 tools modules.

Does the stuff in j2ee and naming depend on other jboss items?  Do they depend
on the jboss module?  If no, then I started at the wrong spot.

Making a deb of naming first, then j2ee, then finally jboss, is perfectly
fine, as far as normaly Debian packaging goes.

Is everything in thirdparty exact copies of external libraries, that get
built, or just checked in pre-compiled version, or a mixture of the two?

In either case, since they are third party modules, and not part of jboss,
they can not be packaged with jboss in Debian.

What I will end up doing(and have already started, I made a jaxp.deb tonight),
is packaging each one of these external bits of code, by going to the proper
location upstream, and packaging what they release.

If jboss has patched these upstream sources, have the patches then been sent
upstream?

 If you are trying to build a 3.0 .deb then please use the 'jboss-all' module
 from cvs and use 'build/build.sh release' to create a release suitable for
 stuffing into the package.  The files will be inder 'build/output/jboss-*/

I'm not building a single jboss deb.  What I have done for 2.4, is make
separate debs, split along the same lines as each top-level directory in the
2.4.3 tarball.

The list of packages follows:

jboss jboss-server jboss-transaction jboss-tomcat-service jboss-client
jboss-admin jboss-common jnp-server jnp-client jbossmq jbossmq-client jbosssx
jbosssx-client jboss-contrib-hsqldb jboss-contrib-oswego jboss-contrib-tyrex
jboss-contrib-castor jboss-contrib jboss-dev jboss-docs

jboss-contrib contains external sources, that shouldn't be part of the final
jboss deb framework.  I put them there, to make it quicker for me to get
things going.

jboss-contrib-* are things that I have identify as being DFSG-free, and should
be packaged separately, by going to each upstream location.  After that is
done, jboss would then just depend on those.

jboss-transaction and jboss-contrib-tyrex both provide transaction services,
and can't be installed at the same time.

The -client packages are for use on system that talks to a remote jboss
server.

jboss-server has an init script, and starts the jboss server as a separate
user(jboss).  jnp-server is the same, but the user is jnp-server.

jboss-tomcat-service depends on tomcat.deb.  Because of the way tomcat.deb is
layed out, tomcat.home needs to be set correctly for it to build.  However,
the TomcatService stuff in jboss doesn't support setting tomcat.home, so I
made a patch for it(see my earlier email).

Finally, package jboss is an empty package, that depends on all the other
appriopriate packages, so that once they are all installed, you end up with
jboss-tomcat.tar.gz.

Additionally, to support all these splits, I chopped jboss.conf and jboss.jcml
into configuration fragments.  Each deb can then include a config fragment,
and I rebuild the config files when the debs are installed.  I understand that
3.0 does this completely differently, which means my work will be wasted.
That's fine by me, as what I have seen discussed on this list in the last few
days seems quite nice(the -service stuff).


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

Re: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Wed, 14 Nov 2001, Jason Dillon wrote:

 This is not an appropriate response my friend... especially from a newcomer.
 I certainly am not motivated to help by such comments... though I will
 persist anyways.

Well, I kept repeating the same thing over and over and over, and wasn't
getting anywhere.  Sorry for coming off badly.


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

[JBoss-dev] Automated JBoss Testsuite Results

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   187



Successful tests:  148

Errors:25

Failures:  14





[time of test: 15 November 2001 6:24 GMT]
[java.version: 1.3.1]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.3.1-b24]
[java.vm.name: Java HotSpot(TM) Server VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-12]

See http://lubega.com for full details

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.  Its easy, just run the target 
'run-basic-testsuite' from the main build.xml.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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

[JBoss-dev] CVS update: jboss/src/etc/conf/default hsqldb-default-service.xml

[David Jencks]

  User: d_jencks
  Date: 01/11/14 22:27:28

  Modified:src/etc/conf/default hsqldb-default-service.xml
  Log:
  Modified to be an example and test of anonymous mbean-refs
  
  Revision  ChangesPath
  1.4   +19 -9 jboss/src/etc/conf/default/hsqldb-default-service.xml
  
  Index: hsqldb-default-service.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/hsqldb-default-service.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- hsqldb-default-service.xml2001/11/12 18:35:18 1.3
  +++ hsqldb-default-service.xml2001/11/15 06:27:28 1.4
  @@ -7,7 +7,7 @@
   !--   --
   !-- = --
   
  -!-- $Id: hsqldb-default-service.xml,v 1.3 2001/11/12 18:35:18 d_jencks Exp $ --
  +!-- $Id: hsqldb-default-service.xml,v 1.4 2001/11/15 06:27:28 d_jencks Exp $ --
   
   
   server
  @@ -22,14 +22,6 @@
 !-- to ConnectionFactoryLoader   --
 !--  --
   
  -  mbean code=org.jboss.jdbc.HypersonicDatabase 
  -  name=JBOSS-SYSTEM:service=Hypersonic
  -attribute name=Port1476/attribute
  -attribute name=Silenttrue/attribute
  -attribute name=Databasedefault/attribute
  -attribute name=Tracefalse/attribute
  -  /mbean
  -
 mbean code=org.jboss.resource.ConnectionFactoryLoader 
 name=JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=DefaultDS
   attribute 
name=ManagedConnectionFactoryPropertiesConnectionURL=jdbc:hsqldb:hsql://localhost:1476
  @@ -37,6 +29,10 @@
 UserName=sa/attribute
   attribute name=JndiNameDefaultDS/attribute
   attribute name=TransactionManagerNamejava:/TransactionManager/attribute
  +
  +!--Anonymous mbean-ref to database being started --
  +mbean-refJBOSS-SYSTEM:service=Hypersonic/mbean-ref
  +
   mbean-ref name=ResourceAdapterNameJCA:service=RARDeployment,name=Minerva 
JDBC LocalTransaction ResourceAdapter/mbean-ref
   mbean-ref 
name=ConnectionManagerFactoryLoaderNameJCA:service=ConnectionManagerFactoryLoader,name=MinervaSharedLocalCMFactory/mbean-ref
   attribute name=ConnectionManagerProperties#
  @@ -62,6 +58,10 @@
 AutoCommit=true/attribute
   attribute name=JndiNameNoTransDS/attribute
   attribute name=TransactionManagerNamejava:/TransactionManager/attribute
  +
  +!--Anonymous mbean-ref to database being started --
  +mbean-refJBOSS-SYSTEM:service=Hypersonic/mbean-ref
  +
   mbean-ref name=ResourceAdapterNameJCA:service=RARDeployment,name=Minerva 
JDBC LocalTransaction ResourceAdapter/mbean-ref
   mbean-ref 
name=ConnectionManagerFactoryLoaderNameJCA:service=ConnectionManagerFactoryLoader,name=MinervaNoTransCMFactory/mbean-ref
   attribute name=ConnectionManagerProperties#
  @@ -77,6 +77,16 @@
 org.jboss.resource.security.ManyToOnePrincipalMapping
  /attribute
   attribute name=PrincipalMappingPropertiesUserName=sa/attribute
  +  /mbean
  +
  +  !-- Moved to end to test anonymous mbean-refs --
  +
  +  mbean code=org.jboss.jdbc.HypersonicDatabase 
  +  name=JBOSS-SYSTEM:service=Hypersonic
  +attribute name=Port1476/attribute
  +attribute name=Silenttrue/attribute
  +attribute name=Databasedefault/attribute
  +attribute name=Tracefalse/attribute
 /mbean
   
   /server
  
  
  

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/system ServiceConfigurator.java

[David Jencks]

  User: d_jencks
  Date: 01/11/14 22:30:22

  Modified:src/main/org/jboss/system ServiceConfigurator.java
  Log:
  Added anonymous mbean-ref and mbean-ref-lists. (i.e, don't supply a name).  See 
hsqldb-default-service for an example
  
  Revision  ChangesPath
  1.7   +82 -64jboss/src/main/org/jboss/system/ServiceConfigurator.java
  
  Index: ServiceConfigurator.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceConfigurator.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ServiceConfigurator.java  2001/11/13 07:55:00 1.6
  +++ ServiceConfigurator.java  2001/11/15 06:30:22 1.7
  @@ -42,7 +42,7 @@
* 
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
  - * @version $Revision: 1.6 $
  + * @version $Revision: 1.7 $
*
* pb20010830 marc fleury:/b
* ul
  @@ -237,40 +237,49 @@
 }
 // Set mbean references (object names)
 ArrayList mBeanRefs = new ArrayList();
  -  NodeList mbeanRefElements = mbeanElement.getElementsByTagName(mbean-ref);
  -  log.debug(found  + mbeanRefElements.getLength() +  mbean-ref elements);
  -  for (int j = 0; j  mbeanRefElements.getLength(); j++) {
  - Element mbeanRefElement = (Element)mbeanRefElements.item(j);
  - String mbeanRefName = mbeanRefElement.getAttribute(name);
  - if (!mbeanRefElement.hasChildNodes()) 
  +  NodeList mBeanRefElements = mbeanElement.getElementsByTagName(mbean-ref);
  +  log.debug(found  + mBeanRefElements.getLength() +  mbean-ref elements);
  +  for (int j = 0; j  mBeanRefElements.getLength(); j++) {
  + Element mBeanRefElement = (Element)mBeanRefElements.item(j);
  + String mBeanRefName = mBeanRefElement.getAttribute(name);
  + if (!mBeanRefElement.hasChildNodes()) 
{
  -throw new DeploymentException(No ObjectName supplied for mbean-ref  + 
mbeanRefName);   
  +throw new DeploymentException(No ObjectName supplied for mbean-ref  + 
mBeanRefName);   
   
}   
// Get the mbeanRef value
  - String mbeanRefValue = 
((Text)mbeanRefElement.getFirstChild()).getData().trim();
  - ObjectName mbeanRefObjectName = new ObjectName(mbeanRefValue);
  - log.debug(considering  + mbeanRefName +  with object name  + 
mbeanRefObjectName);
  - MBeanAttributeInfo[] attributes = info.getAttributes();
  - for (int k = 0; k  attributes.length; k++) {
  -if (mbeanRefName.equals(attributes[k].getName())) {
  -   String typeName = attributes[k].getType();
  -   if (!javax.management.ObjectName.equals(typeName)) 
  -   {
  -  throw new DeploymentException(Trying to set  + mbeanRefName +  
as an MBeanRef when it is not of type ObjectName);   
  -   } // end of if ()
  -   if (!mBeanRefs.contains(mbeanRefObjectName)) 
  -   {
  -  mBeanRefs.add(mbeanRefObjectName);
  -   } // end of if ()
  + String mBeanRefValue = 
((Text)mBeanRefElement.getFirstChild()).getData().trim();
  + ObjectName mBeanRefObjectName = new ObjectName(mBeanRefValue);
  + if (!mBeanRefs.contains(mBeanRefObjectName)) 
  + {
  +mBeanRefs.add(mBeanRefObjectName);
  + } // end of if ()
  +  namefound:
  + if (mBeanRefName == null || .equals(mBeanRefName)) 
  + {
  +log.debug(Anonymous dependency on object name  + mBeanRefObjectName); 
   
  + } // end of if ()
  + else 
  + {
  +log.debug(considering  + mBeanRefName +  with object name  + 
mBeanRefObjectName);
  +MBeanAttributeInfo[] attributes = info.getAttributes();
  +for (int k = 0; k  attributes.length; k++) {
  +   if (mBeanRefName.equals(attributes[k].getName())) {
  +  String typeName = attributes[k].getType();
  +  if (!javax.management.ObjectName.equals(typeName)) 
  +  {
  + throw new DeploymentException(Trying to set  + mBeanRefName 
+  as an MBeanRef when it is not of type ObjectName);   
  +  } // end of if ()
   
  -   log.debug(mbeanRefName +  set to  + mbeanRefValue +  in  + 
objectName);
  -   server.setAttribute(objectName, new Attribute(mbeanRefName, 
mbeanRefObjectName));
  +  log.debug(mBeanRefName +  set to  + mBeanRefValue +  in  + 
objectName);
  +  server.setAttribute(objectName, new Attribute(mBeanRefName, 
mBeanRefObjectName));
   
  -   break;
  -}
  - }
  - 
  +  break namefound;
  +   }//name test
  +}//for
 

Re: [JBoss-dev] crimson.jar ref in server/src/etc/run.mf

[Scott M Stark]

It would only cause a problem if there were inconsistencies between the
common xml classes. If you set the JAXP properties your saying which
parser factory to use so it doesn't matter if fatories for other parsers are
on the classpath. I switch parsers all the time with this entry in the
manifest.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 10:11 PM
Subject: [JBoss-dev] crimson.jar ref in server/src/etc/run.mf


 Is there any reason why crimson.jar is referenced in
server/src/etc/run.mf?

 Won't this make it hard to switch jaxp compliant parsers?

 --jason


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



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

Re: [JBoss-dev] can't build jboss from cvs

[David Jencks]

Out of curiousity, where does connector (jbosscx) fit into your packaging
scheme?  For 3.0 you might consider putting the contents of pool and
connector into one package (if they aren't already) as pool is now small
and only used by jbosscx.

david jencks

On 2001.11.15 01:11:20 -0500 Adam Heath wrote:
 On Wed, 14 Nov 2001, Jason Dillon wrote:
 
  First off you are using the wrong cvs module to build a functional
 JBoss 3.0
  release.  The build system and cvs organization has changed
 drammatically
  from 2.x
 
  I know there are not any docs to point this out directly, which I am
 going
  to fix.  http://jboss.org/developers/cvs.jsp has been updated to
 reflect the
  current list of supported modules.
 
 I hope the doc situation is taking care of by the time a beta release of
 3.0
 comes out(this is similiar to the way tomcat work(s/ed)).
 
  I assumed that you had checked out jboss-all, which is why I responded
 with
  the questions about your cvs acess and such... which I did not see an
 answer
  too.
 
 Look in the mail where I included the build.sh.
 
  I will now assume that you have checked out 'jboss', which is just the
  jboss-all/server module in MAIN, but is the entire server environment
 for
  2.4.
 
  You can not simply build this module by itself.  It depends on the
  jboss-all/j2ee and jboss-all/naming modules as well as the thirdparty
 and
  tools modules.
 
 Does the stuff in j2ee and naming depend on other jboss items?  Do they
 depend
 on the jboss module?  If no, then I started at the wrong spot.
 
 Making a deb of naming first, then j2ee, then finally jboss, is perfectly
 fine, as far as normaly Debian packaging goes.
 
 Is everything in thirdparty exact copies of external libraries, that get
 built, or just checked in pre-compiled version, or a mixture of the two?
 
 In either case, since they are third party modules, and not part of
 jboss,
 they can not be packaged with jboss in Debian.
 
 What I will end up doing(and have already started, I made a jaxp.deb
 tonight),
 is packaging each one of these external bits of code, by going to the
 proper
 location upstream, and packaging what they release.
 
 If jboss has patched these upstream sources, have the patches then been
 sent
 upstream?
 
  If you are trying to build a 3.0 .deb then please use the 'jboss-all'
 module
  from cvs and use 'build/build.sh release' to create a release suitable
 for
  stuffing into the package.  The files will be inder
 'build/output/jboss-*/
 
 I'm not building a single jboss deb.  What I have done for 2.4, is make
 separate debs, split along the same lines as each top-level directory in
 the
 2.4.3 tarball.
 
 The list of packages follows:
 
 jboss jboss-server jboss-transaction jboss-tomcat-service jboss-client
 jboss-admin jboss-common jnp-server jnp-client jbossmq jbossmq-client
 jbosssx
 jbosssx-client jboss-contrib-hsqldb jboss-contrib-oswego
 jboss-contrib-tyrex
 jboss-contrib-castor jboss-contrib jboss-dev jboss-docs
 
 jboss-contrib contains external sources, that shouldn't be part of the
 final
 jboss deb framework.  I put them there, to make it quicker for me to get
 things going.
 
 jboss-contrib-* are things that I have identify as being DFSG-free, and
 should
 be packaged separately, by going to each upstream location.  After that
 is
 done, jboss would then just depend on those.
 
 jboss-transaction and jboss-contrib-tyrex both provide transaction
 services,
 and can't be installed at the same time.
 
 The -client packages are for use on system that talks to a remote jboss
 server.
 
 jboss-server has an init script, and starts the jboss server as a
 separate
 user(jboss).  jnp-server is the same, but the user is jnp-server.
 
 jboss-tomcat-service depends on tomcat.deb.  Because of the way
 tomcat.deb is
 layed out, tomcat.home needs to be set correctly for it to build. 
 However,
 the TomcatService stuff in jboss doesn't support setting tomcat.home, so
 I
 made a patch for it(see my earlier email).
 
 Finally, package jboss is an empty package, that depends on all the other
 appriopriate packages, so that once they are all installed, you end up
 with
 jboss-tomcat.tar.gz.
 
 Additionally, to support all these splits, I chopped jboss.conf and
 jboss.jcml
 into configuration fragments.  Each deb can then include a config
 fragment,
 and I rebuild the config files when the debs are installed.  I understand
 that
 3.0 does this completely differently, which means my work will be wasted.
 That's fine by me, as what I have seen discussed on this list in the last
 few
 days seems quite nice(the -service stuff).
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 

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

RE: [JBoss-dev] can't build jboss from cvs

[Adam Heath]

On Wed, 14 Nov 2001, Jason Dillon wrote:

 If you are trying to build a 3.0 .deb then please use the 'jboss-all' module
 from cvs and use 'build/build.sh release' to create a release suitable for
 stuffing into the package.  The files will be inder 'build/output/jboss-*/

Ok, I've done this, and everything has built fine.

The layout of build/output looks useable, and I can produce debs from that.
I'll be moving stuff around, to make it fit properly in FHS.  I'll be making
some things into symlinks, to give jboss a correct view on the world.  In
other cases, I'll modify the configuration files to access the correct
locations directly.

Now, to the biggest issue with all this.  Could the final jboss tarball that
is created, *NOT* have any external source?  I can understand having a tarball
that does have this source, but could it be called jboss-bundle-src.tar.gz, or
something.  If there is no source tarball that is in this pristince state,
then I will not be able to upload jboss to Debian, because then it would mean
that Debian is distributing non-free software, which is not allowed.

Making debs of course, doesn't really matter about what is included and what
isn't.  But for actual upload to the Debian archive(and all its mirrors), I
*NEED* this non-free code and external code removed from the source tarball.
Even if this means the build system contains broken references to these
missing files, that is fine.

Additionally, I tried setting build.compiler=jikes in build/build.xml, but it
didn't compile blindly fast.  Is this the correct way to use jikes?


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

Re: [JBoss-dev] Separating JMX/EJB

[Rickard Öberg]

marc fleury wrote:

 we agree on the metaprogramming, we are going to make it dynamic too,
 
 some other day I will publish a white paper :) Let Rickard fire first


I intend to write a whitey on it some day too, but basically it goes 
something like this:
* Meta-programming is good, but not inherent to EJB
* The EJB programming model in general is flawed. (See EJB-INTEREST for 
lots of conflicting answers to common questions. If experts can't figure 
it out, how are mortals supposed to?!)
* In particular, dynamic (re)configuration of EJB is not possible, and 
it should be (compare with JMX/Jini)
* The EJB persistence model is flawed, compared with JDO.

/Rickard

-- 
Rickard Öberg


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