[Xdoclet-user] RE: [JBoss-dev] XDoclet in /tools has BUGSSSSSS

[Vincent Harcq]

Andy,
David has tagged xdoclet cvs with a Jboss specific tag sometimes ago.
The version today is very very more confident for CMP.
Come and tag whenever you want :)  Don't forget (amazing) xjavadoc.

I take the opportunity to launch a call for help (crossed post to
xdoclet lists)
There are still some issues (fucking bugs is a better word imho) with
Jboss 3 CMP 2 engine.
If somebody can report Unit Tests for that it would be great.
The idea is simple : provide two beans with generic names
(OneOneMasterCMPBean, OneOneChildCMPBean, OneManyMasterCMPBean,
OneManyChildCMPBean, etc...) with all needed xdoclet tags PLUS a
"reference" ejb-jar.xml PLUS a "reference" jboss-cmp.xml.
That's all.  
Then the unit tests system will generate the DD, do xml comparisons and
report errors.
Very easy.
Come to xdoclet devel to help.  
This is unacceptable that weblogic cmp works and not jboss.

Thanks.

Vincent

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Andreas Schaefer
> Sent: jeudi 18 avril 2002 8:27
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [JBoss-dev] XDoclet in /tools has BUGSS
> 
> 
> Hi David
> 
> What shall I do with you ?
> 
> The current XDoclet in /tools is buggy !!!
> It does not work with EJB-CMP column-names
> (the good old "@jboss:column-name" is not
> working and the new "@ejb-persistence" is not
> working, either).
> 
> ATTENTION: when you change /tools you change
> this also for "jboss-website" (maybe more).
> 
> Maybe it would be a good idea if we label "beta"
> archives with another name to indicate that this
> is not a fully tested version ?
> 
> Have fun
> 
> x
> Andreas Schaefer
> Senior Consultant
> JBoss Group, LLC
> x
> 
> 
> 
> ___
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 


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


___
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user


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

RE: [JBoss-dev] Waaaaaaaaooooooooouuuuwwwwwwww

[Vincent Harcq]

The MESSAGE is more important than the details.  
Pluggable, micro kernel, add-on products, add-on services, free base
product.
2.4/3.0 does not mind here.
You do not choose a product after reading a "best of" vote from anybody.
Jboss is recognized now.
Peace.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Yannick Menager
> Sent: mercredi 27 mars 2002 22:23
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Wo
> 
> 
> Erm. quite honestly, those guys at Javaworld must have been drunk 
> when they made those awards. I mean, JBoss is quite good, and 
> I'm using 
> it, but comparing JBoss 2.4.x and Weblogic 6.1 is ridiculous, they're 
> not even in the same league, as 2.4 doesn't even has clustering 
> support... If they were talking about 3.0, at least, I could 
> understand 
> but saying 2.4 is better than wls 6.x and websphere is really 
> streching 
> the limits of imagination.
> 
> Vincent Harcq wrote:
> 
>http://www.javaworld.com/javaworld/jw-03-2002/jw-0326-awards-p3.html
>
>
>___
>Jboss-development mailing list [EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development
>



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


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


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


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

[JBoss-dev] Waaaaaaaaooooooooouuuuwwwwwwww

[Vincent Harcq]

http://www.javaworld.com/javaworld/jw-03-2002/jw-0326-awards-p3.html


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

[JBoss-dev] Jboss DTD for xdoclet bundle

[Vincent Harcq]

Hi,

I wanted to update Jboss DTD before release xdoclet release 1.1.2 but I
am not sure what is needed on the DTD side.
We package them in xdoclet to permit xml validation at the end of their
generation.

Do we have to maintain DTD that not have _x_y in them ?
I remember that the rule is that the jboss.dtd, jaws.dtd, jboss-cmp.dtd
and jboss-web.dtd are only used for future developement.
As soon as _x_y are created they should not be used by the "users".

Am I correct here ?

Then I maybe found an exception : there no jboss-web_2_4.dtd.

TIA.
Vincent.


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

RE: [JBoss-dev] New jboss_3_0.dtd

[Vincent Harcq]

I think Local-jndi-name is missing for 3 bean types

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Scott M Stark
> Sent: vendredi 8 février 2002 18:36
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] New jboss_3_0.dtd
> 
> 
> Thanks for update.
> 
> 
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> 
> - Original Message -
> From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, February 08, 2002 7:37 AM
> Subject: [JBoss-dev] New jboss_3_0.dtd
> 
> 
> > Hi All
> >
> > I have just checked in a new jboss_3_0.dtd file (and added local 
> > resolve
> to
> > XmlFileLoader).
> >
> > Several changes were made recently to jboss.xml and there 
> have been a 
> > couple of posts about where to put dtd changes.
> >
> > The official line is:-
> > jboss.dtdwas suposed to be frozen for 2.2
> > and jboss_2_4.dtd frozen for the 2_4 branch (the gospel according to
> Scott:-)
> >
> > Any changes made for 3.0 must go into jboss_3_0.dtd. jboss.dtd 
> > shouldn't be touched. jboss_2_4.dtd should only be touched if the 
> > change affects the 2_4 branch.
> >
> > I have trawled the existing jboss dtd files and the 
> metadata classes 
> > that read the dtds. I have put in everything I could find. 
> Some of it 
> > is commented - some of it isn't.
> >
> > I think I've got everything, but
> >
> > Please can anyone who has added to jboss.xml/standardjboss.xml or 
> > jboss.dtd/jboss_2_4.dtd in the last month or two check the new 
> > jboss_3_0.dtd and make sure their changes are correct. Also add 
> > comments where appropriate or drop me an email and I'll do it.
> >
> > thanks
> >
> > Mike Swainston-Rainford
> >
> 
> 
> 
> ___
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 



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


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

RE: [JBoss-dev] JBOSS @ JAVAONE TSHIRT CONTEST

[Vincent Harcq]

Front: One j2ee server to rule them all, One j2ee server to find them,
One j2ee server to bring them all
Back : and in the darkness bind them. 



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


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

RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java

[Vincent Harcq]

I am currently working on this.
I have a problem with entity pool.
It is in the case of reclaim is true.
There is one case when the EntityInstancePool will not send back the
instance to the pool : when EntityInstancePool.free() is called inside a
transaction, here the instance will be thrown away.
So if I change the counting algorithm to take into account how many
instance are currently in use, I may come to a point where I will never
come back to the MaximumSize because some instances will be lost.

After looking further, this problem will also arise with stateless
session bean in case of errors (StatelessSessionInterceptor.invoke()).

Could we just NOT verify the maximumsize when pushing back to the pool
and eventually have more instances in the pool that MaximumSize.  The
StrictMaximumSize would solve the problem when people really need it ?

Vincent.


> There is another issue with how the feeder interacts with the 
> pool. The getCurrentSize is really the pool free instance 
> count. Only on startup is this also the pool count. After the 
> pool has been filled once, (MaximumSize - getCurrentSize) is 
> no longer how many instances need to be added to the pool. 
> Say MaximumSize is 10 and the pool is filled by the feeder. 
> Next 10 clients invoke methods concurrently and take the pool 
> free count to 0 and getCurrentSize is also 0. The feeder then 
> wakes up and puts 10 more instances into the pool. The client 
> invocations next complete and all 10 instances are discarded 
> as the pool is seen to be full. The AbstractInstancePool is 
> not counting instances correctly when another thread is 
> adding instances.
> 



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


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

RE: [JBoss-dev] Destroying cmp BEAN instances

[Vincent Harcq]

Title: Message



Wow 
:)
And 
all that free for us, users so that we can ask free advices, complain, 
...
Thank 
you !

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]] On Behalf Of 
  marc fleurySent: jeudi 17 janvier 2002 21:43To: 
  [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Björn Blum'; 'JBOSS 
  DEV'Subject: RE: [JBoss-dev] Destroying cmp BEAN 
  instances
  forums WILL be back online, 
   
  we 
  have a machine at DenverOnline that will take care of static website, and we 
  are getting a machine at Rackspace that will do nothing but forums on RAID 1 
  and all.  We are getting the machine tomorrow, I will try to salvage the 
  data from the forums.
   
  the 
  new installation is fully redundant with DAT tape rotation taken care of by 
  rackspace etc etc, I will let you know on the data restoring as soon as I 
  know
   
  marcf
  
-Original Message-From: Vincent Harcq 
[mailto:[EMAIL PROTECTED]]Sent: Thursday, January 17, 2002 
9:38 AMTo: 'marc fleury'; [EMAIL PROTECTED]; 'Björn Blum'; 
'JBOSS DEV'Subject: RE: [JBoss-dev] Destroying cmp BEAN 
instances
As 
somebody point me on (defunct) Forums, calling a method that simply 
throws an RunTimeException should unvalidate the CMP 
Bean.
 
In EJB 2.0 and 1.1, all 
non-application exceptions thrown by the instance result in the 
rollback
of the transaction in which the 
instance executed, and in discarding the instance.

Having an MBean could be simpler anyway.
 
With that feature inside the container, would you find useful to have 
something like  a la Seppuku ?  https://sourceforge.net/tracker/?func=detail&aid=502757&group_id=22866&atid=376688
 
Vincent

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]] On Behalf Of 
  marc fleurySent: jeudi 17 janvier 2002 19:16To: 
  [EMAIL PROTECTED]; 'Björn Blum'; 'JBOSS DEV'Subject: RE: 
  [JBoss-dev] Destroying cmp BEAN instances
  Bill didn't you say you wanted to tackle that 
  problem?
   
  Seems like I won't be able to finish the deployer so you have 10 
  days :)
   
  marcf
  
-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of 
Bill BurkeSent: Thursday, January 17, 2002 7:08 
AMTo: 'Björn Blum'; 'JBOSS DEV'Subject: RE: 
[JBoss-dev] Destroying cmp BEAN instances
You mean clear the cache?  The caches are 
not exposed through mbeans, so there is no way to do this.  Please 
log a feature request at sourceforge

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of 
  Björn BlumSent: Thursday, January 17, 2002 3:51 
  AMTo: JBOSS DEVSubject: [JBoss-dev] Destroying 
  cmp BEAN instances
  Hello,
   
  may 
  somebody tell me, how i can force the container of the app server to 
  destroy some instances of cmp beans? (Sorry, if this question is 
  foolish, but I'm new in developing with EJBs and 
  JBOSS)
   
  thanx 
  bjoern

RE: [JBoss-dev] Destroying cmp BEAN instances

[Vincent Harcq]

Title: Message



As 
somebody point me on (defunct) Forums, calling a method that simply throws 
an RunTimeException should unvalidate the CMP Bean.

In EJB 2.0 and 1.1, all non-application 
exceptions thrown by the instance result in the rollback
of the transaction in which the 
instance executed, and in discarding the instance.

Having 
an MBean could be simpler anyway.
 
With 
that feature inside the container, would you find useful to have something like 
 a la Seppuku ?  https://sourceforge.net/tracker/?func=detail&aid=502757&group_id=22866&atid=376688
 
Vincent

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]] On Behalf Of 
  marc fleurySent: jeudi 17 janvier 2002 19:16To: 
  [EMAIL PROTECTED]; 'Björn Blum'; 'JBOSS DEV'Subject: RE: 
  [JBoss-dev] Destroying cmp BEAN instances
  Bill 
  didn't you say you wanted to tackle that problem?
   
  Seems like I won't be able to finish the deployer so you have 10 days 
  :)
   
  marcf
  
-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On Behalf Of 
Bill BurkeSent: Thursday, January 17, 2002 7:08 
AMTo: 'Björn Blum'; 'JBOSS DEV'Subject: RE: 
[JBoss-dev] Destroying cmp BEAN instances
You mean clear the cache?  The caches are not 
exposed through mbeans, so there is no way to do this.  Please log a 
feature request at sourceforge

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of 
  Björn BlumSent: Thursday, January 17, 2002 3:51 
  AMTo: JBOSS DEVSubject: [JBoss-dev] Destroying cmp 
  BEAN instances
  Hello,
   
  may somebody 
  tell me, how i can force the container of the app server to destroy some 
  instances of cmp beans? (Sorry, if this question is foolish, but I'm new 
  in developing with EJBs and JBOSS)
   
  thanx 
  bjoern

RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java

[Vincent Harcq]

OK,
Just to say I will work on these things as soon as I can.


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Scott M Stark
> Sent: dimanche 30 décembre 2001 20:43
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] CVS update: 
> jboss/src/main/org/jboss/ejb/plugins 
> AbstractInstancePool.java 
> MessageDrivenInstanceInterceptor.java 
> StatefulSessionInstanceInterceptor.java 
> StatelessSessionInstanceInterceptor.java
> 
> 
> The testcase would set a class flag in the bean class if an 
> exception occurred in the setSessionContext method. When the 
> unit tests run and invoke a method on a bean, the bean would 
> check this flag in its only business method and throw an exception.
> 
> The simplest intermediate fix is to delay the start of the 
> feeder timer by 10 seconds or so. More exacting startup 
> criteria can be dealt with as needed.
> 
> There is another issue with how the feeder interacts with the 
> pool. The getCurrentSize is really the pool free instance 
> count. Only on startup is this also the pool count. After the 
> pool has been filled once, (MaximumSize - getCurrentSize) is 
> no longer how many instances need to be added to the pool. 
> Say MaximumSize is 10 and the pool is filled by the feeder. 
> Next 10 clients invoke methods concurrently and take the pool 
> free count to 0 and getCurrentSize is also 0. The feeder then 
> wakes up and puts 10 more instances into the pool. The client 
> invocations next complete and all 10 instances are discarded 
> as the pool is seen to be full. The AbstractInstancePool is 
> not counting instances correctly when another thread is 
> adding instances.
> 
> - Original Message -
> From: "Vincent Harcq" <[EMAIL PROTECTED]>
> To: "'Scott M Stark'" <[EMAIL PROTECTED]>; 
> <[EMAIL PROTECTED]>
> Sent: Sunday, December 30, 2001 3:17 AM
> Subject: RE: [JBoss-dev] CVS update: 
> jboss/src/main/org/jboss/ejb/plugins
> AbstractInstancePool.java MessageDrivenInstanceInterceptor.java
> StatefulSessionInstanceInterceptor.java
> StatelessSessionInstanceInterceptor.java
> 
> 
> 
> 
> ___
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 



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


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

