RE: [JBoss-dev] ClassCastException from ProxyCompiler$Proxy35.getId(generated)
From: Alexey Loubyansky [mailto:[EMAIL PROTECTED] Hello Michael, at the moment, I can't comment on why findAll works. The cause, perhapsm is the types mismatch between the one that is used by MySQL driver for generated keys be default and the one you use for primary key column. AFAIK, MySQL's default is java.lang.Integer. Abstracting from vendor-specific types supported in current Branch_3_2. It is not yet ported to HEAD. You got it. MySQL is returning a Long for their generated keys. In Statement they use Types.BIGINT. Meanwhile, we are mapping to Integer correctly in the normal load process, so, that explains why everything else works. So, what do we do about it? Should JDBCGetGeneratedKeysCreateCommand test for Number and convert to expected type? Or should we urge MySQL to create the type based upon the type of field it is? Thanks, Michael --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCastException from ProxyCompiler$Proxy35.getId(generated)
-Original Message- From: Newcomb, Michael P. So, what do we do about it? Should JDBCGetGeneratedKeysCreateCommand test for Number and convert to expected type? Or should we urge MySQL to create the type based upon the type of field it is? Actually, JDBCGetGeneratedKeysCreateCommand just calls getObject() on the result set. We probably need to run it through whatever code the normal loading process goes through so it will call ResultSet.getInt/Short/Long() based upon the metadata? Michael --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ClassCastException from ProxyCompiler$Proxy35.getId(generated)
jboss-head from ~ July 1. RedHat 8 JDK 1.4.1 Mysql I have a simple bean that has auto-generated Integer primary keys. MyLocal myLocal = myLocalHome.create(name, description); myLocal.getName(); -- works fine myLocal.getDescription(); -- works fine myLocal.getId(); -- Throws ClassCastException in the proxy. Bean gets created fine. Primary key comes back fine from the SQL insert (verified in log file from debug from JDBCGetGeneratedKeysCreateCommand). But, for some reason, when I call getId() it throws a ClassCastException. Calling getName() and getDescription() work fine. What's wierd, is that I can do a myLocalHome.findAll(), iterate through the returned collection and call getId() on those just fine. It just seems to be when I call getId() on the returned local ejb... Any clues? Thanks, Michael This is being done from a Servlet... --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss_3_0.dtd vs jboss_3_2.dtd
-Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED] Subject: Re: [JBoss-dev] jboss_3_0.dtd vs jboss_3_2.dtd ... the enterprise-beans element model would have to be: !ELEMENT enterprise-beans (session | entity | message-driven)* content model for backward compability and consistency with the ejb-jar 2.0 DTD. Done. The ordering of the jboss child elements should also be consistent between 3.0 and 3.2. I think the jboss element content model in 3.2 needs to be: !ELEMENT jboss (enforce-ejb-restrictions?, security-domain?, unauthenticated-principal?, resource-managers?, enterprise-beans?, invoker-proxy-bindings?, container-configurations?) as this is consistent with the invoker-proxy-bindings and container-configurations ordering in the standardjboss.xml descriptor and is consistent with the 3.0 element ordering. 3.2 standardjboss.xml has form: invoker-proxy-bindings ... /invoker-proxy-bindings enforce-ejb-restrictionsfalse/enforce-ejb-restrictions container-configurations ... /container-configurations So, that content model doesn't match the 3.2 dtd. Plus, the 3.0 dtd has resource-managers after enterprise-beans, so, I'm not sure how it's consistent with the 3.0 content model? How about: !ELEMENT jboss (enforce-ejb-restrictions?, security-domain?, unauthenticated-principal?, enterprise-beans?, resource-managers?, invoker-proxy-bindings?, container-configurations?) And, I'll fix the standardjboss.xml file in 3.2 and HEAD to move enforce-ejb-restrictions above all the invoker-proxy-bindings. What do you think? Michael --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss_3_0.dtd vs jboss_3_2.dtd
Updating XDoclet and there are a couple of small backwards compatibility issues: JBoss 3.0: !ELEMENT enterprise-beans (session | entity | message-driven)+ - any order - at least one JBoss 3.2: !ELEMENT enterprise-beans (session*, entity*, message-driven*) - session beans, then entity beans, then message-driven beans - none required 3.2 will break if beans interspersed or listed out of this order. Can we go back to !ELEMENT enterprise-beans (session | entity | message-driven)* but use '*' instead of '+'? Or did the parser change to reflect the new definition? JBoss 3.0: !ELEMENT jboss (enforce-ejb-restrictions?, security-domain?, unauthenticated-principal?, enterprise-beans?, resource-managers?, container-configurations?) - enterprise beans come before resource managers JBoss 3.2: !ELEMENT jboss (enforce-ejb-restrictions?, security-domain?, unauthenticated-principal?, resource-managers?, invoker-proxy-bindings?, enterprise-beans?, container-configurations?) - enterprise beans come after resource managers I have to update the XDoclet templates and now need to check jboss revision to put enterprise-beans after resource-managers for 3.2+ and vice-versa for 3.2. Should I fix the 3.2 dtd to reflect 3.0? Or have the parsers changed... Thanks, Michael --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] sub-deployments
I have a WAR file with an applet. The applet requires some old classes that conflict with those required by JSPs/Servlets in the WAR file. The classes for the applet are in a jar file, applet_only_classes.jar. When I deploy my WAR, JBoss creates a UCL for this jar file, even though it is only intended to be 'served', not used by the server. Every now and then I get ClassFormatErrors and Linkage problems inside JBoss because when the server code goes looking for classes, it finds these old classes instead of the correct ones. WAR: - applet_only_classes.jar - *.html - *.jsp - WEB-INF/web.xml - WEB-INF/lib/server_classes.jar Shouldn't only stuff in WEB-INF be subject to sub-deployment? That would solve my problem because applet_only_classes.jar would not be found and therefore would hose up the server. Basic problem is, SubDeployerSupport.init() tries to deploy everything in a 'deployable item' through SubDeployerSupport.processNestedDeployments(). What happens if you want to have a web site that serves up your old application releases as jar files? We could override isDeployable in AbstractWebContainer and do a super.isDeployable() 'WEB-INF' is in the given url. Is there someway around this that I'm missing? Thanks, Michael --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ATTENTION! Developers with CVS access
-Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] 1. What have you worked on in the past? Various bug fixes: worked with Dain on some of the read-ahead performance issues; worked with David to get the EAR deploying *-ds.xml and *-service.xml files; etc... 2. What are you currently working on? Keeping XDoclet JBoss component up-to-date. Currently involved in my companies project. We will be making massive use of J2EE and will be really stressing JBoss to it's performance limits in about a year or so. I am currently just continuing to test JBoss with my assortment of tests here. If/when a problem is encountered, I fix it. 3. What will you be working on and when? I am currently a member of the XDoclet team and will be working with David to bring over the JBoss component when XDoclet stabilizes the 1.2 release. I try to work with Dain and Alex on keeping the XDoclet JBoss component up-to-date with any metadata changes. 4. What do you want to work on? I like XDoclet and like keeping it up-to-date with the JBoss core. I like working with Dain on performance improvements to the CMP engine. We have had to postpone some of the more performance dependent work for a few months, so I haven't been able to send comments to Dain about problems/successes I've had. 5. What is your SourceForge name/id? (So I can cross you off list of who contacted me). mnewcomb Michael --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] QueuedPessimisticEJBLock bug?
Red Hat 7.2 JDK 1.4.1-b21 jboss-head from ~2pm EST 10/29/2002 Scenario: Session bean which gets some data from some EntityBeans. Session bean is tied to a client GUI in which the user can 'click' a button and the client calls a method on the Session bean to retrieve some data. Problem: We are getting intermittent ApplicationDeadlockExceptions. Particularly, the Application deadlock detected: Current thread already has tx lock in different transaction.. Possible Cause?: From initial analysis, I think it has something to do with BeanLockSupport.deadlockDetection(Transaction miTx). The first test in deadlockDetection() is to see if Thread.currentThread().equals(holdingThread). If they are equal, you get the exception. Well, the code that it is being thrown on is just a CMP field of an entity bean. That code does not cause any re-entrance. The only thing I can think of is that the same RMI worker thread happened to receive two user 'clicks' in rapid succession, thus causing deadlockDetection to see the same thread trying to get the lock on the EntityBean. This theory is only possible if QueuedPessimisticEJBLock.endTransaction() doesn't get called before the Session bean returns from the first call. When QueuedPessimisticEJBLock.endTransaction() is called, it nulls out the holdingThread and therefore this particular exception can never occur. Does this theory make sense? Thanks, Michael --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ... what happened?
Um, what is up with JBossMQ? I'm working of the latest CVS (actually the problem below has been happening for the past few weeks) and JMS is absent from JNDI. The sample Queues and Topics are being created because I see them in the Agent View under the jboss.mq.destination section. I also see all the invocation layers under the jboss.mq section. However, when I do a JNDIView, there is no queue/topic sub-contexts in the global JNDI namespace nor are there any connection factories. Is JMS disabled somehow in the default build? If so, why are the topics/queues being created if they aren't going to be made available? Thanks, Michael ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] missing org.jboss.util.id.GUID from client jars?
It looks like org.jboss.util.Primitives is required by the org.jboss.util.id.* classes as well. The problem lies in the fact that the testsuite uses the same classpath to run as it does to build. In testsuite/build.xml, part of the 'tests.classpath' property (which is used in the build *and* junit tasks) includes 'thirdparty.classpath'. Well, the thirdparty.classpath property includes the 'dependentmodule.classpath' property, which pretty much includes all the module classpaths directly. So, in essence, the testsuite doesn't even look at the clients directory. Michael -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 5:45 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] missing org.jboss.util.id.GUID from client jars? Hey, can you try again. Sorry about this, I don't know why our testsuite does not check this. Do you have a testcase would you can submit to detect this? --jason On Wednesday 15 May 2002 07:42 pm, you wrote: Almost. Now it's missing org.jboss.util.MuLong. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 3:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] missing org.jboss.util.id.GUID from client jars? Hello. Sorry about that. Can you re-run your client again after refreshing your CVS tree rebuilding. We should probably setup a test to check for these too... --jason Quoting [EMAIL PROTECTED]: I just did a CVS co this morning and when I ran my client, I got a NoClassDefFound for org.jboss.util.id.GUID. My classpath just points to all the jars in the client directory. I checked jboss-common-client.jar and that class is not in there. So, I copied jboss-common.jar from lib to client and the problem went away. Should id/* be in jboss-common-client.jar? Michael ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] missing org.jboss.util.id.GUID from client jars?
The problem lies in the fact that the testsuite uses the same classpath to run as it does to build. In testsuite/build.xml, part of the 'tests.classpath' property (which is used in the build *and* junit tasks) includes 'thirdparty.classpath'. Well, the thirdparty.classpath property includes the 'dependentmodule.classpath' property, which pretty much includes all the module classpaths directly. So, in essence, the testsuite doesn't even look at the clients directory. Michael -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 5:45 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] missing org.jboss.util.id.GUID from client jars? Hey, can you try again. Sorry about this, I don't know why our testsuite does not check this. Do you have a testcase would you can submit to detect this? --jason On Wednesday 15 May 2002 07:42 pm, you wrote: Almost. Now it's missing org.jboss.util.MuLong. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 3:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] missing org.jboss.util.id.GUID from client jars? Hello. Sorry about that. Can you re-run your client again after refreshing your CVS tree rebuilding. We should probably setup a test to check for these too... --jason Quoting [EMAIL PROTECTED]: I just did a CVS co this morning and when I ran my client, I got a NoClassDefFound for org.jboss.util.id.GUID. My classpath just points to all the jars in the client directory. I checked jboss-common-client.jar and that class is not in there. So, I copied jboss-common.jar from lib to client and the problem went away. Should id/* be in jboss-common-client.jar? Michael ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] missing org.jboss.util.id.GUID from client jars?
Almost. Now it's missing org.jboss.util.MuLong. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 3:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] missing org.jboss.util.id.GUID from client jars? Hello. Sorry about that. Can you re-run your client again after refreshing your CVS tree rebuilding. We should probably setup a test to check for these too... --jason Quoting [EMAIL PROTECTED]: I just did a CVS co this morning and when I ran my client, I got a NoClassDefFound for org.jboss.util.id.GUID. My classpath just points to all the jars in the client directory. I checked jboss-common-client.jar and that class is not in there. So, I copied jboss-common.jar from lib to client and the problem went away. Should id/* be in jboss-common-client.jar? Michael ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] missing org.jboss.util.id.GUID from client jars?
I just did a CVS co this morning and when I ran my client, I got a NoClassDefFound for org.jboss.util.id.GUID. My classpath just points to all the jars in the client directory. I checked jboss-common-client.jar and that class is not in there. So, I copied jboss-common.jar from lib to client and the problem went away. Should id/* be in jboss-common-client.jar? Michael ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossOne T-Shirts...
Did someone already have something like this? JBoss: Size does matter: 40,000+ downloads a month. Michael -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 2:18 PM Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] JBossOne T-Shirts... The slogan from me that Marc posted was supposed to be two different sayings, as follows: JBoss Because nothing is worth $10,000/cpu. JBoss DIE BEA! DIE! DIE! DIE! (props to alt.wesley.crusher.die.die.die) I don't necessarily like the latter anymore. Makes us look like the underdog and this poor rhetoric. This makes us look weak; it is much better to paint us as all powerful. Along those lines my new sayings are: JBoss You know who's boss. (this one from my mom) JBoss We have already won. Peace-out, -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossOne T-Shirts...
Sorry, wrong numbers... See, size does matter... JBoss: Size does matter: 100,000+ downloads a month. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 3:03 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBossOne T-Shirts... Did someone already have something like this? JBoss: Size does matter: 40,000+ downloads a month. Michael ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: RE: RE: [JBoss-dev] something is broken...
Since String is final, the hashcode is probably precomputed when the String is created, thereby not causing any processing but the retrieval of the value. Not sure if this is true, but, it makes sense to me... Michael -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 2:06 AM To: [EMAIL PROTECTED] Subject: Re: RE: RE: RE: [JBoss-dev] something is broken... This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBOSS @ JAVAONE TSHIRT CONTEST
JBoss: YOUR developers have probably already contributed. Michael ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] so how fast is string comparison
Most of the strings we are talking about are dynamic (or at least run-time configurable), so we would have to do string.intern() to be able to use == and I don't think that you'd want that internal list of strings growing like that. Besides, when you have a new string and do an intern(), it looks up the common string in a hashtable using hashcode to return the string on which you can do == on. Michael -Original Message- From: Adam Heath [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 1:17 PM To: marc fleury Cc: Jboss-Development@Lists. Sourceforge. Net Subject: Re: [JBoss-dev] so how fast is string comparison On Thu, 7 Feb 2002, marc fleury wrote: when we do if (string.equals(this)) else if (string.equals(that)) how much slower is it than switch (stringAsInt) case THIS: case THAT: If strings are final, then you can use ==, instead of the much slower .equals(). A switch stmt is really nothing more than a series of if/elseif blocks. So, making all strings static/final, and using ==, should make for a win, without making the code hard to read by using abstract ints. ___ 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] ReadAheadCache patch to use 'page-size' attribute
This is a patch to ReadAheadCache.java that uses the 'page-size' attribute under the 'read-ahead' element. Michael read_ahead_patch.txt Index: ReadAheadCache.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ReadAheadCache.java,v retrieving revision 1.1 diff -r1.1 ReadAheadCache.java 22a23 import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCReadAheadMetaData; 46a48,49 private int pageSize = 1000; 54a58,60 JDBCReadAheadMetaData metaData = manager.getMetaData().getReadAhead(); pageSize = metaData.getPageSize(); 171d176 int pageSize = 1000;
[JBoss-dev] data source problems (hosed?)
When I deploy my mysql-service.xml file, it seems to wait for ever on these services that it depends on. The same thing happens when I deploy the hsql-default-service.xml file. I'm sure it is probably my fault somehow, but please help! when I deploy mysql-service.xml: 2002-02-01 11:18:27,160 INFO [org.jboss.system.ServiceController] waiting in create jboss.jca:service=ConnectionFactoryLoader,name=TEE_DS waiting on jboss.jca:service=RARDeployment,name=Minerva JDBC LocalTransaction ResourceAdapter 2002-02-01 11:18:27,162 INFO [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ConnectionFactoryLoader,name=TEE_DS on jboss.jca:service=RARDeployment,name=Minerva JDBC LocalTransaction ResourceAdapter when I deploy hsql-default.xml: 2002-02-01 12:00:04,353 INFO [org.jboss.system.ServiceController] waiting in start jboss:service=ConnectionFactoryLoader,name=DefaultDS on jboss.jca:service=RARDeployment,name=Minerva JDBC LocalTransaction ResourceAdapter 2002-02-01 12:00:04,355 INFO [org.jboss.system.ServiceController] waiting in start jboss:service=ConnectionFactoryLoader,name=NoTransDS on jboss.jca:service=RARDeployment,name=Minerva JDBC LocalTransaction ResourceAdapter I've attached my mysql-service.xml and hsql-default-service.xml files. Thanks, Michael mysql-service.xml hsqldb-default-service.xml mysql-service.xml Description: Binary data hsqldb-default-service.xml Description: Binary data
[JBoss-dev] MinimumSize ignored in AbstractInstancePool?
Why is MinimumSize a required sub-element of container-pool-conf when AbstractInstancePool doesn't even look at it? Could we a) make it optional and b) implement it? When MinimumSize is present, it should populate the pool with the minimum amount of instances. A simple loop over minSize with pool.push(get()); should do it. Thanks, Michael ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MinimumSize ignored in AbstractInstancePool?
Should use add() instead of pool.push(get());. Just now discovered that method. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 3:33 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] MinimumSize ignored in AbstractInstancePool? Why is MinimumSize a required sub-element of container-pool-conf when AbstractInstancePool doesn't even look at it? Could we a) make it optional and b) implement it? When MinimumSize is present, it should populate the pool with the minimum amount of instances. A simple loop over minSize with pool.push(get()); should do it. Thanks, Michael ___ 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
