[JBoss-dev] PATCH: make jaws debug configurable via jaws.xml
A while back there was a thread on the 'debug' variable within JAWS. I
was quite vocal in saying that it should not be static final and that it
should be mutable at run time. I've made this configurable through jaws.xml.
This still defaults to false, but can be turned on for an ejb-jar by
adding a debug element as a child of the jaws element in jaws.xml:
jaws
datasourcejava:/DefaultDS/datasource
type-mappingPostgreSQL/type-mapping
debugtrue/debug
...
/jaws
Naturally, this can also be used to turn it on globally, if desired.
The remainder of this message is output from `cvs diff` in the
jboss/src/main/ejb/plugins/jaws directory. Can a comitter please commit
this, or tell me how to produce a more acceptable patch? (or tell me to
go away, that's fine too)
thanks,
danch
Index: jdbc/JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.29
diff -r1.29 JDBCCommand.java
124a125
this.debug = factory.getDebug();
Index: jdbc/JDBCCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java,v
retrieving revision 1.5
diff -r1.5 JDBCCommandFactory.java
54a55
private boolean debug = false;
78c79
jamd = jfl.load();
---
jamd = jfl.load();
80a82,83
debug = jamd.getDebug();
log.debug("debug="+debug);
107a111,115
}
public boolean getDebug()
{
return debug;
cvs server: Diffing metadata
Index: metadata/JawsApplicationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsApplicationMetaData.java,v
retrieving revision 1.4
diff -r1.4 JawsApplicationMetaData.java
53a54,55
private boolean debug = false;
102c104,106
protected ClassLoader getClassLoader() { return classLoader; }
---
public boolean getDebug() { return debug; }
protected ClassLoader getClassLoader() { return classLoader; }
167a172,179
//enable extra debugging?
Element debugElement = getOptionalChild(element, "debug");
if (debugElement != null) {
String stringDebug = getElementContent( debugElement );
debug = Boolean.valueOf(stringDebug).booleanValue();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] PATCH: make jaws debug configurable via jaws.xml
This patch has been committed danch wrote: A while back there was a thread on the 'debug' variable within JAWS. I was quite vocal in saying that it should not be static final and that it should be mutable at run time. I've made this configurable through jaws.xml. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata JawsEntityMetaData.java
User: danch
Date: 01/03/26 07:55:43
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
JawsEntityMetaData.java
Log:
Bill Burke's patch to do sql 'select ... for update' for smoother locking at the DB
level
Revision ChangesPath
1.7 +10 -3
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
Index: JawsEntityMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JawsEntityMetaData.java 2001/02/12 09:23:00 1.6
+++ JawsEntityMetaData.java 2001/03/26 15:55:43 1.7
@@ -34,7 +34,7 @@
* @see related
* @author a href="[EMAIL PROTECTED]"Sebastien Alborini/a
* @author a href="mailto:[EMAIL PROTECTED]"Dirk Zimmermann/a
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class JawsEntityMetaData extends MetaData implements XmlLoadable {
// Constants -
@@ -60,6 +60,9 @@
// do we use tuned updates?
private boolean tunedUpdates;
+// do we use 'SELECT ... FOR UPDATE' syntax?
+private boolean selectForUpdate;
+
// is the bean read-only?
private boolean readOnly;
private int timeOut;
@@ -194,8 +197,8 @@
public Iterator getEjbReferences() { return entity.getEjbReferences(); }
public String getPrimKeyField() { return entity.getPrimKeyField(); }
-
+ public boolean hasSelectForUpdate() { return selectForUpdate; }
// XmlLoadable implementation
@@ -227,7 +230,11 @@
// read only? If not provided, keep default.
String roStr = getElementContent(getOptionalChild(element,
"read-only"));
if (roStr != null) readOnly = Boolean.valueOf(roStr).booleanValue();
-
+
+ String sForUpStr = getElementContent(getOptionalChild(element,
"select-for-update"));
+ if (sForUpStr != null) selectForUpdate =
(Boolean.valueOf(sForUpStr).booleanValue());
+ selectForUpdate = selectForUpdate !readOnly;
+
// read only timeout?
String toStr = getElementContent(getOptionalChild(element,
"time-out"));
if (toStr != null) timeOut = Integer.valueOf(toStr).intValue();
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Performance (was Re: [JBoss-user] JBoss verses Orion)
OK, just a brief update on what I've done and what it taught me. I created a 'Counter' mbean to track singleton performance counters and a CounterInterceptor to stick into interceptor stacks to allow me to get a feel for where the time was going. This told me that the TxInterceptor was taking about .5 ms per invocation. I also wrote a test just to see how quickly the same 'functionality' would run in process without EJB overhead: about .002 ms. The odd thing was that this was about how fast Orion was running in-process. That Ain't Right. Big lights lit up here: I hadn't specified a container transaction, and Orion defaulted to Supports or some such nonsense, whereas JBoss defaults to Required. If I didn't want a transaction, I wouldn't use an EJB. Change the descriptor, and Orion slows down by about 100-200%. Eula's, licenses, and such make me nervous about posting hard numbers from Orion, but JBoss is still running a lot slower (think multipliers of 20-30). The problem is the there's no work being done within this transaction, which is where the important numbers live. Speaking of benchmark transactions with meaninful work, how is Tom doing on the ECPerf descriptors? Tommorrow evening, I'll post a more detailed summary, if anybody wants one. The comparison of which interceptors are eating time should be interesting, if nothing else. I'll also check the counter stuff (MBean and interceptor) into CVS - that could also be helpful in monitoring/tuning production applications. Right now, it's all in the org.jboss.util package. Should I leave it there or move it? thanks, danch marc fleury wrote: | | ||I've spent the day running some test similiar to Paul's. || ||My environment is Linux on a PIII 500, running Sun's 1.3 and ||1.3.1beta JDKs. || ||In the case of a standalone client looping and repeatedly calling the ||same method on a stateless session bean, I found that Orion averaged ||about 3ms. per invocation where JBoss was averaging 6-10 ms/invocation. | |It is very broken we have been running the stuff at well below those |numbers. | |In fact we ran around 1-2 ms (depending on stateless). we will see. | |Pf, tired... | |marc ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util CounterInterceptor.java CounterService.java CounterServiceMBean.java
User: danch
Date: 01/04/03 21:49:52
Added: src/main/org/jboss/util CounterInterceptor.java
CounterService.java CounterServiceMBean.java
Log:
MBean and interceptor to allow statistics gathering on time spent in EJB methods
Revision ChangesPath
1.1 jboss/src/main/org/jboss/util/CounterInterceptor.java
Index: CounterInterceptor.java
===
package org.jboss.util;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import org.jboss.ejb.MethodInvocation;
import org.jboss.ejb.Container;
import org.jboss.ejb.plugins.*;
import org.jboss.logging.Logger;
import org.jboss.util.CounterService;
/**
* Interceptor that uses the CounterService MBean to record the length of time
* spent in 'lower' interceptors (below it in the stack).
* pbHow to use:/b/p
* pFirst, the CounterService MBean must be installed in JBoss. To do this,
* place the following in your JBoss.jcml file, near the very end./p
* code
* lt;mbean code="org.jboss.util.CounterService"
name="DefaultDomain:service=CounterService" gt; lt;/mbeangt;
* /code
* pThis will start up and enable the centralized counter in your JBoss server
* instance.
* pNext, you need to configure this interceptor into the interceptor stacks
* of any beans you wish to monitor. This can be done either globally for a
* container-config in standardjboss.xml, or on a per-bean basis in a jar's
* jboss.jcml. Just insert the following at the top of the
lt;container-interceptorsgt;
* section. If you're overriding this for a bean in jboss.xml, you'll need to
* override the entire container-interceptors section./p
* code
* lt;interceptorgt;org.jboss.util.CounterInterceptorlt;/interceptorgt;
* /code
* pThis can go anywhere in the container-interceptors section, but either
* the top or the bottom will probably be best for gathering application
* statistics.
* @author a href="mailto:[EMAIL PROTECTED]"Dan Christopherson/href
*/
public class CounterInterceptor extends AbstractInterceptor {
Container container = null;
CounterService counter = null;
boolean loggedNoCounter = false;
StringBuffer baseCounterName = null;
int baseNameLength = 0;
public CounterInterceptor() {
}
public void setContainer(Container container) {
baseCounterName = new StringBuffer(container.getBeanClass().getName());
baseNameLength = baseCounterName.length();
this.container = container;
}
public Container getContainer() {
return container;
}
public Object invokeHome(MethodInvocation mi) throws Exception {
long startTime=System.currentTimeMillis();
try {
return super.invokeHome(mi);
} finally {
if (getCounter() != null) {
long endTime=System.currentTimeMillis();
baseCounterName.append("Home.");
baseCounterName.append(mi.getMethod().getName());
counter.accumulate(baseCounterName.toString(), endTime-startTime);
baseCounterName.setLength(baseNameLength);
}
}
}
public Object invoke(MethodInvocation mi) throws Exception {
long startTime=System.currentTimeMillis();
try {
return super.invoke(mi);
} finally {
if (getCounter() != null) {
long endTime=System.currentTimeMillis();
baseCounterName.append('.');
baseCounterName.append(mi.getMethod().getName());
counter.accumulate(baseCounterName.toString(), endTime-startTime);
baseCounterName.setLength(baseNameLength);
}
}
}
public void init() throws java.lang.Exception {
//get a reference to the CounterService from JNDI
Logger.debug("CounterInterceptor initializing");
}
private CounterService getCounter() {
if (counter == null) {
try {
InitialContext ctx = new InitialContext();
counter = (CounterService)ctx.lookup("java:/CounterService");
} catch (NamingException ne) {
if (!loggedNoCounter) {
Logger.warning("CounterInterceptor can't get counter service "+ne);
loggedNoCounter = true;
}
}
}
return counter;
}
}
1.1 jboss/src/main/org/jboss/util/CounterService.java
Index: CounterService.java
===
package org.jboss.util;
import java.text.DecimalFormat;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Vector;
import javax.naming.InitialContext;
[JBoss-dev] Re: [JBoss-user] bug when server is under load
I've moved this over to jboss-dev, where this bit will seem more appropriate. danch wrote: For what it's worth, I've seen similiar behavior under heavy threading (see archives under JBoss vs. Orion or Performance). I'm suspicious of the transaction interceptor (just because it seems to take about half of the time used in processing a request), but the code looks good. The message you're seeing (which I saw also in a multithreaded test) is particularly disturbing because the way JBoss' stateless session instance pool works, there should never be contention for a stateless session bean (as far as I can tell at any rate - I may be wrong). Well, what can I say: when I'm wrong I'm wrong. This has nothing to do with locks on beans. This was a lock on an internal bits of the JBoss transaction manager. The JBoss tm is written so that it attempts to reuse 'TxCapsule' instances by pooling them up in SoftReferences in a linked list. The problem is that they're not _quite_ available for reuse when the get put into the free list - they still have to do a hueristic check (and with trace on, throw something in the log) before they're unlocked. There _is_ a bit of a race condition here: it's possible for the capsule to get reused before (or while) it's doing its hueristic checks, which could potentially prevent the right thing from happening if a hueristic exception needs to happen. That, however, is highly unlikely in the test you're running. As far as fixing this bit of a race condition goes, I see two possiblilities: 1. Release the instance in the finally clause. Problem is that there are plenty of cases where it shouldn't be release, leading to a flag for it. 2. Make the method that initializes the capsule for re-use lock it. That way he'll wait for the hueristic checks to happen before blowing away the various state and status fields. We'll still see this message, but won't have this bit of a race condition behind it. If nobody objects, I'll implement option 2 tommorrow eve. For the record, there are some other things that make me nervous in this tm code: the TxCapsule and TransactionImpl have a circular dependency and in the process of cleaning up, the TransactionImpl will lose his referece to the TxCapsule before TxCapsule.commit() has actually returned to TransactionImpl.commit(). This just makes me nervous, like I said. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] JBoss 2.2: run.sh
Replying to dev. Should we have separate Unix vs. Windows binaries, just to ensure that we get things like this (and the line ending thing) right? -danch [EMAIL PROTECTED] wrote: Should I post this here or to dev? run.sh doesn't default to have execute permissions which is easy to fix but somewhat annoying. Jason Yip Software Developer, ThoughtWorks, Inc http://www.thoughtworks.com (312) 560-4978 (cell) "It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change." -- Charles Darwin ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
Have you tried putting the jetty mbean stuff in jboss.conf rather than jboss.jcml? I believe (but I'm not a JMX expert) that the Service (init,start,stop,destroy) only applies to mbeans listed in jboss.jcml, not those in jboss.conf. Julian Gosnell wrote: Greg has released JettyJMX, a packaged which integrates with Jetty in order that all major components of Jetty become MBeans. I have been integrating this into jboss_jetty, so that Jetty is now listed by the JMX agent as a collection of services, all with published interfaces, instead of one megalithic service. I have a problem ! JBoss seems to expect MBeans registered with it's JMX Server to support a JBoss-inspired life-cycle init()/start()/stop()/destroy(). Jetty MBeans support a different lifecycle which has no init() method. Every time a Jetty MBean is registered, JBoss tries to call it's init() method, resulting in an exception being thrown from within JMX. Maybe I am taking the wrong approach. I would like internal Jetty services to be available to JBoss users via JMX. However these internal services should be managed by Jetty, not JBoss (I don't expect someone else to come in and call lifecycle methods on objects I own...) Can this be done ? Do I register Jetty MBeans against another JMX Server ? If so can I hook this into the main JBoss one ? Should JBoss-Jetty actually be this JMX Server ? How should we scope groups of nested services within JBoss ? That should do it ! Jules __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] snapshot of load bug?
In the short term, I'll send you a patch. Probably there would be a JBoss 2.2.1 release at some point, as well. Bear in mind, however, that I really don't think we've found the bug that you're seeing: the race I found really only (as far as I can tell) effected cases where a Hueristic exception should have been thrown. I'll do more testing tonight, more similiar to your testing. Christian Hargraves wrote: Howdy, Thank you guys very much for finding the problem to that bug that shows up under load. I have been trying to get our company to use JBoss instead of WebLogic and your guys' prompt attention impressed our CIO very very much. I was wondering when you are planning on releasing the fix to that bug? We would be willing to test it for you guys. Thanks again Christian Hargraves ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] using jBoss in a production environment?!?
Torben Jger wrote: Hi all! Just ported our b2b platform from IAS to jBoss it seems that jBoss is having some performance problems. A simple jsp (in embedded tomcat) reading some entities over a finder method is real slow (table contains only 30 rows!!). Running this jsp with Inprise Application Server you couldn't recognize any action on the server. Is it a CMP bean or a BMP bean? You do realize that accessing entities directly from a JSP is probably not going to perform well on a variety of application servers, right? Also, Tomcat is known to not be the fastest JSP engine out there. I am using standard jBoss 2.2 installation with embedded tomcat. Database is running on another server (100 Mbit). Dev-Environment PIII 600 512 MB RAM jdk 1.3 tested on RH7.0 (23 sec) and w2k (9 sec) Are those times averaged, or first-run. You'll find that JBoss under hotspot gets quite a bit faster in subsequent runs. jdbc-driver: i-net sprinta2000 @ M$-SQL-Server 2000 Having said to my CEOs jBoss is the server to choose, I now have a problem to underline this statement when I have to present my work next week. If I can't fill this lack of performance my boss isn't struggling anymore whether to change the appserver or not. So, jBoss will be dead. :-( Why is jBoss so slow in this case? Are any performance improvements planned in near future? I've been looking at performance a bit. This was on haitus while we get the ECPerf stuff running so that we have real-world(ish) test cases. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] fix in contrib/tomcat for release 2.2.1?
I've made a small fix in the contrib module that should go in release 2.2.1, if possible. I've tagged the modified file with the Rel_2_2_1 tag, although the rest of the contrib module is untagged. For what it's worth, I'll also have changes to the main jboss module this evening. Can we hold off on a release until tommorrow? thanks, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm TxCapsule.java
User: danch
Date: 01/04/16 18:28:41
Modified:src/main/org/jboss/tm Tag: Branch_2_2 TxCapsule.java
Log:
prevent race condition and lock contention
Revision ChangesPath
No revision
No revision
1.24.2.1 +9 -4 jboss/src/main/org/jboss/tm/TxCapsule.java
Index: TxCapsule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/tm/TxCapsule.java,v
retrieving revision 1.24
retrieving revision 1.24.2.1
diff -u -r1.24 -r1.24.2.1
--- TxCapsule.java2001/02/09 18:56:17 1.24
+++ TxCapsule.java2001/04/17 01:28:41 1.24.2.1
@@ -48,7 +48,7 @@
* @author a href="mailto:[EMAIL PROTECTED]"Marc Fleury/a
* @author a href="mailto:[EMAIL PROTECTED]"Ole Husgaard/a
*
- * @version $Revision: 1.24 $
+ * @version $Revision: 1.24.2.1 $
*/
class TxCapsule implements TimeoutTarget
{
@@ -380,6 +380,10 @@
} finally {
unlock();
+
+// This instance is now ready for reuse (when we release the lock).
+if (done)
+ releaseInstance(this);
}
}
@@ -425,6 +429,10 @@
}
} finally {
unlock();
+
+// This instance is now ready for reuse (when we release the lock).
+if (done)
+ releaseInstance(this);
}
}
@@ -1383,9 +1391,6 @@
// If using a special class, second constructor argument is now useless.
if (xidConstructor != null)
xidConstructorArgs[1] = null; // This now needs initializing
-
- // This instance is now ready for reuse (when we release the lock).
- releaseInstance(this);
}
/**
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm TxCapsule.java
User: danch
Date: 01/04/16 18:29:06
Modified:src/main/org/jboss/tm TxCapsule.java
Log:
prevent race condition and lock contention
Revision ChangesPath
1.25 +9 -4 jboss/src/main/org/jboss/tm/TxCapsule.java
Index: TxCapsule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/tm/TxCapsule.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- TxCapsule.java2001/02/09 18:56:17 1.24
+++ TxCapsule.java2001/04/17 01:29:06 1.25
@@ -48,7 +48,7 @@
* @author a href="mailto:[EMAIL PROTECTED]"Marc Fleury/a
* @author a href="mailto:[EMAIL PROTECTED]"Ole Husgaard/a
*
- * @version $Revision: 1.24 $
+ * @version $Revision: 1.25 $
*/
class TxCapsule implements TimeoutTarget
{
@@ -380,6 +380,10 @@
} finally {
unlock();
+
+// This instance is now ready for reuse (when we release the lock).
+if (done)
+ releaseInstance(this);
}
}
@@ -425,6 +429,10 @@
}
} finally {
unlock();
+
+// This instance is now ready for reuse (when we release the lock).
+if (done)
+ releaseInstance(this);
}
}
@@ -1383,9 +1391,6 @@
// If using a special class, second constructor argument is now useless.
if (xidConstructor != null)
xidConstructorArgs[1] = null; // This now needs initializing
-
- // This instance is now ready for reuse (when we release the lock).
- releaseInstance(this);
}
/**
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-416576 ] fixed race inTxCapsule
Yes. Scott was planning on packaging that up tommorrow or so. Jim Archer wrote: Hi Dan... --On Monday, April 16, 2001 6:49 PM -0700 [EMAIL PROTECTED] wrote: Group: v2.2.1 Does this mean that this fix will be released with the 2.2.1 bug fix release this week? Thanks! Jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-name java: prefix need
Is it possible that people upgrading will need to put the 'java:' back into their res-jndi-names where appropriate? [EMAIL PROTECTED] wrote: Change Notes item #416812, was updated on 2001-04-17 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=416812group_id=22866 Category: None Group: v2.2.1 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Removed res-jndi-name java: prefix need Initial Comment: Fixed bug #414854. The requirement that the res-jndi-name be prefixed with java: has been removed from the ApplicationMetaData class. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=416812group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadataApplicationMetaData.java
Your code itself shouldn't change. I believe that it will just be places where you're mapping resource references in jboss.xml that would change, or have I misinterpreted, Scott? Jim Archer wrote: Can this change be postponed? Some of us are using code generators and it would be more than a simple search/replace exercise to accomadate this. Or, is it possible to set the code such that it works with or without the java: prefix? Jim --On Wednesday, April 18, 2001 8:14 AM +1200 Toby Allsopp [EMAIL PROTECTED] wrote: On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] wrote: User: starksm Date: 01/04/17 12:36:37 Modified:src/main/org/jboss/metadata Tag: Branch_2_2 ApplicationMetaData.java Log: Remove the requirement that the res-jndi-name be prefixed with java: This could break applications that used to work, right? Is this really a "bug" that needs to be fixed for 2.2? I absolutely agree that it's a good idea in 2.3. If this is going into 2.2, shouldn't the change note at least warn people that it might break things? Toby. ___ 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 Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
Maybe support the java:/ defaulting in 2.2.1 but issue a deprecation warning? Scott M Stark wrote: I don't have a strong opinion on its inclusion so if in general this is going to cause more problems then it solves it can be left out of the 2.2.1 release. An ApplicationMetaData level compatability flag could be added to indicate whether the java:/ prefix should be assumed and this could be made true by default in 2.2.1. I don't know that this should be mantained in the main branch as using the full JNDI name that includes the java:/ prefix works and that it could be left off is not documented anywhere that I can find. - Original Message - From: "Jim Archer" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 17, 2001 1:49 PM Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java Can this change be postponed? Some of us are using code generators and it would be more than a simple search/replace exercise to accomadate this. Or, is it possible to set the code such that it works with or without the java: prefix? Jim --On Wednesday, April 18, 2001 8:14 AM +1200 Toby Allsopp [EMAIL PROTECTED] wrote: On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] wrote: User: starksm Date: 01/04/17 12:36:37 Modified:src/main/org/jboss/metadata Tag: Branch_2_2 ApplicationMetaData.java Log: Remove the requirement that the res-jndi-name be prefixed with java: This could break applications that used to work, right? Is this really a "bug" that needs to be fixed for 2.2? I absolutely agree that it's a good idea in 2.3. If this is going into 2.2, shouldn't the change note at least warn people that it might break things? Toby. ___ 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 Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins MetricsInterceptor.java
You Rock! [EMAIL PROTECTED] wrote: User: juhalindfors Date: 01/04/18 08:25:51 Modified:src/main/org/jboss/ejb/plugins MetricsInterceptor.java Log: Reimplemented to move msg.publish() overhead out of the invocation thread. Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Oracle DDL generated by jaws
You probably want to turn JAWS creation of tables off. It really won't go to the extent that you'd like it too, and what it _does_ do will probably annoy you as a DBA. If you look in standardjaws.xml, you'll see a set of flags near the top, one of which is for the table creation. You can also create a 'jaws.xml' specific to your beans to map the bean's fields to different column names than JAWS would default to. This way you can retain any naming standards you have in place, etc. There's some jaws documentation in the manual (in the Documentation section of www.jboss.org), but improving the documentation of jaws/standardjaws.xml has been on my plate for a while now. -danch Linda Hagedorn wrote: Hello, Can anyone tell me if jaws can generate Oracle create syntax similar to the following examples? I'm an Oracle DBA and new to the jaws product. I need to create indexes in tablespaces separate from the data tablespaces. This isn't difficult in Oracle DDL, but I need to know if jaws can do it. create table reg.lh_test ( col1 number not null, col2 varchar2(10), constraint lh_test_pk primary key (col1,col2) using index tablespace TSINDEX storage(initial 8M next 8M minextents 1 maxextents 5) ) tablespace TSDATA storage(initial 8M next 8M minextents 1 maxextents 5) ; create index reg.lh_test_ix1 on lh_test (col2) pctfree 10 initrans 2 maxtrans 255 storage(initial 8m next 8m minextents 1 maxextents 2147483645 pctincrease 0 freelists 1 freelist groups 1 buffer_pool default tablespace TSINDEX logging compute statistics ; Any information or referral to documentation is appreciated. If I've made something unclear, please let me try again. Thank you, Linda Hagedorn Oracle DBA Saltare, Inc. 650-345-1200 x239 [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RFC: Add isolation level attribute in jboss.xml or jaws.xml?
Does anyone have opinions on whether this would be a good feature or not? The 1.1 spec does not specify how isolation levels should be handled, except for BMT session beans, and by saying/implying that beans can call resource manager specific APIs to set it themselves (carefully). If this seems like a good idea, should this setting be in jboss.xml (and cover BMP and CMP entities as well as sessions), or in jaws.xml (covering _only_ CMP entities, since others are free to call the resource manager's APIs)? thanks, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
I was about to tackle the most significant performance related problem in JAWS (see the discussion and feature request on CMP and finders: optimized and optimize collection finders, respectively) I've been building database applications for quite a while now (damn near the only thing i've ever done, software-wise) and am willing to take this task on. More comments follow in-line. marc fleury wrote: OK, I now believe that I am staring at a simple fact. The PERFORMANCE IN CONTAINERS IS BOLONEY! Our container can run in 0.05ms (yes **m**s) and still excercise 80 of its features. what costs a lot is **serialization** and we find that in JDBC calls and network calls. It appears that our JDBC calls are not optimized at all. We know it is just JawsCMP but it is what people really look at when they work on JBoss. There are tons of optimizations such as using raw ids in the database (Oracle). The way we would work this is that we could then map the primary keys to the raw ID (simple map) and the lookups would be kick ass fast. As a first step here, I'll make the 'command factory' used by JAWS for a container configurable. This will make it easier to make DBMS specific implementations of certain commands. I believe we also implement correctly the isModified, but we could really do a getModified that would return the names of the modified fields. We could then bypass the tuned updates. Personally, I'd rather keep the 'tuned' updates code, since it requires no-more container specific code. What's done now mirrors the behavior of Borland's CMP implementation, which is a very developer-friendly system. What do you see that's bad in the tuned updates? Finally the load today is very blind and very stupid. We just load everyone. A simple implementation of the versioning pattern in the database (where we add a field that is the version of the record) enables us to get the right version in little time and saves us time in loading since we can just select version where rawID for example :) This is a fine optional feature. I've implemented this in BMP beans and it shouldn't be too hard to add. If you are interested in leading this effort and have serious db background please let the board know marc _ 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
Re: [JBoss-dev] Main.java, let's clean it up
marc fleury wrote: Ok is the patchdir stuff used at all? I've used that a couple of times. marc _ 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
Re: [JBoss-dev] Main.java, let's clean it up
I've used it to let people try patches for bugfixes. This way people who have run into a bug have an option other than to wait for the next release. marc fleury wrote: can you be more specific, do you use it with releases from us (since we don't really release a patchdir...) or do you do it yourself. Please describe marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of danch |Sent: Monday, May 07, 2001 10:27 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Main.java, let's clean it up | | |marc fleury wrote: | | Ok is the patchdir stuff used at all? | |I've used that a couple of times. | | | | | marc | | _ | 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
Re: [JBoss-dev] TODO List on SourceForge
Note that I've already a feature request for the optimization of finders. Bordet, Simone wrote: H, our grumpy JBoss is back, and what a comeback !!! Marc, I'll suggest you to add TODO tasks on the sourceforge site, so that it's easier to keep track of them, I would have added the ones you mentioned here, but probably I don't have the admin privileges to add TODO tasks. See http://sourceforge.net/pm/?group_id=22866 BTW, they are (till now): 1) URL JMX Installation 2) JBoss CMP Fast 3) Deployer 4) Commit option D 5) Transaction Isolation level 6) In memory CMP store 7) jboss.properties 8) General code cleanup, including o TPC importer and MI o Container factory CLs o ServiceControl and Jetty-JMX easy integration (as well as JSR 77 start/stop lifecycle interface) o ConfigurationService and the byte[] bug (solved perhaps ?) o Main.java and URL reading of MLets (related to bullet No 1, yes ?) Simon ___ 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] JBoss, CVS Emacs
Somewhere on the sourceforge site there's a page on enabling key based authentication for ssh. This should do what you need. Julian Gosnell wrote: Every time I interact with JBoss CVS I am asked for a password. My Emacs does not seem to know how to deal with this. (I'm using vc on top of cvs). Is there any way I can work around this (e.g. tell Emacs what to use as the passwd, store it in a file somewhere where openssh will find it etc...) ? It would really help me develop quicker if I could do all my normal diffing, committing and logging from inside Emacs, instead of having to keep switching back to the command line. Any takers ? Thanks, Jules 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
Re: [JBoss-dev] Policy for what to include in stable (2.2.x) branches?
Toby Allsopp wrote: Hi, all. I've just made some changes that are more features enhancements than bug fixes, and I'm not sure whether I should be merging them into the 2.2 branch. What this comes down to is: what exactly should go into the 2.2.x releases? Is it only bug fixes with no new features, or is it also low-risk new features? My personal opinion would be bug fixes only. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util FinderResults.java
User: danch
Date: 01/05/26 17:49:16
Added: src/main/org/jboss/util FinderResults.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.1 jboss/src/main/org/jboss/util/FinderResults.java
Index: FinderResults.java
===
package org.jboss.util;
import java.util.Collection;
import java.util.Iterator;
import java.util.Map;
/**
* A collection of keys carrying additional information about the query from
* which they came. this is used to optimize (or maybe un-deoptimize)
* multi-finders in the CMPPersistenceManager.
*
* @author a href=mailto:[EMAIL PROTECTED];danch/a
*/
public class FinderResults implements Collection {
private Collection keys;
/** hold arbitrary data from the query. This is an object rather than a
* string so that we can better support non-relational/non-jdbc storages */
private Object queryData;
private Object finder;
private Object[] queryArgs;
private Map entities;
/** Constructor taking the collection of keys to hold and the query data.
*/
public FinderResults(Collection keys, Object queryData, Object finder, Object[]
args) {
this.keys = keys;
this.queryData = queryData;
this.finder = finder;
this.queryArgs = args;
}
public Collection getAllKeys() {
return keys;
}
public void setKeys(Collection newKeys) {
this.keys = newKeys;
}
public Object getQueryData() {
return queryData;
}
public Object getFinder() {
return finder;
}
public Object[] getQueryArgs() {
return queryArgs;
}
public Map getEntityMap() {
return entities;
}
public void setEntityMap(Map entities) {
this.entities = entities;
}
public int size() {
return keys.size();
}
public boolean isEmpty() {
return keys.isEmpty();
}
public boolean contains(Object o) {
return keys.contains(o);
}
public Iterator iterator() {
return keys.iterator();
}
public Object[] toArray() {
return keys.toArray();
}
public Object[] toArray(Object[] array) {
return keys.toArray(array);
}
public boolean add(Object o) {
return keys.add(o);
}
public boolean remove(Object o) {
return keys.remove(o);
}
public boolean containsAll(Collection otherCollection) {
return keys.containsAll(otherCollection);
}
public boolean addAll(Collection otherCollection) {
return keys.addAll(otherCollection);
}
public boolean removeAll(Collection otherCollection) {
return keys.removeAll(otherCollection);
}
public boolean retainAll(Collection otherCollection) {
return keys.retainAll(otherCollection);
}
public void clear() {
keys.clear();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/bmp CustomFindByEntitiesCommand.java
User: danch
Date: 01/05/26 17:49:15
Modified:src/main/org/jboss/ejb/plugins/jaws/bmp
CustomFindByEntitiesCommand.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.3 +9 -6
jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java
Index: CustomFindByEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CustomFindByEntitiesCommand.java 2001/01/02 22:43:47 1.2
+++ CustomFindByEntitiesCommand.java 2001/05/27 00:49:15 1.3
@@ -19,6 +19,7 @@
import org.jboss.logging.Logger;
import org.jboss.ejb.plugins.jaws.JPMFindEntitiesCommand;
import org.jboss.metadata.BeanMetaData;
+import org.jboss.util.FinderResults;
/**
* JAWSPersistenceManager CustomFindByEntitiesCommand.
@@ -29,7 +30,7 @@
*
* @see org.jboss.ejb.plugins.jaws.jdbc.JDBCFindEntitiesCommand
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class CustomFindByEntitiesCommand implements JPMFindEntitiesCommand
{
@@ -57,22 +58,24 @@
// JPMFindEntitiesCommand implementation -
- public Collection execute(Method finderMethod,
+ public FinderResults execute(Method finderMethod,
Object[] args,
EntityEnterpriseContext ctx)
throws java.rmi.RemoteException, FinderException
{
- Collection result = null;
+ FinderResults result = null;
// invoke implementation method on ejb instance
try {
// if expected return type is Collection, return as is
// if expected return type is not Collection, wrap result in Collection
if (finderMethod.getReturnType().equals(Collection.class)) {
- result =
(Collection)finderImplMethod.invoke(ctx.getInstance(),args);
+ Collection coll =
(Collection)finderImplMethod.invoke(ctx.getInstance(),args);
+result = new FinderResults(coll, null, null, null);
} else {
- result = new ArrayList(1);
- result.add(finderImplMethod.invoke(ctx.getInstance(),args));
+ Collection coll = new ArrayList(1);
+ coll.add(finderImplMethod.invoke(ctx.getInstance(),args));
+result = new FinderResults(coll, null, null, null);
}
} catch (IllegalAccessException e1) {
throw new FinderException(Unable to access finder
implementation:+finderImplMethod.getName());
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws JPMLoadEntitiesCommand.java JAWSPersistenceManager.java JPMCommandFactory.java JPMFindEntitiesCommand.java
User: danch
Date: 01/05/26 17:49:15
Modified:src/main/org/jboss/ejb/plugins/jaws
JAWSPersistenceManager.java JPMCommandFactory.java
JPMFindEntitiesCommand.java
Added: src/main/org/jboss/ejb/plugins/jaws
JPMLoadEntitiesCommand.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.27 +14 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/JAWSPersistenceManager.java
Index: JAWSPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/JAWSPersistenceManager.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- JAWSPersistenceManager.java 2000/12/07 18:16:10 1.26
+++ JAWSPersistenceManager.java 2001/05/27 00:49:15 1.27
@@ -11,6 +11,7 @@
import java.rmi.RemoteException;
import java.util.Collection;
+import java.util.Map;
import javax.ejb.CreateException;
import javax.ejb.DuplicateKeyException;
@@ -25,16 +26,18 @@
import org.jboss.ejb.plugins.jaws.jdbc.JDBCCommandFactory;
import org.jboss.logging.Log;
+import org.jboss.util.FinderResults;
/**
* Just Another Web Store - an O/R mapper
*
* @see org.jboss.ejb.EntityPersistenceStore
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.26 $
+ * @version $Revision: 1.27 $
*/
public class JAWSPersistenceManager
implements EntityPersistenceStore
@@ -55,10 +58,12 @@
JPMCreateEntityCommand createEntityCommand;
JPMRemoveEntityCommand removeEntityCommand;
JPMLoadEntityCommand loadEntityCommand;
+ JPMLoadEntitiesCommand loadEntitiesCommand;
JPMStoreEntityCommand storeEntityCommand;
JPMActivateEntityCommand activateEntityCommand;
JPMPassivateEntityCommand passivateEntityCommand;
+
Log log = Log.createLog(JAWS);
@@ -87,6 +92,7 @@
createEntityCommand = commandFactory.createCreateEntityCommand();
removeEntityCommand = commandFactory.createRemoveEntityCommand();
loadEntityCommand = commandFactory.createLoadEntityCommand();
+ loadEntitiesCommand = commandFactory.createLoadEntitiesCommand();
storeEntityCommand = commandFactory.createStoreEntityCommand();
activateEntityCommand = commandFactory.createActivateEntityCommand();
@@ -130,7 +136,7 @@
return findEntityCommand.execute(finderMethod, args, ctx);
}
- public Collection findEntities(Method finderMethod,
+ public FinderResults findEntities(Method finderMethod,
Object[] args,
EntityEnterpriseContext ctx)
throws RemoteException, FinderException
@@ -148,6 +154,12 @@
throws RemoteException
{
loadEntityCommand.execute(ctx);
+ }
+
+ public void loadEntities(FinderResults keys)
+ throws RemoteException
+ {
+ loadEntitiesCommand.execute(keys);
}
public void storeEntity(EntityEnterpriseContext ctx)
1.3 +3 -1 jboss/src/main/org/jboss/ejb/plugins/jaws/JPMCommandFactory.java
Index: JPMCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/JPMCommandFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JPMCommandFactory.java2000/12/07 15:44:29 1.2
+++ JPMCommandFactory.java2001/05/27 00:49:15 1.3
@@ -10,7 +10,7 @@
* Interface for JAWSPersistenceManager Command Factories
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public interface JPMCommandFactory
{
@@ -37,6 +37,8 @@
public JPMRemoveEntityCommand createRemoveEntityCommand();
public JPMLoadEntityCommand createLoadEntityCommand();
+
+ public JPMLoadEntitiesCommand createLoadEntitiesCommand();
public JPMStoreEntityCommand createStoreEntityCommand();
1.3 +3 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/JPMFindEntitiesCommand.java
Index: JPMFindEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/JPMFindEntitiesCommand.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JPMFindEntitiesCommand.java 2000/12/07 15
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EntityPersistenceManager.java EntityPersistenceStore.java
User: danch Date: 01/05/26 17:49:14 Modified:src/main/org/jboss/ejb EntityPersistenceManager.java EntityPersistenceStore.java Log: added 'read-ahead' option for finders in JAWS Revision ChangesPath 1.5 +3 -1 jboss/src/main/org/jboss/ejb/EntityPersistenceManager.java Index: EntityPersistenceManager.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EntityPersistenceManager.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- EntityPersistenceManager.java 2000/12/07 15:44:10 1.4 +++ EntityPersistenceManager.java 2001/05/27 00:49:14 1.5 @@ -14,6 +14,8 @@ import javax.ejb.FinderException; import javax.ejb.RemoveException; +import org.jboss.util.FinderResults; + /** * This interface is implemented by any EntityBean persistence managers plugins. * @@ -24,7 +26,7 @@ * * @see EntityContainer * @author Rickard Öberg ([EMAIL PROTECTED]) - * @version $Revision: 1.4 $ + * @version $Revision: 1.5 $ */ public interface EntityPersistenceManager extends ContainerPlugin 1.4 +17 -3 jboss/src/main/org/jboss/ejb/EntityPersistenceStore.java Index: EntityPersistenceStore.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EntityPersistenceStore.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- EntityPersistenceStore.java 2000/12/07 15:44:10 1.3 +++ EntityPersistenceStore.java 2001/05/27 00:49:14 1.4 @@ -9,12 +9,14 @@ import java.lang.reflect.Method; import java.rmi.RemoteException; import java.util.Collection; +import java.util.Map; import javax.ejb.CreateException; import javax.ejb.FinderException; import javax.ejb.RemoveException; import org.jboss.ejb.ContainerPlugin; +import org.jboss.util.FinderResults; /** * This interface is implemented by any EntityBean persistence Store. @@ -26,8 +28,9 @@ * * @see EntityPersistenceManager * @author Rickard Öberg ([EMAIL PROTECTED]) - * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a - * @version $Revision: 1.3 $ + * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a + * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a + * @version $Revision: 1.4 $ */ public interface EntityPersistenceStore extends ContainerPlugin @@ -78,7 +81,7 @@ * @exception RemoteException thrown if some system exception occurs * @exception FinderException thrown if some heuristic problem occurs */ - public Collection findEntities(Method finderMethod, Object[] args, EntityEnterpriseContext instance) + public FinderResults findEntities(Method finderMethod, Object[] args, EntityEnterpriseContext instance) throws Exception; @@ -106,6 +109,17 @@ * @exception RemoteException thrown if some system exception occurs */ public void loadEntity(EntityEnterpriseContext instance) + throws RemoteException; + + /** +* This method is called whenever a set of entities should be preloaded from +* the underlying storage. The persistence store is allowed to make this a +* null operation +* +* @param instances the EntityEnterpriseContexts for the entities that must be loaded +* @param keys a PagableKeyCollection previously returned from findEntities. +*/ + public void loadEntities(FinderResults keys) throws RemoteException; /** ___ 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.dtd
User: danch Date: 01/05/26 17:49:17 Modified:src/resources/org/jboss/metadata jaws.dtd Log: added 'read-ahead' option for finders in JAWS Revision ChangesPath 1.3 +18 -4 jboss/src/resources/org/jboss/metadata/jaws.dtd Index: jaws.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws.dtd,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jaws.dtd 2001/04/25 05:28:01 1.2 +++ jaws.dtd 2001/05/27 00:49:16 1.3 @@ -28,8 +28,20 @@ bean in this ejb-jar. This includes query specifications for any finders that either do not correspond to a single cmp-field or that require a specific ordering. it must contain an ejb-name element, can contain 0 or more cmp-field - elements and my contain 0 or more finder elements. -- -!ELEMENT entity (ejb-name,cmp-field*,finder*) + elements and my contain 0 or more finder elements. + Other options include: + read-ahead: When a finder is called, load all data for all entities. + read-only: Do not persist any changes to the bean's state. + table-name: Name of the corresponding table. + tuned-updates: emit 'update' SQL statements that update only changed fields. + create-table: On deploy, create the table if it doesn't exist. + remove-table: On undeploy, drop the table from the database (with _all_ _data_!!! + select-for-update: On loading the bean, use the 'select ... for update' syntax, + locking the row. + pk-constraint: If create-table is on, create it with a primary key. + time-out: -- +!ELEMENT entity (ejb-name,cmp-field*,finder*,read-ahead?,read-only?, + table-name?,tuned-updates?,create-table?,remove-table?,select-for-update?) !-- ejb-name within an entity element must contain the ejb-name as specified in ejb-jar.xml. -- @@ -38,8 +50,10 @@ !-- the finder element overrides JAWS default behavior for a finder, or specifies JAWS behavior for finders requiring multi-column where clauses or a specific ordering. it must contain name and query elements and my contain - 1 order element -- -!ELEMENT finder (name,query,order?) + 1 order element. + After JBoss version 2.3, it may contain a read-ahead element indicating whether + or not all data for the entities selected should be loaded immediatly. -- +!ELEMENT finder (name,query,order?,read-ahead?) !-- the name within a finder element must contain the name of the finder method from the bean's home interface -- ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins CMPFilePersistenceManager.java CMPPersistenceManager.java
User: danch
Date: 01/05/26 17:49:15
Modified:src/main/org/jboss/ejb/plugins
CMPFilePersistenceManager.java
CMPPersistenceManager.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.9 +10 -5
jboss/src/main/org/jboss/ejb/plugins/CMPFilePersistenceManager.java
Index: CMPFilePersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPFilePersistenceManager.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CMPFilePersistenceManager.java2000/12/07 15:44:23 1.8
+++ CMPFilePersistenceManager.java2001/05/27 00:49:15 1.9
@@ -35,6 +35,7 @@
import org.jboss.ejb.EntityContainer;
import org.jboss.ejb.EntityPersistenceStore;
import org.jboss.ejb.EntityEnterpriseContext;
+import org.jboss.util.FinderResults;
/**
* description
@@ -42,7 +43,7 @@
* @see related
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class CMPFilePersistenceManager
implements EntityPersistenceStore
@@ -137,7 +138,7 @@
return null;
}
- public Collection findEntities(Method finderMethod, Object[] args,
EntityEnterpriseContext ctx)
+ public FinderResults findEntities(Method finderMethod, Object[] args,
EntityEnterpriseContext ctx)
throws RemoteException
{
if (finderMethod.getName().equals(findAll))
@@ -154,10 +155,10 @@
}
// Logger.debug(Find all entities done);
- return result;
+ return new FinderResults(result,null,null,null);
} else
{
- return new java.util.ArrayList();
+ return new FinderResults(new java.util.ArrayList(),null,null,null);
}
}
@@ -191,7 +192,11 @@
}
}
- private void storeEntity(Object id, Object obj)
+ public void loadEntities(FinderResults keys) {
+ //this is a no op for this persistence store.
+ }
+
+ private void storeEntity(Object id, Object obj)
throws RemoteException {
try
1.19 +69 -39jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index: CMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- CMPPersistenceManager.java2001/05/02 11:03:16 1.18
+++ CMPPersistenceManager.java2001/05/27 00:49:15 1.19
@@ -15,6 +15,7 @@
import java.util.Iterator;
import java.util.ArrayList;
import java.util.HashMap;
+import java.util.Map;
import javax.ejb.EntityBean;
import javax.ejb.CreateException;
@@ -33,6 +34,9 @@
import org.jboss.ejb.EntityPersistenceStore;
import org.jboss.metadata.EntityMetaData;
+import org.jboss.util.FinderResults;
+import org.jboss.util.Sync;
+
/**
* The CMP Persistence Manager implements the semantics of the CMP
* EJB 1.1 call back specification.
@@ -42,7 +46,7 @@
*
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @version $Revision: 1.18 $
+* @version $Revision: 1.19 $
*/
public class CMPPersistenceManager
implements EntityPersistenceManager {
@@ -278,21 +282,43 @@
}
public Collection findEntities(Method finderMethod, Object[] args,
EntityEnterpriseContext ctx)
-throws Exception {
-
+throws Exception
+{
// The store will find the id and return a collection of PrimaryKeys
- Collection ids = store.findEntities(finderMethod, args, ctx);
+ FinderResults ids = store.findEntities(finderMethod, args, ctx);
+
+ AbstractInstanceCache cache = (AbstractInstanceCache)con.getInstanceCache();
+ Map contextMap = new HashMap();
+ ArrayList keyList = new ArrayList();
+ Iterator idEnum = ids.iterator();
+ while(idEnum.hasNext()) {
+ Object key = idEnum.next();
+ Object cacheKey = ((EntityCache)cache).createCacheKey(key);
+ keyList.add(cacheKey);
+
+ Sync mutex = (Sync)cache.getLock(cacheKey);
+ try
+ {
+ mutex.acquire();
- // Build a collection of cacheKeys
- ArrayList list = new ArrayList(ids.size());
-Iterator idEnum = ids.iterator();
-while(idEnum.hasNext()) {
-
- // Get a cache key for it
- list.add(((EntityCache)
con.getInstanceCache
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCLoadEntitiesCommand.java JDBCCommandFactory.java JDBCFindAllCommand.java JDBCFindEntitiesCommand.java JDBCFindEntityCommand.java JDBCFinderCommand.java JDBCLoadEntityCommand.java
User: danch
Date: 01/05/26 17:49:16
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCCommandFactory.java JDBCFindAllCommand.java
JDBCFindEntitiesCommand.java
JDBCFindEntityCommand.java JDBCFinderCommand.java
JDBCLoadEntityCommand.java
Added: src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCLoadEntitiesCommand.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.7 +10 -4
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java
Index: JDBCCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCCommandFactory.java 2001/03/26 15:19:36 1.6
+++ JDBCCommandFactory.java 2001/05/27 00:49:15 1.7
@@ -25,6 +25,7 @@
import org.jboss.ejb.plugins.jaws.JPMCreateEntityCommand;
import org.jboss.ejb.plugins.jaws.JPMRemoveEntityCommand;
import org.jboss.ejb.plugins.jaws.JPMLoadEntityCommand;
+import org.jboss.ejb.plugins.jaws.JPMLoadEntitiesCommand;
import org.jboss.ejb.plugins.jaws.JPMStoreEntityCommand;
import org.jboss.ejb.plugins.jaws.JPMActivateEntityCommand;
import org.jboss.ejb.plugins.jaws.JPMPassivateEntityCommand;
@@ -42,7 +43,7 @@
* JAWSPersistenceManager JDBCCommandFactory
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class JDBCCommandFactory implements JPMCommandFactory
{
@@ -130,9 +131,9 @@
return beanExistsCommand;
}
- public JPMFindEntitiesCommand createFindAllCommand()
+ public JPMFindEntitiesCommand createFindAllCommand(FinderMetaData f)
{
- return new JDBCFindAllCommand(this);
+ return new JDBCFindAllCommand(this, f);
}
public JPMFindEntitiesCommand createDefinedFinderCommand(FinderMetaData f)
@@ -140,7 +141,7 @@
return new JDBCDefinedFinderCommand(this, f);
}
- public JPMFindEntitiesCommand createFindByCommand(Method finderMethod)
+ public JPMFindEntitiesCommand createFindByCommand(Method finderMethod,
FinderMetaData f)
throws IllegalArgumentException
{
return new JDBCFindByCommand(this, finderMethod);
@@ -204,6 +205,11 @@
public JPMLoadEntityCommand createLoadEntityCommand()
{
return new JDBCLoadEntityCommand(this);
+ }
+
+ public JPMLoadEntitiesCommand createLoadEntitiesCommand()
+ {
+ return new JDBCLoadEntitiesCommand(this);
}
public JPMStoreEntityCommand createStoreEntityCommand()
1.4 +5 -3
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindAllCommand.java
Index: JDBCFindAllCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindAllCommand.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JDBCFindAllCommand.java 2000/12/07 15:44:36 1.3
+++ JDBCFindAllCommand.java 2001/05/27 00:49:15 1.4
@@ -7,6 +7,8 @@
package org.jboss.ejb.plugins.jaws.jdbc;
+import org.jboss.ejb.plugins.jaws.metadata.FinderMetaData;
+
/**
* JAWSPersistenceManager JDBCFindAllCommand
*
@@ -15,15 +17,15 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class JDBCFindAllCommand extends JDBCFinderCommand
{
// Constructors --
- public JDBCFindAllCommand(JDBCCommandFactory factory)
+ public JDBCFindAllCommand(JDBCCommandFactory factory, FinderMetaData f)
{
- super(factory, FindAll);
+ super(factory, f);
String sql = SELECT + getPkColumnList() + FROM +
jawsEntity.getTableName();
1.9 +15 -8
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.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JDBCFindEntitiesCommand.java 2001/02/12 18:31:13 1.8
+++ JDBCFindEntitiesCommand.java 2001/05/27 00:49:15 1.9
@@ -22,6 +22,7 @@
import org.jboss.ejb.plugins.jaws.JPMFindEntitiesCommand;
import
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommandFactory.java JDBCDefinedFinderCommand.java JDBCFindByCommand.java
User: danch
Date: 01/05/27 10:59:00
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCCommandFactory.java
JDBCDefinedFinderCommand.java
JDBCFindByCommand.java
Log:
Fixed build errors I introduced yesterday
Revision ChangesPath
1.8 +3 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java
Index: JDBCCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JDBCCommandFactory.java 2001/05/27 00:49:15 1.7
+++ JDBCCommandFactory.java 2001/05/27 17:59:00 1.8
@@ -43,7 +43,8 @@
* JAWSPersistenceManager JDBCCommandFactory
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.7 $
+ * @author a href=[EMAIL PROTECTED]danch (Dan Christopherson/a
+ * @version $Revision: 1.8 $
*/
public class JDBCCommandFactory implements JPMCommandFactory
{
@@ -144,7 +145,7 @@
public JPMFindEntitiesCommand createFindByCommand(Method finderMethod,
FinderMetaData f)
throws IllegalArgumentException
{
- return new JDBCFindByCommand(this, finderMethod);
+ return new JDBCFindByCommand(this, finderMethod, f);
}
// JPMCommandFactory implementation --
1.13 +3 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java
Index: JDBCDefinedFinderCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JDBCDefinedFinderCommand.java 2001/05/04 18:58:33 1.12
+++ JDBCDefinedFinderCommand.java 2001/05/27 17:59:00 1.13
@@ -26,7 +26,8 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.12 $
+ * @author a href=[EMAIL PROTECTED]danch (Dan Christopherson/a
+ * @version $Revision: 1.13 $
*/
public class JDBCDefinedFinderCommand extends JDBCFinderCommand
{
@@ -39,7 +40,7 @@
public JDBCDefinedFinderCommand(JDBCCommandFactory factory, FinderMetaData f)
{
- super(factory, f.getName());
+ super(factory, f);
typeMapping = jawsEntity.getJawsApplication().getTypeMapping();
1.8 +5 -3
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindByCommand.java
Index: JDBCFindByCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindByCommand.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JDBCFindByCommand.java2000/12/07 15:44:36 1.7
+++ JDBCFindByCommand.java2001/05/27 17:59:00 1.8
@@ -16,6 +16,7 @@
import org.jboss.logging.Logger;
import org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData;
+import org.jboss.ejb.plugins.jaws.metadata.FinderMetaData;
/**
* JAWSPersistenceManager JDBCFindByCommand
@@ -25,7 +26,8 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.7 $
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
+ * @version $Revision: 1.8 $
*/
public class JDBCFindByCommand extends JDBCFinderCommand
{
@@ -36,10 +38,10 @@
// Constructors --
- public JDBCFindByCommand(JDBCCommandFactory factory, Method finderMethod)
+ public JDBCFindByCommand(JDBCCommandFactory factory, Method finderMethod,
FinderMetaData md)
throws IllegalArgumentException
{
- super(factory, finderMethod.getName());
+ super(factory, md);
String cmpFieldName = finderMethod.getName().substring(6).toLowerCase();
Logger.debug(Finder:+cmpFieldName);
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Please help me understand CVS tags on Sourceforge
It's in. Sorry for the delay - I was unable to test myself due to problems with Postgres and blobs. thanks, danch Scott M Stark wrote: No, I have not created the JBoss_2_2_2 tag because I'm waiting for a jaws update. I will merge the change. - Original Message - From: Juha Lindfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 30, 2001 2:58 PM Subject: Re: [JBoss-dev] Please help me understand CVS tags on Sourceforge Hi, At 14:49 30.5.2001 -0400, you wrote: I need the activation bug fix made in revision 1.7 of StatefulSessionEnterpriseContext.java. Revision 1.6 has been tagged Rel_2_3_0 but 1.7 has not. Does this mean revision 1.7 will be included in a release after 2.3.0? yes, everything after Rel_2_3_0 will go into 2.4 stable release once we feature freeze the 2.3 development and move into 2.4 beta stage (should happen soon, maybe after J1?). However this particular fix looks like something we should put into 2.2.2 as well. Scott, did you tag it yet, can you merge this one in? -- Juha ___ 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-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
User: danch
Date: 01/05/30 16:00:42
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
Log:
Fixed bug #424059 CMP field of type Object is broken
Revision ChangesPath
1.31 +27 -23jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
Index: JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- JDBCCommand.java 2001/03/26 15:19:36 1.30
+++ JDBCCommand.java 2001/05/30 23:00:42 1.31
@@ -57,7 +57,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.30 $
+ * @version $Revision: 1.31 $
*/
public abstract class JDBCCommand
{
@@ -405,7 +405,7 @@
if(result == null)
return null;
-if(destination.isAssignableFrom(result.getClass()))
+if(destination.isAssignableFrom(result.getClass())
!result.getClass().equals(MarshalledObject.class) )
return result;
else if(debug)
log.debug(Got a +result.getClass().getName()+: '+result+' while
looking for a +destination.getName());
@@ -455,28 +455,32 @@
// ejb-reference: get the object back from the handle
if (result instanceof Handle) result =
((Handle)result).getEJBObject();
-if(!destination.isAssignableFrom(result.getClass())) {
-boolean found = false;
-if(destination.isPrimitive()) {
-if((destination.equals(Byte.TYPE) result instanceof
Byte) ||
- (destination.equals(Short.TYPE) result instanceof
Short) ||
- (destination.equals(Character.TYPE) result instanceof
Character) ||
- (destination.equals(Boolean.TYPE) result instanceof
Boolean) ||
- (destination.equals(Integer.TYPE) result instanceof
Integer) ||
- (destination.equals(Long.TYPE) result instanceof
Long) ||
- (destination.equals(Float.TYPE) result instanceof
Float) ||
- (destination.equals(Double.TYPE) result instanceof
Double)
- ) {
-found = true;
-}
-}
-if(!found) {
-log.debug(Unable to load a ResultSet column into a
variable of type '+destination.getName()+' (got a +result.getClass().getName()+));
-result = null;
-}
-}
+// is this a marshalled object that we stuck in earlier?
+if (result instanceof MarshalledObject
!destination.equals(MarshalledObject.class))
+result = ((MarshalledObject)result).get();
+
+ if(!destination.isAssignableFrom(result.getClass())) {
+ boolean found = false;
+ if(destination.isPrimitive()) {
+ if((destination.equals(Byte.TYPE) result instanceof Byte) ||
+(destination.equals(Short.TYPE) result instanceof Short)
||
+(destination.equals(Character.TYPE) result instanceof
Character) ||
+(destination.equals(Boolean.TYPE) result instanceof
Boolean) ||
+(destination.equals(Integer.TYPE) result instanceof
Integer) ||
+(destination.equals(Long.TYPE) result instanceof Long) ||
+(destination.equals(Float.TYPE) result instanceof Float)
||
+(destination.equals(Double.TYPE) result instanceof
Double)
+ ) {
+ found = true;
+ }
+ }
+ if(!found) {
+ log.debug(Unable to load a ResultSet column into a variable
of type '+destination.getName()+' (got a +result.getClass().getName()+));
+ result = null;
+ }
+ }
-ois.close();
+ ois.close();
} catch (RemoteException e) {
throw new SQLException(Unable to load EJBObject back
from Handle: +e);
} catch (IOException e) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
User: danch
Date: 01/05/30 15:47:49
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_2
JDBCCommand.java
Log:
Fixed bug #424059 - CMP field of type object fails
Revision ChangesPath
No revision
No revision
1.30.2.1 +27 -23jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
Index: JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.30
retrieving revision 1.30.2.1
diff -u -r1.30 -r1.30.2.1
--- JDBCCommand.java 2001/03/26 15:19:36 1.30
+++ JDBCCommand.java 2001/05/30 22:47:48 1.30.2.1
@@ -57,7 +57,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.30 $
+ * @version $Revision: 1.30.2.1 $
*/
public abstract class JDBCCommand
{
@@ -405,7 +405,7 @@
if(result == null)
return null;
-if(destination.isAssignableFrom(result.getClass()))
+if(destination.isAssignableFrom(result.getClass())
!result.getClass().equals(MarshalledObject.class) )
return result;
else if(debug)
log.debug(Got a +result.getClass().getName()+: '+result+' while
looking for a +destination.getName());
@@ -455,28 +455,32 @@
// ejb-reference: get the object back from the handle
if (result instanceof Handle) result =
((Handle)result).getEJBObject();
-if(!destination.isAssignableFrom(result.getClass())) {
-boolean found = false;
-if(destination.isPrimitive()) {
-if((destination.equals(Byte.TYPE) result instanceof
Byte) ||
- (destination.equals(Short.TYPE) result instanceof
Short) ||
- (destination.equals(Character.TYPE) result instanceof
Character) ||
- (destination.equals(Boolean.TYPE) result instanceof
Boolean) ||
- (destination.equals(Integer.TYPE) result instanceof
Integer) ||
- (destination.equals(Long.TYPE) result instanceof
Long) ||
- (destination.equals(Float.TYPE) result instanceof
Float) ||
- (destination.equals(Double.TYPE) result instanceof
Double)
- ) {
-found = true;
-}
-}
-if(!found) {
-log.debug(Unable to load a ResultSet column into a
variable of type '+destination.getName()+' (got a +result.getClass().getName()+));
-result = null;
-}
-}
+// is this a marshalled object that we stuck in earlier?
+if (result instanceof MarshalledObject
!destination.equals(MarshalledObject.class))
+result = ((MarshalledObject)result).get();
+
+ if(!destination.isAssignableFrom(result.getClass())) {
+ boolean found = false;
+ if(destination.isPrimitive()) {
+ if((destination.equals(Byte.TYPE) result instanceof Byte) ||
+(destination.equals(Short.TYPE) result instanceof Short)
||
+(destination.equals(Character.TYPE) result instanceof
Character) ||
+(destination.equals(Boolean.TYPE) result instanceof
Boolean) ||
+(destination.equals(Integer.TYPE) result instanceof
Integer) ||
+(destination.equals(Long.TYPE) result instanceof Long) ||
+(destination.equals(Float.TYPE) result instanceof Float)
||
+(destination.equals(Double.TYPE) result instanceof
Double)
+ ) {
+ found = true;
+ }
+ }
+ if(!found) {
+ log.debug(Unable to load a ResultSet column into a variable
of type '+destination.getName()+' (got a +result.getClass().getName()+));
+ result = null;
+ }
+ }
-ois.close();
+ ois.close();
} catch (RemoteException e) {
throw new SQLException(Unable to load EJBObject back
from Handle: +e);
} catch (IOException e) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
http
Re: [JBoss-dev] jboss daily test results
James Cook wrote: I assume that tests are run from the HEAD branch? If so, I would also assume that the current 2.2.2 (stable?) release also suffered quite a few errors/failures? Why would you assume that? HEAD and 2.2.2 are quite distinctly different branches. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Caching - Locking - Server Dies!
Bill Burke wrote: Vinay, I'm pretty sure the EJB spec says that an instance of an EntityBean can only process one request at a time. I think this is what the Context lock is for. When you say that your bean is readonly, you mean that you defined it in JAWS as readonly? I'm pretty sure the code does NOT check to see if the EntityBean is JAWS and therefore doesn't check to see if it is readonly. I'll confirm that. the JAWS readonly stuff is confined within JAWS. IMHO, there should be an option to remove EntityBean locking and let the Database handle the synchronization either through the select-for-update option, or doing the locks in BMP. I'd tend to agree, but that we'd also have to allow multiple instances of a bean in memory in order to gaurentee the proper threading behavior. This would improve throughput on scenarios with small datasets and large numbers of concurrent users. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem running jbosstest
Georg Rehfeld wrote: Hi Ole, I could easily commit that change, but: Am I the only one who has seen this problem? Might be, you are the only one testing? :-) I think the problem was only on Unix systems. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] New problems in JAWS?
danch (Dan Christopherson) wrote: Scott M Stark wrote: But your change works fine in the 2.2.2 codebase as I ran the same testsuite against it before making the release and I reran it today and it does not show the same errors. Is there a difference in the code comitted to the 2.2.2 branch versus main? Thank you. I was afraid I had a paper bag problem on my hands! On the other hand, it gets curiouser and curioser: The stack trace you posted earlier indicates that JAWS is trying to put something into a java.util.Collection for some reason. Better trace output from jaws is in order (like which column was it?). This is actually a bug that I introduced in the finder optimization. I've found it, but the fix is going to get a bit involved - hopefully I'll be able to commit tommorrow night. A probably work-around is to _not_ specify a PK field in the cmp-fields section of the entity's jaws.xml. The Customer bean ran into this bug because its name field is part of the PK but also in the cmp fields list. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata JawsEntityMetaData.java
User: danch
Date: 01/06/05 18:07:40
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
JawsEntityMetaData.java
Log:
Fixed bug caused by change in load operation associated with finder optimization.
Revision ChangesPath
1.9 +3 -1
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
Index: JawsEntityMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JawsEntityMetaData.java 2001/05/27 00:49:16 1.8
+++ JawsEntityMetaData.java 2001/06/06 01:07:40 1.9
@@ -34,7 +34,7 @@
* @see related
* @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class JawsEntityMetaData extends MetaData implements XmlLoadable {
// Constants -
@@ -166,6 +166,8 @@
public Iterator getPkFields() { return pkFields.iterator(); }
+ public int getNumberOfPkFields() { return pkFields.size(); }
+
public String getTableName() { return tableName; }
public boolean getCreateTable() { return createTable; }
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCLoadEntityCommand.java
User: danch
Date: 01/06/05 18:07:40
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCLoadEntityCommand.java
Log:
Fixed bug caused by change in load operation associated with finder optimization.
Revision ChangesPath
1.32 +4 -3 jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
Index: JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- JDBCCommand.java 2001/05/30 23:00:42 1.31
+++ JDBCCommand.java 2001/06/06 01:07:40 1.32
@@ -57,7 +57,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.31 $
+ * @version $Revision: 1.32 $
*/
public abstract class JDBCCommand
{
@@ -386,6 +386,7 @@
protected Object getResultObject(ResultSet rs, int idx, Class destination)
throws SQLException{
+log.debug(getting a +destination.getName()+ from resultset at index +idx);
Object result = null;
Method method = (Method)rsTypes.get(destination.getName());
@@ -484,9 +485,9 @@
} catch (RemoteException e) {
throw new SQLException(Unable to load EJBObject back
from Handle: +e);
} catch (IOException e) {
-throw new SQLException(Unable to load a ResultSet column into a
variable of type '+destination.getName()+': +e);
+throw new SQLException(Unable to load a ResultSet column +idx+
into a variable of type '+destination.getName()+': +e);
} catch (ClassNotFoundException e) {
-throw new SQLException(Unable to load a ResultSet column into a
variable of type '+destination.getName()+': +e);
+throw new SQLException(Unable to load a ResultSet column +idx+
into a variable of type '+destination.getName()+': +e);
}
}
1.10 +55 -10
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java
Index: JDBCLoadEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JDBCLoadEntityCommand.java2001/05/27 00:49:15 1.9
+++ JDBCLoadEntityCommand.java2001/06/06 01:07:40 1.10
@@ -11,6 +11,8 @@
import java.lang.reflect.Method;
import java.util.Iterator;
+import java.util.ArrayList;
+import java.util.List;
import java.util.HashMap;
import java.rmi.NoSuchObjectException;
@@ -36,12 +38,28 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.9 $
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
+ * @version $Revision: 1.10 $
*/
public class JDBCLoadEntityCommand
extends JDBCQueryCommand
implements JPMLoadEntityCommand
{
+ /**what is the position of each cmp field in the generated select statement?
+* this simply maps the position of the field in the CMP list to its position
+* in the generated select statement. This is neccessary because of the variable
+* number of key columns (which are skipped in a load) and because there can
+* be overlap between the two: pkfields and cmpfields are neither disjoint sets
+* nor is the cmpfields a subset of pkfields (not that that makes sense to
+* me right now, but I'll roll with it until I have more chance to analyse -
danch)
+*/
+ int [] cmpFieldPositionInSelect = null;
+
+ /** This const is used in places where I need to add an offset to a count
+* to account for the fact that JDBC counts from one whilst every other
+* damn thing in the languase starts at 0, the way God intended!
+*/
+ private static final int JDBC_WART_OFFSET = 1;
// Constructors --
public JDBCLoadEntityCommand(JDBCCommandFactory factory)
@@ -62,27 +80,47 @@
String sql = SELECT ;
HashMap alreadyListed = new HashMap();
// put the key fields in first
+ // we'll stash the column names here so that we can later map an overlapped
+ // column (overlap between PK and CMP) into its spot in the select statement.
+ String[] pkColumnNames = new String[jawsEntity.getNumberOfPkFields()];
Iterator keyIt = jawsEntity.getPkFields();
- boolean first = true
Re: [JBoss-dev] New problems in JAWS?
As of about 3 minutes ago, the 'bank' test is green in JUnit again. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
OK, I think we're talking about the same sort of thing. This looks good.
Bill Burke wrote:
Sorry my pseudo code was sooo confusing.
Here's something better
synchronized(ctx)
{
while (ctx.isLocked()) {
ctx.wait(5000);
if (ctx.isLocked()) {
log.log(LOCKING-WAITING);
}
else
{
ctx.lock();
break;
}
}
}
// do stuff...
synchronized(ctx)
{
ctx.unlock();
ctx.notify();
}
I think this, or something like it, will workImportant to noteI
don't think you should catch InterruptedException because I'm not sure how
Transaction Timeouts work.
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
K.V. Vinay Menon wrote: To be honest if the response time for a lookup is 5 seconds your clients would go shopping elsewhere! 5 seconds is the worst case: normally you'll be notified long before that happens. Actually 5 seconds is so much worst case that that's probably about the point where you decide that you must have a deadlock and roll yourself back to save the other transaction. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
I tried to send this out earlier today, but it never showed up (trouble on my end) The reason I was suggesting an oracle specific option name was because I really think that we need to use the Oracle specific syntax to return the rowid value on inserts. Georg Rehfeld wrote: Dear Vinay, Have started looking at the code again, Do we want to specifically say 'oracle-tuned-updates'. What if actually proves useful for some other database - can't we just call it just 'rowid-column' and use the presence or absence of the tag to use rowid based updates? What about 'stable-rowid-column' and a good comment and documentation? regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ 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] FW: Busy wait on one thread
Bill Burke wrote: Marc, I've rewritten EntityInstanceInterceptor a little(see my race condition fix email please) and put it some code so that LOCKING-WAITING isn't printed a zillion times. I also added a Thread.yield() before continue; in the lock-do-while-loop. I've also started looking into ditching the do..while loop in favor of wait/notify. It's much more complicated than I originally anticipated, but I'm making progress. IMHO, the whole locking business should be ditched when you have commit-option-C. Let the database to the synching for you with the select-for-update feature(CMP) or make the BMP developers handle the locking. That will require multiple instances of each bean to be spec compliant. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws JPMLoadEntitiesCommand.java
User: danch
Date: 01/06/12 23:52:17
Modified:src/main/org/jboss/ejb/plugins/jaws
JPMLoadEntitiesCommand.java
Log:
second pass at collection finder optimization - this fixes problem with defined
finders doing joins
Revision ChangesPath
1.2 +6 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/JPMLoadEntitiesCommand.java
Index: JPMLoadEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/JPMLoadEntitiesCommand.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JPMLoadEntitiesCommand.java 2001/05/27 00:49:15 1.1
+++ JPMLoadEntitiesCommand.java 2001/06/13 06:52:17 1.2
@@ -13,10 +13,14 @@
import org.jboss.ejb.plugins.jaws.metadata.PkFieldMetaData;
/**
- * Interface for JAWSPersistenceManager LoadEntities
+ * Interface for JAWSPersistenceManager LoadEntities - bpre/b load data for a
+ * batch of entities. 'LoadEntities' is a bit of a misnomer - it should actually
+ * preload the data into a the FinderResults so that the LoadEntity command
+ * can later get it. This somewhat circuitous route is needed so that we don't
+ * violate the container contract by loading data before ejbActivate is called.
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public interface JPMLoadEntitiesCommand
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
User: danch
Date: 01/06/15 16:59:07
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
Clean up of stuff left over in CMPPersistenceManager from 1st round finder
optimization: my test (1000 entities) now completes in about 8.7 seconds - cached was
6.4 seconds
Revision ChangesPath
1.21 +7 -31 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index: CMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- CMPPersistenceManager.java2001/06/04 20:46:42 1.20
+++ CMPPersistenceManager.java2001/06/15 23:59:07 1.21
@@ -46,7 +46,8 @@
*
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @version $Revision: 1.20 $
+* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
+* @version $Revision: 1.21 $
*/
public class CMPPersistenceManager
implements EntityPersistenceManager {
@@ -299,44 +300,19 @@
return ((EntityCache) con.getInstanceCache()).createCacheKey(id);
}
+/** find multiple entities */
public Collection findEntities(Method finderMethod, Object[] args,
EntityEnterpriseContext ctx)
throws Exception
{
// The store will find the id and return a collection of PrimaryKeys
FinderResults ids = store.findEntities(finderMethod, args, ctx);
-
- AbstractInstanceCache cache = (AbstractInstanceCache)con.getInstanceCache();
- Map contextMap = new HashMap();
- ArrayList keyList = new ArrayList();
- Iterator idEnum = ids.iterator();
- while(idEnum.hasNext()) {
- Object key = idEnum.next();
- Object cacheKey = ((EntityCache)cache).createCacheKey(key);
- keyList.add(cacheKey);
-
- Sync mutex = (Sync)cache.getLock(cacheKey);
- try
- {
- mutex.acquire();
-
- // Get context
- ctx = (EntityEnterpriseContext)cache.get(cacheKey);
- // if ctx has a transaction, we skip it - either it's our Tx
- //or we plain don't want to block here.
- if (ctx.getTransaction() == null) {
-contextMap.put(key, ctx);
- }
- } catch (InterruptedException ignored) {
- } finally {
- mutex.release();
- }
- }
-
- ids.setEntityMap(contextMap);
store.loadEntities(ids);
- return keyList;
+ // Note: for now we just return the keys - RabbitHole should return the
+ // finderResults so that the invoker layer can extend this back
+ // giving the client an OO 'cursor'
+ return ids.getAllKeys();
}
/*
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCLoadEntitiesCommand.java
User: danch
Date: 01/06/15 16:59:07
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCLoadEntitiesCommand.java
Log:
Clean up of stuff left over in CMPPersistenceManager from 1st round finder
optimization: my test (1000 entities) now completes in about 8.7 seconds - cached was
6.4 seconds
Revision ChangesPath
1.3 +1 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntitiesCommand.java
Index: JDBCLoadEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntitiesCommand.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JDBCLoadEntitiesCommand.java 2001/06/13 06:52:17 1.2
+++ JDBCLoadEntitiesCommand.java 2001/06/15 23:59:07 1.3
@@ -41,7 +41,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class JDBCLoadEntitiesCommand
extends JDBCLoadEntityCommand
@@ -84,7 +84,6 @@
protected Object handleResult(ResultSet rs, Object argOrArgs) throws Exception
{
FinderResults keys = (FinderResults)((Object[])argOrArgs)[0];
- Map instances = keys.getEntityMap();
while (rs.next())
{
Object key = createKey(rs);
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/docs customizingjaws.xml
User: danch
Date: 01/06/15 17:49:32
Modified:src/docs customizingjaws.xml
Log:
added doc for read-ahead option
Revision ChangesPath
1.8 +42 -0 manual/src/docs/customizingjaws.xml
Index: customizingjaws.xml
===
RCS file: /cvsroot/jboss/manual/src/docs/customizingjaws.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- customizingjaws.xml 2001/06/02 08:09:08 1.7
+++ customizingjaws.xml 2001/06/16 00:49:32 1.8
@@ -442,6 +442,48 @@
paraWe strongly suggest you use SQL92 as default query
language. T-SQL is provided for ease-of-use if you have existing T-SQL queries./para
/section
+ section
+ titleAdvanced options for declared finders/title
+ paraAuthor:
+author
+ firstnameDan/firstname
+ surnameChristopherson/surname
+/author
+email[EMAIL PROTECTED]/email or email[EMAIL PROTECTED]/email
+ /para
+ paraAs of JBoss version 2.3 beta (6/15/2001), it is possible to request
+ that JAWS preload data for all entities selected by a declared finder. This
+ avoids a performance problem where the database will be queried separately
+ to load data for each bean returned by the finder. To activate this
+ optimization, simply add lt;read-aheadgt;truelt;/read-aheadgt; to
+ your finder declaration. Note that as of the same version, you can override
+ this option for the autogenerated findAll method as well./para
+
+ paraThis is an example jaws.xml showing use of this
option/para
+ programlisting![CDATA[
+ jaws
+ enterprise-beans
+ entity
+ ejb-nameClassBean/ejb-name
+ finder
+ namefindBigClasses/name
+ querystudentCount {0} AND teacherName = {1}/query
+ orderstudentCount DESC/order
+ read-aheadtrue/read-ahead
+ /finder
+ finder
+ namefindAll/name
+ query /
+ order /
+ read-aheadtrue/read-ahead
+ /finder
+ /entity
+ /enterprise-beans
+ ...
+ /jaws
+
+]]/programlisting
+ /section
section
titleCustom finders coded in your beans/title
paraAuthor:
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] no select-for-update with finder optimization(read-ahead)
Ya, I realized I'd missed that right after I committed. If you want to get that in there, go ahead. thanks, danch Bill Burke wrote: Danch, Great work on the finder optimization stuff. Our project really needs this feature for performance tuning. One thing you forgot I think, is adding select-for-update when doing your select for read-ahead finders. Is there any serious problem doing a select-for-update with read-ahead? We're using select-for-update to synch multiple instances of JBoss, so we can't use this new optimization until select-for-update can be enabled. If you see no problem, I can add this myself. Seems pretty straight-forward. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFinderCommand.java
I really like the way you designed this: the PreloadFinderCommand acting as a decorator really makes things clearer. This is getting faster everytime one of us touches it. Something I noticed, Bill - your changes only worked for defined finders. I've extended them so that they work for findAll and the regular autogenerated findByField stuff as well. To support this I changed the 'defined' member of JDBCPreloadFinderCommand to be a JDBCFinderCommand (superclass of all finders) and made his setParameters method simply delegate to the embedded finder command. I also changed the name of the embedded finder to finderDelegate: I think that's more descriptive now. I'm going to test that a bit more, then check in. -danch [EMAIL PROTECTED] wrote: User: patriot1burke Date: 01/06/21 14:57:22 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS thread usage
Chris' nightly test runs have only been failing with these OutOfMemory exceptions for the last couple of nights. Either it was a recent change that caused this or a recently added test that brought it into the open -danch Hiram Chirino wrote: I'm embarased. I'll look into it right away. Since the JMS client and server stuff is running in the same VM when using ASF I should be able to get rid of the socket calls and thus free up the threads that are polling the sockets. I'll also see if I can get rid of the SpySession Threads when using the ASF.. Regards, Hiram - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 8:04 PM Subject: [JBoss-dev] JMS thread usage I have been running the jbosstest suite off and on throughout the day against a snapshot of main on linux to look into the issue people have reported concerning running out of processes on linux. I am seeing a steady increase in threads from 32 for the baseline just after startup to 229 after one interation of the test suite to 329 after about 10 iterations of the test suite. Clearly were leaking threads and it could be that the test code is not cleaning up correctly, but I am seeing a large portion of the threads associated with JMS and I question why this should be. Out of the 329 threads there are 266 JMS associated threads. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCCommandFactory.java JDBCPreloadFinderCommand.java
User: danch
Date: 01/06/21 20:24:49
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCCommandFactory.java
JDBCPreloadFinderCommand.java
Log:
extended Bill's earlier work to work on findAll and findBy commands as well
Revision ChangesPath
1.34 +10 -1 jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
Index: JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- JDBCCommand.java 2001/06/18 14:34:27 1.33
+++ JDBCCommand.java 2001/06/22 03:24:49 1.34
@@ -57,7 +57,11 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.33 $
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
+ * @version $Revision: 1.34 $
+ *
+ * Revision:
+ * 20010621 danch: add getter for name
*/
public abstract class JDBCCommand
{
@@ -125,6 +129,11 @@
this.debug = factory.getDebug();
}
+ /** return the name of this command */
+ public String getName() {
+ return name;
+ }
+
// Protected -
/**
1.12 +30 -12
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java
Index: JDBCCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommandFactory.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JDBCCommandFactory.java 2001/06/21 21:55:01 1.11
+++ JDBCCommandFactory.java 2001/06/22 03:24:49 1.12
@@ -69,11 +69,13 @@
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=[EMAIL PROTECTED]danch (Dan Christopherson)/a
* @author a href=[EMAIL PROTECTED]Bill Burke/a
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*
* Revision:
* 20010621 Bill Burke: createDefinedFinderCommand creates different objects
- * based on the read-head flag of the FinderMetaData.
+ *based on the read-head flag of the FinderMetaData.
+ * 20010621 danch: extended Bill's change to work on other finder types;
+ *removed stale todos.
*/
public class JDBCCommandFactory implements JPMCommandFactory
{
@@ -95,12 +97,10 @@
/** a map of data preloaded within some transaction for some entity. This map
* is keyed by Transaction and the data are hashmaps with key = entityKey and
-* data = Object[] containing the entity data.
-* @todo use weak references to ease memory. */
+* data = Object[] containing the entity data. */
private Map preloadedData = new HashMap();
/** A map of data preloaded without a transaction context. key=entityKey,
* data = Object[] containing entity data
-* @todo use weak references to ease memory.
*/
private Map nonTransactionalPreloadData = new HashMap();
@@ -125,7 +125,7 @@
{
this.container = container;
this.log = log;
-
+
this.javaCtx = (Context)new InitialContext().lookup(java:comp/env);
String ejbName = container.getBeanMetaData().getEjbName();
@@ -144,10 +144,10 @@
if (metadata == null) {
throw new DeploymentException(No metadata found for bean + ejbName);
}
-
+
tm = (TransactionManager) container.getTransactionManager();
- softRefHandler.schedule(new PreloadRefQueueHandlerTask(), 50);
+ softRefHandler.schedule(new PreloadRefQueueHandlerTask());
}
// Public
@@ -195,7 +195,14 @@
public JPMFindEntitiesCommand createFindAllCommand(FinderMetaData f)
{
- return new JDBCFindAllCommand(this, f);
+ if (f.hasReadAhead())
+ {
+ return new JDBCPreloadFinderCommand(this, new JDBCFindAllCommand(this, f));
+ }
+ else
+ {
+ return new JDBCFindAllCommand(this, f);
+ }
}
public JPMFindEntitiesCommand createDefinedFinderCommand(FinderMetaData f)
@@ -213,7 +220,14 @@
public JPMFindEntitiesCommand createFindByCommand(Method finderMethod,
FinderMetaData f)
throws IllegalArgumentException
{
- return new JDBCFindByCommand(this, finderMethod, f);
+ if (f.hasReadAhead())
+ {
+ return new JDBCPreloadFinderCommand(this, new JDBCFindByCommand(this,
finderMethod, f));
+ }
+ else
[JBoss-dev] CVS update: manual/src/docs customizingjaws.xml
User: danch Date: 01/06/21 20:47:40 Modified:src/docs customizingjaws.xml Log: added brief/terse explanation of the interaction between read-ahead option and transactions Revision ChangesPath 1.9 +267 -259 manual/src/docs/customizingjaws.xml Index: customizingjaws.xml === RCS file: /cvsroot/jboss/manual/src/docs/customizingjaws.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- customizingjaws.xml 2001/06/16 00:49:32 1.8 +++ customizingjaws.xml 2001/06/22 03:47:40 1.9 @@ -1,15 +1,15 @@ ?xml version = 1.0 encoding = UTF-8? chapter id=jaws - titleCustomizing JAWS/title - paraAuthor:author - firstnameSebastien/firstname - surnameAlborini/surname - /author - email[EMAIL PROTECTED]/email - /para - section - titleIntroduction/title - paraJAWS is the O/R mapper used by JBoss to manage CMP entity beans. JAWS is configured in a file named standardjaws.xml, located in the conf/config-name directory in the JBoss distribution. The default quoteconfig-name/quote is quotedefault/quote./para + titleCustomizing JAWS/title + paraAuthor:author + firstnameSebastien/firstname + surnameAlborini/surname + /author + email[EMAIL PROTECTED]/email + /para + section + titleIntroduction/title + paraJAWS is the O/R mapper used by JBoss to manage CMP entity beans. JAWS is configured in a file named standardjaws.xml, located in the conf/config-name directory in the JBoss distribution. The default quoteconfig-name/quote is quotedefault/quote./para paraThis file configures JAWS for all JBoss. You can then extend this configuration on a per-application basis by putting a jaws.xml @@ -21,91 +21,91 @@ directory of the emphasisjar/emphasis archive. /para - paraHere is what you can do with standardjaws.xml / jaws.xml:/para - itemizedlist - listitem - para Specify a datasource and the type-mappings to use with it - /para - /listitem - listitem - para Set a bunch of options concerning jaws behavior - /para - /listitem - listitem - para Specify how JAWS should build/use your tables - /para - /listitem - listitem - para Define finders to access you entity beans - /para - /listitem - listitem - para Define a type mapping - /para - /listitem - /itemizedlist - paraIf you want to know everything about jaws.xml, see the Jaws.xml DTD. The + paraHere is what you can do with standardjaws.xml / jaws.xml:/para + itemizedlist + listitem +para Specify a datasource and the type-mappings to use with it + /para + /listitem + listitem +para Set a bunch of options concerning jaws behavior + /para + /listitem + listitem +para Specify how JAWS should build/use your tables + /para + /listitem + listitem +para Define finders to access you entity beans + /para + /listitem + listitem +para Define a type mapping + /para + /listitem + /itemizedlist + paraIf you want to know everything about jaws.xml, see the Jaws.xml DTD. The general structure of the jaws.xml can be found here. All parts of this file are optional: you only provide what you need!/para - /section - section - titleSpecifying a datasource/title - paraA datasource is, mainly, a database plus a driver plus a connection pool. By + /section + section + titleSpecifying a datasource/title + paraA datasource is, mainly, a database plus a driver plus a connection pool. By default, jboss uses the Hypersonic datasource. To add another datasource, you have to declare it as a JMX MLet: see the manual./para - paraThe second ARG of this MLet is the JNDI name of the datasource, i.e. the name + paraThe second ARG of this MLet is the JNDI name of the datasource, i.e. the name you have to use to access it. To tell JAWS to use this datasource, simply add in your jaws.xml file
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCInitCommand.java
User: danch
Date: 01/06/21 22:04:23
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCInitCommand.java
Log:
merged patch 424409 - not null constraint for columns (thanks to David Jencks) also
fixed a bug where remapping the name of a primary key field caused the primary key
constraint to be wrong
Revision ChangesPath
1.35 +36 -35jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
Index: JDBCCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- JDBCCommand.java 2001/06/22 03:24:49 1.34
+++ JDBCCommand.java 2001/06/22 05:04:23 1.35
@@ -58,10 +58,11 @@
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Revision: 1.34 $
+ * @version $Revision: 1.35 $
*
* Revision:
* 20010621 danch: add getter for name
+ * 20010621 (ref 1.25) danch: improve logging: an exception execing SQL is an error!
*/
public abstract class JDBCCommand
{
@@ -164,11 +165,11 @@
{
log.debug(name + command executing: + theSQL);
}
- stmt = con.prepareStatement(theSQL);
- setParameters(stmt, argOrArgs);
- result = executeStatementAndHandleResult(stmt,
argOrArgs);
+ stmt = con.prepareStatement(theSQL);
+ setParameters(stmt, argOrArgs);
+ result = executeStatementAndHandleResult(stmt, argOrArgs);
} catch(SQLException e) {
- log.debug(e);
+ log.error(Exception caught executing SQL: +e);
throw e;
} finally
{
@@ -458,12 +459,12 @@
// Use the class loader to deserialize
try {
- ObjectInputStream ois = new ObjectInputStream(bais);
+ObjectInputStream ois = new ObjectInputStream(bais);
- result = ((MarshalledObject) ois.readObject()).get();
+result = ((MarshalledObject) ois.readObject()).get();
- // ejb-reference: get the object back from the handle
- if (result instanceof Handle) result =
((Handle)result).getEJBObject();
+// ejb-reference: get the object back from the handle
+if (result instanceof Handle) result = ((Handle)result).getEJBObject();
// is this a marshalled object that we stuck in earlier?
if (result instanceof MarshalledObject
!destination.equals(MarshalledObject.class))
@@ -491,8 +492,8 @@
}
ois.close();
- } catch (RemoteException e) {
- throw new SQLException(Unable to load EJBObject back
from Handle: +e);
+ } catch (RemoteException e) {
+throw new SQLException(Unable to load EJBObject back from Handle:
+e);
} catch (IOException e) {
throw new SQLException(Unable to load a ResultSet column +idx+
into a variable of type '+destination.getName()+': +e);
} catch (ClassNotFoundException e) {
@@ -503,20 +504,20 @@
return result;
}
- /**
- * Wrapper around getResultObject(ResultSet rs, int idx, Class destination).
- */
- protected Object getResultObject(ResultSet rs, int idx, CMPFieldMetaData
cmpField)
- throws SQLException {
- if (!cmpField.isNested()) {
- // do it as before
- return getResultObject(rs, idx, cmpField.getField().getType());
- }
-
- // Assuming no one will ever use BLOPS in composite objects.
- // TODO Should be tested for BLOPability
- return rs.getObject(idx);
- }
+ /**
+* Wrapper around getResultObject(ResultSet rs, int idx, Class destination).
+*/
+ protected Object getResultObject(ResultSet rs, int idx, CMPFieldMetaData
cmpField)
+ throws SQLException {
+ if (!cmpField.isNested()) {
+ // do it as before
+ return getResultObject(rs, idx, cmpField.getField().getType());
+ }
+
+ // Assuming no one will ever use BLOPS in composite objects.
+ // TODO Should be tested for BLOPability
+ return rs.getObject(idx);
+ }
/**
@@ -646,7 +647,7 @@
protected Object getCMPFieldValue(Object instance, CMPFieldMetaData
fieldMetaData)
throws
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata CMPFieldMetaData.java
User: danch
Date: 01/06/21 22:04:24
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
CMPFieldMetaData.java
Log:
merged patch 424409 - not null constraint for columns (thanks to David Jencks) also
fixed a bug where remapping the name of a primary key field caused the primary key
constraint to be wrong
Revision ChangesPath
1.7 +309 -283
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java
Index: CMPFieldMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- CMPFieldMetaData.java 2001/05/03 12:36:03 1.6
+++ CMPFieldMetaData.java 2001/06/22 05:04:24 1.7
@@ -31,230 +31,249 @@
*
* @see related
* @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @author a href=mailto:[EMAIL PROTECTED];Vincent Harcq/a
- * @version $Revision: 1.6 $
+ * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
+ * @author a href=mailto:[EMAIL PROTECTED];Vincent Harcq/a
+ * @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
+ * @version $Revision: 1.7 $
+ *
+ * Revison:
+ * 20010621 danch: merged patch from David Jenks - null constraint on columns.
*/
public class CMPFieldMetaData extends MetaData implements XmlLoadable {
- // Constants -
+ // Constants -
- // Attributes
+ // Attributes
- // the entity this field belongs to
- private JawsEntityMetaData jawsEntity;
+ // the entity this field belongs to
+ private JawsEntityMetaData jawsEntity;
- // name of the field
+ // name of the field
private String name;
- // the actual Field in the bean implementation
- private Field field;
+ // the actual Field in the bean implementation
+ private Field field;
- // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
- private int jdbcType;
- // true if jdbcType has been initialized
- private boolean validJdbcType;
+ // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
+ private int jdbcType;
+ // true if jdbcType has been initialized
+ private boolean validJdbcType;
+
+ // the sql type, used for table creation.
+ private String sqlType;
+
+ // the column name in the table
+ private String columnName;
+
+ // for table creation, whether to include not null constraint on column
+ private boolean nullable = true;
+
+ private boolean isAPrimaryKeyField;
+
+
+ /**
+* We need this for nested field retrieval.
+*/
+ private String ejbClassName;
+
+ /**
+* We need this for nested fields. We could compute it from ejbClassName on the
fly,
+* but it's faster to set it once and cache it.
+*/
+ private Class ejbClass;
+
+ /**
+* Is true for fields like data.categoryPK.
+*/
+ private boolean isNested;
+
+ // Static
+
+ // Constructors --
+ public CMPFieldMetaData(String name, JawsEntityMetaData jawsEntity) throws
DeploymentException {
+ this.name = name;
+ this.jawsEntity = jawsEntity;
+
+ // save the class name for nested fields
+ ejbClassName = jawsEntity.getEntity().getEjbClass();
+ ejbClassName = jawsEntity.getEntity().getEjbClass();
+
+ try {
+ // save the class for nested fields
+ ejbClass =
jawsEntity.getJawsApplication().getClassLoader().loadClass(ejbClassName);
+ field = ejbClass.getField(name);
+ } catch (ClassNotFoundException e) {
+ throw new DeploymentException(ejb class not found: + ejbClassName);
+ } catch (NoSuchFieldException e) {
+ // we can't throw an Exception here, because we could have a nested field
+ checkField();
+ }
- // the sql type, used for table creation.
- private String sqlType;
+ // default, may be overridden by importXml
+ columnName = getLastComponent(name);
- // the column name in the table
- private String columnName;
+ // cannot set defaults for jdbctype/sqltype, type mappings are not loaded yet.
+ }
- private boolean isAPrimaryKeyField;
+ // Public
+ public String getName() { return name
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCInitCommand.java
User: danch
Date: 01/06/21 22:41:05
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCInitCommand.java
Log:
fix bug when PK field != columnname
Revision ChangesPath
No revision
No revision
1.12.6.1 +21 -15
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java
Index: JDBCInitCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java,v
retrieving revision 1.12
retrieving revision 1.12.6.1
diff -u -r1.12 -r1.12.6.1
--- JDBCInitCommand.java 2001/01/24 20:36:24 1.12
+++ JDBCInitCommand.java 2001/06/22 05:41:05 1.12.6.1
@@ -30,7 +30,12 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.12 $
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
+ * @version $Revision: 1.12.6.1 $
+ *
+ * Revision:
+ * 20010621 danch: fixed bug where mapping a PK field to a different column name
+ *resulted in an improper PK constraint.
*/
public class JDBCInitCommand
extends JDBCUpdateCommand
@@ -59,17 +64,18 @@
first = false;
}
- // If there is a primary key field,
- // and the bean has explicitly pk-constrainttrue/pk-constraint in jaws.xml
- // add primary key constraint.
- if (jawsEntity.getPrimKeyField() != null jawsEntity.hasPkConstraint()) {
- sql += ,CONSTRAINT pk+jawsEntity.getTableName()+ PRIMARY KEY (;
- for (Iterator i = jawsEntity.getPkFields();i.hasNext();) {
- sql += ((PkFieldMetaData)i.next()).getName();
- sql += i.hasNext()?,:;
- }
- sql +=);
+ // If there is a primary key field,
+ // and the bean has explicitly pk-constrainttrue/pk-constraint in jaws.xml
+ // add primary key constraint.
+ if (jawsEntity.getPrimKeyField() != null jawsEntity.hasPkConstraint()) {
+ sql += ,CONSTRAINT pk+jawsEntity.getTableName()+ PRIMARY KEY (;
+ for (Iterator i = jawsEntity.getPkFields();i.hasNext();) {
+String keyCol = ((PkFieldMetaData)i.next()).getColumnName();
+sql += keyCol;
+sql += i.hasNext()?,:;
}
+ sql +=);
+ }
sql += );
@@ -122,10 +128,10 @@
jdbcExecute(null);
factory.getContainer().getTransactionManager().commit ();
- // Create successful, log this
- log.log(Created table '+jawsEntity.getTableName()+'
successfully.);
- log.debug(Primary key of table '+jawsEntity.getTableName()+'
is '
- +jawsEntity.getPrimKeyField()+'.);
+// Create successful, log this
+log.log(Created table '+jawsEntity.getTableName()+'
successfully.);
+log.debug(Primary key of table '+jawsEntity.getTableName()+' is
'
+ +jawsEntity.getPrimKeyField()+'.);
} catch (Exception e)
{
log.debug(Could not create table +
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAWS -Single Datasource
No reason, really. Enter it as a feature request. If you've time, post a patch, but look at Dain's 2.0 CMP stuff first -danch Vinay Menon wrote: Hello, Is there any specific reason why the datasource tag needs to be applicable to the entire JAWS xml? This would mean that all the beans essentially tie to the same datasource i.e. database and need splitting up of the application into smaller units with their own separate deployement descriptors. Or am I missing something? Vinay Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com 'http://explorer.msn.com' ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAWS -Single Datasource
Dain Sundstrom wrote: No reason to tie an entire jar to a single datasource. I'll check my code to see if it can support multiple datasources, although I don't think it will work with most DBs. This would require the DBs to natively support JDBC 2.0 XA transactions, and if I remember most DBs don't have 2-phase commit drivers yet. -dain I believe they are getting much closer (at least if implementations of the XA extensions to JDBC are a true indicator). Of course, many of the XA implementations are broken in incompatible ways. Also, this wouldn't matter so long as the beans that are in different databases are in different transactions. But then there'd be no reason not to split them into different ejb-jar files. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFinderCommand.java
We need to talk a little bit here - my long term notion for the finderresults was to extend it into the invoker layers so that the collection that a client gets from these would be a proxy over the finder results. At that point we could add a 'page-size' parameter and a protocol between the client proxy and the server-side FinderResults to request that a new page of entities be brought into memory. This would allow us to support finders returning truly huge result sets without crashing out on memory. Naturally, this would really only be useful from batch processes for example (no matter how well we optimize, no user is going to sit while the software goes through 10 million rows!), so the real utility of it could easily be questioned. Would such a feature seem useful to you? Any others with opinions on the matter? Yeah, I saw your comment in CMPPersistenceManager. It's a great idea! But, I just don't like having code hanging around that isn't being used and is there for possible future features. What happens sometimes is that the future feature is never implemented and different people end up maintaining that code base and are confused about why the code is there. IMHO, FinderResults isn't being used now, so it should be removed until the 'remote cursor' feature is added. Good enough. We're also going to have to coordinate with Dain to make sure that these optimizations get over into the 2.0 CMP stuff. I've only looked at that briefly so far. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] finder optimization(read-ahead) phase 3
Bill Burke wrote: Can you explain this again in other words? I'm kind of confused. Are you saying you don't want to have a hashMap of preloaded data per transaction? But just one global cache? I think that is a bad idea. I'll clarify more if this is what you mean. That is what I mean (for option A only!). We can also do a look aside for option A (as you said higher up in your email) to make sure we don't read-ahead something that's already in the cache. Here goes again for my rational: In option A, we own the database, so there can be no external changes. If the data is changed by another transaction in JBoss, it will go through JAWS load code first, so the data will be taken out of the read-ahead before it is modified. Have I missed something? thanks, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Bill Burke wrote: Why can't a transaction manage different resources and each of those resources use a different transaction-isolation level? What's wrong with that? If different resources == different DB connections, i suppose it could. Maybe. But I keep thinking of the isolation level as an attribute of the transaction itself. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: |But if they're in the same transaction, they must use the same isolation |level - per our discussion on the database doing an implicite commit |when you try to change levels. I don't think it makes logical sense to |talk about having two different transaction isolation levels in the same |transaction, either - either the transaction is serializable or the |transaction is read-committed. why not? the STATE is read-committed or not, meaning that a theoretical level I have no problem saying that a transaction can encompass beans that are read-only (most of them, like a calendar and a whachamakalit list of stuff (menu) from where you select your products taht doesn't change (catalog?)) but the order would of course be read write. For design reasons I might want to use the global transaction to emcompass the records and have different isolations on their state. You don't agree? marcf I'm thinking of the isolation level as an immutable part of the transaction - partly because this is how the databases implement it (at least as far as JDBC goes). Sure, it would be useful to be able to specify different levels per bean, but given the apparent constraints that the databases are putting us under, implementing it against the database isn't feasable. Now, if we do move the notion of isolation level into the container further (which I think we've both mentioned) so that we can get the cache's et. al. helping us out, then I can certainly agree with your 'theoretical' case. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/interfaces - New directory
User: danch Date: 01/06/29 21:32:32 jbosstest/src/main/org/jboss/test/readahead/interfaces - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead - New directory
User: danch Date: 01/06/29 21:33:31 jbosstest/src/resources/readahead - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead/META-INF - New directory
User: danch Date: 01/06/29 21:34:16 jbosstest/src/resources/readahead/META-INF - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build/subprojects build-readahead.xml
User: danch
Date: 01/06/29 21:38:05
Added: src/build/subprojects build-readahead.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/build/subprojects/build-readahead.xml
Index: build-readahead.xml
===
?xml version=1.0?
!-- The JBossTest CMP read-ahead testsuite build file --
project name=JBossTest-ReadAhead default=jar
!-- === --
!-- Compiles the source code--
!-- === --
target name=compile
mkdir dir=${build.classes.dir}/
javac srcdir=${src.dir}
destdir=${build.classes.dir}
classpath=${classpath}
debug=on
deprecation=on
optimize=off
includes=org/jboss/test/readahead/**
/
/target
!-- === --
!-- Creates the JBossTest bank ejb-jar file --
!-- === --
target name=jar depends=compile
delete dir=${build.classes.dir}/META-INF/
copy todir=${build.classes.dir}
fileset dir=${src.resources}/readahead/
/copy
jar jarfile=${build.lib.dir}/readaheadtest.jar
basedir=${build.classes.dir}
manifest=${etc.dir}/manifest.mf
includes=org/jboss/test/readahead/interfaces/**,org/jboss/test/readahead/test/**,*.*
/
jar jarfile=${build.deploy.dir}/readahead.jar
basedir=${build.classes.dir}
includes=org/jboss/test/util/ejb/**,org/jboss/test/readahead/interfaces/**,org/jboss/test/readahead/ejb/**,**/*.xml
/
/target
/project
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build build.xml
User: danch Date: 01/06/29 21:38:05 Modified:src/build build.xml Log: Added tests for readahead functionality. Note that this only checks to see if they work: it doesn't verify that it's actually performing well Revision ChangesPath 1.37 +7 -2 jbosstest/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/build.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- build.xml 2001/06/26 01:08:49 1.36 +++ build.xml 2001/06/30 04:38:05 1.37 @@ -148,7 +148,8 @@ antcall target=web-subproject / antcall target=jmsra-subproject / antcall target=logging-subproject / - antcall target=threading-subproject / +antcall target=threading-subproject / +antcall target=readahead-subproject / /target target name=bank-subproject depends=prepare @@ -227,7 +228,11 @@ !-- Log4j logging tests -- ant antfile=src/build/subprojects/build-logging.xml / /target - target name=threading-subproject depends=prepare +target name=readahead-subproject depends=prepare +!-- CMP finder readahead tests -- +ant antfile=src/build/subprojects/build-readahead.xml / +/target +target name=threading-subproject depends=prepare !-- threading tests -- ant antfile=src/build/subprojects/build-threading.xml / /target ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/interfaces AddressHome.java AddressPK.java AddressRemote.java CMPFindTestEntityHome.java CMPFindTestEntityRemote.java CMPFindTestSessionHome.java CMPFindTestSessionRemote.java
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/interfaces
AddressHome.java AddressPK.java AddressRemote.java
CMPFindTestEntityHome.java
CMPFindTestEntityRemote.java
CMPFindTestSessionHome.java
CMPFindTestSessionRemote.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressHome.java
Index: AddressHome.java
===
package org.jboss.test.readahead.interfaces;
import java.util.Collection;
import java.rmi.RemoteException;
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
/**
* Home interface for one of the entities used in read-ahead finder tests
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: AddressHome.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public interface AddressHome extends EJBHome {
public AddressRemote create(String key, String addressId, String address,
String city, String state, String zip) throws
RemoteException, CreateException;
public AddressRemote findByPrimaryKey(AddressPK primaryKey) throws
RemoteException, FinderException;
public Collection findByKey(String key) throws RemoteException, FinderException;
public Collection findByCity(String city) throws RemoteException, FinderException;
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressPK.java
Index: AddressPK.java
===
package org.jboss.test.readahead.interfaces;
import java.io.Serializable;
/**
* Primary key class for one of the entities used in read-ahead finder tests.
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: AddressPK.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public class AddressPK implements Serializable {
public String key = ;
public String addressId = ;
public AddressPK() {
}
public AddressPK(String key, String addressId) {
this.key = key;
this.addressId = addressId;
}
public boolean equals(Object obj) {
if (this.getClass().equals(obj.getClass())) {
AddressPK that = (AddressPK) obj;
return this.key.equals(that.key) this.addressId.equals(that.addressId);
}
return false;
}
public int hashCode() {
return key.hashCode()+addressId.hashCode();
}
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressRemote.java
Index: AddressRemote.java
===
package org.jboss.test.readahead.interfaces;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
/**
* Remote interface for one of the entities used in read-ahead finder tests
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: AddressRemote.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public interface AddressRemote extends EJBObject {
public java.lang.String getZip() throws RemoteException;
public void setZip(java.lang.String newZip) throws RemoteException;
public java.lang.String getState() throws RemoteException;
public void setState(java.lang.String newState) throws RemoteException;
public java.lang.String getCity() throws RemoteException;
public void setCity(java.lang.String newCity) throws RemoteException;
public void setAddress(java.lang.String newAddress) throws RemoteException;
public java.lang.String getAddress() throws RemoteException;
public java.lang.String getAddressId() throws RemoteException;
public java.lang.String getKey() throws RemoteException;
public void setAddressId(java.lang.String newAddressId) throws RemoteException;
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/CMPFindTestEntityHome.java
Index: CMPFindTestEntityHome.java
===
package org.jboss.test.readahead.interfaces;
import java.util.Collection;
import java.rmi.RemoteException;
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
/**
* Home interface for one of the entities used in read-ahead finder tests.
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id
[JBoss-dev] CVS update: jbosstest/src/resources/readahead client.policy jndi.properties
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead client.policy jndi.properties
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/resources/readahead/client.policy
Index: client.policy
===
grant {
// Allow everything for now
permission java.security.AllPermission;
};
1.1 jbosstest/src/resources/readahead/jndi.properties
Index: jndi.properties
===
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jnp.interfaces
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead/META-INF ejb-jar.xml jaws.xml
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead/META-INF ejb-jar.xml jaws.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/resources/readahead/META-INF/ejb-jar.xml
Index: ejb-jar.xml
===
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'
ejb-jar
enterprise-beans
entity
ejb-nameCMPFindTestEntity/ejb-name
homeorg.jboss.test.readahead.interfaces.CMPFindTestEntityHome/home
remoteorg.jboss.test.readahead.interfaces.CMPFindTestEntityRemote/remote
ejb-classorg.jboss.test.readahead.ejb.CMPFindTestEntity/ejb-class
persistence-typeContainer/persistence-type
prim-key-classjava.lang.String/prim-key-class
reentrantFalse/reentrant
cmp-field
field-namekey/field-name
/cmp-field
cmp-field
field-namename/field-name
/cmp-field
cmp-field
field-namerank/field-name
/cmp-field
cmp-field
field-nameserialNumber/field-name
/cmp-field
primkey-fieldkey/primkey-field
/entity
session
ejb-nameCMPFindTestSession/ejb-name
homeorg.jboss.test.readahead.interfaces.CMPFindTestSessionHome/home
remoteorg.jboss.test.readahead.interfaces.CMPFindTestSessionRemote/remote
ejb-classorg.jboss.test.readahead.ejb.CMPFindTestSession/ejb-class
session-typeStateless/session-type
transaction-typeContainer/transaction-type
/session
entity
ejb-nameAddress/ejb-name
homeorg.jboss.test.readahead.interfaces.AddressHome/home
remoteorg.jboss.test.readahead.interfaces.AddressRemote/remote
ejb-classorg.jboss.test.readahead.ejb.Address/ejb-class
persistence-typeContainer/persistence-type
prim-key-classorg.jboss.test.readahead.interfaces.AddressPK/prim-key-class
reentrantFalse/reentrant
cmp-field
field-namekey/field-name
/cmp-field
cmp-field
field-nameaddressId/field-name
/cmp-field
cmp-field
field-nameaddress/field-name
/cmp-field
cmp-field
field-namecity/field-name
/cmp-field
cmp-field
field-namestate/field-name
/cmp-field
cmp-field
field-namezip/field-name
/cmp-field
/entity
/enterprise-beans
/ejb-jar
1.1 jbosstest/src/resources/readahead/META-INF/jaws.xml
Index: jaws.xml
===
jaws
enterprise-beans
entity
ejb-nameCMPFindTestEntity/ejb-name
tuned-updatestrue/tuned-updates
pk-constrainttrue/pk-constraint
finder
namefindAll/name
query /
order /
read-aheadtrue/read-ahead
/finder
finder
namefindByCity/name
query, address where CMPFindTestEntity.key = address.key AND
address.city = {0}/query
order /
read-aheadtrue/read-ahead
/finder
/entity
entity
ejb-nameAddress/ejb-name
tuned-updatestrue/tuned-updates
pk-constrainttrue/pk-constraint
finder
namefindByCity/name
queryaddress.city = {0}/query
order /
read-aheadtrue/read-ahead
/finder
/entity
/enterprise-beans
/jaws
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/bin readaheadtest.bat readaheadtest.sh
User: danch Date: 01/06/29 21:38:05 Added: src/bin readaheadtest.bat readaheadtest.sh Log: Added tests for readahead functionality. Note that this only checks to see if they work: it doesn't verify that it's actually performing well Revision ChangesPath 1.1 jbosstest/src/bin/readaheadtest.bat Index: readaheadtest.bat === java -Djava.security.policy=jar:file:../lib/readaheadtest.jar!/client.policy -Djava.security.manager -classpath ../lib/readaheadtest.jar junit.swingui.TestRunner org.jboss.test.readahead.test.Main 1.1 jbosstest/src/bin/readaheadtest.sh Index: readaheadtest.sh === #!/bin/sh java -Djava.security.policy=jar:file:../lib/readaheadtest.jar!/client.policy -Djava.security.manager -classpath ../lib/readaheadtest.jar junit.swingui.TestRunner org.jboss.test.readahead.test.Main ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/test Main.java
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/test Main.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/readahead/test/Main.java
Index: Main.java
===
package org.jboss.test.readahead.test;
import javax.naming.Context;
import javax.naming.InitialContext;
import org.jboss.test.readahead.interfaces.CMPFindTestSessionHome;
import org.jboss.test.readahead.interfaces.CMPFindTestSessionRemote;
import junit.framework.TestCase;
import junit.framework.Test;
import junit.framework.TestSuite;
/**
* TestCase driver for the readahead finder tests
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: Main.java,v 1.1 2001/06/30 04:38:06 danch Exp $
*
* Revision:
*/
public class Main extends TestCase {
CMPFindTestSessionRemote rem = null;
public Main(String name) {
super(name);
}
public static Test suite() {
return new TestSuite(Main.class);
}
protected void tearDown() throws Exception {
if (rem != null) {
System.out.println(Removing test data);
rem.removeTestData();
rem.remove();
rem = null;
}
}
protected void setUp()
throws Exception
{
if (rem != null)
return;
System.out.println(Deploying);
new org.jboss.jmx.client.Deployer().deploy(../deploy/readahead.jar);
System.out.println(Creating test data);
Context ctx = new InitialContext();
CMPFindTestSessionHome home =
(CMPFindTestSessionHome)ctx.lookup(CMPFindTestSession);
rem = home.create();
rem.createTestData();
}
public void testFindAll() throws Exception {
rem.testFinder();
}
public void testFindByCity() throws Exception {
rem.testByCity();
}
public void testAddressByCity() throws Exception {
rem.addressByCity();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead - New directory
User: danch Date: 01/06/29 21:32:14 jbosstest/src/main/org/jboss/test/readahead - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] FW: [JBoss-user] Strange Behavior When DataSource goes down.
I tend to agree with Doug on this. Also, I think it's reasonable that the pools be able to tell the difference between inability to create a new object (connection, in this case) and simple pool exhaustion - there's no reason to block startup of the whole server just because one datasource is bad - you could be taking 20 applications down just because 1 has a database that went down. This like inability to connect should also be logged at error level. If nobody objects, I'll take this on and add this feature for 3.0. -danch. Ferguson, Doug wrote: Hi, This is a thread that I think needs to move to DEV... Basically I feel that it is a royal pain that jboss hangs whenever I try to startup jboss when a datbase is down and I've set the mbean to blocking. I would like to see a timeout feature to where I can setup the mbean with a timeout parameter for the blocking. I would also be nice to have a default timeout. Other people brought up interesting issues... Please check the thread. Thanks, d. -Original Message- From: Kaseman, Mark T To: '[EMAIL PROTECTED]' Sent: 6/29/2001 11:40 AM Subject: RE: [JBoss-user] Strange Behavior When DataSource goes down. Number 2 is a big issue for me and OS/390 DB2. DB2 has an idle thread time out parameter, that causes the datasource to become unusable once DB2 kills the inactive connection/thread. I then must reboot JBOSS. Orion server recovers the connection with no problem. -Original Message- From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 12:11 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Strange Behavior When DataSource goes down. In this case, no query has been executed. What I'd change: 1. In the pools, object factory create methods should throw an exception when they can't create an object - this way we can tell pool exhaustion from inability to create a pooled resource. 2. The pools should have an ability to test connections to determine if they're still good (configurable, of course). This is for those whose database thwacks them on the head after some period of time (and no ability to turn that behavior off) others? -danch David Jencks wrote: Well, I kind of agree, however I don't know how to distinguish between the db crashing and executing a query whose first results are available in 3 hours...and you're willing to wait. I think if the driver can distinguish and throw an exception, you get to see the exception. Otherwise, what do you do? Some kind of time awareness such as jini leases would be nice, however there certainly isn't any support for them in jdbc. Any ideas? david jencks On 2001.06.28 15:32:20 -0400 Richard Kasperowski wrote: David Jencks wrote: Hi, I find it hard to understand what you want. jboss does try out connections from configured datasources on startup, and hangs if they can't connect. I don't see how this is a severe problem: if your datasource isn't working, neither will your app. When a datasource becomes unavailable after startup, it might be desirable for the application to tell the user, sorry, the database is unavailable.? A user might find that more satisfactory than being denied service. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ 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] CVS update: jbosspool/src/main/org/jboss/pool/jdbc/xa XAPoolDataSource.java
User: danch
Date: 01/07/01 20:20:08
Modified:src/main/org/jboss/pool/jdbc/xa XAPoolDataSource.java
Log:
Added timeout parameter for blocking
Revision ChangesPath
1.2 +6 -0 jbosspool/src/main/org/jboss/pool/jdbc/xa/XAPoolDataSource.java
Index: XAPoolDataSource.java
===
RCS file:
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/jdbc/xa/XAPoolDataSource.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- XAPoolDataSource.java 2001/05/15 07:58:24 1.1
+++ XAPoolDataSource.java 2001/07/02 03:20:08 1.2
@@ -22,6 +22,10 @@
* @see org.jboss.pool.factories.XAConnectionFactory
*
* @author Aaron Mulder ([EMAIL PROTECTED])
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
+ *
+ * Revision:
+ * 20010701 danch added code for timeout in blocking.
*/
public class XAPoolDataSource implements DataSource, Referenceable, ObjectFactory {
private static HashMap sources = new HashMap();
@@ -103,6 +107,8 @@
public int getMaxSize() {return pool.getMaxSize();}
public void setBlocking(boolean blocking) {pool.setBlocking(blocking);}
public boolean isBlocking() {return pool.isBlocking();}
+public void setBlockingTimeout(int blockingTimeout)
{pool.setBlockingTimeout(blockingTimeout);}
+public int getBlockingTimeout() {return pool.getBlockingTimeout();}
public void setIdleTimeoutEnabled(boolean allowShrinking)
{pool.setIdleTimeoutEnabled(allowShrinking);}
public boolean isIdleTimeoutEnabled() {return pool.isIdleTimeoutEnabled();}
public void setGCEnabled(boolean allowGC) {pool.setGCEnabled(allowGC);}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jbosspool.jar
User: danch Date: 01/07/01 20:29:14 Modified:src/lib jbosspool.jar Log: allow specification of a timeout in JDBC connection pools when blocking is enabled Revision ChangesPath 1.2 +356 -359 jboss/src/lib/jbosspool.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build problem with CVS HEAD
For the record, I didn't literally checkout the HEAD branch - this was just a default checkout (no tag specified). The only difference I can think of between my system and those who report it working is that I'm running on a reiserfs filesystem - the jar files could get sent back to Ant in an unusual order? Just guessing. -danch Bordet, Simone wrote: Yo, I'm back to real life ! I'd suggest not to use HEAD tag, it's used by CVS and does not reflect the most recent code on the main trunk. If I remember well, just deleted files have HEAD tag, so you will checkout them even if they're not part of the most recent code. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Does anybody know what databases are case sensitive WRT column and table
names (or even keywords). I've never run into case sensitive SQL
databases before.
[EMAIL PROTECTED] wrote:
Bugs item #438115, was opened at 2001-07-02 19:50
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=438115group_id=22866
Category: JBossCMP
Group: v2.4 BETA (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Jara (mjara)
Assigned to: Nobody/Anonymous (nobody)
Summary: JAWS lower-cases custom finder SQL text
Initial Comment:
JAWS is now lower-casing all custom finder SQL text
specified in jaws.xml. Most database drivers seem to
ignore case, but some (such as JConnect5.2/SybaseASE)
do not.
For example, if I have this in my jaws.xml file:
entity
ejb-nameEventDescription/ejb-name
finder
namefindByEventType/name
query, TypeDescriptionPair,
EventType WHERE EventType.description={0} AND
EventType.enumerationIndex=TypeDescriptionPair.eventTyp
eKey AND
TypeDescriptionPair.eventDescriptionKey=EventDescriptio
n.enumerationIndex/query
orderEventDescription.description/order
/finder
/entity
All table and field names are lower-cased on
execution. This is the trace logged in Beta 2.4:
2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
161.218.184.161] DEBUG JAWS - findByEventType command
executing: SELECT EventDescription.enumerationIndex,
EventDescription.description FROM EventDescription,
typedescriptionpair, eventtype where
eventtype.description=? and
eventtype.enumerationindex=typedescriptionpair.eventtyp
ekey and
typedescriptionpair.eventdescriptionkey=eventdescriptio
n.enumerationindex ORDER BY
EventDescription.description
2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
161.218.184.161] DEBUG JAWS - Set parameter: idx=1,
jdbcType=VARCHAR, value=Construction
2001-07-02 20:39:22,285 [RMI TCP Connection(8)-
161.218.184.161] DEBUG JAWS -
com.sybase.jdbc2.jdbc.SybSQLException: The column
prefix 'eventdescription' does not match with a table
name or alias name used in the query. Either the table
is not specified in the FROM clause or it has a
correlation name which must be used instead.
This DOES work properly in release 2.2 (maintaining
case as entered in jaws.xml.)
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=438115group_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
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Vinay Menon wrote: Dan, Oracle case sensitive as well. One of the chaps here put a finder query ... where flg='T' Obviously it didn't work cos the JDBCDefinedFinderCommand issued it to the backed as where flg=i't'. This is cos the where clause is constructed with the lower case query. Do you want me to fix it? D'Oh! That one I expect to not work - SQL is usually case sensitive with the _contents_ of columns. Go ahead and fix, if you've the time. thanks much, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fetch size and JBossPool and Jaws
Toby Allsopp wrote: 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. 2. For any finder method add a fetch-size deployment descriptor in jaws. Comments ? This makes sense to me. It also fits in with my evil plot to do 'cursor' type things on finders. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] how to bind 2 datasource in jboss.jcml?
still wrote: hi,everybody: i use MS Access You probably shouldn't do that. .and i have 2 tables to work with.and i successfully load the sun's jdbc:odbc database driver That's probably bad too. ODBC driver (used to, anyway, when I had to use them) be really non-threadable in a bad way. OK, that's way more flip an answer than I like to give, but damn, man, if you're gonna be cheap, be _good_ and cheap! use Interbase, postgreSQL, or something that works! ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] why is NoSuchEntityException ignored?
On Fri, Aug 10, 2001 at 10:45:47AM -0400, Bill Burke wrote: What about other instances of JBoss or different applications hitting the DB, or even the DBA doing some admin work? Plus, I've just checked in some new interceptors and a MethodOnly locking mechanism to allow instance per transaction. Also, if it can never happen, why ignore it? I agree - at the very least freak out into the log, so that we know that something 'impossible' has happened. -danch (friend of Murphy) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
Ferguson, Doug wrote: Well, Alot of my datasources are loaded on the fly... I can't have the type in a password when jboss starts. Also, when there are many differnet databases... it becomes unmanagable.. d. But if you encrypt the password on disk, you need a key to decrypt it with. Unless you make a sysadmin keep a floppy in a vault with this key on it and only mount that floppy when JBoss is starting, then take it out right away, you'll have to store the key on disk on the same machine where the encrypted passwords are stored. This makes the encrypted password clear-text equivalent. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] URGENCY? WSDL/UDDI/ebXML
Bill Burke wrote: Man you crack me up sometimes :) We used to have a running joke about support calls for O2K. I'm sorry, but you're just too stupid to use our product. Please cd to /usr/local and rm -rf o2k. Bill I think we've _all_ wanted to say that one time or another! -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Enhydra vs. JBoss
They're barely and only lately J2EE. THey had a lot of resistence to the whole JSP thing (based on some legitimate criticisms) and only recently Started doing EJB (via Jonas, from Bull). I haven't looked in a while, but I thought that EJB integration was only available in their 'enterprise' edition, which is available only at cost. Another thing that bothered me about the article was the apparent lack of cluefulness about what open source _is_: they didn't mention the difference in license terms or the fact that JBoss can be used by and contributed to by anyone. -danch On Wed, Aug 29, 2001 at 12:22:46PM -0400, Bill Burke wrote: From reading the IBD article, is Enhydra a competitor of JBoss? I went to their web site and it seemed that Enhydra really wasn't Open Source, but a J2EE implementation that came with the source. If they are a competitor in the Open Source arena, how can we kick their ass? Or maybe we already do? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Datasources and the java:/ namespace
Vinay Menon wrote: Hello Folks, Is there any specific reason we have the jdbc datasources bound under java:/ as opposed to java:/comp/env/jdbc/ ? The java:comp/env (note: no '/' between ':' and 'comp') is for the environment of a J2EE component. This must be set up separately for each EJB, and Web war. See the documentation on jboss.xml and jboss-web.xml for how to map the 'java:/xxx' datasource entry into the java:comp/env namespace for a component. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
On Wed, Sep 19, 2001 at 06:22:18PM +0100, Ignacio Coloma wrote: Hi, I am not sure, but looking in the EJB spec (draft version), for two times it specifically forbid the optimized EJB calls made in JBoss. Citing the draft: You can turn the optimization off. Most container vendors implement this optimization. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBossCMP] RE: [JBoss-dev] Tuned-updates OFF?
CMP just shouldn't update primary keys. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Cc: Jaws@Kpi. Com. Au [EMAIL PROTECTED] Sent: Thursday, October 18, 2001 11:17 AM Subject: [JBossCMP] RE: [JBoss-dev] Tuned-updates OFF? More than thatBecause of our ignorance on DB schema design back in March, we almost didn't use JBoss because tuned-updates were OFF by default which caused updates of PrimaryKeys which caused DB deadlock all over the place in our application. For CMP 2.0, I'm remember that tuned-updates are always on no matter what. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, October 18, 2001 11:50 AM To: Jboss-Development@Lists. Sourceforge. Net Cc: Jaws@Kpi. Com. Au Subject: [JBoss-dev] Tuned-updates OFF? I am looking at the new configuration files in 2.4.1 and it seems that the CMP engines come with tuned-updates turned OFF by default. Why is this? I suspect there is a reason but can't think of it off the top of my head. I strongly recommend turning this on as people will see a sharp drop in performance without these... please what is the reason these are removed... whodunit? marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- This is the JBossCMP mailing list. Please send email to '[EMAIL PROTECTED]' with the command 'unsubscribe jbosscmp [email@address]' in the body of the mail to be removed from this list. Please note that after a few days of emails bouncing to your address you will be unsubscribed. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] compile error in MessageDrivenTxInterceptorBMT - 2.4 branch?
On the current CVS, I'm getting errors like the following. Method disassociateThread() not found in interface javax.transaction.TransactionManager. [javac] Transaction t1 = tm.disassociateThread(); So what am I missing? thanks all, danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] compile error in MessageDrivenTxInterceptorBMT - 2.4 branch?
I looked at the RH version of the interceptor in question and all it seems to do is pass-through: invokeHome throws an exception (no home methods on MDBs) and invoke just calls invokeNext. Shouldn't invoke at least suspend the current transaction? I was also hoping that someone who better understood the transactional needs of the MDBs would at least tell me what to do. David Jencks wrote: I noticed this earlier this week and no one responed to my question;-) Scott changed TxManager to TransactionManager in the base class TxInterceptorBMT without doing a clean/build. I thought about reverting, but looked at the 3.0 code where a better solution was implemented. I didn't have time to backport that to 2.4, so hoped someone who understood it better could do so... What would you think about putting in depends tasks into the compile targets at least in 3.0 to make this kind of problem less likely at the cost of slightly slower builds? Thanks David Jencks On 2001.10.25 21:16:27 -0400 danch wrote: On the current CVS, I'm getting errors like the following. Method disassociateThread() not found in interface javax.transaction.TransactionManager. [javac] Transaction t1 = tm.disassociateThread(); So what am I missing? thanks all, danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
FWIW, Bluestone did this. I tried to get them to stop.
Aaron Mulder wrote:
How do you compile the client code if the home/remote exists only
in the VM of the running server?
Aaron
On Mon, 12 Nov 2001, marc fleury wrote:
I know there are many tools out there that do almost what I am going to
describe already, it is an improvement on x-doclet.
I am wondering if the generation step cannot be done at deployment time. I
think we have the bytecode generation tools stuff that generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server side), and the
client sees the generated Hello (naming convention we remove the bean)
and HelloHome. This way the client can see the classes with the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? -danch Scott M Stark wrote: Any of the interceptors can be made stateless, its a question of the cost of reassociating the state from the container meta-data and having to cast from an opaque generic form to the data required by the interceptor. The current state in the security interceptors is just cached data derived from the container meta-data. In the case of the SecurityProxyInterceptor the derived data can be an expensive transformation of the container meta-data. |should not need to know or store the interceptor-specific state info for |its chain. IMHO using a catch-all (or cache-all) map is a bit of a hack. |In particular, this conflicts directly with the security proxy interceptor. But isn't the state that the security interceptor uses really meta-data about the container? Shouldn't the interceptors get all meta-data from the *container*? If that is done, you'd get very clean separation of concerns, where the interceptor act upon the meta-data, but is not responsible for the actual meta-data. To me that seems more natural. So, the point isn't that the security interceptors should be stateless. In fact, they may very well be stateful. However, they should not have state *particular to any one container* (compare with Stateless Session Beans). ___ 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] Separating JMX/EJB
Rickard Oberg wrote: Bill Burke wrote: Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. While the packaging is cool, IMHO it's more of a practical detail than a real advancement. practical details are very important in the traditional IT world. Most developers are nowhere near as dedicated and talented as those who've been taking part in this conversation. To me, personally, it's all about the meta-programming and dynamicity of building large constructs from small blocks, which is enabled by having simple blocks that fit together like lego. JBoss is like lego. In many forms and different shapes, sizes and colors, but at the same time it's all the same. It's a nice illusion though. Very cool, indeed. But don't knock practicality 8^}) -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Rickard Öberg wrote: That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( Something people have been compaining about roughly forever. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Bill Burke wrote: In our app, we don't use wars and ears, only jars for our EJBs. Our jsps run off of a directory exposed through Jetty. That way we can easily modify jsps on the fly. Can't see why anybody would use WARS and EARS unless you were shipping a product. I've worked in a lot of companies where the production environment was that separated from development - the simpler the package you can hand over the better, since the people who support production environments tend to be on a different planet. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB QL
Peter Levart wrote: What about using finder methods like in BMP EBs? The responsibility of a BMP finder method is to return a Collection of primary keys. That's easy to do with JDBC/SQL. There would only have to be a way to apply BMP finders to CMP beans and we'll have dynamic SQL already. Currently I'm using JDBC/SQL to retrieve primary keys and then a loop of findByPrimaryKey() for each key to obtain Local interfaces and it takes about 1-2 seconds per 30 objects. The abovementioned BMP finders would speed things up considerably since it would only take one invocation... That may still takes n+1 DB hits - remember that the BMP finder returns a set of keys - beyond that you're OK if the bean is already in cache (commit option A). If you're doing all this from a session bean (in transaction) it shouldn't be any faster with a BMP finder than what you're doing. Unless I'm missing something big. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