[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jaws_2_4.dtd jaws_3_0.dtd

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/30 03:26:58

  Modified:src/resources/org/jboss/metadata jaws_2_4.dtd jaws_3_0.dtd
  Log:
  Missing jdbc-type and sql-type on cmp-field element
  
  Revision  ChangesPath
  1.6   +1 -1  jboss/src/resources/org/jboss/metadata/jaws_2_4.dtd
  
  Index: jaws_2_4.dtd
  ===
  RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws_2_4.dtd,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jaws_2_4.dtd  2001/07/12 17:39:47 1.5
  +++ jaws_2_4.dtd  2001/12/30 11:26:58 1.6
  @@ -74,7 +74,7 @@
in ejb-jar.xml. -->
   
   
  -
  +
   
   
   
  
  
  
  1.3   +1 -1  jboss/src/resources/org/jboss/metadata/jaws_3_0.dtd
  
  Index: jaws_3_0.dtd
  ===
  RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws_3_0.dtd,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jaws_3_0.dtd  2001/12/05 05:05:34 1.2
  +++ jaws_3_0.dtd  2001/12/30 11:26:58 1.3
  @@ -71,7 +71,7 @@
in ejb-jar.xml. -->
   
   
  -
  +
   
   
   
  
  
  

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

RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java

[Vincent Harcq]

There is no test case I could write to show this problem.  When an
exception occurs in set...Context(), the instance is not push in the
pool which is correct.  When everything is ready to avoid these
exceptions, the pool will begin to grow.  If a direct get() is made an
exception will be thrown as before so I guess it is also OK.
BTW, the postinit is not the best idea.  An independant Mbean could take
care of starting the pool feeder after the deployment.  It could then
also be paused during redeployment.
I am ok to leave this problem, ... Or fix it myself the way you want.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Scott M Stark
> Sent: dimanche 30 décembre 2001 7:27
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] CVS update: 
> jboss/src/main/org/jboss/ejb/plugins 
> AbstractInstancePool.java 
> MessageDrivenInstanceInterceptor.java 
> StatefulSessionInstanceInterceptor.java 
> StatelessSessionInstanceInterceptor.java
> 
> 
> Oh, well, that is what comments and test cases are for. Add a 
> test case that demonstrates the problem and I'll fix this in 
> the next release.
> 
> > Hi,
> > There is a reason why I did not start the pool from the 
> > ContainerFactory (well another that the classloader issue that you 
> > fixed ;) ) The setSessionContext have, in most cases, Home 
> lookup (to 
> > cache them) and if all beans are not deployed you can have 
> JNDI lookup 
> > failure (when using flat ejb-jar's for example).  It is a 
> problem that 
> > can happen in other cases as well I must agree and that the 
> developer 
> > should take care of, but it appears as a "Jboss bug" when you first 
> > see it. I can only see one solution : have a postinit() method in 
> > container that is called when all containers have started.
> >
> > Vincent.
> - Original Message -
> From: "Vincent Harcq" <[EMAIL PROTECTED]>
> To: "'Scott M Stark'" <[EMAIL PROTECTED]>; 
> <[EMAIL PROTECTED]>
> Sent: Saturday, December 29, 2001 6:15 PM
> Subject: RE: [JBoss-dev] CVS update: 
> jboss/src/main/org/jboss/ejb/plugins
> AbstractInstancePool.java MessageDrivenInstanceInterceptor.java
> StatefulSessionInstanceInterceptor.java
> StatelessSessionInstanceInterceptor.java
> 
> 
> 
> 
> ___
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 



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


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

RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java

[Vincent Harcq]

Hi,
There is a reason why I did not start the pool from the ContainerFactory
(well another that the classloader issue that you fixed ;) )
The setSessionContext have, in most cases, Home lookup (to cache them)
and if all beans are not deployed you can have JNDI lookup failure (when
using flat ejb-jar's for example).  It is a problem that can happen in
other cases as well I must agree and that the developer should take care
of, but it appears as a "Jboss bug" when you first see it.
I can only see one solution : have a postinit() method in container that
is called when all containers have started.

Vincent.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Scott M Stark
> Sent: vendredi 28 décembre 2001 23:35
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] CVS update: 
> jboss/src/main/org/jboss/ejb/plugins 
> AbstractInstancePool.java 
> MessageDrivenInstanceInterceptor.java 
> StatefulSessionInstanceInterceptor.java 
> StatelessSessionInstanceInterceptor.java
> 
> 
>   User: starksm 
>   Date: 01/12/28 14:35:14
> 
>   Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
> AbstractInstancePool.java
> MessageDrivenInstanceInterceptor.java
> StatefulSessionInstanceInterceptor.java
> StatelessSessionInstanceInterceptor.java
>   Log:
>   Add a strict pooling behavior that limits the number of 
> instances to that
>   specified by the container-pool-conf/MaximumSize
>   
>   Revision  ChangesPath
>   No   revision
>   
>   
>   No   revision
>   
>   
>   1.9.6.6   +138 -65   
> jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java
>   
>   Index: AbstractInstancePool.java
>   ===
>   RCS file: 
> /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractIn
> stancePool.java,v
>   retrieving revision 1.9.6.5
>   retrieving revision 1.9.6.6
>   diff -u -r1.9.6.5 -r1.9.6.6
>   --- AbstractInstancePool.java   2001/12/27 19:41:16 1.9.6.5
>   +++ AbstractInstancePool.java   2001/12/28 22:35:13 1.9.6.6
>   @@ -17,24 +17,26 @@
>import org.jboss.ejb.EnterpriseContext;
>
>import org.w3c.dom.Element;
>   +
>   +import EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore;
>   +
>import org.jboss.deployment.DeploymentException;
>import org.jboss.metadata.MetaData;
>import org.jboss.metadata.XmlLoadable;
>import org.jboss.logging.Logger;
>
>/**
>   - *  
> * Abstract Instance Pool class containing the basic logic 
> to create
> *  an EJB Instance Pool.
>   - *  
> *
> * @see 
> * @author  href="mailto:[EMAIL PROTECTED]";>Rickard Öberg
> * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
>   - *  @author  href="mailto:[EMAIL PROTECTED]";>Andreas Schaefer
>   - *  @author  href="mailto:[EMAIL PROTECTED]";>Sacha Labourey
>   + * @author  href="mailto:[EMAIL PROTECTED]";>Andreas Schaefer
>   + * @author  href="mailto:[EMAIL PROTECTED]";>Sacha Labourey
>   + * @author mailto:[EMAIL PROTECTED]";>Scott Stark/a>
> *
>   - *  @version $Revision: 1.9.6.5 $
>   + * @version $Revision: 1.9.6.6 $
> *
> *  Revisions:
> *  20010704 marcf:
>   @@ -56,19 +58,26 @@
>   // Constants 
> -
>
>   // Attributes 
> 
>   +   /** A semaphore that is set when the strict max size 
> behavior is in effect.
>   +When set, only maxSize instance may be active and any 
> attempt to get an
>   +instance will block until an instance is freed.
>   +*/
>   +   private FIFOSemaphore strictMaxSize;
>   +   /** The time in milliseconds to wait for the 
> strictMaxSize semaphore.
>   +*/
>   +   private long strictTimeout = Long.MAX_VALUE;
>   +   /** The logging interface */
>   protected Logger log = Logger.getLogger(this.getClass());
>   -
>   +   /** The Container the instance pool is associated with */
>   protected Container container;
>   -
>   /** The instance pool stack */
>   protected Stack pool = new Stack();
>   /** The maximum number of instances allowed in the pool */
>   protected int maxSize = 30;
>   /** determine if we reuse EnterpriseContext objects 
> i.e. if we actually do pooling */
>   protected boolean reclaim = false;
>   -
>   +   /** The pool seed task set from the feeder-policy 
> config element */
>   protected InstancePoolFeeder poolFeeder;
>   -   protected boolean useFeeder = false;
>
>   // Static 
> 
>
>   @@ -103,14 +112,14 @@
>   public void start()
>  throws Exception
>   {
>   +  if( poolFeeder != null && poolFeeder.isStarted() == false )
>   + poolFeeder.start();
>   }
>
>   public void stop()
>   {
>   -

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/27 19:47:11

  Modified:src/etc/conf/default standardjboss.xml
  Log:
  Restore the AbstractInstancePool MaximumSize and add a getMaxSize() method to 
InstancePool. The getMaxSize() method is used by TimedInstancePoolFeeder  instead of 
the capacity element
  
  Revision  ChangesPath
  1.30  +16 -16jboss/src/etc/conf/default/standardjboss.xml
  
  Index: standardjboss.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- standardjboss.xml 2001/12/23 19:50:47 1.29
  +++ standardjboss.xml 2001/12/28 03:47:11 1.30
  @@ -7,7 +7,7 @@
   
   
   
  -
  +
   
   
  false
  @@ -51,9 +51,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -97,9 +97,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -145,9 +145,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -191,9 +191,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -237,9 +237,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -272,9 +272,9 @@
True
 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -306,9 +306,9 @@
True
 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -340,9 +340,9 @@
True
 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -388,9 +388,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -436,9 +436,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -485,9 +485,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -530,9 +530,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -576,9 +576,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -622,9 +622,9 @@

 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  @@ -668,9 +668,9 @@
   
 

  +100
   org.jboss.ejb.plugins.TimedInstancePoolFeeder
   
  -100
   10
   500
   
  
  
  

___
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 AbstractInstancePool.java EntityInstancePool.java SingletonStatelessSessionInstancePool.java TimedInstancePoolFeeder.java

[Vincent Harcq]

  
jboss/src/main/org/jboss/ejb/plugins/TimedInstancePoolFeeder.java
  
  Index: TimedInstancePoolFeeder.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/TimedInstancePoolFeeder.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TimedInstancePoolFeeder.java  2001/12/23 19:50:47 1.1
  +++ TimedInstancePoolFeeder.java  2001/12/28 03:47:10 1.2
  @@ -1,34 +1,24 @@
   /*
  - * JBoss, the OpenSource EJB server
  - *
  - * Distributable under LGPL license.
  - * See terms of license at gnu.org.
  - */
  +* JBoss, the OpenSource EJB server
  +*
  +* Distributable under LGPL license.
  +* See terms of license at gnu.org.
  +*/
   package org.jboss.ejb.plugins;
   
  -import org.jboss.ejb.InstancePool;
  -import org.jboss.ejb.InstancePoolFeeder;
  +import java.util.TimerTask;
  +import java.util.Timer;
   
  -import org.jboss.logging.Logger;
  +import org.w3c.dom.Element;
   
  +import org.jboss.deployment.DeploymentException;
  +import org.jboss.ejb.InstancePool;
  +import org.jboss.ejb.InstancePoolFeeder;
   import org.jboss.metadata.XmlLoadable;
   import org.jboss.metadata.MetaData;
   
  -import org.jboss.deployment.DeploymentException;
  -
  -import org.w3c.dom.Element;
  -
  -import java.util.TimerTask;
  -import java.util.Timer;
  -
   /**
  - * Implementation of Pool feeder that is a java.util.Timer that checks at
  - * regular period the size of the pool and bring it closer to its capacity by
  - * adding a number of new instances.
*
  - * @author mailto:[EMAIL PROTECTED]";>Vincent Harcq
  - *
  - * @version $Revision: 1.1 $
*/
   public class TimedInstancePoolFeeder
 extends TimerTask
  @@ -36,11 +26,11 @@
   {
   
  // Private ---
  -
  +   /** The instance pool we feed */
  private InstancePool ip;
  -
  +   /** The rate in milliseconds between updates to the InstancePool */
  private int rate;
  -   private int capacity;
  +   /** The number of instances to add to the pool each period */
  private int increment;
   
  private Timer timer;
  @@ -48,9 +38,7 @@
   
  // Constructor ---
   
  -   public TimedInstancePoolFeeder()
  -   {
  -   }
  +   public TimedInstancePoolFeeder(){}
   
  // Public 
   
  @@ -58,6 +46,7 @@
  {
 try
 {
  + int capacity = ip.getMaxSize();
if (ip.getCurrentSize() < capacity)
{
   for (int i=0 ; i < increment ; i++)
  @@ -104,14 +93,12 @@
  // XmlLoadable Impl --
   
  public void importXml(Element element)
  -   throws DeploymentException
  +  throws DeploymentException
  {
 try
 {
Element instancePoolConf = MetaData.getUniqueChild(element, 
"feeder-policy-conf");
Element tmp;
  - tmp = MetaData.getUniqueChild(instancePoolConf,"capacity");
  - capacity = Integer.parseInt(MetaData.getElementContent(tmp));
tmp = MetaData.getUniqueChild(instancePoolConf,"increment");
increment = Integer.parseInt(MetaData.getElementContent(tmp));
tmp = MetaData.getUniqueChild(instancePoolConf,"period");
  
  
  

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

[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss.dtd

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/27 19:47:11

  Modified:src/resources/org/jboss/metadata jboss.dtd
  Log:
  Restore the AbstractInstancePool MaximumSize and add a getMaxSize() method to 
InstancePool. The getMaxSize() method is used by TimedInstancePoolFeeder  instead of 
the capacity element
  
  Revision  ChangesPath
  1.17  +156 -152  jboss/src/resources/org/jboss/metadata/jboss.dtd
  
  Index: jboss.dtd
  ===
  RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss.dtd,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- jboss.dtd 2001/12/23 19:50:47 1.16
  +++ jboss.dtd 2001/12/28 03:47:11 1.17
  @@ -1,6 +1,6 @@
   
   
  -
  -
   
  @@ -103,67 +103,67 @@
   level using the authentication-module and role-mapping-manager elements.
   -->
   
  +
  +
   
   
   
   
   
   
   
   
  -
   
   
   
   
   
   
   
  @@ -177,69 +177,69 @@
   -->
   
   
  -
   
   
  -
   
   
  -
   
  -
   
   
  -
   
   
  -
   
   
   
   
   
   
   
  @@ -284,53 +284,53 @@
   
   
   
   
   
  -
   
   
  -
   
   
  -
   
   
  -
   
   
   
   
  @@ -357,19 +357,19 @@
   
   
   
  -
   
  @@ -411,78 +411,78 @@
   
   
   
   
   
   
   
   
   
   
   
   
   
  -
   
   
  -
   
  @@ -500,7 +500,7 @@
   
   Its value must an integer (0, or a valid port number).  Note that
normal user on a UNIX system cannot access privileged ports (<1024)
  -
  +
   Used in: container-invoker-conf for JRMPContainerInvoker
-->
   
  @@ -539,13 +539,13 @@
-->
   
   
  -
   
   
  -
  -
  +
  +
  +
  +
  +
  +
  -
   
  -
  -
  +
   
   
   
   
   
   
  @@ -680,15 +684,15 @@
 This option is only used for entity container configurations.
   
 The commit-option element tells the container which option to use for 
transactions.
  -  Its value must be A, B or C. 
  +  Its value must be A, B or C.
   
  -  - option A: the entiry instance has exclusive access to the database. The 
instance 
  +  - option A: the entiry instance has exclusive access to the database. The 
instance
 stays ready after a transaction.
  -  - option B: the entity instance does not have exclusive access to the 
database. 
  +  - option B: the entity instance does not have exclusive access to the 
database.
 The state is loaded before the next transaction.
  -  - option C: same as B, except the container does not keep the instance after 
commit: 
  +  - option C: same as B, except the container does not keep the instance after 
commit:
 a passivate is immediately performed after the commit.
  -  
  +
 See ejb1.1 specification for details (p118).
   
 Used in: container-configuration
  
  
  

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

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/27 19:47:11

  Modified:src/main/org/jboss/ejb InstancePool.java
  Log:
  Restore the AbstractInstancePool MaximumSize and add a getMaxSize() method to 
InstancePool. The getMaxSize() method is used by TimedInstancePoolFeeder  instead of 
the capacity element
  
  Revision  ChangesPath
  1.10  +8 -1  jboss/src/main/org/jboss/ejb/InstancePool.java
  
  Index: InstancePool.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/InstancePool.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- InstancePool.java 2001/12/23 19:50:47 1.9
  +++ InstancePool.java 2001/12/28 03:47:11 1.10
  @@ -13,7 +13,7 @@
* Defines the model for a EnterpriseContext instance pool.
*
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
  - * @version $Revision: 1.9 $
  + * @version $Revision: 1.10 $
*
* Revisions:
* 20010718 andreas schaefer:
  @@ -72,6 +72,13 @@
   * @return the size of the pool.
   */
  int getCurrentSize();
  +
  +   /**
  +* Get the maximum size of the pool.
  +*
  +* @return the size of the pool.
  +*/
  +   public int getMaxSize();
   
   }
   
  
  
  

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

RE: [JBoss-dev] JBOSS EJB Container Bug ?!

[Vincent Harcq]

Without a feeder-policy, the MaxSize have no meaning : the pool never
grows.
In other words, having to define the size of something that don't grow
seemed confusing to me.
So I thought it was better to make it a part of feeder-policy-conf.
Then I choose to change the name from MaxSize to capacity to avoid
confusion with previous definition/place inside the xml.

If you consider this is more confusing, I can change it to:


100

org.jboss.ejb.plugins.TimedInstancePoolFeeder

10
500



Vincent.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Scott M Stark
> Sent: jeudi 27 décembre 2001 19:14
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?!
> 
> 
> So why was the MaxSize dropped and a feeder pool capacity 
> config element added? The instance pool now grows to the 
> maximum concurrent use count and capacity is a redundant item 
> that should simply be the pool MaxSize value.
> 
> 
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxx
> - Original Message -
> From: "Vincent Harcq" <[EMAIL PROTECTED]>
> To: "'jeff andrews'" <[EMAIL PROTECTED]>; 
> <[EMAIL PROTECTED]>
> Sent: Thursday, December 27, 2001 9:06 AM
> Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?!
> 
> 
> > Hi,
> >
> > On 2.4 the pool is never pre-feed with new instances, 
> instead the pool 
> > is feed after the use of an instance. And depending on the 
> x in 2.4.x, 
> > the pool may have a size of 1 all the time (no reuse at all).
> > There were good reasons for that linked to locking, read 
> archives if you
> > want more infos.
> >
> > Check this : 
> > 
> https://sourceforge.net/tracker/?func=detail&aid=496326&group_id=22866
> > &a
> > tid=381174
> >
> > It will work on Jboss 2.4.4 latest cvs but the dtd/xml 
> files were not 
> > changed, you need to change standardjboss.xml like this : 
> > 
> >
> > 
> org.jboss.ejb.plugins.TimedInstancePoolFeeder > ol
> > icy>
> > 
> > 100
> > 10
> > 500
> > 
> > 
> >
> > Vincent.
> >
> > > Due to a previouse recommendation on one of these
> > > Forums,I have upgraded from JBoss_2.4.0-Tomcat_3.2.3
> > > to JBoss_2.4.3-Jetty_3.1.3-1. I'm running my JBoss
> > > on Linux.
> > >
> > > My problem/question is; How can I force the container
> > > pool
> > > configuration size of JBoss for a deployed stateless session bean 
> > > (for example)to not exceed a specified MaximumSize, based 
> on what I 
> > > have defined it to be in the jboss.xml file used for deployment??
> > >
> > > I tried many defferent kind of MaximumSizes, but it
> > > seems to me (from actual performance tests), that no
> > > matter what I specify as a MaximumSize for my deployed stateless 
> > > session bean, JBoss will always allocate a bean instance for each 
> > > request, even if the number of concurrent
> > > (client) requests to that bean (pool) exceeded the MaximumSize 
> > > specified for the bean's container pool configuration (specified 
> > > within jboss.xml at deployment time)The same kind of 
> behaviour 
> > > problem was also found with deployed stateful session 
> beans type as 
> > > well as deployed entity beans type!!!
> > >
> > > For example:
> > > If I set the container pool configuration (of my bean) 
> MinimumSize = 
> > > 1, and MaximumSize = 1 (Meaning that there should ONLY be 
> one bean 
> > > instance in the pool to be shared among requesting 
> clients).And 
> > > then I had 8 concurrent
> > > (clients) requests (at the same time). All 8 of those 
> requests were 
> > > able to get a remote reference to a bean instance (and 
> uses it) at 
> > > the same time. As apposed to all 8 sharing the single 
> bean instance 
> > > that should have ONLY bean in the pool...
> > >
> > > What am I messing ?!! Please help As I have bean 
> struggling with 
> > > this kind of a problem for over a month now.
> > >
> > > Jeff
> > >
> > >
> > > _
> > > Chat with friends online, try MSN Messenger: 
> > > http://messenger.msn.com
> > >
> > >
> > > 

RE: [JBoss-dev] JBOSS EJB Container Bug ?!

[Vincent Harcq]

Hi,

On 2.4 the pool is never pre-feed with new instances, instead the pool
is feed after the use of an instance.
And depending on the x in 2.4.x, the pool may have a size of 1 all the
time (no reuse at all).
There were good reasons for that linked to locking, read archives if you
want more infos.

Check this :
https://sourceforge.net/tracker/?func=detail&aid=496326&group_id=22866&a
tid=381174

It will work on Jboss 2.4.4 latest cvs but the dtd/xml files were not
changed, you need to change standardjboss.xml like this :


org.jboss.ejb.plugins.TimedInstancePoolFeeder

100
10
500



Vincent.

> Due to a previouse recommendation on one of these
> Forums,I have upgraded from JBoss_2.4.0-Tomcat_3.2.3
> to JBoss_2.4.3-Jetty_3.1.3-1. I'm running my JBoss
> on Linux.
> 
> My problem/question is; How can I force the container
> pool
> configuration size of JBoss for a deployed stateless
> session bean (for example)to not exceed a specified 
> MaximumSize, based on what I have defined it to be in the 
> jboss.xml file used for deployment??
> 
> I tried many defferent kind of MaximumSizes, but it
> seems to me (from actual performance tests), that no
> matter what I specify as a MaximumSize for my deployed 
> stateless session bean, JBoss will always allocate a bean 
> instance for each request, even if the number of concurrent 
> (client) requests to that bean (pool) exceeded the 
> MaximumSize specified for the bean's container pool 
> configuration (specified within jboss.xml at deployment 
> time)The same kind of behaviour problem was also found 
> with deployed stateful session beans type as well as deployed 
> entity beans type!!!
> 
> For example:
> If I set the container pool configuration (of my bean) 
> MinimumSize = 1, and MaximumSize = 1 (Meaning that there 
> should ONLY be one bean instance in the pool to be shared 
> among requesting clients).And then I had 8 concurrent 
> (clients) requests (at the same time). All 8 of those 
> requests were able to get a remote reference to a bean 
> instance (and uses it) at the same time. As apposed to all 8 
> sharing the single bean instance that should have ONLY bean 
> in the pool...
> 
> What am I messing ?!! Please help As I have bean
> struggling with this kind of a problem for over a month
> now.
> 
> Jeff
> 
> 
> _
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 
> 
> ___
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 



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


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

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/23 11:50:47

  Modified:src/main/org/jboss/ejb InstancePool.java
  Added:   src/main/org/jboss/ejb InstancePoolFeeder.java
  Log:
  Add a pool feeder to create asynchronously instances of beans and push them in the 
pool stack.
  Look at jboss.dtd for information on parameters
  
  Revision  ChangesPath
  1.9   +31 -8 jboss/src/main/org/jboss/ejb/InstancePool.java
  
  Index: InstancePool.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/InstancePool.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- InstancePool.java 2001/11/24 20:43:22 1.8
  +++ InstancePool.java 2001/12/23 19:50:47 1.9
  @@ -11,37 +11,52 @@
   
   /**
* Defines the model for a EnterpriseContext instance pool.
  - *  
  + *
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
  - * @version $Revision: 1.8 $
  - *  
  + * @version $Revision: 1.9 $
  + *
* Revisions:
* 20010718 andreas schaefer:
* 
* - Marked the InstancePool as Statistics Provider
* 
  + * 20011208 Vincent Harcq:
  + * 
  + *  Added a Pool Feeder (Thread that pre-create bean instances to avoid
  + *  setContext overhead.
  + * 
*/
   public interface InstancePool
  extends ContainerPlugin, StatisticsProvider
   {
  /**
  +*  Add an instance in the Pool.
  +*  Is used by the TimedInstancePoolFeeder thread to create instances ready for 
use by
  +*  the interceptor.
  +*
  +* @exception Exception when an Instance can not be instantiated
  +*/
  +   public void add()
  + throws Exception;
  +
  +   /**
   * Get an instance without identity.
  -* 
  +*
   * Can be used by finders and create-methods, or stateless beans
   *
   * @returnContext/w instance
  -* 
  -* @throws ExceptionRemoteException  
  +*
  +* @throws ExceptionRemoteException
   */
  EnterpriseContext get() throws Exception;
  -   
  +
  /**
   * Return an anonymous instance after invocation.
   *
   * @param ctxThe context to free.
   */
  void free(EnterpriseContext ctx);
  -   
  +
  /**
   * Discard an anonymous instance after invocation.
   * This is called if the instance should not be reused, perhaps due to some
  @@ -50,5 +65,13 @@
   * @param ctxThe context to discard.
   */
  void discard(EnterpriseContext ctx);
  +
  +   /**
  +* Return the size of the pool.
  +*
  +* @return the size of the pool.
  +*/
  +   int getCurrentSize();
  +
   }
   
  
  
  
  1.1  jboss/src/main/org/jboss/ejb/InstancePoolFeeder.java
  
  Index: InstancePoolFeeder.java
  ===
  /*
   * JBoss, the OpenSource EJB server
   *
   * Distributable under LGPL license.
   * See terms of license at gnu.org.
   */
  package org.jboss.ejb;
  
  import org.jboss.metadata.XmlLoadable;
  import org.jboss.ejb.InstancePool;
  
  /**
   * Interface for bean instances Pool Feeder
   *
   * @author mailto:[EMAIL PROTECTED]";>Vincent Harcq
   *
   * @version $Revision: 1.1 $
   */
  public interface InstancePoolFeeder
extends XmlLoadable
  {
  
 /**
  * Start the pool feeder.
  */
 public void start();
  
 /**
  * Stop the pool feeder.
  */
 public void stop();
  
 /**
  * Sets the instance pool inside the pool feeder.
  *
  * @param ip the instance pool
  */
 public void setInstancePool(InstancePool ip);
  
 /**
  * Tells if the pool feeder is already started.
  * The reason is that we start the PF at first get() on the pool and we
  * want to give a warning to the user when the pool is empty.
  *
  * @return true if started
  */
 public boolean isStarted();
  
  }
  
  
  

___
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 TimedInstancePoolFeeder.java AbstractInstancePool.java EntityInstancePool.java SingletonStatelessSessionInstancePool.java

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/23 11:50:47

  Modified:src/main/org/jboss/ejb/plugins AbstractInstancePool.java
EntityInstancePool.java
SingletonStatelessSessionInstancePool.java
  Added:   src/main/org/jboss/ejb/plugins TimedInstancePoolFeeder.java
  Log:
  Add a pool feeder to create asynchronously instances of beans and push them in the 
pool stack.
  Look at jboss.dtd for information on parameters
  
  Revision  ChangesPath
  1.21  +245 -183  jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java
  
  Index: AbstractInstancePool.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- AbstractInstancePool.java 2001/12/19 05:35:47 1.20
  +++ AbstractInstancePool.java 2001/12/23 19:50:46 1.21
  @@ -1,166 +1,200 @@
   /*
  -* JBoss, the OpenSource J2EE webOS
  -*
  -* Distributable under LGPL license.
  -* See terms of license at gnu.org.
  -*/
  + * JBoss, the OpenSource J2EE webOS
  + *
  + * Distributable under LGPL license.
  + * See terms of license at gnu.org.
  + */
   package org.jboss.ejb.plugins;
   
   import java.rmi.RemoteException;
   import java.rmi.ServerException;
  +import java.util.Stack;
  +import java.util.Iterator;
   import java.util.Map;
   import java.util.HashMap;
  -import java.util.Stack;
  +import java.lang.reflect.Constructor;
   
  -
   import org.jboss.ejb.Container;
   import org.jboss.ejb.InstancePool;
   import org.jboss.ejb.EnterpriseContext;
  +import org.jboss.ejb.InstancePoolFeeder;
   
  -import org.w3c.dom.Element;
   import org.jboss.deployment.DeploymentException;
   import org.jboss.metadata.MetaData;
   import org.jboss.metadata.XmlLoadable;
  -
  +import org.jboss.logging.Logger;
   import org.jboss.management.j2ee.CountStatistic;
   
  +import org.w3c.dom.Element;
   
   /**
  -*  
  -*   Abstract Instance Pool class containing the basic logic to create
  -*  an EJB Instance Pool.
  -*  
  -*
  -*   @see 
  -*   @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
  -*   @author mailto:[EMAIL PROTECTED]";>Marc Fleury
  -*  @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer
  - * @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
  -*   
  -*  @version $Revision: 1.20 $
  -*
  -*  Revisions:
  -*  20010704 marcf:
  -*  
  -*  - Pools if used, do not reuse but restock the pile with fresh instances
  -*  
  -*  20010709 andreas schaefer:
  -*  
  -*  - Added statistics gathering
  -*  
  -*  20010920 Sacha Labourey:
  -*  
  -*  - Pooling made optional and only activated in concrete subclasses for SLSB 
and MDB
  -*  
  -*/
  + *  
  + *   Abstract Instance Pool class containing the basic logic to create
  + *  an EJB Instance Pool.
  + *  
  + *
  + *  @see 
  + *
  + *  @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
  + *  @author mailto:[EMAIL PROTECTED]";>Marc Fleury
  + *  @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer
  + *  @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
  + *
  + *  @version $Revision: 1.21 $
  + *
  + *  Revisions:
  + *  20010704 marcf:
  + *  
  + *  - Pools if used, do not reuse but restock the pile with fresh instances
  + *  
  + *  20010709 andreas schaefer:
  + *  
  + *  - Added statistics gathering
  + *  
  + *  20010920 Sacha Labourey:
  + *  
  + *  - Pooling made optional and only activated in concrete subclasses for SLSB 
and MDB
  + *  
  + *  20011208 Vincent Harcq:
  + *  
  + *  - A TimedInstancePoolFeeder thread is started at first use of the pool
  + *   and will populate the pool with new instances at a regular period.
  + *  
  + */
   public abstract class AbstractInstancePool
   implements InstancePool, XmlLoadable
   {
  -// Constants -
  -
  -// Attributes 
  -private Container container;
  -
  -Stack pool = new Stack();
  -int maxSize = 30;
  -
  +   // Constants -
  +
  +   // Attributes 
  +
  +   protected Logger log = Logger.getLogger(AbstractInstancePool.class);
  +
  +   protected Container container;
  +
  +   protected Stack pool = new Stack();
  +
  +   /** determine if we reuse EnterpriseContext objects i.e. if we actually do 
pooling */
  +   protected boolean reclaim = false;
  +
  +   protected InstancePoolFeeder poolFeeder;
  +   protected boolean useFeeder = false;
  /** Counter of all the Bean instantiated within the Pool **/
  protected CountStatistic mInstantiate = new CountStatistic( "Instantiation", "", 
"Beans instantiated in Pool" );
  /** Counter of all the B

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins InstancePoolFeeder.java TimedInstancePoolFeeder.java AbstractInstancePool.java EntityInstancePool.java SingletonStatelessSessionInstancePool.java

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/23 11:53:01

  Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstancePool.java EntityInstancePool.java
SingletonStatelessSessionInstancePool.java
  Added:   src/main/org/jboss/ejb/plugins Tag: Branch_2_4
InstancePoolFeeder.java
TimedInstancePoolFeeder.java
  Log:
  Add a pool feeder to create asynchronously instances of beans and push them in the 
pool stack.
  This is off by default on 2.4.
  Look at standardjboss.xml and jboss.dtd of 3.0 for information on parameters and how 
to configure it
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.9.6.4   +132 -74   jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java
  
  Index: AbstractInstancePool.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java,v
  retrieving revision 1.9.6.3
  retrieving revision 1.9.6.4
  diff -u -r1.9.6.3 -r1.9.6.4
  --- AbstractInstancePool.java 2001/11/02 08:42:33 1.9.6.3
  +++ AbstractInstancePool.java 2001/12/23 19:53:00 1.9.6.4
  @@ -8,12 +8,10 @@
   
   import java.rmi.RemoteException;
   import java.rmi.ServerException;
  -import java.util.Map;
  -import java.util.HashMap;
   import java.util.Stack;
  +import java.util.Iterator;
  +import java.lang.reflect.Constructor;
   
  -import javax.ejb.EJBHome;
  -
   import org.jboss.ejb.Container;
   import org.jboss.ejb.InstancePool;
   import org.jboss.ejb.EnterpriseContext;
  @@ -25,47 +23,57 @@
   import org.jboss.logging.Logger;
   
   /**
  -*  
  -*Abstract Instance Pool class containing the basic logic to create
  -*  an EJB Instance Pool.
  -*  
  -*
  -*@see 
  -*@author mailto:[EMAIL PROTECTED]";>Rickard Öberg
  -*@author mailto:[EMAIL PROTECTED]";>Marc Fleury
  -*  @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer
  -*  @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
  -*
  -*  @version $Revision: 1.9.6.3 $
  -*
  -*  Revisions:
  -*  20010704 marcf:
  -*  
  -*  - Pools if used, do not reuse but restock the pile with fresh instances
  -*  
  -*  20010709 andreas schaefer:
  -*  
  -*  - Added statistics gathering
  -*  
  -*  20010920 Sacha Labourey:
  -*  
  -*  - Pooling made optional and only activated in concrete subclasses for SLSB 
and MDB
  -*  
  -*/
  + *  
  + *   Abstract Instance Pool class containing the basic logic to create
  + *  an EJB Instance Pool.
  + *  
  + *
  + *   @see 
  + *   @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
  + *   @author mailto:[EMAIL PROTECTED]";>Marc Fleury
  + *  @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer
  + *  @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
  + *
  + *  @version $Revision: 1.9.6.4 $
  + *
  + *  Revisions:
  + *  20010704 marcf:
  + *  
  + *  - Pools if used, do not reuse but restock the pile with fresh instances
  + *  
  + *  20010709 andreas schaefer:
  + *  
  + *  - Added statistics gathering
  + *  
  + *  20010920 Sacha Labourey:
  + *  
  + *  - Pooling made optional and only activated in concrete subclasses for SLSB 
and MDB
  + *  
  + *  20011208 Vincent Harcq:
  + *  
  + *  - A TimedInstancePoolFeeder thread is started at first use of the pool
  + *and will populate the pool with new instances at a regular period.
  + *  
  + */
   public abstract class AbstractInstancePool
  implements InstancePool, XmlLoadable
   {
  // Constants -
   
  // Attributes 
  -   private Container container;
  +
  +   protected Logger log = Logger.getLogger(AbstractInstancePool.class);
   
  -   Stack pool = new Stack();
  -   int maxSize = 30;
  +   protected Container container;
   
  -   // determine if we reuse EnterpriseContext objects i.e. if we actually do pooling
  +   protected Stack pool = new Stack();
  +
  +   /** determine if we reuse EnterpriseContext objects i.e. if we actually do 
pooling */
  protected boolean reclaim = false;
   
  +   protected InstancePoolFeeder poolFeeder;
  +   protected boolean useFeeder = false;
  +
  // Static 
   
// Constructors --
  @@ -105,23 +113,39 @@
   
  public void stop()
  {
  +  if (useFeeder && poolFeeder.isStarted()) poolFeeder.stop();
  +  freeAll();
  }
   
  public void destroy()
  {
  +  if (useFeeder && poolFeeder.isStarted()) poolFeeder.stop();
  +  freeAll();
  }
   
  -public boolean getReclaim()
  -{
  -   return reclaim;
  -}
  -
  -public void setReclaim(boolean reclaim)
  -{
  -   this.

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/23 11:53:01

  Modified:src/main/org/jboss/ejb Tag: Branch_2_4 InstancePool.java
  Log:
  Add a pool feeder to create asynchronously instances of beans and push them in the 
pool stack.
  This is off by default on 2.4.
  Look at standardjboss.xml and jboss.dtd of 3.0 for information on parameters and how 
to configure it
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.6.1   +28 -4 jboss/src/main/org/jboss/ejb/InstancePool.java
  
  Index: InstancePool.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/InstancePool.java,v
  retrieving revision 1.3
  retrieving revision 1.3.6.1
  diff -u -r1.3 -r1.3.6.1
  --- InstancePool.java 2000/12/07 15:44:10 1.3
  +++ InstancePool.java 2001/12/23 19:53:01 1.3.6.1
  @@ -6,14 +6,19 @@
*/
   package org.jboss.ejb;
   
  -import java.rmi.RemoteException;
  -
   /**
  - *
  + *   Base implementation of bean instance Pool.
*  
*   @see 
*   @author Rickard Öberg ([EMAIL PROTECTED])
  - *   @version $Revision: 1.3 $
  + *   @version $Revision: 1.3.6.1 $
  + *
  + * Revisions:
  + * 20011208 Vincent Harcq:
  + * 
  + *  Added a Pool Feeder (Thread that pre-create bean instances to avoid
  + *  setContext overhead.
  + * 
*/
   public interface InstancePool
  extends ContainerPlugin
  @@ -27,6 +32,17 @@
  // Constructors --
  
  // Public 
  +
  +   /**
  +*  Add an instance in the Pool.
  +*  Is used by the TimedInstancePoolFeeder thread to create instances ready for 
use by
  +*  the interceptor.
  +*
  +* @exception Exception when an Instance can not be instantiated
  +*/
  +   public void add()
  + throws Exception;
  +
  /**
   *   Get an instance without identity.
   *   Can be used by finders and create-methods, or stateless beans
  @@ -52,5 +68,13 @@
   * @param   ctx  
   */
  public void discard(EnterpriseContext ctx);
  +
  +   /**
  +* Return the size of the pool.
  +*
  +* @return the size of the pool.
  +*/
  +   public int getCurrentSize();
  +
   }
   
  
  
  

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

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/23 11:50:47

  Modified:src/etc/conf/default standardjboss.xml
  Log:
  Add a pool feeder to create asynchronously instances of beans and push them in the 
pool stack.
  Look at jboss.dtd for information on parameters
  
  Revision  ChangesPath
  1.29  +121 -49   jboss/src/etc/conf/default/standardjboss.xml
  
  Index: standardjboss.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- standardjboss.xml 2001/12/18 22:02:04 1.28
  +++ standardjboss.xml 2001/12/23 19:50:47 1.29
  @@ -7,7 +7,7 @@
   
   
   
  -
  +
   
   
  false
  @@ -50,10 +50,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 B
 
   
  @@ -92,10 +96,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 A
 
   
  @@ -136,10 +144,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 B
 
   
  @@ -178,10 +190,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 B
 
   
  @@ -220,10 +236,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 A
 
   
  @@ -251,10 +271,14 @@

True
 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 
   
 
  @@ -281,10 +305,14 @@

True
 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 
   
 
  @@ -311,10 +339,14 @@

True
 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 
   
 
  @@ -355,6 +387,14 @@
   0.75

 
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 
   
 
  @@ -395,6 +435,14 @@
   0.75

 
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 
   
 
  @@ -436,6 +484,14 @@
   0.75

 
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 
   
 
  @@ -473,10 +529,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 A
 
   
  @@ -515,10 +575,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +500
  +
  + 
 B
 
   
  @@ -557,10 +621,14 @@
   0.75

 
  -  
  - 100
  - 10
  -  
  + 
  +org.jboss.ejb.plugins.TimedInstancePoolFeeder
  +
  +100
  +10
  +   

[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss.dtd

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/23 11:50:47

  Modified:src/resources/org/jboss/metadata jboss.dtd
  Log:
  Add a pool feeder to create asynchronously instances of beans and push them in the 
pool stack.
  Look at jboss.dtd for information on parameters
  
  Revision  ChangesPath
  1.16  +39 -13jboss/src/resources/org/jboss/metadata/jboss.dtd
  
  Index: jboss.dtd
  ===
  RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss.dtd,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jboss.dtd 2001/07/05 19:02:22 1.15
  +++ jboss.dtd 2001/12/23 19:50:47 1.16
  @@ -621,34 +621,60 @@
 org.jboss.metadata.XmlLoadable) for it to load its parameters.
 
 The default instance pools, EntityInstancePool and 
  -  StatelessSessionInstancePool, both accept the following MaximumSize
  -  configuration.
  +  StatelessSessionInstancePool, both accept the following configuration.
   
 Used in: container-configuration
 -->
  -
  +
   
   
  -
  +
   
  -
  +
   
  -The MinimumSize element gives the minimum number of instance to
  -keep in the pool. Its value must be an integer.
  +
  +
   
  -Used in: container-pool-conf for AbstractInstancePool subclasses
  +
  +
  +
  +
  -
  +
   
   

[JBoss-dev] CVS update: jbosstest/lib xalan.jar crimson.jar jaxp.jar

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/15 10:53:18

  Modified:lib  Tag: Branch_2_4 crimson.jar jaxp.jar
  Added:   lib  Tag: Branch_2_4 xalan.jar
  Log:
  Update of latest JAXP libraries to make testsuite run on Branch 2.4
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +456 -438  jbosstest/lib/Attic/crimson.jar
  
<>
  
  
  1.1.2.1   +154 -19   jbosstest/lib/Attic/jaxp.jar
  
<>
  
  
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +3460 -0   jbosstest/lib/Attic/xalan.jar
  
<>
  
  

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

[JBoss-dev] CVS update: jbosstest/src/build build.bat build.sh

[Vincent Harcq]

  User: vharcq  
  Date: 01/12/15 10:53:18

  Modified:src/build Tag: Branch_2_4 build.bat build.sh
  Log:
  Update of latest JAXP libraries to make testsuite run on Branch 2.4
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.3   +2 -2  jbosstest/src/build/Attic/build.bat
  
  Index: build.bat
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/build/Attic/build.bat,v
  retrieving revision 1.3.2.2
  retrieving revision 1.3.2.3
  diff -u -r1.3.2.2 -r1.3.2.3
  --- build.bat 2001/10/20 02:48:29 1.3.2.2
  +++ build.bat 2001/12/15 18:53:18 1.3.2.3
  @@ -4,7 +4,7 @@
   set CLASSPATH=..\..\lib\ant.jar
   set CLASSPATH=%CLASSPATH%;..\..\lib\ant-optional.jar
   set CLASSPATH=%CLASSPATH%;..\..\lib\jboss-ant-addon.jar
  -set CLASSPATH=%CLASSPATH%;..\..\lib\xalan-2.0.0.jar
  +set CLASSPATH=%CLASSPATH%;..\..\lib\xalan.jar
   set CLASSPATH=%CLASSPATH%;..\..\lib\jaxp.jar
   set CLASSPATH=%CLASSPATH%;..\..\lib\parser.jar
   set CLASSPATH=%CLASSPATH%;..\..\lib\crimson.jar
  @@ -12,5 +12,5 @@
   set CLASSPATH=%CLASSPATH%;..\..\lib\javac.jar
   set CLASSPATH=%CLASSPATH%;..\..\src\lib\junit.jar
   
  -java -classpath "%CLASSPATH%" 
-Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl 
org.apache.tools.ant.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 
  +java -classpath "%CLASSPATH%" 
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
 -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl 
org.apache.tools.ant.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 
   @pause
  
  
  
  1.5.2.2   +3 -3  jbosstest/src/build/Attic/build.sh
  
  Index: build.sh
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/build/Attic/build.sh,v
  retrieving revision 1.5.2.1
  retrieving revision 1.5.2.2
  diff -u -r1.5.2.1 -r1.5.2.2
  --- build.sh  2001/10/20 02:48:29 1.5.2.1
  +++ build.sh  2001/12/15 18:53:18 1.5.2.2
  @@ -1,10 +1,10 @@
   #! /bin/sh
  -# $Id: build.sh,v 1.5.2.1 2001/10/20 02:48:29 starksm Exp $
  +# $Id: build.sh,v 1.5.2.2 2001/12/15 18:53:18 vharcq Exp $
   
   TARGET_CLASSPATH=../../lib/ant.jar
   TARGET_CLASSPATH=$TARGET_CLASSPATH:../../lib/ant-optional.jar
   TARGET_CLASSPATH=$TARGET_CLASSPATH:../../lib/jboss-ant-addon.jar
  -TARGET_CLASSPATH=$TARGET_CLASSPATH:../../lib/xalan-2.0.0.jar
  +TARGET_CLASSPATH=$TARGET_CLASSPATH:../../lib/xalan.jar
   TARGET_CLASSPATH=$TARGET_CLASSPATH:../../lib/jaxp.jar
   TARGET_CLASSPATH=$TARGET_CLASSPATH:../../lib/parser.jar
   TARGET_CLASSPATH=$TARGET_CLASSPATH:../../lib/crimson.jar
  @@ -22,4 +22,4 @@
 TARGET_CLASSPATH=`cygpath --path --windows "$TARGET_CLASSPATH"`
   fi
   
  -java -classpath "$TARGET_CLASSPATH" 
-Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl 
org.apache.tools.ant.Main $*
  +java -classpath "$TARGET_CLASSPATH" 
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
 -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl 
org.apache.tools.ant.Main $*
  
  
  

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

Re: [JBoss-dev] Can xdoclet not do unnecessary work?

[Vincent Harcq]

> Here's my chance to get some good info on xdoclet
> from an expert ;-)
> 
> 1. Looking at the docs for xdoclet it looks to me as
> if the merge stuff lets you easily construct a
> complete dd.  I was talking about deploying the same
> java class(es) under several jndi names, with say
> mappings to several database tables.  Is this
> possible?
Yes it is.
And if it is not, it is a bug in xdoclet.
JNDI, h, I go that way already ;-).  The issue here is to all lookups hardcoded in 
your program to name (usually the COMP_NAME generated by xdoclet in home interfaces), 
so you need an indirection here, use jboss.xml could solve the problem here.
I choose to use a Map (read through xml through a MBean) to forward a name A to a name 
B.  For example OrderCMPHome to OrderBMPHome, then all my existing code continue to 
work and go to see another JNDI under different deployment.
Back to xdoclet, here I see no merge point in jboss_xml.j so it's a xdoclet bug :(

Database name:
You have a merge in jboss-jaws.j : jaws-db-settings-{0}.xml
This means if you have jaws-db-settings-OrderBean.xml, when you run xdoclet on 
OrderBean, all the information will be extracted from the file (under a directory path 
similar to the classpath) and replace all what you can find under  in jboss-jaws.j.

Got it ?
Thanks to Ara (Southern Rickard ;) )

> 
> 2. Is there some way to use xdoclet with a package of
> ejb's you buy where you don't get the source code?  I
> thought it started with source code and generated the
> complete deployable package that will work on many
> app servers without further modification.  That's why
> I was talking about role separation.  If you are
> forced to start with binary classes and an existing
> ejb-jar.xml does it help you?

xdoclet works on javadoc/doclet tags so it parses the source file for @ comments on 
class and method.  i am not sure to understand your question :(

__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66&thread=5471

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

[JBoss-dev] Re: Can xdoclet not do unnecessary work?

[Vincent Harcq]

> > Xdoclet checks the timestamp of the file, if newer
> > that the generated, then regenerate.
> 
> 
> Looking harder at my output, it looks like it is only
> regenerating the dd files (no source files have been
> touched).  Is this normal? Is there some way to make
> it quit doing this?

That is on the list to do, no timestamp checking is done for xml files and they are 
always generated (we have to lookup every bean timestamp (and their super classes, 
...).

__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66&thread=5471

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

[JBoss-dev] Re: Can xdoclet not do unnecessary work?

[Vincent Harcq]

> Is there a reasonably simple way to make xdoclet only
> run if one of the files it is processing has changed?
> Most of the time for my server module builds seems
> to be taken with xdoclet, and I never change stuff
> it starts with.

Xdoclet checks the timestamp of the file, if newer that the generated, then regenerate.
The usual way of doing is to touch the files on every build so regenerates every time. 
 The reason is the timestamp is not enough in special cases : update xdoclet with a 
new version (or being a xdoclet developer ;) ) or add a Tag in a super class (xdoclet 
goes through them :-) ).

Second thing : xdoclet runs as fast as the speed, the problem is javadoc.  Some people 
there develop [b]xjavadoc[/b] that will replace javadoc and hopefully run faster :O

__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66&thread=5471

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

Re: [JBoss-dev] Can xdoclet not do unnecessary work?

[Vincent Harcq]

> Generation of config files seems to me to imply that
> each ejb will be
> deployed using only one dd.  This is presumably by
> far the most frequent
> case, and for that it makes a lot of sense.
> Generating all the dd's for
> different app servers seems pretty useful too.  So,
> my current uninformed
> optinion is that it makes the most frequent use
> really easy, and provides
> something to modify for other cases when you need to
> deploy the same
> codebase as several ejbs.
> I think it is mostly targeted at ejb development,
> where one person is
> filling all those roles at once.  If you have a
> separate deployer-person,
> at least it gives you somewhere to start.

I do not agree :O
The [b]merging[/b] feature of xdoclet permits to do almost everything in multi 
deployment mode.  It has really turned xdoclet from a developement tool to also a 
deployment tool.  Personnally I deploy on different environments and never change a 
XML file by hand.

__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66&thread=5471

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

RE: [JBoss-dev] setEntityContext called at pool push time (because of reclaim usage in EntityInstancePool)

[Vincent Harcq]

Hi,
Yes I am doing jndi lookup in setEntityContext()
This push the problem right into my face because I was not caching the
home interfaces.
I turn this into a bug, Bill responded already.
https://sourceforge.net/tracker/?func=detail&aid=488940&group_id=22866&a
tid=376687

I will abuse and go a bit further with something different,
I looked at JNP code and NamingContext.java
When no ejb-link exist (The calling and caller are each in one ejb jar,
each ejb jar in its own ear), the JNDI create a MarshalledObject on the
home interface and store it in the jndi map.
The unmarshalling is done on jndi lookup.
This is very expensive (40 msec).
I have no idea if this is a normal timing or not but it kills
performance also.
I tried to remove that and store the home object directly (it is a
$Proxy object), ... , but the classloaders are different so the classes
does not look the same at lookup time and I receive a ClassCastException
when casting my home interface.
The parent classloaders of the two is a common one :
javax.management.loading.MLet
Is there any means to avoid that ? Jboss 3.0 ?
I guess having only one ear or use the Dumbo stuff could help, I still
have to work on/understand that... 

I migrate a lot of calls to use local interfaces, then see it runs
faster and I only understand why today :) 
With Optimized turn on, we can not say that no serialization occurs :
the jndi lookup one kills a lot.
At this time I was not caching home interfaces, and the performance
difference was easily visible.
I don't see this as a high priority but if one do some performance tests
on Jboss, he should be aware of this.

Regards,
Vincent.

> FROM: Scott M Stark
> DATE: 12/04/2001 09:51:39SUBJECT: 
> RE:  [JBoss-dev] setEntityContext called at pool push time (because of
reclaim usage in EntityInstancePool)
>
> Describe the performance your seeing in more detail as I can't gather
> the details from your previous mails. Is it because you are doing
> work in setEntityContext?

> -----Original Message-
> From: Vincent Harcq [mailto:[EMAIL PROTECTED]] 
> Sent: mardi 4 décembre 2001 7:19
> To: [EMAIL PROTECTED]; 'Development JBoss'
> Subject: RE: [JBoss-dev] setEntityContext called at pool push 
> time (because of reclaim usage in EntityInstancePool)
> 
> 
> This was wrong also :(
> The cache avoids my rerun of setEntityContext. OK.
> But the cache only works for remote methods, not for home 
> methods Whenever I call a home method a new instance of the 
> entity is created, that is the overhead I have. I could solve 
> that by pushing back the context to the pool in 
> EntityInstanceInterceptor.invokeHome but I don't understand 
> the reason for the reclaim flag (it is false for home 
> methods, then AbstractInstancePool discard and recreate a new 
> instance which is the same as not putting the context to the 
> pool) Should I test the ID inside the context and if null 
> then do like reclaim ? I could not see a erason why this 
> should not be done for instances that have been created for 
> home methods calling and that have so no real data in them. 
> This works fine for me, should I run other tests to proove 
> this is ok ? Please give me some feedback.
> 
> Vincent.
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On 
> > Behalf Of Vincent Harcq
> > Sent: lundi 3 décembre 2001 2:49
> > To: 'Development JBoss'
> > Subject: RE: [JBoss-dev] setEntityContext called at pool push 
> > time (because of reclaim usage in EntityInstancePool)
> > 
> > 
> > My last post is wrong, it is in fact a lot more simple:
> > 
> > JBOSS 2.4.4 almost latest CVS
> >  
> > Entity instances are created by the pool on the get() method
> > The creation is followed by setEntityContext The problem is 
> > that the free() method is never called on EntityInstancePool 
> > (except by the passivation method). So an entity bean is 
> > never push to the pool. So the pool is always empty for 
> > entity beans. So on my next call, the 
> > instanciation/setEntityContext happens again.
> > 
> > That's why I see a lot of setEntityContext() happening and
> > this why I see this this as a performance killer because I do 
> > a lot of jndi lookup there.
> > 
> > Is this a normal behaviour or does it hide something ?
> > 
> > Regards.
> > Vincent.
> > 
> > 
> > 
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> > 
> > ___
> > Jboss-development mailing list 
> [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > 
> 
> 
> 
> 
> _
> 
> Do You Yahoo!?
> 
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> 
> 
> 



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

RE: [JBoss-dev] time is up, where is adam heath?

[Vincent Harcq]

You are at a restaurant, 
The Chef offers you the dinner(jboss) and the dessert(free doco).
you have to be polite and interresting to be invited at his personnal
table,
You get nothing more in your plates when you are here, only an
interresting discussion,
you are not polite, he kicks you off,
you are not interresting, he does not listen to you and go to another
table,
you have to bring a flower pot(10$) to get the pause café (full doco).  
you want to be sure his restaurant does not close while he is offering
dinner to more and more people, give him some pans (support contract)
for his new cookers (developers),
he opens another restaurant where you have to pay a fabulous dinner ,
you are free to decide to go there (the consuting/training), you are
free to not go,
he shouts too much, go in the next restaurant and pay for your dinner.

Buuurp, I apologize.



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Hicks, James
> Sent: mardi 4 décembre 2001 16:30
> To: Jboss-Development@Lists. Sourceforge. Net
> Subject: RE: [JBoss-dev] time is up, where is adam heath?
> 
> 
> Let me start off by saying that I don't know what initially 
> sparked this thread, but being an employee of a  subsidiary 
> of a very large telco, I can relate to some points Ean 
> Schuessler made.  Now, I am not attacking anyone on this list 
> or the JBoss Group, I just want to raise a few issues.
> 
> For the past 3 months I have been reviewing app servers to 
> deploy some internal software on.  When I take my proposals 
> to my boss, he will ask a lot of the questions Ean Schuessler asked.
> 
> Let's face it,  there are many 'large' companies that use 
> open source software (tomcat, struts, linux, postgres, mysql, 
> php, perl,), but there aren't many that are using JBoss.  
> It could be that the reason a lot of them haven't looked into 
> JBoss is because of some of the responses on this list made 
> by the people that are behind JBoss.  When a company decides 
> to go with a spefic product, it is a long term investment.  
> The company is looking for stability and longevity in the 
> product.  Seeing some threads on this lists turns a lot of 
> people away.  
> 
> James Hicks
> 
> -Original Message-
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 04, 2001 8:56 AM
> To: Dain Sundstrom; 'Adam Heath'; Bill Burke
> Cc: Jboss-Development@Lists. Sourceforge. Net
> Subject: RE: [JBoss-dev] time is up, where is adam heath?
> 
> 
> The situation has been taken care of, the brainfood guys 
> removed from this list,
> 
> JBoss-dev is for serious contributors and serious technical 
> discussion, I hate waking up and finding 20 mails of flames 
> talking about forking JBoss. I am not going to provide a 
> forum for this on my own lists.
> 
> I thank all of you for your unanimous response and support, 
> let's keep on kicking some ass, we are there, back to work
> 
> marcf
> 
> 
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On 
> Behalf Of Dain 
> |Sundstrom
> |Sent: Tuesday, December 04, 2001 2:36 AM
> |To: 'Adam Heath'; Bill Burke
> |Cc: Jboss-Development@Lists. Sourceforge. Net
> |Subject: RE: [JBoss-dev] time is up, where is adam heath?
> |
> |
> |Adam,
> |
> |The reason people don't remember this is because jboss is so easy to 
> |deploy already that they feel a deb is unecessary.  So your 
> |contribution is not highly valued, and not remembered.
> |
> |-dain
> |
> |> -Original Message-
> |> From: Adam Heath [mailto:[EMAIL PROTECTED]]
> |> Sent: Tuesday, December 04, 2001 1:21 AM
> |> To: Bill Burke
> |> Cc: Adam Heath; Jboss-Development@Lists. Sourceforge. Net
> |> Subject: RE: [JBoss-dev] time is up, where is adam heath?
> |>
> |>
> |> On Tue, 4 Dec 2001, Bill Burke wrote:
> |>
> |> > Didn't see your patch, sorryWell, I actualy couldn't
> |> find it after
> |> > looking a little bit.
> |>
> |> Message-ID: 
> |> <[EMAIL PROTECTED]>
> |> Date: Sun, 18 Nov 2001 14:07:42 -0600 (CST)
> |> Subject: [PATCH]: [JBoss-dev] can't build jboss from cvs
> |>
> |> The above email patches build.xml, only.  It does what I need, to 
> |> split the tarballs/zips up.
> |>
> |> Also, another patch I sent, earlier, contains some miscellaneous 
> |> patches.
> |>
> |> Message-ID: 
> <[EMAIL PROTECTED]>
> |> Date: Tue, 13 Nov 2001 01:24:56 -0600 (CST)
> |> Subject: [JBoss-dev] misc patches needed to make .deb for debian
> |>
> |> > Sorry if the JBoss community is not what you're used to.
> |> It works for us.
> |> > I am now integrating JBoss into a 2nd production system at
> |> a 2nd company,
> |> > with much success, and will be moving onto a 3rd in
> |> January..  The JBoss
> |> > community is doing something right.  I know from experience.
> |>
> |> You have worked at 2 different companies, or did they hire 
> you as a 
> |> consultant just to do this integration(not meaning to sound harsh, 
> |> just being inquistiv

RE: [JBoss-dev] setEntityContext called at pool push time (because of reclaim usage in EntityInstancePool)

[Vincent Harcq]

This was wrong also :(
The cache avoids my rerun of setEntityContext. OK.
But the cache only works for remote methods, not for home methods
Whenever I call a home method a new instance of the entity is created,
that is the overhead I have.
I could solve that by pushing back the context to the pool in
EntityInstanceInterceptor.invokeHome but I don't understand the reason
for the reclaim flag (it is false for home methods, then
AbstractInstancePool discard and recreate a new instance which is the
same as not putting the context to the pool)
Should I test the ID inside the context and if null then do like reclaim
?
I could not see a erason why this should not be done for instances that
have been created for home methods calling and that have so no real data
in them.
This works fine for me, should I run other tests to proove this is ok ?
Please give me some feedback.

Vincent.


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On 
> Behalf Of Vincent Harcq
> Sent: lundi 3 décembre 2001 2:49
> To: 'Development JBoss'
> Subject: RE: [JBoss-dev] setEntityContext called at pool push 
> time (because of reclaim usage in EntityInstancePool)
> 
> 
> My last post is wrong, it is in fact a lot more simple: 
> 
> JBOSS 2.4.4 almost latest CVS
>  
> Entity instances are created by the pool on the get() method 
> The creation is followed by setEntityContext The problem is 
> that the free() method is never called on EntityInstancePool 
> (except by the passivation method). So an entity bean is 
> never push to the pool. So the pool is always empty for 
> entity beans. So on my next call, the 
> instanciation/setEntityContext happens again.
> 
> That's why I see a lot of setEntityContext() happening and 
> this why I see this this as a performance killer because I do 
> a lot of jndi lookup there.
> 
> Is this a normal behaviour or does it hide something ?
> 
> Regards.
> Vincent.
> 
> 
> 
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> ___
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 



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


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

RE: [JBoss-dev] setEntityContext called at pool push time (because of reclaim usage in EntityInstancePool)

[Vincent Harcq]

My last post is wrong, it is in fact a lot more simple: 

JBOSS 2.4.4 almost latest CVS
 
Entity instances are created by the pool on the get() method
The creation is followed by setEntityContext
The problem is that the free() method is never called on
EntityInstancePool (except by the passivation method).
So an entity bean is never push to the pool.
So the pool is always empty for entity beans.
So on my next call, the instanciation/setEntityContext happens again.

That's why I see a lot of setEntityContext() happening and this why I
see this this as a performance killer because I do a lot of jndi lookup
there.

Is this a normal behaviour or does it hide something ?

Regards.
Vincent.



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


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

[JBoss-dev] setEntityContext called at pool push time (because of reclaim usage in EntityInstancePool)

[Vincent Harcq]

Hi,
JBOSS 2.4.4 almost latest CVS

If I have some finders method called, new Entity are created by the
pool, then push (free) in the pool at the end.
The push is done by remove/create because reclaim is false, so
setEntityContext is run here.

So I don't have real pool usage because the overhead of setEntityContext
is always there.
I am doing jndi lookups in setEntityContext which is quite "heavy".

If I use EntityMultiInstanceSynchronizationInterceptor, the free method
of AbstractInstanceCache in not called and so the pool is not used at
all (see EnityInstancePool.free())

I am not confident enough to find the solution.

Regards.
Vincent.





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

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/10/18 13:03:42

  Modified:src/etc/conf/default standardjboss.xml
  Log:
  locking-policy tag is only for entity beans
  
  Revision  ChangesPath
  1.21  +1 -2  jboss/src/etc/conf/default/standardjboss.xml
  
  Index: standardjboss.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- standardjboss.xml 2001/10/16 22:15:36 1.20
  +++ standardjboss.xml 2001/10/18 20:03:42 1.21
  @@ -7,7 +7,7 @@
   
   
   
  -
  +
   
   
  false
  @@ -336,7 +336,6 @@
 
org.jboss.ejb.plugins.StatefulSessionInstanceCache
 
org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager
 org.jboss.tm.TxManager
  -  
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock
 

True
  
  
  

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

[JBoss-dev] Mismatch 2.4 / 3.0 org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock

[Vincent Harcq]

Hi,
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock
is present for stateful beans on standardjboss.xml for 3.0 but not for
2.4.
>From the sources it is not used for stateful session beans.
Can we remove this line from 3.0 ?
Regards.


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

[JBoss-dev] Activation/Passivation of SFSB

[Vincent Harcq]

Just to be sure my remark on bug 457245 will be read ;)

I am working on this bug right now.

Session beans passivates and activates without error.

But after activation I receive a NoSuchObjectException from 

AbstractInstanceCache.

Question : does Activation have to put the object back in 

the cache ?

The problem of local interfaces is quite new, but was there 

any changes in cache and SFSB recently that could have 

break activation of sfsb ?


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

RE: [JBoss-dev] Re: Lutris announcement: a further look

[Vincent Harcq]

I think you are absolutely right.
Can a JBG member agree on this ?
Regards.


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED]] On Behalf Of Luigi P. Bai
> Sent: lundi 17 septembre 2001 17:28
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] Re: Lutris announcement: a further look
> 
> Seems to me that JBoss can get more closely into compliance with the
> various Sun licenses by doing what Netbeans does: provide the various
RI
> jars on a separate page, maybe with an installer build.xml, and ask
users
> to accept Sun's license before getting the jar (or maybe that can be
part
> of the installation process as well). I think right now, with all the
sun
> jars being packaged in with the distribution, JBoss is on shaky
ground,
> since the licenses for those jars, in most cases, specifically says
they
> can't be redistributed.
> 
> On the other hand, I agree that Lutris is spreading FUD about the J2EE
> specs. As long as JBoss doesn't claim to be J2EE compliant (which
means
> passing the test, etc.), I think there is nothing in the specs for
JMS,
> JDBC, etc. that prevents JBoss from implementing their functionality.



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


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

RE: [JBoss-dev] fyi: j2ee, open source, lutris

[Vincent Harcq]

That is pure "branlette".
Nothing against you personnaly of course, I am against the general
feeling ;)
If Sun comes to fight JBoss, we can simply remove these jars from the
distri and add a readme to say where to download these jars and install
them manually.
If anybody wants to fight JBoss, why not fight it on real bugs ?
Take that from a nice view : JBoss is frightening more people because it
becomes stronger that never. 
Lutris is dead in my mind.


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED]] On Behalf Of Toby Hede
> Sent: samedi 15 septembre 2001 1:57
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] fyi: j2ee, open source, lutris
> 
> http://www.theserverside.com/home/thread.jsp?thread_id=9037
> 
> curious about this comment from keith bigalow from lutris:
> 
> Actually, JBOSS is not a clean room implementation. If one downloads
> version
> 2.4 made available 9/10/01, one finds countless inclusions of Sun
> Reference
> Implementation code, which is in violation of the Sun Binary Code
License
> (see inclusions of JAAS, JNDI, XML.JAR (Project X, ver 0.8.0),
> JavaMail 1.2, JAF).
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development


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


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

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/09/10 14:06:01

  Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCFindEntitiesCommand.java
  Log:
  Merge a patch from 3.0 that avoids error during deployment of ejb with only local 
home interfaces.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.10.2.1  +40 -6 
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntitiesCommand.java
  
  Index: JDBCFindEntitiesCommand.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntitiesCommand.java,v
  retrieving revision 1.10
  retrieving revision 1.10.2.1
  diff -u -r1.10 -r1.10.2.1
  --- JDBCFindEntitiesCommand.java  2001/06/18 14:34:27 1.10
  +++ JDBCFindEntitiesCommand.java  2001/09/10 21:06:01 1.10.2.1
  @@ -33,7 +33,15 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Joe Shevland
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
  - * @version $Revision: 1.10 $
  + * @version $Revision: 1.10.2.1 $
  + *
  + *   Revisions:
  + *
  + *   20010812 [EMAIL PROTECTED]:
  + *   
  + *Make load of automated finder method work with local home interfaces
  + *   
  + *
*/
   public class JDBCFindEntitiesCommand implements JPMFindEntitiesCommand
   {
  @@ -99,24 +107,50 @@
 }
 
 // Make commands for any autogenerated finders required
  -  
  -  Method[] homeMethods = factory.getContainer().getHomeClass().getMethods();
  -  
  +  Method[] homeMethods;
  +  Method[] localHomeMethods;
  +  factory.getLog().debug("AutoGenerated finders  - Home="
  + + factory.getContainer().getHomeClass()
  + + " -- LocalHome=" + factory.getContainer().getLocalHomeClass());
  +  if (factory.getContainer().getHomeClass() != null)
  +  {
  + homeMethods = factory.getContainer().getHomeClass().getMethods();
  +  }
  +  else homeMethods = new Method[0] ;
  +  if (factory.getContainer().getLocalHomeClass() != null)
  +  {
  +  localHomeMethods = 
factory.getContainer().getLocalHomeClass().getMethods();
  +  }
  +  else localHomeMethods = new Method[0] ;
  +  Method[] allHomeMethods = new Method[homeMethods.length + 
localHomeMethods.length];
  +
 for (int i = 0; i < homeMethods.length; i++)
 {
  - Method m = homeMethods[i];
  + allHomeMethods[i] = homeMethods[i];
  +  }
  +  for (int i = 0; i < localHomeMethods.length; i++)
  +  {
  + allHomeMethods[homeMethods.length + i] = localHomeMethods[i];
  +  }
  +
  +  for (int i = 0; i < allHomeMethods.length; i++)
  +  {
  +
  + Method m = allHomeMethods[i];
String name = m.getName();
  - 
  +
if (!knownFinderCommands.containsKey(name))
{
   if (name.equals("findAll"))
   {
  +   factory.getLog().debug("Save AutoGenerated "+name+"  "+m);
  FinderMetaData f = new FinderMetaData("findAll");
  knownFinderCommands.put(name, factory.createFindAllCommand(f));
   } else if (name.startsWith("findBy")  && 
!name.equals("findByPrimaryKey"))
   {
  try
  {
  +  factory.getLog().debug("Save AutoGenerated "+name+"  "+m);
 FinderMetaData f = new FinderMetaData(name);
 knownFinderCommands.put(name, factory.createFindByCommand(m, f));
  } catch (IllegalArgumentException e)
  
  
  

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

[JBoss-dev] PK Class and Field

[Vincent Harcq]

Hi,
I had some problem recently with a PK Class and how JawsEMD build the list
of pk fields.
I have a PK class APK with a public field "code".
I also have a PK class BPK that extends APK and also re-define "code" (ok
strange but why not)

This line (of JawsEMD)
Field[] pkClassFields = primaryKeyClass.getFields();
return 2 entries.
That causes problems after in finding the entity bean, etc...
I would think it only return one.  Am i wrong here ?
I have a patch for that, but I would like to know if I misunderstood teh
getFields() method.
I am running 1.3.1_01.
Regards.

Vincent.



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

[JBoss-dev] Jboss 2.4.1

[Vincent Harcq]

Hi,
Under branch 2.4.1.
jboss-j2ee.jar in src/client and src/lib are not the same, the one in client
does not contain EJB 2.0 classes.
Regards.
Vincent.


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

RE: [JBoss-dev] The trouble with ClassLoaders.

[Vincent Harcq]

For 1)
David gives the answer to this some gours ago, remove the \ before the : in
jdbc\:HypersonicSQL\:hsql\://localhost\:1476.
Vincent.


> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> David Maplesden
> Envoyé : jeudi 6 septembre 2001 7:01
> À : JBossDev (E-mail)
> Objet : [JBoss-dev] The trouble with ClassLoaders.
>
>
> I am getting some odd behaviour with the loading of classes since
> marc's RH
> changes and after spending a couple of days testing things out
> and trying to
> convince myself I'm not going mad I've nearly given up trying to
> figure out
> whats going on.
>
> I basically want to know if anyone else is getting any of these (seemingly
> unrelated) problems and and/or whether anyone else knows if I am
> just plain
> doing things wrong.  None of these problems occur with pre-RH JBoss 2.5.
>
> 1) The DefaultDS DataSource throws an SQLException "No suitable
> driver" when
> I try to get a connection even though it seems to initialise correctly and
> the jdbcProvider successfully loaded the org.hsql.jdbcDriver.
>
> Snippets from log...
>
> [JdbcProvider,INFO] Initializing
> [JdbcProvider,INFO] Loaded JDBC-driver:org.hsql.jdbcDriver
> [JdbcProvider,INFO] Initialized
>
> followed by...
>
> [DefaultDS,INFO] Starting
> [DefaultDS,INFO] Started
>
> and finally...
>
> [JDBCManagedConnectionFactory-1,ERROR] Unable to create
> ManagedConnection:
> javax.resource.ResourceException: Unable to create DB connection
> (url=jdbc\:HypersonicSQL\:hsql\://localhost\:1476, user=sa:
> java.sql.SQLException: No suitable driver
>   at
> org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createM
> anagedConn
> ection(JDBCManagedConnectionFactory.java:245)
>   at
> org.jboss.pool.connector.ManagedConnectionPoolFactory.createObject
> (ManagedCo
> nnectionPoolFactory.java:62)
>   at org.jboss.pool.ObjectPool.createNewObject(ObjectPool.java:991)
>   at org.jboss.pool.ObjectPool.getObject(ObjectPool.java:657)
>   at
> org.jboss.pool.connector.SharedLocalConnectionManager.allocateConn
> ection(Sha
> redLocalConnectionManager.java:104)
>   at
> org.jboss.pool.connector.jdbc.JDBCDataSource.getConnection(JDBCDat
> aSource.ja
> va:79)
>
> 2) Originally Jetty failed every time it tried to compile a jsp
> page because
> it can't find the javax.servlet.* classes, even though I had them in the
> lib/ext directory (in javax.servlet.jar) along with everything
> else.  Then I
> added the javax.servlet.jar as a standard extension to my jdk and now it
> can't find some of the jasper classes, although it finds others.
> The error
> message below comes from a jasper class because it can't find
> another jasper
> class, even though they are both in the same jar file!  Jetty also serves
> servlets fine.
>
> [Jetty,WARN] Servlet Exception for /demo/jsp/hello.jsp
> org.apache.jasper.JasperException: JASPER: Unable to compile class for
> JSPC:\DOCUME~1\dmap\LOCALS~1\Temp\JettyContext34026.tmp\_0002fjsp_
> 0002fhello
> _0002ejsphello_jsp_0.java:12: Package org.apache.jasper.runtime
> not found in
> import.
> import org.apache.jasper.runtime.*;
>^
> C:\DOCUME~1\dmap\LOCALS~1\Temp\JettyContext34026.tmp\_0002fjsp_000
> 2fhello_00
> 02ejsphello_jsp_0.java:14: Class
> org.apache.jasper.JasperException not found
> in import.
> import org.apache.jasper.JasperException;
>^
> C:\DOCUME~1\dmap\LOCALS~1\Temp\JettyContext34026.tmp\_0002fjsp_000
> 2fhello_00
> 02ejsphello_jsp_0.java:17: Superclass jsp.HttpJspBase of class
> jsp._0002fjsp_0002fhello_0002ejsphello_jsp_0 not found.
> public class _0002fjsp_0002fhello_0002ejsphello_jsp_0 extends
> HttpJspBase {
>   ^
> 3 errors
>
>   at org.apache.jasper.compiler.Compiler.compile(Compiler.java:249)
>   at
> org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:448)
>   at
> org.apache.jasper.servlet.JasperLoader12$1.run(JasperLoader12.java:160)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at
> org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:156)
>   at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:419)
>   at
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNeces
> sary(JspSe
> rvlet.java:151)
>   at
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(Jsp
> Servlet.ja
> va:163)
>   at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:307)
>   at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at
> com.mortbay.Jetty.Servlet.ServletHolder.handle(ServletHolder.java:488)
>   at
> com.mortbay.Jetty.Servlet.ServletHandler.handle(ServletHandler.java:389)
>   at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:972)
>   at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:927)
>

RE: [JBoss-dev] Jboss 3.0 / DataSource problem

[Vincent Harcq]

Thank you.
It works.

> -Message d'origine-
> De : David Jencks [mailto:[EMAIL PROTECTED]]
> Envoyé : mercredi 5 septembre 2001 23:30
> À : [EMAIL PROTECTED]
> Cc : Dev JBoss
> Objet : Re: [JBoss-dev] Jboss 3.0 / DataSource problem
>
>
> One problem that causes this is escaped : ie \: in the jdbc url.
>
> right now the example .xml has
>
> jdbc\:HypersonicDatabase\:hsql\:
>
>
> Try
> jdbc:HypersonicDatabase:hsql:...
>
> marc's new ServiceDeployer removes all newlines from xml which messes up
> the property file format reading used in ConnectionFactoryLoader.
>  My quick
> fix for ConnectionFactoryLoader didn't account for escaped :.
> Not sure how
> it got through my tests...  I think I'll put the newlines back
> into the xml
> reader.
>
> david jencks
>
>
> On 2001.09.05 13:23:56 -0400 Vincent Harcq wrote:
> > Hi,
> > I have come to this problem before calling for help, I have
> >>  name="JBOSS-SYSTEM:service=JdbcProvider">
> >  
> >   com.inet.tds.TdsDriver,
> >   org.hsql.jdbcDriver
> >   
> >   
> > BTW, this was enough and the add of Opta2000.jar in  > archives=...
> > was also needed.
> >
> > The Pool is created ok.
> > It is at first SQL connection that badaboom.
> >
> > Regards.
> > Vincent.
> >
> >
> > > -Message d'origine-
> > > De : marc fleury [mailto:[EMAIL PROTECTED]]
> > > Envoyé : mercredi 5 septembre 2001 19:09
> > > À : [EMAIL PROTECTED]; Dev JBoss
> > > Objet : RE: [JBoss-dev] Jboss 3.0 / DataSource problem
> > >
> > >
> > > well,
> > >
> > > you still need to declare the JDBC driver in the "JDBC MBean" thingy.
> > >
> > > That is one of the things that we need to change, to have the
> connector
> > > declare what driver he is using as opposed to the kludgy MBean we
> > > have right
> > > now as a front end to loading the drivers.
> > >
> > > marcf
> > >
> > >
> > > |-Original Message-
> > > |From: [EMAIL PROTECTED]
> > > |[mailto:[EMAIL PROTECTED]]On Behalf Of
> > > |Vincent Harcq
> > > |Sent: Wednesday, September 05, 2001 1:01 PM
> > > |To: Dev JBoss
> > > |Subject: [JBoss-dev] Jboss 3.0 / DataSource problem
> > > |
> > > |
> > > |Hi,
> > > |Running latest JBoss 3.0,
> > > |I have defined a datasource based on Opta2000 driver for MS SQL.
> > > |I have added the driver to the list of JDBC driver and the opta
> > > JAR to the
> > > |list of jar in top of jboss-service.xml.
> > > |I used the new way of configuring the pool, I simply copy/paste
> > > the one of
> > > |DefaultDS and changed the minimum.
> > > |
> > > |I got this exception while deploying an entity Bean.
> > > |
> > > |[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection:
> > > |javax.resource.ResourceException: Unable to create DB connection:
> > > |java.sql.SQLException: No suitable driver
> > > |at
> > > |org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createMa
> > > |nagedConn
> > > |ection(JDBCManagedConnectionFactory.java:245)
> > > |
> > > |Does this say something to somebody ?
> > > |
> > > |Thanks.
> > > |Vincent.
> > > |
> > > |
> > > |___
> > > |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-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins BMPPersistenceManager.java

[Vincent Harcq]

  User: vharcq  
  Date: 01/09/05 15:02:51

  Modified:src/main/org/jboss/ejb/plugins BMPPersistenceManager.java
  Log:
  Bug 441821
  Better messages when methods defined in Home interface are not implemented
  
  Revision  ChangesPath
  1.31  +31 -4 jboss/src/main/org/jboss/ejb/plugins/BMPPersistenceManager.java
  
  Index: BMPPersistenceManager.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/BMPPersistenceManager.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- BMPPersistenceManager.java2001/09/01 19:50:30 1.30
  +++ BMPPersistenceManager.java2001/09/05 22:02:51 1.31
  @@ -31,6 +31,7 @@
   
   import org.jboss.management.j2ee.CountStatistic;
   import org.jboss.management.j2ee.TimeStatistic;
  +import org.apache.log4j.Category;
   
   /**
   *   
  @@ -39,7 +40,7 @@
   *  @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
   *  @author mailto:[EMAIL PROTECTED]";>Marc Fleury
   *  @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer
  -*  @version $Revision: 1.30 $
  +*  @version $Revision: 1.31 $
   *
   *  Revisions:
   *  20010709 andreas schaefer:
  @@ -57,6 +58,8 @@
  // Constants -
   
  // Attributes 
  +   Category log = Category.getInstance(BMPPersistenceManager.class);
  +
  EntityContainer con;
   
  Method ejbLoad;
  @@ -126,8 +129,24 @@
 {
if (methods[i].getName().equals("create"))
{
  -createMethods.put(methods[i], con.getBeanClass().getMethod("ejbCreate", 
methods[i].getParameterTypes()));
  -postCreateMethods.put(methods[i], 
con.getBeanClass().getMethod("ejbPostCreate", methods[i].getParameterTypes()));
  +try
  +{
  +   createMethods.put(methods[i], 
con.getBeanClass().getMethod("ejbCreate", methods[i].getParameterTypes()));
  +}
  +catch (NoSuchMethodException e)
  +{
  +   log.error("Home Method " + methods[i] + " not implemented in bean 
class");
  +   throw e;
  +}
  +try
  +{
  +   postCreateMethods.put(methods[i], 
con.getBeanClass().getMethod("ejbPostCreate", methods[i].getParameterTypes()));
  +}
  +catch (NoSuchMethodException e)
  +{
  +   log.error("Home Method " + methods[i] + " not implemented in bean 
class");
  +   throw e;
  +}
}
 }
   
  @@ -136,7 +155,15 @@
 {
if (methods[i].getName().startsWith("find"))
{
  -finderMethods.put(methods[i], con.getBeanClass().getMethod("ejbF" + 
methods[i].getName().substring(1), methods[i].getParameterTypes()));
  +try
  +{
  +   finderMethods.put(methods[i], con.getBeanClass().getMethod("ejbF" + 
methods[i].getName().substring(1), methods[i].getParameterTypes()));
  +}
  +catch (NoSuchMethodException e)
  +{
  +   log.error("Home Method " + methods[i] + " not implemented in bean 
class");
  +   throw e;
  +}
}
 }
  }
  
  
  

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

[JBoss-dev] CVS update: manual/src/examples/build build.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/09/05 14:58:01

  Modified:src/examples/build build.xml
  Log:
  Bug 458826, 457149
  Chapter JDBC examples did not work.
  
  Revision  ChangesPath
  1.14  +267 -261  manual/src/examples/build/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/examples/build/build.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- build.xml 2001/08/15 17:25:08 1.13
  +++ build.xml 2001/09/05 21:58:01 1.14
  @@ -1,261 +1,267 @@
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  - 
  - 
  -
  -
  - 
  -
  - 
  -
  -
  - 
  - 
  -
  - 
  - 
  - 
  -  
  -  
  - 
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  - 
  -
  -
  -
  -
  -
  - 
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  - 
  - 
  -
  -
  -
  -
  -
  -
  - 
  - 
  -
  -
  -
  -
  -
  -
  -
  -
  - 
  -
  -
  -
  -   
  -
  -
  -
  -
  -
  -
  -
  -   
  -
  -
  -
  - 
  -
  -
  -
  -   
  -
  -
  -
  -
  -
  -
  -
  -   
  -
  -
  -
  -   
  -
  -
  -
  -  
  -
  -
  -
  -
  -
  -
  -
  -
  -  
  -
  -
  -
  -
  -
  -
  -
  - 
  -
  -
  -
  - 
  -
  -
  -
  - 
  -
  - 
  - 
  -
  -
  -
  -
  -
  -
  -
  -   
  -
  -
  -
  -   
  -
  -
  -   
  -
  -
  -
  - 
  - 
  - 
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  + 
  + 
  +
  +
  + 
  +
  + 
  +
  +
  + 
  + 
  +
  + 
  + 
  + 
  +  
  +  
  + 
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  + 
  +
  +
  +
  +
  +
  + 
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  + 
  + 
  +
  +
  +
  +
  +
  +
  + 
  + 
  +
  +
  +
  +
  +
  +
  +
  +
  + 
  +
  +
  +
  +   
  +
  +
  +
  +
  +
  +
  +
  +   
  +
  +
  +
  + 
  +
  +
  +
  +   
  +
  +
  +
  +
  +
  +
  +
  +   
  +
  +
  +
  +   
  +
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  + 
  +
  +
  +
  + 
  +
  +
  +
  + 
  +
  + 
  + 
  +
  +
  +
  +
  +
  +
  +
  +   
  +
  +
  +
  +   
  +
  +
  +   
  +
  +
  +
  + 
  + 
  + 
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +

   
   
  @@ -274,6 +280,6 @@
   
   
   
  - 
  - 
  -
  + 
  + 
  +
  
  
  

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

RE: [JBoss-dev] Jboss 3.0 / DataSource problem

[Vincent Harcq]

Hi,
I have come to this problem before calling for help, I have
  
 
  com.inet.tds.TdsDriver,
  org.hsql.jdbcDriver
  
  
BTW, this was enough and the add of Opta2000.jar in  -Message d'origine-
> De : marc fleury [mailto:[EMAIL PROTECTED]]
> Envoyé : mercredi 5 septembre 2001 19:09
> À : [EMAIL PROTECTED]; Dev JBoss
> Objet : RE: [JBoss-dev] Jboss 3.0 / DataSource problem
>
>
> well,
>
> you still need to declare the JDBC driver in the "JDBC MBean" thingy.
>
> That is one of the things that we need to change, to have the connector
> declare what driver he is using as opposed to the kludgy MBean we
> have right
> now as a front end to loading the drivers.
>
> marcf
>
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of
> |Vincent Harcq
> |Sent: Wednesday, September 05, 2001 1:01 PM
> |To: Dev JBoss
> |Subject: [JBoss-dev] Jboss 3.0 / DataSource problem
> |
> |
> |Hi,
> |Running latest JBoss 3.0,
> |I have defined a datasource based on Opta2000 driver for MS SQL.
> |I have added the driver to the list of JDBC driver and the opta
> JAR to the
> |list of jar in top of jboss-service.xml.
> |I used the new way of configuring the pool, I simply copy/paste
> the one of
> |DefaultDS and changed the minimum.
> |
> |I got this exception while deploying an entity Bean.
> |
> |[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection:
> |javax.resource.ResourceException: Unable to create DB connection:
> |java.sql.SQLException: No suitable driver
> |at
> |org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createMa
> |nagedConn
> |ection(JDBCManagedConnectionFactory.java:245)
> |
> |Does this say something to somebody ?
> |
> |Thanks.
> |Vincent.
> |
> |
> |___
> |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] Jboss 3.0 / DataSource problem

[Vincent Harcq]

Hi,
Running latest JBoss 3.0,
I have defined a datasource based on Opta2000 driver for MS SQL.
I have added the driver to the list of JDBC driver and the opta JAR to the
list of jar in top of jboss-service.xml.
I used the new way of configuring the pool, I simply copy/paste the one of
DefaultDS and changed the minimum.

I got this exception while deploying an entity Bean.

[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection:
javax.resource.ResourceException: Unable to create DB connection:
java.sql.SQLException: No suitable driver
at
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createManagedConn
ection(JDBCManagedConnectionFactory.java:245)

Does this say something to somebody ?

Thanks.
Vincent.


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

RE: [JBoss-dev] requirements for build

[Vincent Harcq]

Hi,
I thought the idea was to permit the use of external ANT_HOME.
idea: JBoss build stops if it does not find build-magic.jar in ANT_HOME/lib
Also stops if ANT is not 1.4 version
Maybe other...
(with a 3 pages explanation if necessary)µ
Vincent

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Jason Dillon
> Envoyé : samedi 1 septembre 2001 8:51
> À : Dan - Blue Lotus Software
> Cc : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] requirements for build
>
>
> I will add that to my list of things todo.
>
> Thanks,
>
> --jason
>
>
> On Sat, 1 Sep 2001, Dan - Blue Lotus Software wrote:
>
> > Like I said, simply unsetting the environment variable ANT_HOME
> in the build
> > script should take care of this.
> >
> > I use Ant on many other non-JBoss related projects.  I need
> ANT_HOME to be
> > set for these other projects.  I assume others will have the
> same problem.
> > Because I was not aware JBoss included a fully functional Ant in the
> > distribution, I was thrown off by this.  Simply unsetting ANT_HOME in
> > build.bat (and I suspect build.sh, as this is probably a
> problem for both
> > sides) would have fixed this.
> >
> > -dan
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> > Dillon
> > Sent: Friday, August 31, 2001 11:49 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] requirements for build
> >
> >
> > Perhaps we should ignore any user set ANT_HOME, or warn the
> user if it is
> > set.
> >
> > --jason
> >
> >
> > On Fri, 31 Aug 2001, Dan - Blue Lotus Software wrote:
> >
> > > Yes, this was it.  I suggest we unset ANT_HOME in the build script.
> > >
> > > -dan
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > Vincent Harcq
> > > Sent: Friday, August 31, 2001 7:50 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [JBoss-dev] requirements for build
> > >
> > >
> > > Hi,
> > > Is ANT_HOME env property set ?  Unset it and it will run by
> finding ant
> > from
> > > tools/
> > > Vincent.
> > >
> > > > -Message d'origine-
> > > > De : [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]De la
> part de Dan
> > > > - Blue Lotus Software
> > > > Envoyé : vendredi 31 août 2001 11:21
> > > > À : JBoss Dev
> > > > Objet : [JBoss-dev] requirements for build
> > > >
> > > >
> > > > Well, I downloaded and compiled the Rabbit Hole release of
> JBoss today.
> > > > It's the first time I've built JBoss from scratch in about 6
> > > > months.  At any
> > > > rate, I thought I'd reflect a little on a couple of things,
> so that I
> > can
> > > > save people the 30 minutes I spent figuring it out.
> > > >
> > > > -You need v1.4beta of Ant.  The current release is v1.4beta2.
> > > > -Copy the jar file from
> "/tools/buildmagic-tasks.jar"
> > into
> > > > the "lib" directory under Ant.
> > > >
> > > > Once that's done, you can cd into "/build" and
> > > > type "build".
> > > >
> > > > I'm sorry if this is obvious to everyone on this list.  It
> wasn't for
> > me,
> > > > though.  The directions for buildmagic say nothing about how to
> > *install*
> > > > it.  And the build script contains the  tag, which is
> > > > only supported
> > > > in v1.4beta1 and beyond.
> > > >
> > > > -dan
> > > >
> > > > --
> > > > Dan Kirkpatrick, Software Architect
> > > > Blue Lotus Software+44 (0) 1224 575 985
> > > > [EMAIL PROTECTED]
> > > > http://www.bluelotussoftware.com
> > > >
> > > >
> > > > ___
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> > > _
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.co

RE: [JBoss-dev] requirements for build

[Vincent Harcq]

Hi,
Is ANT_HOME env property set ?  Unset it and it will run by finding ant from
tools/
Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dan
> - Blue Lotus Software
> Envoyé : vendredi 31 août 2001 11:21
> À : JBoss Dev
> Objet : [JBoss-dev] requirements for build
>
>
> Well, I downloaded and compiled the Rabbit Hole release of JBoss today.
> It's the first time I've built JBoss from scratch in about 6
> months.  At any
> rate, I thought I'd reflect a little on a couple of things, so that I can
> save people the 30 minutes I spent figuring it out.
>
> -You need v1.4beta of Ant.  The current release is v1.4beta2.
> -Copy the jar file from "/tools/buildmagic-tasks.jar" into
> the "lib" directory under Ant.
>
> Once that's done, you can cd into "/build" and
> type "build".
>
> I'm sorry if this is obvious to everyone on this list.  It wasn't for me,
> though.  The directions for buildmagic say nothing about how to *install*
> it.  And the build script contains the  tag, which is
> only supported
> in v1.4beta1 and beyond.
>
> -dan
>
> --
> Dan Kirkpatrick, Software Architect
> Blue Lotus Software+44 (0) 1224 575 985
> [EMAIL PROTECTED]
> http://www.bluelotussoftware.com
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


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


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

RE: [JBoss-dev] manual build

[Vincent Harcq]

Hi,

> Interesting, today I worked on the manual build also.  I have it working
> with jdk 1.3.1, ant 1.3, some updated xml jars.
>
> problems I still have:
>
> html files end up in manual instead of manual/output/html
I had to change the copy todir task and some others as well.
If you run one by one (html only or printablehtml only), it simpler to see
where the html are generated.

>
> jbossjms.xml has a syntax error.
>
> Problems I fixed:
>
> build.sh does not set ANT_HOME correctly, so the script uses a system ant
> instead of the one in jboss.
>
> XSLTransform, in ant.jar, uses several classes from Optional.jar, so
> build.sh also has to include optional.jar on the local classpath.
>
> The xml processor files in tools... are out of date versions.

That's the reason why I switched to 1.4.
My build (.bat) is doing :

for %%i in (..\thirdparty\sun\jaxp\lib\*.jar) do call lcp.bat %%i
for %%i in (..\tools\apache\ant\lib\*.jar) do call lcp.bat %%i
for %%i in (..\tools\apache\ant\lib\ext\*.jar) do call lcp.bat %%i

With no more xml jars in ant\lib\

>
> I hope to get the output directory fixed shortly, probably the
> syntax error
> will be easy too.
>
> Since mine works with ant 1.3 should I commit? or should we be forward
> looking?
>
> david jencks
>
> On 2001.08.21 18:56:25 -0400 Vincent Harcq wrote:
> > Hi,
> > Is there anybody trying to make the manual build run correctly?
> >
> > I give it a (painful) try.
> > I succeed to build a part of html and printable-html (hum simply the
> > preface,intro, cmp and jaws for the moment)
> >
> > I choose to move to ant 1.4 that use JAXP 1.1 to avoid problems with
> > style,
> > xsl, ...
> > I needed to change the jboss-all/build/build.bat to include sun/jaxp and
> > ant/lib/ext jars.
> > The manual build.xml has also changed.
> > In jbossdocs.xml I have to reference the _entity_ using full path
> >
> > Because of these (ant 1.4 is beta and I did not check compliance with
> > other
> > modules), I don't know if it is a good idea to commit now.
> > What do you think ?
> > Create a branch until it works ?
> >
> > The problems I have now:
> > printable-html : Some javax.xml.transform.TransformerException when I
> > added
> > more chapter xml files to jbossdocs.xml.
> > printable-html : the CSS is nt included in generated html.
> > printable-html : the file is jbossdocshtml (the . is missing)
> >
> > html: it fails everytime with a
> javax.xml.transform.TransformerException:
> > java.lang.ArrayIndexOutOfBoundsException at the end of the build.
> >
> >
> > Vincent.
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


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


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

[JBoss-dev] manual build

[Vincent Harcq]

Hi,
Is there anybody trying to make the manual build run correctly?

I give it a (painful) try.
I succeed to build a part of html and printable-html (hum simply the
preface,intro, cmp and jaws for the moment)

I choose to move to ant 1.4 that use JAXP 1.1 to avoid problems with style,
xsl, ...
I needed to change the jboss-all/build/build.bat to include sun/jaxp and
ant/lib/ext jars.
The manual build.xml has also changed.
In jbossdocs.xml I have to reference the _entity_ using full path

Because of these (ant 1.4 is beta and I did not check compliance with other
modules), I don't know if it is a good idea to commit now.
What do you think ?
Create a branch until it works ?

The problems I have now:
printable-html : Some javax.xml.transform.TransformerException when I added
more chapter xml files to jbossdocs.xml.
printable-html : the CSS is nt included in generated html.
printable-html : the file is jbossdocshtml (the . is missing)

html: it fails everytime with a javax.xml.transform.TransformerException:
java.lang.ArrayIndexOutOfBoundsException at the end of the build.


Vincent.


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


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

[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml

[Vincent Harcq]

  User: vharcq  
  Date: 01/08/15 08:38:42

  Modified:src/etc/conf/default jboss.jcml
  Log:
  Parametrize the timeout that the deployer takes before coming again looking at the 
directory for new Xars to deploy.
  
  Revision  ChangesPath
  1.57  +4 -1  jboss/src/etc/conf/default/jboss.jcml
  
  Index: jboss.jcml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss.jcml,v
  retrieving revision 1.56
  retrieving revision 1.57
  diff -u -r1.56 -r1.57
  --- jboss.jcml2001/08/14 22:53:52 1.56
  +++ jboss.jcml2001/08/15 15:38:42 1.57
  @@ -7,7 +7,7 @@
   
   
   
  -
  +
   
   

RE: [JBoss-dev] Container.java

[Vincent Harcq]

Hi Scott,

I don't know.
I undeploy by deleting the jar in the deploy/ directory (windows 2000), I
did not try by JMX.
I got:
Bug in com.sun.management.jmx.MBeanServerImpl.unregisterMBean ?

[org.jboss.ejb.AutoDeployer  ] (199) - Auto undeploy of
file:/C:/Projects/VMI/jboss/tmp/deploy/Default/Task.jar
[org.jboss.deployment.J2eeDeployer#Default] (67 ) - Stopping module Task.jar
[org.jboss.ejb.ContainerFactory  ] (67 ) -
Undeploying:file:/C:/Projects/VMI/jboss/tmp/deploy/Default/Task.jar
My debug msg ==> [org.jboss.ejb.MessageDrivenContainer] (426) -
Exception stopping Container
file:/C:/Projects/VMI/jboss/tmp/deploy/Default/Task.jar
javax.management.InstanceNotFoundException:
:service=Container,jndiName=SystemTaskQueue
at
com.sun.management.jmx.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:
945)
at org.jboss.ejb.Container.stop(Container.java:422)
at
org.jboss.ejb.MessageDrivenContainer.stop(MessageDrivenContainer.java:221)

I just try your version of Container.java.
It is working fine.

Vincent.

> This pattern should be used in both the start and stop methods then. I
> have done this and I am able to redeploy ejb jars.
>
> Why can the name ObjectName(":service=Container,jndiName=someName")
> be used to register an mbean but the same name fails to unregister it?
>
> - Original Message -
> From: "Vincent Harcq" <[EMAIL PROTECTED]>
> To: "Dev JBoss" <[EMAIL PROTECTED]>
> Sent: Wednesday, August 15, 2001 5:19 AM
> Subject: [JBoss-dev] Container.java
>
>
> > The server can not re-deploy an ejb jar anymore because of exception on
> > unregistration of MBean.
> >
> > Does this makes sense (on the stop() method)?
> >
> > diff -r1.55 Container.java
> > 421c421
> > <  ObjectName jmxName = new
> >
> ObjectName(":service=Container,jndiName="+this.getBeanMetaData().g
> etJndiName
> > ());
> > ---
> > >  ObjectName jmxName = new
> >
> ObjectName(mbeanServer.getDefaultDomain()+":service=Container,jndi
> Name="+thi
> > s.getBeanMetaData().getJndiName());
> >
> > Vincent.
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

RE: autodeployer bug RE: [JBoss-dev] problems with latest jboss-jetty?

[Vincent Harcq]

Just done :)
Add an attribute Timeout to AutoDeployer MBean (value in milliseconds).
Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de marc
> fleury
> Envoyé : mercredi 15 août 2001 16:04
> À : [EMAIL PROTECTED]
> Objet : autodeployer bug RE: [JBoss-dev] problems with latest
> jboss-jetty?
>
>
> Yeah
>
> my guess is that the deployment bug is due to the fact that it is big and
> that the deployer is too eager.  I think we should put a test in the
> autodeployer that says "if file older than previous_age+15 sec then
> redeploy, or else have a "deploying" boolean be checked in the
> autodeployer
>
> any takers?
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of
> |Julian Gosnell
> |Sent: Wednesday, August 15, 2001 5:36 AM
> |To: [EMAIL PROTECTED]
> |Subject: Re: [JBoss-dev] problems with latest jboss-jetty?
> |
> |
> |I thought it might be to do with the time taken for
> |deployment.
> |
> |I haven't investigated yet, but here are my thoughts.
> |
> |Marc said that the newsite EAR was big. What if it
> |took so long to deploy, that whatever was watching the
> |deploy dir came around again and noticed that it was
> |still there and still not deployed ?
> |
> |Would it try to deploy it again ?
> |
> |
> |Jules
> |
> |
> | --- Scott M Stark <[EMAIL PROTECTED]> wrote: > A
> |trivial testcase is to simply start the bundle
> |> with the tomcat-test.ear in
> |> the deploy
> |> directory and then touch the ear after startup. I
> |> see the same basic
> |> behavior with
> |> both the 2.4.0.26 JBoss tomcat and jetty bundles,
> |> and neither does a double
> |> deployment.
> |>
> |>
> |> - Original Message -
> |> From: Julian Gosnell
> |> To: [EMAIL PROTECTED]
> |> Sent: Monday, August 13, 2001 5:47 PM
> |> Subject: Re: [JBoss-dev] problems with latest
> |> jboss-jetty?
> |>
> |>
> |> Marc,
> |>
> |> I'd be interested to know if the same version of
> |> JBoss with TomCat exhibits
> |> this double deployment problem - otherwise it is
> |> something that I should be
> |> looking at.
> |>
> |>
> |> Jules
> |>
> |>
> |>
> |>
> |>
> |> ___
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |>
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
> |
> |
> |Do You Yahoo!?
> |Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> |or your free @yahoo.ie address at http://mail.yahoo.ie
> |
> |___
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

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

[Vincent Harcq]

  User: vharcq  
  Date: 01/08/15 08:13:45

  Modified:src/main/org/jboss/ejb AutoDeployer.java
AutoDeployerMBean.java
  Log:
  Parametrize the timeout that the deployer takes before coming again looking at the 
directory for new Xars to deploy.
  
  Revision  ChangesPath
  1.21  +19 -2 jboss/src/main/org/jboss/ejb/AutoDeployer.java
  
  Index: AutoDeployer.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/AutoDeployer.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- AutoDeployer.java 2001/08/03 17:15:43 1.20
  +++ AutoDeployer.java 2001/08/15 15:13:45 1.21
  @@ -47,7 +47,7 @@
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Toby Allsopp
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @version $Revision: 1.20 $
  + * @version $Revision: 1.21 $
*/
   public class AutoDeployer
extends ServiceMBeanSupport
  @@ -84,6 +84,9 @@
  // URL list
  String urlList = "";
   
  +   // TimeOut that in case of big ears to deploy should be set high enough
  +   int timeout = 3000;
  +
  /** Filters, one per configured deployer, to decide which files are
  deployable and which should be ignored */
  FilenameFilter[] deployableFilters = null;
  @@ -127,6 +130,16 @@
 return deployerList;
  }
   
  +   public void setTimeout(int to)
  +   {
  +  this.timeout = to;
  +   }
  +
  +   public int getTimeout()
  +   {
  +  return timeout;
  +   }
  +
  // Public 
  public void run()
  {
  @@ -135,7 +148,11 @@
// Sleep
if (running)
{
  -try { Thread.sleep(3000); } catch (InterruptedException e) {}
  +try
  +{
  +   if (log.isDebugEnabled()) log.debug("Wait for "+timeout / 1000 +" 
seconds");
  +   Thread.sleep(timeout);
  +} catch (InterruptedException e) {}
}
   
try
  
  
  
  1.8   +18 -1 jboss/src/main/org/jboss/ejb/AutoDeployerMBean.java
  
  Index: AutoDeployerMBean.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/AutoDeployerMBean.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- AutoDeployerMBean.java2001/08/03 17:15:43 1.7
  +++ AutoDeployerMBean.java2001/08/15 15:13:45 1.8
  @@ -16,7 +16,7 @@
* 
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Toby Allsopp
  - * @version $Revision: 1.7 $
  + * @version $Revision: 1.8 $
*/
   public interface AutoDeployerMBean
  extends ServiceMBean
  @@ -51,5 +51,22 @@
   * @return   The list of deployers that is currently being used.
   */
  String getDeployers();
  +
  +   /**
  +* Set the time in milli seconds the AutoDeployer have to sleep before
  +* looking again for new files.
  +*
  +* @param to Timeout in miliseconds
  +*/
  +   void setTimeout(int to);
  +
  +   /**
  +* Return the time in milli seconds the AutoDeployer have to sleep before
  +* looking again for new files.
  +*
  +* @return The timeout in miliseconds
  +*/
  +   int getTimeout();
  +
   }
   
  
  
  

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

[JBoss-dev] Container.java

[Vincent Harcq]

The server can not re-deploy an ejb jar anymore because of exception on
unregistration of MBean.

Does this makes sense (on the stop() method)?

diff -r1.55 Container.java
421c421
<  ObjectName jmxName = new
ObjectName(":service=Container,jndiName="+this.getBeanMetaData().getJndiName
());
---
>  ObjectName jmxName = new
ObjectName(mbeanServer.getDefaultDomain()+":service=Container,jndiName="+thi
s.getBeanMetaData().getJndiName());

Vincent.


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


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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata XmlFileLoader.java

[Vincent Harcq]

  User: vharcq  
  Date: 01/08/15 05:15:28

  Modified:src/main/org/jboss/metadata XmlFileLoader.java
  Log:
  Introduce version 3.0 of jaws dtd because of DEBUG removed.
  
  Revision  ChangesPath
  1.19  +2 -1  jboss/src/main/org/jboss/metadata/XmlFileLoader.java
  
  Index: XmlFileLoader.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/XmlFileLoader.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- XmlFileLoader.java2001/08/03 17:15:54 1.18
  +++ XmlFileLoader.java2001/08/15 12:15:28 1.19
  @@ -37,7 +37,7 @@
*   @author mailto:[EMAIL PROTECTED]";>Wolfgang Werner
*   @author mailto:[EMAIL PROTECTED]";>Darius Davidavicius
*   @author mailto:[EMAIL PROTECTED]";>Scott Stark
  - *   @version $Revision: 1.18 $
  + *   @version $Revision: 1.19 $
*
*   Revisions:
*   20010620 Bill Burke: Print an error message when failing to load 
standardjboss.xml
  @@ -284,6 +284,7 @@
   registerDTD("-//Sun Microsystems, Inc.//DTD Connector 1.0//EN", 
"connector_1_0.dtd");
   registerDTD("-//JBoss//DTD JAWS//EN", "jaws.dtd");
   registerDTD("-//JBoss//DTD JAWS 2.4//EN", "jaws_2_4.dtd");
  +registerDTD("-//JBoss//DTD JAWS 3.0//EN", "jaws_3_0.dtd");
   registerDTD("-//JBoss//DTD JBOSS//EN","jboss.dtd");
   registerDTD("-//JBoss//DTD JBOSS 2.4//EN","jboss_2_4.dtd");
}
  
  
  

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

[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jaws_3_0.dtd

[Vincent Harcq]

  User: vharcq  
  Date: 01/08/15 05:15:28

  Added:   src/resources/org/jboss/metadata jaws_3_0.dtd
  Log:
  Introduce version 3.0 of jaws dtd because of DEBUG removed.
  
  Revision  ChangesPath
  1.1  jboss/src/resources/org/jboss/metadata/jaws_3_0.dtd
  
  Index: jaws_3_0.dtd
  ===
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

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

RE: [JBoss-dev] Jaws debug mode

[Vincent Harcq]

Hi,

> Does anyone know what the cost of the isXXXEnabled() methods are? 
>  Should we
> define booleans after Category creation, that can cache these values to
> improve speed, or just keep calling isXXXEnabled() each time?

>From the log4j sources:
  public
  boolean isDebugEnabled() {
if(hierarchy.disable >=  Priority.DEBUG_INT)
  return false;   
return Priority.DEBUG.isGreaterOrEqual(this.getChainedPriority());
  }

The getChainedPriority is a recursive method:
for(Category c = this; c != null; c=c.parent)
{
   if(c.priority != null) 
 return c.priority;
}

Save the result in a boolean and test the boolean will improve performance.
I am not at all a performance guru, I have no idea at which level it will.

It is a good idea to do what you propose.

> --jason

Vincent.

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


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

RE: [JBoss-dev] RE: new build system

[Vincent Harcq]

There is no jdom.jar with Jboss.
I used to use it and before scott's changes, I could not put it in lib/ext
because it uses XML builder and those were in lib/, bla bla bla
So after the build, it was still out of lib/ext, and so not finding org.xml
and sisters that are now in lin/ext

And with the new build system at the same time, it was too much for me ;)

No problems anymore.
Thanks.
Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Jason Dillon
> Envoye : mardi 14 aout 2001 21:13
> A : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] RE: new build system
>
>
> Hrm... I do not remeber a jdom.jar.  Why don't you just drop all
> supporting
> jars into lib/ext ?
>
> --jason
>
>
> On Tue, 14 Aug 2001, Vincent Harcq wrote:
>
> > This the jar containing my MBean classes,
> > It needs the etc/conf in the classpath to find a file to load
> and ... parse.
> > I am not able to test that before 8 hours from now, I have seen that my
> > jdom.jar was setup using JBOSS_CLASSPATH wich is not used
> anymore for xml.
> > So the problem comes from my side.  For sure.
> > I'll keep you inform anyway.
> >
> > Thanks.
> > Vincent.
> > >= Original Message From Jason Dillon <[EMAIL PROTECTED]> =
> > >> jboss.conf
> > >>  > >> CODEBASE="../../lib/ext/">
> > >> 
> > >> 
> > >
> > >What is hm-jmx.jar?
> > >
> > >--jason
> > >
> > >
> > >___
> > >Jboss-development mailing list
> > >[EMAIL PROTECTED]
> > >http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

RE: [JBoss-dev] RE: new build system

[Vincent Harcq]

I solve my problem.
jdom.jar was in the JBOSS_CLASSPATH.
I copied it to lib/ext.

Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Vincent Harcq
> Envoye : mardi 14 aout 2001 8:29
> A : Jason Dillon
> Cc : Dev JBoss
> Objet : [JBoss-dev] RE: new build system
>
>
> Hi,
>
> > This is because of the classpath changes that scott made.  The
> jaxp parser
> > jars have been moved from lib to lib/ext.
> >
> > Where is your MBean loaded from, jboss.jcml or jboss.conf?  If it is
> > jboss.conf, then you will need to add the jaxp.jar and
> > crimson.jar's to the
> > archive list.
>
> It is loaded from jboss.jcml.
>
> >
> > Don't know if that helps, but I found that when I am using the XML
> > configuration for the Log4jService, it will complain about these too.
> >
> > If this happens from inside jboss.jcml, and both of these files
> > are actually
> > in the lib/ext directory, then something else is wrong.
> Unfortunatly the
> > bootstrap classloading that goes on is still a little bit of a
> mistery to
> > me.
> >
> > SAX, DOM, Whatever.
> >
> > If you still have files other than jmxri.jar in your output/jboss-*/lib
>
> No it is clean.
>
> > directory then you should probably re-build with something like
> this from
> > the build module:
> >
> >   ./build.sh clean release
> >
> > Or just remove everything in output/jboss-*/lib and:
> >
> >   ./build.sh
> >
> > Which will install all the correct files.  Let me know a little
> more about
> > where this MBean is loaded and if any of this helps.
>
> jboss.jcml:
>  name="HubMethods:service=TestFileLoader">
>     test.xml
> 
>
> jboss.conf
>  CODEBASE="../../lib/ext/">
> 
> 
>
> I will try to look at other MBeans and how they can parse XML documents...
> I am out for the day, it will be for tomorrow...
>
> Thanks.
> Vincent.
>
> >
> > --jason
> >
> >
> > On Tue, 14 Aug 2001, Vincent Harcq wrote:
> >
> > > Hi,
> > > I build OK.
> > > I run OK except for one custom MBean.  This is due to xml
> > changes I guess.
> > > I receive an exception java.lang.NoClassDefFoundError:
> org/w3c/dom/Node
> > > On the line of my MBean that do DOMBuilder builder = new DOMBuilder();
> > > This class is coming from JDOM.
> > >
> > > I try adding this to jboss.conf
> > >  > > CODEBASE="../../lib/ext/">
> > > 
> > > 
> > > 
> > > without success.
> > >
> > > It worked when xml stuffs was in lib/
> > >
> > > Should I not use JDOM but pure sax instead ?
> > >
> > > Regards.
> > > Vincent.
> > >
> > >
> > > > -Message d'origine-
> > > > De : Jason Dillon [mailto:[EMAIL PROTECTED]]
> > > > Envoye : lundi 13 aout 2001 8:04
> > > > A : [EMAIL PROTECTED]
> > > > Cc : Dev JBoss
> > > > Objet : RE: new build system
> > > >
> > > >
> > > > > That is a problem that will come again, I want to be sure
> > to understand:
> > > > > If you add a new link in CVSROOT/modules for jboss-all, a
> > Check Out is
> > > > > needed ?  an Update is not enough ?
> > > >
> > > > Yes.  Checkout is the only time that CVS will pay any
> attention to the
> > > > CVSROOT/modules file.  The exact module name you used is lost
> > > > after that and
> > > > all CVS has to work on is the data in CVS/Root &
> > CVS/Repository.  Update
> > > > simply checks the files (and sub-directories) of modules
> which it has
> > > > previouly checked out and has CVS/* files for.
> > > >
> > > > It is safe to run a checkout over an existing workspace,
> > though you might
> > > > get some silly warnings.  Just be sure to update afterwards
> > for the full
> > > > effect.
> > > >
> > > > > Or is it only a problem when running first Check Out and
> > > > killing it in the
> > > > > middle (over a 56k phone line, it will happen to others
> > than me I bet) ?
> > > > > I will make clean CO at work (adsl hehe) and let you know
> > how far I go.
> > > >
> > > > Checkout over an existing workspace *should not* consume
> that much BW.
> > > >
> > > > --jason
> > > >
> > > >
> > >
> > >
> > > _
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> >
> >
>
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

RE: [JBoss-dev] RE: new build system

[Vincent Harcq]

This the jar containing my MBean classes,
It needs the etc/conf in the classpath to find a file to load and ... parse.
I am not able to test that before 8 hours from now, I have seen that my 
jdom.jar was setup using JBOSS_CLASSPATH wich is not used anymore for xml.
So the problem comes from my side.  For sure.
I'll keep you inform anyway.

Thanks.
Vincent.
>= Original Message From Jason Dillon <[EMAIL PROTECTED]> =
>> jboss.conf
>> > CODEBASE="../../lib/ext/">
>> 
>> 
>
>What is hm-jmx.jar?
>
>--jason
>
>
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-development



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

[JBoss-dev] RE: new build system

[Vincent Harcq]

Hi,

> This is because of the classpath changes that scott made.  The jaxp parser
> jars have been moved from lib to lib/ext.
>
> Where is your MBean loaded from, jboss.jcml or jboss.conf?  If it is
> jboss.conf, then you will need to add the jaxp.jar and
> crimson.jar's to the
> archive list.

It is loaded from jboss.jcml.

>
> Don't know if that helps, but I found that when I am using the XML
> configuration for the Log4jService, it will complain about these too.
>
> If this happens from inside jboss.jcml, and both of these files
> are actually
> in the lib/ext directory, then something else is wrong.  Unfortunatly the
> bootstrap classloading that goes on is still a little bit of a mistery to
> me.
>
> SAX, DOM, Whatever.
>
> If you still have files other than jmxri.jar in your output/jboss-*/lib

No it is clean.

> directory then you should probably re-build with something like this from
> the build module:
>
>   ./build.sh clean release
>
> Or just remove everything in output/jboss-*/lib and:
>
>   ./build.sh
>
> Which will install all the correct files.  Let me know a little more about
> where this MBean is loaded and if any of this helps.

jboss.jcml:

test.xml


jboss.conf




I will try to look at other MBeans and how they can parse XML documents...
I am out for the day, it will be for tomorrow...

Thanks.
Vincent.

>
> --jason
>
>
> On Tue, 14 Aug 2001, Vincent Harcq wrote:
>
> > Hi,
> > I build OK.
> > I run OK except for one custom MBean.  This is due to xml
> changes I guess.
> > I receive an exception java.lang.NoClassDefFoundError: org/w3c/dom/Node
> > On the line of my MBean that do DOMBuilder builder = new DOMBuilder();
> > This class is coming from JDOM.
> >
> > I try adding this to jboss.conf
> >  > CODEBASE="../../lib/ext/">
> > 
> > 
> > 
> > without success.
> >
> > It worked when xml stuffs was in lib/
> >
> > Should I not use JDOM but pure sax instead ?
> >
> > Regards.
> > Vincent.
> >
> >
> > > -Message d'origine-
> > > De : Jason Dillon [mailto:[EMAIL PROTECTED]]
> > > Envoye : lundi 13 aout 2001 8:04
> > > A : [EMAIL PROTECTED]
> > > Cc : Dev JBoss
> > > Objet : RE: new build system
> > >
> > >
> > > > That is a problem that will come again, I want to be sure
> to understand:
> > > > If you add a new link in CVSROOT/modules for jboss-all, a
> Check Out is
> > > > needed ?  an Update is not enough ?
> > >
> > > Yes.  Checkout is the only time that CVS will pay any attention to the
> > > CVSROOT/modules file.  The exact module name you used is lost
> > > after that and
> > > all CVS has to work on is the data in CVS/Root &
> CVS/Repository.  Update
> > > simply checks the files (and sub-directories) of modules which it has
> > > previouly checked out and has CVS/* files for.
> > >
> > > It is safe to run a checkout over an existing workspace,
> though you might
> > > get some silly warnings.  Just be sure to update afterwards
> for the full
> > > effect.
> > >
> > > > Or is it only a problem when running first Check Out and
> > > killing it in the
> > > > middle (over a 56k phone line, it will happen to others
> than me I bet) ?
> > > > I will make clean CO at work (adsl hehe) and let you know
> how far I go.
> > >
> > > Checkout over an existing workspace *should not* consume that much BW.
> > >
> > > --jason
> > >
> > >
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
>
>


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


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

[JBoss-dev] RE: new build system

[Vincent Harcq]

Hi,
I build OK.
I run OK except for one custom MBean.  This is due to xml changes I guess.
I receive an exception java.lang.NoClassDefFoundError: org/w3c/dom/Node
On the line of my MBean that do DOMBuilder builder = new DOMBuilder();
This class is coming from JDOM.

I try adding this to jboss.conf




without success.

It worked when xml stuffs was in lib/

Should I not use JDOM but pure sax instead ?

Regards.
Vincent.


> -Message d'origine-
> De : Jason Dillon [mailto:[EMAIL PROTECTED]]
> Envoye : lundi 13 aout 2001 8:04
> A : [EMAIL PROTECTED]
> Cc : Dev JBoss
> Objet : RE: new build system
>
>
> > That is a problem that will come again, I want to be sure to understand:
> > If you add a new link in CVSROOT/modules for jboss-all, a Check Out is
> > needed ?  an Update is not enough ?
>
> Yes.  Checkout is the only time that CVS will pay any attention to the
> CVSROOT/modules file.  The exact module name you used is lost
> after that and
> all CVS has to work on is the data in CVS/Root & CVS/Repository.  Update
> simply checks the files (and sub-directories) of modules which it has
> previouly checked out and has CVS/* files for.
>
> It is safe to run a checkout over an existing workspace, though you might
> get some silly warnings.  Just be sure to update afterwards for the full
> effect.
>
> > Or is it only a problem when running first Check Out and
> killing it in the
> > middle (over a 56k phone line, it will happen to others than me I bet) ?
> > I will make clean CO at work (adsl hehe) and let you know how far I go.
>
> Checkout over an existing workspace *should not* consume that much BW.
>
> --jason
>
>


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


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

[JBoss-dev] RE: new build system

[Vincent Harcq]

OK.
That is a problem that will come again, I want to be sure to understand:
If you add a new link in CVSROOT/modules for jboss-all, a Check Out is
needed ?  an Update is not enough ?
Or is it only a problem when running first Check Out and killing it in the
middle (over a 56k phone line, it will happen to others than me I bet) ?
I will make clean CO at work (adsl hehe) and let you know how far I go.

Thanks and don't be sorry, the sytem looks very strong now :)

Vincent.

> -Message d'origine-
> De : Jason Dillon [mailto:[EMAIL PROTECTED]]
> Envoye : lundi 13 aout 2001 7:39
> A : [EMAIL PROTECTED]
> Objet : RE: new build system
>
>
> Good.  In the future I would suggest that you checkout the module
> over your
> current workspace.  Sorry for the trouble... I was not wrong in thinking
> there would be a few snags.
>
> I also have some updated docs, which I will publish on Monday.
>
> --jason
>
>
> On Mon, 13 Aug 2001, Vincent Harcq wrote:
>
> > I just co plugins and copy it to jboss-all,
> > It works ok now.
> > Thanks.
> >
> >
> > > -Message d'origine-
> > > De : Vincent Harcq [mailto:[EMAIL PROTECTED]]
> > > Envoye : lundi 13 aout 2001 7:19
> > > A : Jason Dillon; [EMAIL PROTECTED]
> > > Objet : RE: new build system
> > >
> > >
> > > Hi,
> > > I receive
> > > [execmodules] Missing build file; skipping module: plugins/varia
> > >
> > > In fact I don't have a plugins directory at all in jboss-all.
> > >
> > > The modules of CVSROOT seems OK.
> > > I had to kill my cvs co command at first, may be it is the
> problem, I will
> > > retry a fresh cvs co.
> > >
> > > Regards.
> > > Vincent
> > >
> > > > -Message d'origine-
> > > > De : Jason Dillon [mailto:[EMAIL PROTECTED]]
> > > > Envoye : dimanche 12 aout 2001 23:46
> > > > A : [EMAIL PROTECTED]
> > > > Objet : Re: new build system
> > > >
> > > >
> > > > Could you show me what you actually ran to build it?
> > > >
> > > > These are copied from the plugins/varia module, since that is
> > > where those
> > > > sources live now.  They should install idb.jar, idb-plugin.jar,
> > > > hsql.jar and
> > > > hsql-plugin.jar plus some other bits for tyrex and castor jdo.
> > > >
> > > > Let me know.
> > > >
> > > > --jason
> > > >
> > > >
> > > > On Sun, 12 Aug 2001, Vincent Harcq wrote:
> > > >
> > > > > Hi,
> > > > > i just update my cvs and ... understand you made the big jump.
> > > > > So I checked out jboss-all.
> > > > > i have some issues after build release (run after build configure)
> > > > >
> > > > > 1. hsql.jar and idb.jar are not copied to lib/ext
> > > > > 2. the server start complain : java.lang.ClassNotFoundException:
> > > > > org.jboss.jdbc.HypersonicDatabase
> > > > >
> > > > > the server then blocks on InstantDB.
> > > > >
> > > > >
> > > > > Regards.
> > > > > Vincent.
> > > > >
> > > > >
> > > > >
> > > > > _
> > > > > Do You Yahoo!?
> > > > > Get your free @yahoo.com address at http://mail.yahoo.com
> > > > >
> > > >
> > > >
> > >
> > >  _ Do You
> > > Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
>
>


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


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

[JBoss-dev] Jaws debug mode

[Vincent Harcq]

Hi,
I modify JDBCCommand & co to use log4j for debugging.

Should I commit that ?

I also get rid of debug option of standardjaws.xml to use log4j declaration
instead.
It permits better control on which class to debug (find,update,...)

Should I commit that ?
My concern is regarding performance changes it will cause.

Regards.
Vincent.


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


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

RE: [JBoss-dev] ejb-local-ref and ejb-link

[Vincent Harcq]

> |Using local interfaces from web would be stupid I agree.
>
> I am not sure that is true, nor what he says.
>
> In fact we already use "local" stuff in the optimized version.  I guess it
> wouldn't be portable that's all and would limit your deployment
> option. But
> since we automate that already in the current base it is kind of a moot
> point.  All the spec has bought us in this case is "portability" but the
> feature is the same :( -> mucho code and little gain

Yes, that's what I thought before beginning my big surgery, and it verifies
now : little/no gain after migrating a lot to local interfaces.

Anyway it makes things _clearer_ with session bean facade and (cmp 1.1) cmp
relationships.

Sorry but I disagree (with you-agree with Dan) on the web part, when
portability comes in priority before performance, when I want to be able to
have a web tier separate from the ejb tier.
Even if JBoss handle everything in one VM, I can not make assumption on how
the deployment will be made.
I hope you will agree that saying "performance ==> deployment ==>
portability" is not always a good message.  "portability ==> deployment ==>
performance" can be an option too.


> marcf

Vincent


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


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

RE: [JBoss-dev] ejb-local-ref and ejb-link

[Vincent Harcq]

Thank you Dan.
It's clearer now, and even think I prefer this way of working.
Using local interfaces from web would be stupid I agree.
Even between ejb jars seems dangerous to me.

(btw I only have independant ejb jar for the moment, no ears. I will not be
able to verify your remarks(classloading and ejb-link), I keep them under my
pillow...)

Regards.
Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dan
> OConnor
> Envoye : mercredi 8 aout 2001 13:51
> A : Dev JBoss
> Objet : Re: [JBoss-dev] ejb-local-ref and ejb-link
>
>
> Hi Vincent,
>
> The specification does not indicate the limitations of the scope in
> which local interfaces are effective, beyond requiring that they be
> co-located in a JVM. I wish it did, and I advocated a specific
> statement in the spec in a discussion on ejb-interest.
>
> Obviously pass-by-reference semantics will only work when you
> have a common classloader. The classloader scheme is particular
> to an application server implementation. You are 100% safe using
> local references only within a JAR, and you are probably safe using
> local references between JARs in an EAR. (Someone more familiar
> with the current classloading scheme can comment on this.)
>
> In my opinion, you are not portable using local references between
> EARs. It might be supported by JBoss when Marc solves the
> "dumbo" problem, but I still wouldn't recommend this approach.
>
> You didn't ask, but... using local references from the web tier is
> possible. However, it is probably a bad idea. An important
> deployment option is to have the web and business-logic tiers on
> different physical machines, e.g. for security. Using a local
> interface completely forecloses this deployment option.
>
> In terms of ejb-link... because local interfaces probably shouldn't be
> available outside of an EAR, they can always be configured using
> an ejb-link. (In theory, at least, ejb-link can link between JARs in
> an EAR. Does it work in JBoss? Haven't tried it...) So when I
> implemented local interfaces, I required ejb-link rather than
> introducing some funky JNDI publishing scheme.
>
> I'm not the only one to do this. I recently saw some posts to ejb-
> interest from the pramati server team advocating this approach.
> These were after my implementation, and I didn't get the idea from
> them, but they give some confirmation to my approach. For
> example, see http://archives.java.sun.com/cgi-
> bin/wa?A2=ind0107&L=ejb-
> interest&P=R15438&D=0&H=0&O=T&T=1.
>
> There is support for the other point of view. BEA WebLogic 6.1
> requires a JNDI name for the local home interface.
>
> Perhaps the EJB 2.0 final spec will clarify these issues.
>
> -Dan
>
>
> On 8 Aug 01, at 11:57, Vincent Harcq wrote:
>
> > Hi,
> > Currently the container verifies that an ejb-link exists inside an
> > ejb-local-ref.
> > I read through the spec and don't see this is required.
> > In most cases the 2 beans will be in the same jar so no
> problem, but this
> > limitation should not happen imho.
> >
> > A second point:
> > Local interfaces access must be in the same JVM.
> > It is not required they must be in the same JAR or the same EAR.
> > Will this "pass by reference" work into JBoss ?
> > Can 2 ejb jar talk to each other with "pass by reference" if they are
> > deployed separately ?
> >
> > Vincent.
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

[JBoss-dev] ejb-local-ref and ejb-link

[Vincent Harcq]

Hi,
Currently the container verifies that an ejb-link exists inside an
ejb-local-ref.
I read through the spec and don't see this is required.
In most cases the 2 beans will be in the same jar so no problem, but this
limitation should not happen imho.

A second point:
Local interfaces access must be in the same JVM.
It is not required they must be in the same JAR or the same EAR.
Will this "pass by reference" work into JBoss ?
Can 2 ejb jar talk to each other with "pass by reference" if they are
deployed separately ?

Vincent.


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


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

[JBoss-dev] Local only Home interface and JDBCFindEntitiesCommand

[Vincent Harcq]

Hi,
Line 99:
   Method[] homeMethods =
factory.getContainer().getHomeClass().getMethods();

cause a NPE in case I deploy an cmp entity bean with _only_ a Local Home
interface : the container have only a Local Home class defined.

In more general, should this class be review to handle any combination
possible (only remote/only local/both)

Do you think it is something to do now or on the new CMP 2.0 module ?

Vincent.


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


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

[JBoss-dev] CVS update: manual/src/docs advconfig.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/08/05 07:43:58

  Modified:src/docs advconfig.xml
  Log:
  resource-ref section : java.net.URL and resource-managers
  
  Revision  ChangesPath
  1.17  +96 -16manual/src/docs/advconfig.xml
  
  Index: advconfig.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/advconfig.xml,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- advconfig.xml 2001/08/05 13:48:24 1.16
  +++ advconfig.xml 2001/08/05 14:43:58 1.17
  @@ -66,13 +66,21 @@
The EJB specification facilitate the access to external 
"resources" through the use of deployment
   descriptor entries in ejb-jar.xml.  The tag is .
  +
  + 
The res-ref-name element specifies the name of a resource 
manager connection factory reference.
  + 
  + 
The res-type element specifies the type of the data source. The 
type is specified by the Java 
   interface (or class) expected to be implemented by the data source.
  + 
  + 
The res-auth element specifies whether the enterprise bean code 
signs on programmatically to 
   the resource manager, or whether the Container will sign on to the resource manager 
on behalf of the bean. 
   In the latter case, the Container uses information that is supplied by the 
Deployer.  Valid entry are 
   "Container" and "Application".
  + 
  +
Example:
   .  The first two
  -generally takes the value of corresponding entry in ejb-jar.xml.
  +in .
  +
  + 
  + res-ref-name must always be present and takes the value of 
corresponding entry in ejb-jar.xml.
  + 
  + 
jndi-name points to the general definition of the resource in 
JBoss installation.
  + 
  + 
  + res-url is used for java.net.URL type Resource only and define 
the URL.
  + 
  + 
  + resource-name is there to introduce a new level of indirection 
to a Resource Manager.
  + 
  +
  + A Resource Manager is defined globally for an EJB JAR inside 

  +
  + 
  + res-name must always be defined and takes the value of 
corresponding resource-name entry of 
  +resource-ref.
  + 
  + 
  + res-jndi-name points to the general definition of the resource 
in JBoss installation.
  + 
  + 
  + res-url is used for java.net.URL type Resource only and define 
the URL.
  + 
  + 
  + res-class can be blank, or is the Java type of the 
resource.
  + 
  +
Example:
   
  +Note that this example include complexity not necessary in all cases.  Resource 
Managers does not have to be
  +specified.  The simple example for JDBC DataSource is:
  +
  -To access the Resource from your bean, do something like:
  +
  +To access the Resource from your bean, do something like:
   

[JBoss-dev] CVS update: manual/src/docs advconfig.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/08/05 06:48:24

  Modified:src/docs advconfig.xml
  Log:
  Section on resource-ref entry
  
  Revision  ChangesPath
  1.16  +125 -0manual/src/docs/advconfig.xml
  
  Index: advconfig.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/advconfig.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- advconfig.xml 2001/07/16 05:17:52 1.15
  +++ advconfig.xml 2001/08/05 13:48:24 1.16
  @@ -45,6 +45,131 @@



  + Declaring Resource Reference
  + Author:
  + Vincent
  + Harcq
  + 
  + [EMAIL PROTECTED]
  + 
  + 
  + Introduction
  + Resources are mainly used to access SQL DataSource object for 
use in BMP (Bean Managed Persistence)
  +entity beans or session beans.  They can also be used to access other type of 
resources like JavaMail Session
  +for example.
  + The EJB specification defines how to define deployment 
descriptor entries to define such Resources.
  +JBoss defines an entry in jboss.xml for that purpose that can be seen as an 
indirection of what is done in 
  +ejb-jar.xml to the actual implementation of the resource.
  + 
  + 
  + ejb-jar.xml
  + The EJB specification facilitate the access to external 
"resources" through the use of deployment
  +descriptor entries in ejb-jar.xml.  The tag is .
  + The res-ref-name element specifies the name of a resource 
manager connection factory reference.
  + The res-type element specifies the type of the data source. The 
type is specified by the Java 
  +interface (or class) expected to be implemented by the data source.
  + The res-auth element specifies whether the enterprise bean code 
signs on programmatically to 
  +the resource manager, or whether the Container will sign on to the resource manager 
on behalf of the bean. 
  +In the latter case, the Container uses information that is supplied by the 
Deployer.  Valid entry are 
  +"Container" and "Application".
  + Example:
  +
  +
  + 
  + 
  + jboss.xml
  + jboss.xml will redirect the res-ref-name entry to the 
implementation of the resource.  This is done
  +in .  The first two
  +generally takes the value of corresponding entry in ejb-jar.xml.
  + jndi-name points to the general definition of the resource in 
JBoss installation.
  + Example:
  +
  +To access the Resource from your bean, do something like:
  +
  +or
  +
  + 
  + 
  + 
  + JDBC Datasources
  + For JDBC datasources, it points to the JNDI name bound to the 
Connection Pool.  This is defined in
  +jboss.jcml like:
  +
  +
  + 
  + 
  + JavaMail Session
  + For JavaMail session, it points to the JNDI name bound to the 
JavaMail session.  This is defined in
  +jboss.jcml like:
  +
  +
  + 
  + 
  + JMS Connection Factory
  + This is QueueConnectionFactory for JBoss 2.2 and 
ConnectionFactory for JBoss 2.4.
  + 
  + 
  + Other
  + You can define your own Resources as MBean, then use them from 
ejbs.  A example to look at for 
  +more information is http://www.jboss.org/jboss-castor.jsp";>Castor.
  + 
  + 
  + 
Specifying the deployment name of your beans
You have coded your beans. You now want to deploy them and be 
   able to access them from your clients. For this, JBoss will register your beans in 
the JNDI namespace. All you have to tell is the name under which they must be 
registered.
  
  
  

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

RE: [JBoss-dev] Any examples of using the scheduler

[Vincent Harcq]

http://www.jboss.org/documentation/HTML/ch11s52.html

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Tim
> Fox
> Envoyé : mercredi 18 juillet 2001 19:48
> À : [EMAIL PROTECTED]
> Objet : [JBoss-dev] Any examples of using the scheduler
>
>
> I need to use a scheduler to hit some ejbs - apparently jboss has one,
> although I can find no examples/documentation on how to use this.
> Anyone know of any pointers?
> Cheers
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

RE: [JBoss-dev] JBoss Publication

[Vincent Harcq]

Good work andy!
Good mix Simple/Complex example that shows (only) one of the JBoss advanced
feature.
Now I am waiting more :)
JMX for the next article ?

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Schaefer, Andreas
> Envoyé : mardi 17 juillet 2001 22:19
> À : jBoss-Dev (E-mail)
> Objet : [JBoss-dev] JBoss Publication
>
>
> Hi Geeks
>
> No teaser anymore but real fact:
> http://www.onjava.com/pub/a/onjava/2001/07/16/jboss.html
>
> Enjoy
>
> Have fun - Mad Andy / Better Pizza
>
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> while( true ) { think(); write(); publish(); }
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

[JBoss-dev] CVS update: manual/src/docs basicconfiguration.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/16 22:35:39

  Modified:src/docs basicconfiguration.xml
  Log:
  mention tomcat/specific conf subdirectory (recurrent question)
  
  Revision  ChangesPath
  1.9   +5 -2  manual/src/docs/basicconfiguration.xml
  
  Index: basicconfiguration.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/basicconfiguration.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- basicconfiguration.xml2001/04/02 23:30:37 1.8
  +++ basicconfiguration.xml2001/07/17 05:35:21 1.9
  @@ -75,8 +75,11 @@

conf
JBoss configuration set(s) are located 
here.  By default there is only one 
  - configuration set - "default".  Adding more than one 
configuration set is permitted.
  - See  for more 
details.
  + configuration set - "default". Adding more than one 
configuration set is permitted. If you run 
  + JBoss bundled with a web container (Tomcat or Jetty), 
a special configuration set is used
  + ("tomcat" or "jetty").
  + See  
  + for more details. 


client
  
  
  

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

[JBoss-dev] CVS update: manual/src/docs advconfig.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/15 22:17:52

  Modified:src/docs advconfig.xml
  Log:
  Correct link to MDB chapter (thanks to Doug Ferguson)
  Remove wrong info on setting period to 0
  
  Revision  ChangesPath
  1.15  +1 -3  manual/src/docs/advconfig.xml
  
  Index: advconfig.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/advconfig.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- advconfig.xml 2001/07/08 22:17:11 1.14
  +++ advconfig.xml 2001/07/16 05:17:52 1.15
  @@ -515,7 +515,7 @@
   per se, rather than a copy.
   Another element is , it defines the port on which 
JBoss runs its RMI Server.  It has to 
   be changed when running multiple instances of JBoss on the same server.
  -The other elements are specific to Message Driven Beans and are explained in 

  +The other elements are specific to Message Driven Beans and are explained in 






  @@ -716,7 +715,6 @@
   capacity upon 3 other parameters (see below).
   While the period of this task is 400 seconds, the first run happens at a 
   random time between 0 and 400 seconds. 
  -To disable the resizer set the period to 0.
   ]]>


  
  
  

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

[JBoss-dev] CVS update: manual/src/docs howtomdb.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/15 22:16:36

  Modified:src/docs howtomdb.xml
  Log:
  Add id to be able to xref to this chapter
  
  Revision  ChangesPath
  1.7   +2 -2  manual/src/docs/howtomdb.xml
  
  Index: howtomdb.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/howtomdb.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- howtomdb.xml  2001/05/29 21:45:12 1.6
  +++ howtomdb.xml  2001/07/16 05:16:36 1.7
  @@ -1,5 +1,5 @@
   
  - 
  + 
Working with Message Driven Beans   
Author:
Peter
  @@ -717,7 +717,7 @@
   ]]>


  - 
  + 
Advanced MDB configuration
The MDB implementation for JBoss have been written such that a 
user should not have to know a lot about the internals of JBoss. A part from the feew 
necessary lines in jboss.xml nothing else than standard knowledge of Message Driven 
Beans should suffice.
Following the design of JBoss, the MDB implementation is also 
extremely configurable, if one want to tune or totally change the default 
configuration and implementation! Here follows some short notes on howto configure MDB 
for JBoss
  
  
  

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

RE: [JBoss-dev] Fetch size and JBossPool and Jaws

[Vincent Harcq]

Danch,
I have done that "by default" (one fetch size for all finders).
Honestly, I misunderstood what fetch size was...

What I wanted is a limit of entity bean loaded with a finder method.
Say I have 2 records.
I have a findStartAtName(String name) method.
I want to avoid instantiating all 2 beans but only, say 100.
Then I use again this finder method to retrieve the next 100, etc...

I can avoid the instanciation of entity context by hacking the
JDBCFind...Command.
Using Cursor on ResultSet, I got it now.

Are you working on that Danch ?

Vincent.

ps: I can still commit the fetch size stuff, it is good to have.

>
> It also fits in with my evil plot to do 'cursor' type things on finders.
>
> -danch
>


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


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

RE: [JBoss-dev] Fetch size and JBossPool and Jaws

[Vincent Harcq]

Hi,

> On Tue, Jul 10, 2001 at 08:48:15AM +0200, Vincent Harcq wrote:
> > Hi,
> > I want to add a feature that will allow to set the FetchSize
> associated with
> > Statement in Jaws/JBossPool.
> > The default FetchSize is in fact dependant of the driver (and
> is not always
> > 0, meaning get all records), that's an hazardous thing imho.
> > 1. A bit like IsolationLevel that we can specify on the Pool
> setting, add a
> > FetchSize attribute.
>
> Why not just set the fetch size on the Statement when you create it?
> This doesn't feel like an attribute of the connection pool to me, but
> of the particular query you're executing.

My mistake.
In fact I wanted a default for all finder methods, so the right place is in
standardjaws.xml

>
> > 2. For any finder method add a fetch-size deployment descriptor in jaws.
> > Comments ?
>
> This makes sense to me.
>
> Toby.
>

Vincent.


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


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

RE: [JBoss-dev] Fool proof? I think not.

[Vincent Harcq]

Many thanks Scott.

I'm a firestarter, twisted firestarter

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Scott M Stark
> Envoyé : mardi 10 juillet 2001 20:32
> À : [EMAIL PROTECTED]
> Objet : [JBoss-dev] Fool proof? I think not.
>
>
> // TestPK.java
> class AccountPK implements java.io.Serializable
> {
>private int _hashCode = Integer.MIN_VALUE;
>public java.lang.String id;
>
>public AccountPK(java.lang.String id)
>{
>   this.id = id;
>}
>public int hashCode()
>{
>   if (_hashCode == Integer.MIN_VALUE)
>   {
>  _hashCode += this.id.hashCode();
>   }
>   return _hashCode;
>}
>public boolean equals(Object obj)
>{
>   AccountPK pk = (AccountPK)obj;
>   boolean eq = true;
>   eq = eq && this.id.equals(pk.id);
>   return eq;
>}
> }
>
> public class TestPK
> {
> public static void main (String args[])
> {
>AccountPK key1 = new AccountPK("key1");
>AccountPK key2 = new AccountPK("key1");
>CacheKey key3 = new CacheKey(key1);
>CacheKey key4 = new CacheKey(key2);
>if( key3.hashCode() != key4.hashCode() )
>   System.out.println("key3, key4 hashCode test failed");
>if( key3.equals(key4) == false )
>   System.out.println("key3, key4 equals test failed");
>
>AccountPK key11 = new AccountPK("key1");
>AccountPK key21 = new AccountPK("key1");
>key21.hashCode(); // Cause key21._hashCode value to update
>CacheKey key31 = new CacheKey(key11);
>CacheKey key41 = new CacheKey(key21);
>if( key31.hashCode() != key41.hashCode() )
>   System.out.println("key31, key41 hashCode test failed");
>if( key31.equals(key41) == false )
>   System.out.println("key31, key41 equals test failed");
> }
>
> }
>
> Produces:
>
> key31, key41 hashCode test failed
> key31, key41 equals test failed
>
> Why? Because Serialization includes the private state of the
> object. This is
> a perfectly valid PK which is not handled correctly by CacheKey. If the
> _hashCode value is marked as transient all works. The assumption being
> made by CacheKey is that the only ivars in the PK are its fields
> that define
> its identity.
>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

RE: [JBoss-dev] Any problems vith the cache in 2.4?

[Vincent Harcq]

I agree, I was a bit too enthousiast on this problem, it will cause
confusion.  I leave it to you.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de marc
> fleury
> Envoyé : mardi 10 juillet 2001 17:42
> À : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] Any problems vith the cache in 2.4?
>
>
> what what bothers me with this on-going discussion: we don't care whether
> you fuck up  your own hashcode or not, we wrap it up and afaik
> Bill plugged
> teh last hole there, so that should really be tight as a drum...
>
> show me a clear bug repro on this and I will buy it... if it is plain gone
> then let's burry it.
>
> we need closure not impressions.
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of
> |Vincent Harcq
> |Sent: Tuesday, July 10, 2001 11:29 AM
> |To: [EMAIL PROTECTED]
> |Subject: RE: [JBoss-dev] Any problems vith the cache in 2.4?
> |
> |
> |Yep.
> |I am working on 2.5.  Checked out every week or so.
> |
> |But the problem of Hiram is its hashCode of, "my hand in the fire".
> |
> |> the changes of the cache are found in 2.5.  I might retrofit them
> |> to 2.4 for
> |> other reasons.
> |>
> |> are you using 2.5 when you say the problems are gone?
> |>
> |> |I got this one also.
> |> |It disappeared.
> |> |I think (not sure) it was because of my bloody hashCode() method.
> |> |Maybe it is linked to recent changes on cvs version through.
> |>
> |>
> |> marcf
> |>
> |>
> |>
> |> ___
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |> http://lists.sourceforge.net/lists/listinfo/jboss-development
> |>
> |>
> |
> |___
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>


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

RE: [JBoss-dev] Any problems vith the cache in 2.4?

[Vincent Harcq]

Yep. 
I am working on 2.5.  Checked out every week or so.

But the problem of Hiram is its hashCode of, "my hand in the fire".

> the changes of the cache are found in 2.5.  I might retrofit them 
> to 2.4 for
> other reasons.
> 
> are you using 2.5 when you say the problems are gone?
> 
> |I got this one also.
> |It disappeared.
> |I think (not sure) it was because of my bloody hashCode() method.
> |Maybe it is linked to recent changes on cvs version through.
> 
> 
> marcf
> 
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 

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

RE: [JBoss-dev] Any problems vith the cache in 2.4?

[Vincent Harcq]

I got this one also.
It disappeared.
I think (not sure) it was because of my bloody hashCode() method.
Maybe it is linked to recent changes on cvs version through.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Hiram Chirino
> Envoyé : mardi 10 juillet 2001 7:11
> À : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] Any problems vith the cache in 2.4?
>
>
>
> Talking about spooky cache problems, I've run into this problem:
>
> I disable the cache by using the 'NoPassivationCachePolicy' and Commit
> option 'C'.  I create a new bean instance.  Later I try to remove
> it but I
> fail (If you guys want, I'll get you guys a stack trace).  I am workin
> around the problem by loading the bean first by reading some of
> the values
> of the fields before I do the remove().  Seems to me like a cache problem
> since reading some fields makes it happy again.
>
> Anybody run into this??
>
> Regards,
> Hiram
>
> >From: "marc fleury" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: <[EMAIL PROTECTED]>
> >Subject: RE: [JBoss-dev] Any problems vith the cache in 2.4?
> >Date: Fri, 6 Jul 2001 08:28:18 -0400
> >
> >
> >
> >|-Original Message-
> >|From: [EMAIL PROTECTED]
> >|[mailto:[EMAIL PROTECTED]]On Behalf Of
> >|Lennart Petersson
> >|Sent: Friday, July 06, 2001 4:21 AM
> >|To: [EMAIL PROTECTED]
> >|Subject: SV: [JBoss-dev] Any problems vith the cache in 2.4?
> >|
> >|
> >|Hi! Problem 1 solved by you Vincent - that was the missing
> >|toString() method in the PK class (Should that really matter, why
> >|are JBoss using it in the cache?).
> >
> >that is not correct, we create a "safe" cache key so something is really
> >spooky
> >
> >marcf
> >
> >|
> >|Problem 2 was no problem, it was the old EJBDoclet passivate bug.
> >|The erroneous component was not regenerated with a corrected
> >|EJBDoclet (it was not my component :)
> >|
> >|So that mean that all you guys can keep on with 3.0 :-)
> >|
> >|THANKS!
> >|
> >|/Lennart
> >|
> >|- Original Message -
> >|From: Vincent Harcq <[EMAIL PROTECTED]>
> >|To: <[EMAIL PROTECTED]>
> >|Sent: Friday, July 06, 2001 9:05 AM
> >|Subject: RE: [JBoss-dev] Any problems vith the cache in 2.4?
> >|
> >|
> >|> Can you try this:
> >|> 1. Solution 1
> >|> Add a toString to your PK (hack entitypk.j).
> >|> Also put your Cache size very high.
> >|> And your overager periods very high as well.
> >|> 2. Solution 2.
> >|> Set your cache size to 1/1 (min/max)
> >|>
> >|> Let us know please.
> >|> Vincent.
> >|>
> >|
> >|
> >|
> >|___
> >|Jboss-development mailing list
> >|[EMAIL PROTECTED]
> >|http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> >___
> >Jboss-development mailing list
> >[EMAIL PROTECTED]
> >http://lists.sourceforge.net/lists/listinfo/jboss-development
>
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

[JBoss-dev] Fetch size and JBossPool and Jaws

[Vincent Harcq]

Hi,
I want to add a feature that will allow to set the FetchSize associated with
Statement in Jaws/JBossPool.
The default FetchSize is in fact dependant of the driver (and is not always
0, meaning get all records), that's an hazardous thing imho.
1. A bit like IsolationLevel that we can specify on the Pool setting, add a
FetchSize attribute.
2. For any finder method add a fetch-size deployment descriptor in jaws.
Comments ?
TIA
Vincent.


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


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

[JBoss-dev] CVS update: manual/src/docs jdbc-database.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/09 13:03:19

  Modified:src/docs jdbc-database.xml
  Log:
  Add (JBoss 2.4) TransactionIsolation (thanks to Bill Burke)
  
  Revision  ChangesPath
  1.10  +13 -1 manual/src/docs/jdbc-database.xml
  
  Index: jdbc-database.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/jdbc-database.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jdbc-database.xml 2001/07/08 09:54:25 1.9
  +++ jdbc-database.xml 2001/07/09 20:03:19 1.10
  @@ -174,7 +174,8 @@
false
false
1.0
  - 0 
  + 0
  + TRANSACTION_SERIALIZABLE [JBoss 
2.4]
   ]]>


  @@ -338,6 +339,17 @@
  the pool. This time is important if shrinking or garbage 
collection are
  enabled (particularly the latter).
false
  + 
  + 
  + 
TransactionIsolation [JBoss 2.4]
  + Sets the 
Transaction isolation level on the SQL Connection.  Valid values are
  + TRANSACTION_NONE, 
TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED , 
  + TRANSACTION_REPEATABLE_READ, 
TRANSACTION_SERIALIZABLE.  The choice of the level allows
  + to choose a trade-off between 
performance and transaction isolation.  The values listed are from
  + poor to full isolation; but from good 
to poor performance.  Refer to 
  + http://java.sun.com/j2se/1.3/docs/api/java/sql/Connection.html";>java.sql.Connection
  + for more information.
  + -1 (SQL driver 
default)



  
  
  

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

[JBoss-dev] CVS update: manual/src/docs advconfig.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/08 15:17:12

  Modified:src/docs advconfig.xml
  Log:
  2.2 compliance
  remove t3 (grrr jboss IS the reference)
  make home lookup "classic" (portablenarrow)
  cosmetics
  
  Revision  ChangesPath
  1.14  +104 -44   manual/src/docs/advconfig.xml
  
  Index: advconfig.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/advconfig.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- advconfig.xml 2001/07/07 19:25:16 1.13
  +++ advconfig.xml 2001/07/08 22:17:11 1.14
  @@ -7,6 +7,12 @@

[EMAIL PROTECTED]

  + JBoss 2.2 compliance checked by:
  +         Vincent
  +     Harcq
  + 
  + [EMAIL PROTECTED]  
  + 

What is jboss.xml?
To deploy your beans, you have to specify (nearly) everything 
about them in a 
  @@ -67,19 +73,23 @@
   
   
 
  -  ...
   
   ]]>
And your bean will be available under the "MyBeanName" 
in JNDI.
   In your client code, your call will look like this:
  - public class Client {  
   
  -  ...
  -  public static void main(String arg[]) {
  -...
  -//No need to use the "narrow" operation, a cast will work in jboss
  -MyBeanHome home = (MyBeanHome) new InitialContext().lookup("MyBeanName");
  -...
  -  }
  + import javax.naming.InitialContext;
  +import javax.rmi.PortableRemoteObject;
  +   
  +public class Client { 
  +  
  +   public static void main(String args[]) {
  +  ...  
  +  InitialContext namingContext = new InitialContext();
  +  Object ref = namingContext.lookup("MyBeanName");
  +  MyBeanHome home = (MyBeanHome)PortableRemoteObject.narrow(ref, 
MyBeanHome.class);
  +  ...
  +   }
  +  
   }
Here the "MyBeanName" refers to the name of your bean in 
the JNDI namespace. 
   JBoss does not currently allow 
  @@ -114,15 +124,19 @@
   new metadata, this is what we call "differential" jboss.xml).
Your bean is then available in JNDI under 
somePath/otherName
In your client code, your call will look like 
this:
  - public class Client {  
   
  -  ...
  -  public static void main(String arg[]) {
  -...
  -//No need to use the "narrow" operation, a cast will work in jboss
  -MyBeanHome home = (MyBeanHome) new 
  -InitialContext().lookup("somePath/otherName");
  -...
  -  }
  + import javax.naming.InitialContext;
  +import javax.rmi.PortableRemoteObject;
  +   
  +public class Client { 
  +   
  +   public static void main(String args[]) {
  +  ...
  +  InitialContext namingContext = new InitialContext();
  +  Object ref = namingContext.lookup("somePath/otherName");
  +  MyBeanHome home = (MyBeanHome)PortableRemoteObject.narrow(ref, 
MyBeanHome.class);
  +  ...
  +   }
  +   
   }


  @@ -135,18 +149,34 @@
   the beginner trails) this is for bean calls all on the server. Most of these 
   calls are done inside the 
   server VM.
  - This call will look like this: (beans running on the server must 
use the 
  -java:comp/env namespace).
  - public class ABean implements SessionBean {

  -...
  -public void BusinessMethod(...) {
  -...
  - 
  -BHome home = (BHome)ctx.lookup("java:comp/env/ejb/myBean");
  -B bean = home.create(pk);
  -...
  -}
  + This call will look like this:
  + public class ABean implements SessionBean {
  +
  +   public void businessMethod(...) {
  +  ...
  +  InitialContext namingContext = new InitialContext();
  +  Object ref = namingContext.lookup("java:comp/env/ejb/myBean");
  +  BHome home = (BHome)PortableRemoteObject(ref);
  +  B bean = home.create(pk);
  +  ...
  +   }
  +
   }
  + You can also have a lookup relative to "java:comp/env" like this 
:
  + public class ABean implements SessionBean {
  +
  +   public void businessMethod(...) {
  +  ...
  +  InitialContext namingContext = new InitialContext();
  +  Object ref = namingContext.lookup("ejb/myBean");
  +  BHome home = (BHome)PortableRemoteObject(ref);
  +  B bean = home.create(pk);
  +  ...
  +   }
  +
  +}
  + This notation let better understand the redirection done by 
JBoss for the JNDI lookup.  As 

[JBoss-dev] jboss.xml 1.2.2 invoker

[Vincent Harcq]

I was reviewing the docs and found that (or i need a serious glass wash)
there is no difference between 1.3 and 1.2.2 configurations.
I guess they are still there for backward compatibility only and may be
considered as deprecated.
Correct ?
TIA
Vincent


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


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

RE: [JBoss-dev] JAWS_2_4 DTD

[Vincent Harcq]

The main trunk does not need any tags because we do not follow what is done
by revision on the main trunk.
On the main trunk you commit, commit and commit and don't take care of
revision: ALPHA.
Once a Branch is created, it means it is for a stable release, then we have
to be sure to know what has been done, so we use the release tags to fine
tune, be able to reproduce a problem by getting this specific release the
customer uses and on which he has the problem:BETA and FINAL.
When you use the main trunck, you are alone to find out any problems within
it.
It was unclear to me at the beginning, but it has in fact a lot of sense to
turn JBoss into a very fiable product.
Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Vinay Menon
> Envoyé : dimanche 8 juillet 2001 14:33
> À : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] JAWS_2_4 DTD
>
>
> Vincent,
> Many thanks! I've commited the changes to the jaws.dtd and
> jaws_2_4.dtd
> to the main trunk as well [i.e the one without the Branch_2_4] tag.
>
> Now running cvs log at jboss24/ what I see is that Rel 2_4_0_11
> was the last
> used tag and am going to increment it by one as you said and tag it. What
> about the trunk?
>
> Vinay
>
> - Original Message -
> From: "Vincent Harcq" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, July 08, 2001 1:14 PM
> Subject: RE: [JBoss-dev] JAWS_2_4 DTD
>
>
> > I am not sure Scott is around, so I'll try to explain.
> >
> > I check out "Branch_2_4" into a jboss24/ directory
> > I check out with no tags into jboss/
> >
> > I change a file in jboss/, build, test and commit it
> > I copy the file in jboss24/, build, test and commit it
> >
> > I "cvs log" (from jboss/ for example) on "bin/run.sh" (for example), and
> see
> > the latest 2.4 Tag is Rel_2_4_0_11.
> > From "jboss24/" I then "cvs tag Rel_2_4_0_12" (recursively).
> >
> > Right?
> >
> > > -Message d'origine-
> > > De : [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]De la part de
> > > Vinay Menon
> > > Envoyé : dimanche 8 juillet 2001 13:48
> > > À : [EMAIL PROTECTED]
> > > Objet : Re: [JBoss-dev] JAWS_2_4 DTD
> > >
> > >
> > > Scott,
> > > Alright did go thru the document. I am a complete CVS
> dumbo. Is this
> > > what I need to do
> > >
> > > 1. Check in all the changes back to Branch_2_4 AND to the main trunk?
> > > 2. Once I check in the code what is the 'cvs tag Rel_2_3_1_3' I should
> be
> > > using?
> > >
> > > Many thanks in advance.
> > >
> > > Vinay
> > >
> > >
> > > - Original Message -
> > > From: "Scott M Stark" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Sunday, July 08, 2001 12:15 AM
> > > Subject: Re: [JBoss-dev] JAWS_2_4 DTD
> > >
> > >
> > > > kvvinaymenon,
> > > >
> > > > You need to follow the cvs proceedures for updating a branch and
> making
> > > sure
> > > > the changes are applied to main. Read them here:
> > > > http://www.jboss.org/CVSAdmin.jsp
> > > > and then clean up your changes.
> > > >
> > > > - Original Message -
> > > > From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Saturday, July 07, 2001 3:56 PM
> > > > Subject: [JBoss-dev] JAWS_2_4 DTD
> > > >
> > > >
> > > > >
> > > > > the datasource element was added to the entity element in version
> > > 1.1.2.2
> > > > > on Bracnh_2_4. But it hasn't been updated on the main branch
> > > or added to
> > > > > the 2_4 label. Shouldn't this change go onto both main and the
> current
> > > 2_4
> > > > > label?
> > > > >
> > > > > There is also a code change associated with this -
> > > > >
> src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
> > > also
> > > > > on the 2_4 branch but not in the label but these changes
> are on main
> > > > (added
> > > > > in version 1.11).
> > > > >
> > > > > Mike S-R
> > > > >
> > > > >
> > > > > ___

RE: [JBoss-dev] JAWS_2_4 DTD

[Vincent Harcq]

I am not sure Scott is around, so I'll try to explain.

I check out "Branch_2_4" into a jboss24/ directory
I check out with no tags into jboss/

I change a file in jboss/, build, test and commit it
I copy the file in jboss24/, build, test and commit it

I "cvs log" (from jboss/ for example) on "bin/run.sh" (for example), and see
the latest 2.4 Tag is Rel_2_4_0_11.
>From "jboss24/" I then "cvs tag Rel_2_4_0_12" (recursively).

Right?

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Vinay Menon
> Envoyé : dimanche 8 juillet 2001 13:48
> À : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] JAWS_2_4 DTD
>
>
> Scott,
> Alright did go thru the document. I am a complete CVS dumbo. Is this
> what I need to do
>
> 1. Check in all the changes back to Branch_2_4 AND to the main trunk?
> 2. Once I check in the code what is the 'cvs tag Rel_2_3_1_3' I should be
> using?
>
> Many thanks in advance.
>
> Vinay
>
>
> - Original Message -
> From: "Scott M Stark" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, July 08, 2001 12:15 AM
> Subject: Re: [JBoss-dev] JAWS_2_4 DTD
>
>
> > kvvinaymenon,
> >
> > You need to follow the cvs proceedures for updating a branch and making
> sure
> > the changes are applied to main. Read them here:
> > http://www.jboss.org/CVSAdmin.jsp
> > and then clean up your changes.
> >
> > - Original Message -
> > From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, July 07, 2001 3:56 PM
> > Subject: [JBoss-dev] JAWS_2_4 DTD
> >
> >
> > >
> > > the datasource element was added to the entity element in version
> 1.1.2.2
> > > on Bracnh_2_4. But it hasn't been updated on the main branch
> or added to
> > > the 2_4 label. Shouldn't this change go onto both main and the current
> 2_4
> > > label?
> > >
> > > There is also a code change associated with this -
> > > src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
> also
> > > on the 2_4 branch but not in the label but these changes are on main
> > (added
> > > in version 1.11).
> > >
> > > Mike S-R
> > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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


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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging/log4j ConsoleAppender.java

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/08 03:02:38

  Modified:src/main/org/jboss/logging/log4j Tag: Branch_2_4
ConsoleAppender.java
  Log:
  Add output of exception stack trace when using cat.debug("message",e)
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.2.1   +24 -2 jboss/src/main/org/jboss/logging/log4j/ConsoleAppender.java
  
  Index: ConsoleAppender.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/logging/log4j/ConsoleAppender.java,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  --- ConsoleAppender.java  2001/06/15 21:54:20 1.2
  +++ ConsoleAppender.java  2001/07/08 10:02:38 1.2.2.1
  @@ -12,14 +12,15 @@
   import org.apache.log4j.Category;
   import org.apache.log4j.Priority;
   import org.apache.log4j.spi.LoggingEvent;
  +import org.apache.log4j.Layout;
   
   /** A log4j Appender implementation that writes to the System.out and
   System.err console streams. It also installs PrintStreams for System.out
   and System.err to route logging through those objects to the log4j
   system via a category named Default.
   
  -@author [EMAIL PROTECTED]
  -@version $Revision: 1.2 $
  +@author mailto:[EMAIL PROTECTED]";>Scott Stark.
  +@version $Revision: 1.2.2.1 $
   */
   public class ConsoleAppender extends AppenderSkeleton
   {
  @@ -64,5 +65,26 @@
   err.print(msg);
   else
   out.print(msg);
  +if(this.layout.ignoresThrowable())
  +{
  +String[] s = event.getThrowableStrRep();
  +if (s != null)
  +{
  + int len = s.length;
  + for(int i = 0; i < len; i++)
  +{
  +if( event.priority == Priority.ERROR )
  +{
  + err.print(s[i]);
  + err.print(Layout.LINE_SEP);
  +}
  +else
  +{
  + out.print(s[i]);
  + out.print(Layout.LINE_SEP);
  +}
  +}
  +}
  +}
   }
   }
  
  
  

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging/log4j ConsoleAppender.java

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/08 03:00:09

  Modified:src/main/org/jboss/logging/log4j ConsoleAppender.java
  Log:
  Add output of exception stack trace when using cat.debug("message",e)
  
  Revision  ChangesPath
  1.4   +23 -1 jboss/src/main/org/jboss/logging/log4j/ConsoleAppender.java
  
  Index: ConsoleAppender.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/logging/log4j/ConsoleAppender.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ConsoleAppender.java  2001/06/18 20:01:27 1.3
  +++ ConsoleAppender.java  2001/07/08 10:00:09 1.4
  @@ -12,6 +12,7 @@
   import org.apache.log4j.Category;
   import org.apache.log4j.Priority;
   import org.apache.log4j.spi.LoggingEvent;
  +import org.apache.log4j.Layout;
   
   /** A log4j Appender implementation that writes to the System.out and
   System.err console streams. It also installs PrintStreams for System.out
  @@ -19,7 +20,7 @@
   system via a category named Default.
   
   @author mailto:[EMAIL PROTECTED]";>Scott Stark.
  -@version $Revision: 1.3 $
  +@version $Revision: 1.4 $
   */
   public class ConsoleAppender extends AppenderSkeleton
   {
  @@ -64,5 +65,26 @@
   err.print(msg);
   else
   out.print(msg);
  +if(this.layout.ignoresThrowable())
  +{
  +String[] s = event.getThrowableStrRep();
  +if (s != null)
  +{
  + int len = s.length;
  + for(int i = 0; i < len; i++)
  +{
  +if( event.priority == Priority.ERROR )
  +{
  + err.print(s[i]);
  + err.print(Layout.LINE_SEP);
  +}
  +else
  +{
  + out.print(s[i]);
  + out.print(Layout.LINE_SEP);
  +}
  +}
  +}
  +}
   }
   }
  
  
  

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

[JBoss-dev] CVS update: manual/src/docs jdbc-database.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/08 02:54:25

  Modified:src/docs jdbc-database.xml
  Log:
  Essai to kill the recurent question on connection pools accessible by standalone 
client.
  
  Revision  ChangesPath
  1.9   +4 -0  manual/src/docs/jdbc-database.xml
  
  Index: jdbc-database.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/jdbc-database.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- jdbc-database.xml 2001/07/07 21:56:57 1.8
  +++ jdbc-database.xml 2001/07/08 09:54:25 1.9
  @@ -98,6 +98,10 @@

To add a pool, you need to add sections to jboss.conf and jboss.jcml, both of which can be 
found in the conf directory.
  + 
  + Warning : These connection pools are only accessible from within 
EJBs or Web applications running inside JBoss, 
  + not from standalone client applications.
  + 

The JDBC 2.0 Optional Package
Before we configure the pool, we need to take a brief 
detour into specifications. 
  
  
  

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

RE: [JBoss-dev] [ jboss-Patches-439278 ] log4j ConsoleAppender xxx(msg,e) (fwd)

[Vincent Harcq]

On SF attached.
oops no, I forget it.
I will commit it anyway, i am using SF to see if nobody says "No not good !"
If no responses after a few days, I guess nobody is against it and commit.
OK?


> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Jason Dillon
> Envoye : dimanche 8 juillet 2001 6:37
> A : [EMAIL PROTECTED]
> Objet : [JBoss-dev] [ jboss-Patches-439278 ] log4j ConsoleAppender
> xxx(msg,e) (fwd)
>
>
> Where is the patch?  There is nothing attached to this.
>
> --jason
>
>
> -- Forwarded message --
> Date: Sat, 07 Jul 2001 04:19:23 -0700
> From: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] [ jboss-Patches-439278 ] log4j
> ConsoleAppender xxx(msg,e)
>
> Patches item #439278, was opened at 2001-07-07 04:19
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=376687&aid=439278
&group_id=22866

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: log4j ConsoleAppender xxx(msg,e)

Initial Comment:
The JBoss log4j COnsoleAppender does not show the
exception message when we use, for example,
cat.debug("exception !!", e)

This patch solves the problem.

--

You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=439278&group_id=
22866

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


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


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


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

[JBoss-dev] CVS update: manual/src/docs howtomssql.xml jbossdocs.xml jdbc-database.xml

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/07 14:56:58

  Modified:src/docs howtomssql.xml jbossdocs.xml jdbc-database.xml
  Log:
  Compliance 2.2 for MS SQL How To
  Move MS SQL HowTo to JDBC Chapter
  Add version required and Minerva Pool data source configuration for Inet Opta driver
  Mention MS SQLSERVER2000 Mapping
  
  Revision  ChangesPath
  1.11  +65 -63manual/src/docs/howtomssql.xml
  
  Index: howtomssql.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/howtomssql.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- howtomssql.xml2001/06/30 12:37:49 1.10
  +++ howtomssql.xml2001/07/07 21:56:57 1.11
  @@ -116,6 +116,7 @@
Supplier
JDBC Type
Availability
  + Version



  @@ -126,6 +127,7 @@

Type 4
Free/Open Source
  + 


Merant DataDirect Connect 
JDBC
  @@ -134,6 +136,7 @@

Type 4
Commercial
  + 


i-net Opta JDBC
  @@ -142,6 +145,7 @@

Type 4
Commercial
  + 4.10FIX


WebLogic jDriver for Microsoft 
SQL Server
  @@ -150,6 +154,7 @@

Type 4
Commercial
  + 


Atinav aveConnect JDBC
  @@ -158,6 +163,7 @@

Type 4
Commercial
  + 


Sun JDBC-ODBC 
Bridge*
  @@ -167,6 +173,7 @@

Type 4
Free
  + 



  @@ -201,6 +208,18 @@



  + Installing the FreeTDS driver
  + 
  + Download FreeTDS on http://www.freetds.org.  You 
should take the snapshot named freetds_jdbc.snapshot.jar.
  + Copy it to %JBOSS_HOME%/lib/ext.
  + 
  + 
  + To use the Sun JDBC-ODBC bridge with JBoss and MS SQL 
Server you need to create an ODBC datasource that 
  + references your MS SQL Server database. For this 
tutorial it will be assumed that a datasource named 
  + jboss_odbc has been created 
that points to an MS SQL Server database.
  + 
  + 
  + 
Installing the Merant DataDirect Connect JDBC 
driver

According to the blurb on Merant's site:
  @@ -343,6 +362,20 @@



  + Adding the FreeTDS driver to the JBoss 
JDBC driver list
  + 
  + 
  + 
  +
  +   
  
+  org.hsql.jdbcDriver,org.enhydra.instantdb.jdbc.idbDriver,com.internetcds.j

[JBoss-dev] CVS update: newsite/doco_files documentation-example.tar.gz documentation-example.zip

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/06 14:52:39

  Modified:doco_files documentation-example.tar.gz
documentation-example.zip
  Log:
  Correct non 2.2 feature in jaws example
  
  Revision  ChangesPath
  1.3   +103 -119  newsite/doco_files/documentation-example.tar.gz
  
<>
  
  
  1.3   +178 -151  newsite/doco_files/documentation-example.zip
  
<>
  
  

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

[JBoss-dev] CVS update: manual/src/examples/build readme.txt

[Vincent Harcq]

  User: vharcq  
  Date: 01/07/06 14:47:49

  Modified:src/examples/build readme.txt
  Log:
  ant, not build
  
  Revision  ChangesPath
  1.3   +2 -2  manual/src/examples/build/readme.txt
  
  Index: readme.txt
  ===
  RCS file: /cvsroot/jboss/manual/src/examples/build/readme.txt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- readme.txt2001/06/25 05:34:38 1.2
  +++ readme.txt2001/07/06 21:47:49 1.3
  @@ -9,9 +9,9 @@
   
   2. To run a specific build "cmp-cd-compile" as specified in the manual, type
   
  - build cmp-cd-compile
  + ant cmp-cd-compile
   
   3. To run a specific client example, type
   
  - build cmp-cd-test1
  + ant cmp-cd-test1
   
  
  
  

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

RE: Hell---o???? RE: [JBoss-dev] cvs down this morning?

[Vincent Harcq]

it do not work : cvs [update aborted]: recv() from server
cvs.sourceforge.net: EOF

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de marc
> fleury
> Envoyé : vendredi 6 juillet 2001 17:17
> À : [EMAIL PROTECTED]
> Objet : Hell---o RE: [JBoss-dev] cvs down this morning?
>
>
>
> anyone out there?
>
> I am alone on this planet...??? so I go flying a couple of hours
> and I come
> back and the planet is full of monkeys? (plug) ah come on...
>
> does the cvs work? is this really year 23999?
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of marc
> |fleury
> |Sent: Friday, July 06, 2001 10:13 AM
> |To: [EMAIL PROTECTED]
> |Subject: RE: [JBoss-dev] cvs down this morning?
> |
> |
> |can anyone connect to it?
> |I am trying to download teh new jetty for the www.jboss.org website and I
> |can't connect
> |
> |
> |:(
> |
> |marcf
> |
> ||-Original Message-
> ||From: [EMAIL PROTECTED]
> ||[mailto:[EMAIL PROTECTED]]On Behalf Of marc
> ||fleury
> ||Sent: Friday, July 06, 2001 10:10 AM
> ||To: Jboss-Development@Lists. Sourceforge. Net
> ||Subject: [JBoss-dev] cvs down this morning?
> ||
> ||
> ||marcf
> ||
> ||_
> ||Marc Fleury, Ph.D
> ||[EMAIL PROTECTED]
> ||_
> ||
> ||
> ||___
> ||Jboss-development mailing list
> ||[EMAIL PROTECTED]
> ||http://lists.sourceforge.net/lists/listinfo/jboss-development
> |
> |
> |
> |___
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>


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