Re: [JBoss-dev] Why are we using this bogus construct
I'd just like to say that I believe David is exactly right here. I've been following (or rather trying and failing most of the time) the javaMemoryModel (http://www.cs.umd.edu/~pugh/java/memoryModel/) mailing list, and this kind of issue is very difficult to analyse correctly. My advice, FWIW, is to stop messing around and just use util.concurrent by Doug Lea (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html). There aren't many people who can prove that their tricky concurrent Java code is correct, but Doug Lea can. Just use EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap and sleep at night. Toby. On Thu, Feb 13, 2003 at 02:14:28PM -0500, David Jencks wrote: I think the jboss code has the same problem as double checked locking -- described by Joshua Bloch as wildly counterintuitive. ... I don't think localMap has a accurate view of clients unless this is synchronized. Just as with double-checked locking, it can read a partially initialized version of clients. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Let's drop the org.jboss.ejb.DeploymentException
On Thu, Nov 01, 2001 at 07:13:42PM -0800, Scott M Stark wrote: We have two equivalent exceptions org.jboss.deployment.DeploymentException and org.jboss.ejb.DeploymentException. In a number of places we have to catch a org.jboss.ejb.DeploymentException just to rethrow it as a org.jboss.deployment.DeploymentException. Very ugly. I'm going to drop the ejb package version in favor of the more general org.jboss.deployment.DeploymentException version. Speak now or kiss the ejb version goodbye. Yay! I tried to do this ages ago, when I was first writing JBossCX (and introduced org.jboss.deployment.DeploymentException), but ran into a very weird verification problem that I couldn't track down (I think I posted to jboss-dev about it) so I gave up and left them both in there. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Reorganizing connector/jbosscx
On Thu, Sep 06, 2001 at 12:52:51PM -0400, David Jencks wrote: Hi, I'm reorganizing the connector/pool stuff so it makes more sense. Hooray! Here's my proposed directory structure under org/jboss/resource -adapter --jdbccommon (classes shared between 2 jdbc wrapper rar's) --jdbclocal (classes for jdbc non xa wrapper) --jdbcxa (classes for jdbc xa wrapper) Perhaps -adapter --jdbc ---local ---xa ? Not important, on the whole. --jms (soon) I'm not completely sure that I like the actual resource adapters as part of JBossCX. Nah, actually, as long as they're built into separate RARs I don't mind at all. Don't mind me. -connectionmanager --jboss -security (already there) adapter and connectionmanager are moved from pool. So JBossPool still exists and contains the generic object pooling code? I want to make jbosscx contain everything except the adapters (which turn into .rars and are deployed separately). I want to make jbosscx into a .sar containing the mbean configuration for RARDeployer and the 3 connectionmanagerfactoryloaders. Cool. I'm not really happy with the name ConnectionManagerFactoryLoader; it sounds and looks too much like ConnectionFactoryLoader. If you have a better idea for the name of this, please feel free to change it. [As a possible future step I'd like to rewrite the ConnectionManagerFactoryLoader stuff to avoid the x license, share common code, and eliminate the distinction between ConnectionManager and JBossConnectionManager. Maybe even implement the JBossConnectionListener stuff so you don't have to get each connection within a transaction.] I'm not sure what you mean about the X license. CMFL is LGPL. Are you referring to the CMs themselves? JBossConnectionManager only exists so the the Minerva connection managers could be independent of JBoss. Kill kill kill. In a related issue, I'd like to make the hypersonic/defaultds configuration into a hsql-service.xml or possibly a sar including the hypersonic database itself. Sounds good. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (no subject)
On Fri, Aug 17, 2001 at 11:22:51AM -0400, marc fleury wrote: use BMP and access your datasource by name based on the user, or write that code for CMP you are the first to require this. This isn't the first request for this functionality that I've seen. The JCA-based pools are theoretically capable of supporting this. See org.jboss.resource.security.PrincipalMapping in jbosscx (or connector or something, dang newfangled module system). You'd need to implement a mapping that returns a different resource principal for each caller principal. Toby. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Robert Xiong |Sent: Wednesday, August 15, 2001 1:24 AM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] (no subject) | | |Hello, |I am new to Jboss and J2EE. Here is my question: |Since I have to specify the datasource when I deploy |my nean (using CMP), just wondering how can I use the |same bean to access diffrent datasource? In a ASP |model, different user will access different database |schema using the exactly same application. How can we |dynamicly allocate a datasource to the bean based on |the user login? Does Jaws.xml DTD let us to do that? |Thanks for you answer. | |Robert | |= |Robert Xiong |Sr. Software Engineer ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/security ManyToOnePrincipalMapping.java PrincipalMapping.java PrincipalMappingSupport.java
On Sat, Aug 18, 2001 at 09:55:29PM -0700, David Jencks wrote:
User: d_jencks
Date: 01/08/18 21:55:29
Modified:src/main/org/jboss/resource/security
ManyToOnePrincipalMapping.java
PrincipalMapping.java PrincipalMappingSupport.java
Log:
Converted logging to log4j and prettied format
public class ManyToOnePrincipalMapping
- extends PrincipalMappingSupport
-{
+ extends PrincipalMappingSupport {
This isn't right. Please adjust the settings and try prettying again.
It's awful now.
Toby.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Renaming properties in ConnectionFactoryLoader
On Sun, Aug 19, 2001 at 12:17:26PM -0700, Jason Dillon wrote: I would go for clearer names over legacy names. I agree, although ManagedConnectionFactoryProperties is enormously long. I would go for JNDIName over ConnectionFactoryName. Toby. On Sun, 19 Aug 2001, David Jencks wrote: I'd like to suggest that we (I) change some of the attribute names in ConnectionFactoryLoader in jboss.jcml to make it a little clearer what they are for: new old ManagedConnectionFactoryProperties Properties ConnectionFactoryName -- or --JndiName FactoryName I'd also like to do this soon before many people start using them. Any thoughts? david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/security ManyToOnePrincipalMapping.java PrincipalMapping.java PrincipalMappingSupport.java
On Sun, Aug 19, 2001 at 11:15:24PM -0400, David Jencks wrote: Hi Toby, Could you be more specific about what you don't like? I'm having a little trouble seeing the results as awful. Ok, that was a bit harsh, I admit. What I mean is that the results don't conform to the JBoss coding standards. For example, all of the opening braces have been moved onto the previous line rather than being on a line by themselves. Also, there is some weird extra whitespace in some places. What was wrong with the formatting that deserved such a drastic approach? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transition to JCA only - should I commit now?
On Sat, Aug 11, 2001 at 08:40:06AM -0400, David Jencks wrote: On 2001.08.11 01:41:38 -0400 Toby Allsopp wrote: David Jencks wrote: Are there any plausible uses for the RawXADataSourceLoader? Er, putting XADataSource implementations in JNDI? Its purpose is to instantiate and configure a vendor's XADataSource implementation so that the XA JDBC resource adapter can use it to create XAConnections. hmm, the xa ra accepts a DataSourceClass as a parameter, do you know of a configuration that can't be set using just the connection factory loader? Is this intended for subclassing for weirdo xadatasources that require special code to initialize? I'd be somewhat tempted to encourage people to write a special adapter by subclassing XAManagedConnectionFactory instead. Aside from giving the xadatasource to the xa- jdbc-rar, are there any reasons anyone would want to look up an xadatasource in jndi? I was not aware that XAManagedConnectionFactory could instantiate and configure XADataSources, so that completely obsoletes RawXADataSourceLoader. It was initially put there to get the BlackBox example working. Please remove it if you want. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbosspool: implementation of connectionClosed() in org.jboss.pool .connector.BaseConnectionManager$XAListener
On Wed, Aug 01, 2001 at 02:37:45PM +0200, Jung , Dr. Christoph wrote:
I just stumbled over the following piece of code in
org.jboss.pool.connector.BaseConnectionManager$XAListener:
This XA stuff makes my head hurt, but I'll give it a go.
public void connectionClosed(ConnectionEvent evt) {
...
// XAResource is delisted
if(trans != null) {
// Delist if closing before transaction was ended
try {
trans.delistResource(xar, XAResource.TMSUCCESS);
} catch(SystemException e) {
e.printStackTrace();
}
}
...
}
which basically means that a pooled resource is marked RS_ENDED in the
TxCapsule after being asked to end(Xid,TMSUCCESS).
Now imagine that the resource is returned to the pool and dispensed for
another time within the same persistent transaction. This means that
the TxCapsule, when asked to enlistResource(), will not call
start(Xid,TMRESUME) in order to resume the tx association.
I don't follow this. TxCapsule.enlistResource calls
TxCapsule.startResource, which will call start on the resource
no matter what it thinks the state of the resource is. My
reading of the code says that in the scenario you describe
above the resource will receive a start(xid, XAResource.TMJOIN)
call, which is fine, I think.
Wouldn´t it be correct to do a
try {
trans.delistResource(xar, XAResource.TMSUSPEND);
} catch(SystemException e) {
e.printStackTrace();
}
instead, which would cause the state of the resource to become RS_SUSPENDED
in the TxCapsule before returning to the pool and forcing
the IMHO right behaviour ...
The meaning of suspend with regards to XA transactions is very
unclear to me. All I've heard about it is argument (see some old
threads on this list for example).
My, admittedly limited and unclear, understanding is that TMSUCCESS
is correct.
Ole? Aaron?
Toby.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] cvs module dependencies
On Thu, Jul 26, 2001 at 03:42:09PM -0700, Jason Dillon wrote: I am working on a build system proof of concept, that integrates cvs modules as sources instead of binaries. Things are going well, but I have run into a few module dependency issues. Currently there is only one that is causing a problem. There is a circular dependency between jboss and jbosspool: 1) JDBCDataSourceLoader(jboss) depends on JDBCPoolDataSource(jbosspool) 2) XADataSourceLoader(jboss) depends on XAPoolDataSource(jbosspool) I suggest moving the *Loader classes to the jbosspool module (with _no_ package name changes) as the simple short-term solution to this problem. That seems reasonable. The *DataSourceLoader MBeans should be rewritten to be simple wrappers for ConnectionFactoryLoader, at which point they should live in jbosscx. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] cvs module dependencies
On Thu, Jul 26, 2001 at 08:48:14PM -0400, David Jencks wrote: Hi, I'm working on this rewriting. Should I change the package?? Seems like no, these are going to be sort of deprecated anyway, only there for backwards compatibility, so we should keep the package the same. Agreed? Agreed. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-444219 ] Can't add connection factories after rar
[EMAIL PROTECTED] wrote:
Patches item #444219, was opened at 2001-07-24 12:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=444219group_id=22866
Category: JBossCX
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: David Jencks (d_jencks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't add connection factories after rar
Initial Comment:
The current RARDeployer/ConnectionFactoryLoader assumes
that the connection factories are all loaded and
started before the RARDeployer deploys the rar's used
by the connection factory loaders. This means you
can't add more connection factories later. The patch
below fixes this by implementing startService on
ConnectionFactoryLoader to check if the needed rar has
been deployed. If so, it immediately loads the
connection factory, instead of waiting for rar
deployment notification... which will never come.
Good point. I will apply this patch. Thanks.
If requested , I will supply a test class for this change.
Did you really think this wouldn't be requested? :-) Please supply
this, if you'd be so kind.
--PATCH--
It's a good idea to attach the patch as a file to avoid it being
destroyed by mail clients and/or web browsers. Generally unified diffs
are preferred (diff -u).
protected void destroyService()
{
resourceAdapterName = null;
factoryName = null;
properties = null;
rarDeployerName = null;
tmName = null;
cmfName = null;
cmProps = null;
// Principal mapping parameters
princMapClass = null;
princMapProps = null;
rarDeployerObjectName = null;
/** The JNDI name to which this connection factory
is bound */
bindName = null;
cm = null;
}
What is the purpose of this?
Toby.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/lib jboss-deployer.jar
User: tobyallsopp Date: 01/07/25 02:47:46 Modified:src/lib jboss-deployer.jar Log: Patch #444219 from David Jencks ([EMAIL PROTECTED]). Adds support for the addition of connection factory loaders after their resource adapters have been deployed. Revision ChangesPath 1.2 +19 -16jbosscx/src/lib/jboss-deployer.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/build build.xml
User: tobyallsopp
Date: 01/07/25 02:50:51
Modified:src/build build.xml
Log:
Fixed classpath for jboss-deployer.jar (needed log4j.jar).
Revision ChangesPath
1.81 +1 -0 jboss/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/src/build/build.xml,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -r1.80 -r1.81
--- build.xml 2001/07/10 23:59:51 1.80
+++ build.xml 2001/07/25 09:50:51 1.81
@@ -91,6 +91,7 @@
!-- Deployer library build classpath --
path id=deployer.classpath
pathelement location=${build.deployer.classes.dir}/
+ pathelement location=${src.lib.dir}/log4j.jar/
pathelement location=${lib.dir}/jmxri.jar/
/path
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jbosscx.jar
User: tobyallsopp Date: 01/07/25 02:52:41 Modified:src/lib jbosscx.jar Log: Patch #444219 from David Jencks ([EMAIL PROTECTED]). Adds support for the addition of connection factory loaders after their resource adapters have been deployed. Revision ChangesPath 1.5 +99 -94jboss/src/lib/jbosscx.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment DeployerMBeanSupport.java
User: tobyallsopp
Date: 01/07/25 02:52:41
Modified:src/main/org/jboss/deployment DeployerMBeanSupport.java
Log:
Patch #444219 from David Jencks ([EMAIL PROTECTED]). Adds
support for the addition of connection factory loaders after their
resource adapters have been deployed.
Revision ChangesPath
1.3 +31 -3 jboss/src/main/org/jboss/deployment/DeployerMBeanSupport.java
Index: DeployerMBeanSupport.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/deployment/DeployerMBeanSupport.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DeployerMBeanSupport.java 2001/06/18 20:01:21 1.2
+++ DeployerMBeanSupport.java 2001/07/25 09:52:41 1.3
@@ -16,10 +16,16 @@
import org.jboss.util.ServiceMBeanSupport;
/**
- * description
+ * An abstract base class for deployer service implementations.
*
* @author a href=mailto:[EMAIL PROTECTED];Toby Allsopp/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
+ *
+ * pbRevisions:/b
+ *
+ * pb20010725 Toby Allsopp (patch from David Jencks)/b
+ * ulliAdded codegetDeployments/code method so that subclasses
+ * can find out what has been deployed./li/ul
*/
public abstract class DeployerMBeanSupport
extends ServiceMBeanSupport
@@ -128,7 +134,10 @@
*/
protected Object getInfo(URL url)
{
- return deployments.get(url);
+ synchronized (deployments)
+ {
+ return deployments.get(url);
+ }
}
/**
@@ -152,6 +161,25 @@
*/
protected abstract void undeploy(URL url, Object info)
throws IOException, DeploymentException;
+
+ /**
+* Returns the deployments that have been deployed by this
+* deployer. The codeMap/code returned from this method is a
+* snapshot of the deployments at the time the method is called and
+* will not reflect any subsequent deployments or undeployments.
+*
+* @return a mapping from codeURL/code to
+* codeDeploymentInfo/code
+*/
+ protected Map getDeployments()
+ {
+ Map ret = new HashMap();
+ synchronized (deployments)
+ {
+ ret.putAll(deployments);
+ }
+ return ret;
+ }
// Private ---
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource ConnectionFactoryLoader.java RARDeployer.java RARDeployerMBean.java
User: tobyallsopp
Date: 01/07/25 02:47:46
Modified:src/main/org/jboss/resource ConnectionFactoryLoader.java
RARDeployer.java RARDeployerMBean.java
Log:
Patch #444219 from David Jencks ([EMAIL PROTECTED]). Adds
support for the addition of connection factory loaders after their
resource adapters have been deployed.
Revision ChangesPath
1.5 +75 -8 jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java
Index: ConnectionFactoryLoader.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ConnectionFactoryLoader.java 2001/06/20 02:46:00 1.4
+++ ConnectionFactoryLoader.java 2001/07/25 09:47:46 1.5
@@ -49,16 +49,26 @@
import org.jboss.util.ServiceMBeanSupport;
/**
- * Service that configures an instance of a deployed resource
- * adapter and binds the resulting connection factory into JNDI.
+ * Service that configures an instance of a deployed resource
+ * adapter and binds the resulting connection factory into JNDI.
*
- * p This service does nothing until it receives a notification
- * from the RAR deployer that the resource adapter has been
- * deployed.
+ * p This service does nothing until the RAR deployer indicates that
+ * the resource adapter has been deployed. If the resource adapter is
+ * deployed prior to this service being started then the connection
+ * factory is loaded immediately, otherwise notification from the RAR
+ * deployer is waited for.
*
- * @see RARDeployer
- * @author Toby Allsopp ([EMAIL PROTECTED])
- * @version $Revision: 1.4 $
+ * @see RARDeployer
+ * @author a href=[EMAIL PROTECTED]Toby Allsopp/a
+ * @version $Revision: 1.5 $
+ *
+ * pbRevisions:/b
+ *
+ * pb20010725 Toby Allsopp (patch from David Jencks)/b
+ * ul
+ * liSupport the case of the resource adapter being deployed
+ * before this service is started
+ * /ul
*/
public class ConnectionFactoryLoader
extends ServiceMBeanSupport
@@ -165,6 +175,63 @@
new RAFilter(log), null);
log = Log.createLog(factoryName);
+ }
+
+ protected void startService()
+ throws Exception
+ {
+ // If this factory has not already been loaded...
+ if (!cfs.containsKey(factoryName))
+ {
+ // ... and the RAR deployer exists...
+ if (server.isRegistered(rarDeployerObjectName))
+ {
+Object[] args = new Object[] { resourceAdapterName };
+String[] sig = new String[] { java.lang.String };
+RARMetaData rmd = (RARMetaData) server.invoke(
+ rarDeployerObjectName, getMetaData, args, sig);
+// ... and the RAR has been deployed...
+if (rmd != null)
+{
+ // ... then load the connection factory immediately
+ // because we have missed notification of the RAR's
+ // deployment
+ loadConnectionFactory(rmd);
+}
+ }
+ }
+ }
+
+ protected void stopService()
+ {
+ // If this factory has been loaded...
+ if (cfs.containsKey(factoryName))
+ {
+ try
+ {
+// ... and the RAR deployer exists...
+if (server.isRegistered(rarDeployerObjectName))
+{
+ Object[] args = new Object[] { resourceAdapterName };
+ String[] sig = new String[] { java.lang.String };
+ RARMetaData rmd = (RARMetaData) server.invoke(
+ rarDeployerObjectName, getMetaData, args, sig);
+ // ... and the RAR has been deployed...
+ if (rmd != null)
+ {
+ // ... then unload the connection factory
+ // immediately because we won't be around to receive
+ // notification of the RAR's undeployment
+ unloadConnectionFactory(rmd);
+ }
+}
+ }
+ catch (Exception e)
+ {
+log.error(Problem stopping ConnectionFactoryLoader service:);
+log.exception(e);
+ }
+ }
}
// NotificationListener implementation ---
1.4 +30 -41jbosscx/src/main/org/jboss/resource/RARDeployer.java
Index: RARDeployer.java
===
RCS file: /cvsroot/jboss/jbosscx/src/main/org/jboss/resource/RARDeployer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- RARDeployer.java 2001/05/05 07:12:46 1.3
Re: [JBoss-dev] [ jboss-Patches-444219 ] Can't add connection factories after rar
On Wed, Jul 25, 2001 at 09:17:48AM -0400, David Jencks wrote:
Thanks, Toby,
see below.
On 2001.07.25 05:36:00 -0400 Toby Allsopp wrote:
[EMAIL PROTECTED] wrote:
If requested , I will supply a test class for this change.
Did you really think this wouldn't be requested? :-) Please supply
this, if you'd be so kind.
Well, some of my other patches have been ignored, its hard to want to go to
the effort of writing an ignored test class too ;-)
This patch would be much easier to write a test case for if my previous
patch was also accepted, #443701, this makes it easy to add/remove mbeans
via jcml configuration mini-files. Do you thing there is any chance it
will be accepted?
Ah, I see. I thought that had been applied, but I see now that it hasn't.
I'd apply it, but I don't have the time to test it (or fully understand
it) right at the moment.
Personally, I think the best way to proceed is for Marc to give you
CVS commit access. Marc, you listening?
protected void destroyService()
{
resourceAdapterName = null;
factoryName = null;
properties = null;
rarDeployerName = null;
tmName = null;
cmfName = null;
cmProps = null;
// Principal mapping parameters
princMapClass = null;
princMapProps = null;
rarDeployerObjectName = null;
/** The JNDI name to which this connection factory
is bound */
bindName = null;
cm = null;
}
What is the purpose of this?
Do you know what destroy is conceptually supposed to do? Is there a
reference explainging this? Most mbeans seem to do nothing. I think the
result should be the bean can't be restarted and should be unregistered
from the mbean server. Maybe this is a bad idea?
The only idea I have is that destroy is meant to undo what was done in
init. I don't see any value in deliberately making things broken in
case the world goes mad. Perhaps someone else has more to add here.
Toby.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossCX use of Mbeans
On Wed, Jul 18, 2001 at 03:38:29PM -0400, Jay Walters wrote: Do I need an MBean for each connector which I'm deploying to JBossCX (maybe I'm really confused here)? It seems that this is how the two which are distributed with the standard JBoss release are configured. Is this how it works right now? Is there some reason that it needs to be this way? The way it currently works is that you need an MBean for each connection factory you want to have in JNDI, just like you need an MBean for each JDBC connection pool. It would be nice to be able to set up the connection factory as part of an EAR, e.g. using a jboss-application.xml file. I think I left some commented out code in RARDeployer.java that looks for a jboss-ra.xml file in the RAR and treats it like an excerpt from jboss.jcml. I think this approach is alright, but perhaps we should define a general mechanism for an application to contain an MBean configuration that is started when the app is deployed and stopped when it is undeployed. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] J2EE Connector spec
On Tue, Jul 17, 2001 at 10:17:31AM +0200, Tomasz Skutnik wrote: Hi ! I'd like to know what is the policy of JBoss J2EE interfaces development ? My problem is that I'm implementing WebDAV connector using J2EE connector specification (PFD2 - Proposed Final Draft - 05 April 2001, acquired from www.jcp.org), but JBoss jboss-j2ee.jar contains classes with outdated interfaces (according to this spec). My question is : What's the JBoss policy of implementing (or keeping up-to-date) with specs ? Are we going to move to newer spec (although it's still only PFD) or wait for official release ? I'm not aware of any general policy on this, but I'd imagine that the idea is to keep as up to date as possible in the main CVS branch. Updating JBossCX to PFD2 is something I've been intending to do for a while (I even logged a job-thingy at SourceForge to remind myself). I've had other priorities for a while (and will continue to have them for a while longer, I hope). Taking that we try to follow specs as fast as possible (even PFDs/Drafts etc.) should I post diffs to patch jboss-j2ee.jar sources (removed 4 methods from javax.resource.cci.ConnectionFactory interface, few changes in org.jboss.RARDeployer to take deployment descriptor changes into account, and possibly modifying DDs of existings connectors) ? Of course there'll be impact on existing deployment/connector code/DDs, but it should also be quite simple. I don't think it's necessary to worry too much about backward compatibility in the main CVS branch. You'd need to update the jboss-j2ee interfaces, the JBossCX stuff and the bundled resource adapters (the JDBC ones from JBossPool and the JMS one from wherever its source is). If you want to do this, I'd be grateful. Submit a patch to SourceForge and I'll try to find time to review and commit it. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fetch size and JBossPool and Jaws
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. Toby. ___ 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 JDBCCommand.java
On Wed, Jun 27, 2001 at 02:32:01PM -0400, Bill Burke wrote: I'm pretty sure that the jbosspool stuff(org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl) will give back the same Connection with every ds.getConnection() while within the same transaction. Thus, with the current code base, you cannot do connection.setIsolationLevel at the JAWS level. This may be different with the JCA stuff though. Can somebody elaborate? Nope, it should be the same, i.e. access within a transaction will share the same connection. The JBossPool JCA resource adapter is just the existing connection pool logic wrapped in the JCA interfaces. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shouldn't expose transaction-isolation within CMP
On Tue, Jun 26, 2001 at 04:21:12PM -0400, Bill Burke wrote: Any way, I think I should roll back my change. If you agree marc, just say so and it is done. I don't know any thing about Minerva, so if you want that changed, someone else would be better suited. If no one wants to do it, I'll look at it. -dain I know what to do for Minerva(aka org.jboss.pool.jdbc, correct?) and can put these changes in. But I really wouldn't know what to do with JCA, that is, if a change is required there as well. I think that this is a sane thing to add to JBossPool. It is unrelated to JCA as it is a JDBC-only thing. It would be a configuration option for the resource adapter if you were using a JDBC resource adapter. There is a JDBC resource adpater in JBossPool. I can't recall exactly how it is configured, but I think that it is passed a set of properties that are passed straight through to the underlying pool, so it might be possible to make no changes to the resource adapter in order to take advantage of the isolation level setting. I say make the change to the JDBC pooling code and I'll look at the resource adpater implications when I get around to spending time on JBoss again (at which point I'll remove direct access to the pools and make it purely JCA based). Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug 424768
On Mon, Jun 25, 2001 at 04:42:05PM +0200, Burkhard Vogel wrote: Hi, I would love to fix this bug, however I can' t get an insight of org.jboss.bool (I tried a couple of hours), still I would really need a fix for it, as I relay of scrollable ResultSets, unfortunately noone has touched anything of org.jboss.pool code... I really hoped some bugs would get fixing in 2.4 release. The lack of changes to JBossPool is somewhat my fault. I haven't been spending much time on JBoss recently so there is now something of a backlog of JBossPool and JBossCX changes that I want to make. I'm too lazy to look up bug whatever, but I assume it's something to do with scrollable ResultSets. I seem to recall that this was a simple matter of passing extra arguments through to the statement or something. This is going to sound a bit nasty, but if you won't fix the bug yourself then quit complaining. This is the developer list, not the paid support list. The JBossPool code isn't that hard to understand. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fixed very small problem with ConnectionFactoryLoader
On Wed, Jun 20, 2001 at 02:22:16PM -0700, Jason Dillon wrote: Get rid of the version number. Make sure that the CVS tags are in synch between the jboss and jbosscx modules. Whenever you update the jbosscx.jar in jboss, there should be a tag in both modules so that you can always obtain the jbosscx source from which the jbosscx.jar was created. Do you have a suggested scheme for the tags, or a system for tagging? Follow the steps detailed on the web site, i.e. add a tag to the jboss module when you update the jar file. Add a tag with the same name to the jbosscx module when you do this. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/etc class.java interface.java
Toby Allsopp wrote: On Mon, Jun 18, 2001 at 09:49:57PM -0400, Bill Burke wrote: Does anybody use emacs? We should have a java-mode specific to jboss. Does anybody *not* use emacs? They wouldn't admit it anyway. Unless they use vi. I have a jboss style from when the standard was 3 spaces. If there's interest I can post it (when I get home) along with instructions on how to automatically activate it when editing JBoss sources. Ok. As promised, here is the jboss style: (c-add-style jboss '(java (c-basic-offset . 3) (c-offsets-alist (substatement-open . 0) (arglist-intro . + This can be activated by the function c-set-style. This is bound to C-c . by default. The method I use for using this style automatically when working on JBoss is to define a new major mode. I use the JDE (http://jde.sunsite.dk/), so this is based on jde-mode, but you could base it on java-mode just as easily. (defun jboss-jde-mode () JDE mode with JBoss coding style (interactive) (jde-mode) (c-set-style jboss)) (setq auto-mode-alist (cons '(/jboss/.*\\.java$ . jboss-jde-mode) auto-mode-alist)) This means that whenever you open a java file with jboss as part of its path you will get the new mode. You should probably pick a regex that works for you because this won't work for any modules that don't have a directory called jboss on the way to the source. If you do all of your JBoss development out of /home/toby/cvs-jboss, for example, you might want to change that regex to ^/home/toby/cvs-jboss/.*\\.java$. Toby. P.S. I'm not volunteering to give emacs support to anyone, I'm sorry. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fixed very small problem with ConnectionFactoryLoader
On Tue, Jun 19, 2001 at 07:55:05PM -0700, Jason Dillon wrote: Hello, I ran into a problem with ConnectionFactoryLoader PrincipalMappingProperties was not set or when it was set like this: attribute name=PrincipalMappingProperties/attribute This would cause the princMapProps to remain a null, and cause a NullPointerException when loading. I set it to default to which fixes this problem. Fair enough. I think I did domething similar for another attribute a while back. I am sending this because I am not really sure what the procedure is for updating the jbosscx-*.jar in the jboss module. There is some versioning there and I am not really sure if that should change or not. Ah, yes. The version number really shouldn't be there, I've decided (or been persuaded). If you want to replace the versioned jar with just plain jbosscx.jar I'd be grateful. Anyways, the change is small and if folks set PrincipalMappingProperties to a non-null or something with a new line it will work fine. I am currious if the ConfigurationService should be modified to deal with this. I think so, but I am not 100% sure. It seems to me that if there is an attribute/ in jboss.jcml that the service should call the setter even if the value is . Currently if the value is , the attribute's setter will not be called. It seems like a good idea to call the setter even if the value is the empty string, like you say. Should I update the jbosscx-*.jar in jboss or leave it for the name major integration? Get rid of the version number. Make sure that the CVS tags are in synch between the jboss and jbosscx modules. Whenever you update the jbosscx.jar in jboss, there should be a tag in both modules so that you can always obtain the jbosscx source from which the jbosscx.jar was created. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/etc class.java interface.java
Ok, I'm failing to stay out of this argument once again. Crap.
On Mon, Jun 18, 2001 at 08:36:52AM -0700, [EMAIL PROTECTED] wrote:
/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
+* JBoss, the OpenSource EJB server
+*
+* Distributable under LGPL license.
+* See terms of license at gnu.org.
+*/
Huh? Why?
package x;
+//EXPLICIT IMPORTS
+import a.b.C1; // GOOD
+import a.b.C2;
+import a.b.C3;
+// DO NOT WRITE
+import a.b.*; // BAD
No argument on this.
+/**
+* description
+*
+* @see related
+* @author a href=mailto:{email};{full name}/a.
+* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
+* @version $Revision: 1.4 $
+*
+* Revisions:
+*
+* mmdd author: explicit fix description (no line numbers but methods) go
beyond the cvs commit message
+* eg:
+* 20010516 marc fleury: Ask all developers to clearly document the Revision,
changed the header.
I'm not going to repeat the argument we had a while back about this, but I
still believe that this is a Very Bad Idea. It will not be maintained because
it's duplication of work that people already do when they write CVS commit
logs.
Here's a solution to your perceived problem of not having access to the CVS
history when offline: maintain a local mirror of the CVS repository on
your machine.
Also, if you are going to do this, put some HTML in there so that the
javadocs are readable.
+// DO NOT USE TAB TO INDENT CODE USE *2* SPACES FOR PORTABILITY AMONG EDITORS
Ok, fine. Why *2* spaces all of a sudden? AFAIK, all of the existing code
is 3 or 4 spaces. In some ways, TABs are better for editor portability
because people can choose the width of the TABs that they prefer. I prefer
spaces, however, so I'm not going to argue.
It seems to me that if the goal is to make it as easy as possible for people
to contribute to JBoss then there should be an absolute minimum of red tape
and bizzarre coding standards.
Toby.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/etc class.java interface.java
On Mon, Jun 18, 2001 at 09:49:57PM -0400, Bill Burke wrote: Does anybody use emacs? We should have a java-mode specific to jboss. Does anybody *not* use emacs? They wouldn't admit it anyway. Unless they use vi. I have a jboss style from when the standard was 3 spaces. If there's interest I can post it (when I get home) along with instructions on how to automatically activate it when editing JBoss sources. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/etc class.java interface.java
On Tue, Jun 19, 2001 at 04:19:23AM +0200, Georg Rehfeld wrote: Hi, How about using the Java Coding Standard by Sun? yes, most people have seen that, it's easy to get by looking at http://java.sun.com/docs/codeconv/, many people already follow it. other open source projects ... have been mostly 4 (spaces). yes, 4 columns indent clearly, everything hanging after column 128 should be considered bad coding style. Most editors CAN do spaces, Ack! I spit on you and challenge you to a duel!! There are only 80 columns!!! Anything past column 80 cannot be read Seriously, where does 128 come from? 80 is something of a legacy that is not so relevent any more but it's a reasonable LCD, IMHO. Toby. (in a flame-starting mood today :-) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is Monday still a good 2.4 freeze date
Vesco Claudio wrote: My patches to implement JCA deployment are applied? :-) I thought you were getting RW access and were going to do it yourself? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] minerva-1_0b3.jar missed in JBoss 2.3 beta?
Further to this, see Change Note #424377 (http://sourceforge.net/tracker/index.php?func=detailaid=424377group_id=22866atid=381174). Toby. On Thu, May 31, 2001 at 09:38:57AM -0500, danch (Dan Christopherson) wrote: Minerva has been forked. JBoss (2.3 or later) now uses JBoss-pool, source for which is in CVS at sourceforge. Darius Davidavicius wrote: After i compiled last source code of Jboss server i have found minerva-1_0b3.jar is missed in dist/lib/ext If it is removed? What is replacment for it? if for Jboss 2.1 i was getting oraclePoll like: mbean code=org.jboss.jdbc.XADataSourceLoader name=DefaultDomain:service=XADataSource,name=oraclePool attribute name=PoolNameoraclePool/attribute attribute name=DataSourceClassorg.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl/attribute Thanks for reply in advance, Darius D ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss pool (former Minerva) transaction bug?
On Thu, May 31, 2001 at 04:32:56PM -0400, Anatoly Akkerman wrote: The subordinate transactions (on server2 and server3) call commit() on their datasources and return their votes to the main coordinator. The coordinator based on the votes takes a heuristic decision on what to do about the completion of this transaction. If there were no errors reported, the TM decides to complete the commit heuristically. So, it does not throw any exceptions, but tries to tell all the subordinates to forget() the transaction. This indicated that the last request (commit()) was accepted by everybody and everybody can now forget about this transaction. I don't see how this can work. What happens if one of the subtransactions fails? I would have thought that the originator would need to use some kind of two-phase protocol to make sure that all of the subtransactions are prepared successfully before asking any of them to commit. My mistake, of course it calles prepare() and gets the votes then calls the commit() and makes a heuristic decision on whether to finish off with forget() or to rollback() and then forget(). I am not currently looking at the Tyrex source and I am not a transaction specialist myself, so I don't remember all the details off hand. This still doesn't make sense to me, but this conversation isn't getting anywhere. I'm not going to spend the time necessary to fully understand this, so I'll leave it to you and any distributed transaction experts that pop up. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss pool (former Minerva) transaction bug?
On Wed, May 30, 2001 at 07:19:26PM -0400, Anatoly Akkerman wrote: Hello everybody Hello. I guess I should attempt to field this. I am running into problems with JBoss pools and Tyrex. This time it is a 2pc hueristic commit issue. Great. A wurble-munging wickety booger. When Tyrex commits a distributed transaction in 2pc, it asks all the subordinate transactions to commit which ask their local XAResources to commit. Minerva on a commit call disassociates itself from the transaction (sets current to null). Are you talking about Minerva's XADataSource implementation (org.jboss.pool.jdbc.xa.wrapper.XA*)? This implementation is just a wrapper for non-XA JDBC drivers so that they can participate in transactions managed by a JTA transaction manager. It doesn't magically give these drivers the ability to handle 2pc correctly. I'm not sure what scenario exactly you're testing, but if you're using the wrappers then you should not have more than one resource enlisted in the transaction. Tyrex upon getting successful commits from the XAResources, being in 2pc sets heuristic to COMMIT and asks the XAResources to forget() the transaction. I don't understand what JTA is talking about with heuristic this and that. It seems like a mechanism for dealing with strange situations or something. What is Tyrex trying to achieve with this heuristic stuff? What do you mean by sets heuristic to COMMIT? Minerva throws an exception because it already disassociated itself from the transaction (i.e. current == null while id is not null). Also, minerva assumes that the forget() is always called when a commit() or rollback() have failed. Well, this is not really true, forget can get called during a heuristic commit as in the case described above. This may well be a problem with Minerva/JBossPool, but the wrappers really aren't meant to handle anything complicated. Anyone can suggest to me where I could find out what is the correct semantics of the API? I've tried the jta spec but could not see anything conclusive. Any idea how minerva should handle this properly? The JTA spec is all I have to go on. It refers to the X/Open XA spec, but that's not free. Also, as a side issue, the jta spec says that the XAResources should support sharing (3.4.6) which seems to be lacking from the minerva (JBoss pool) implementation? Am I making a mistake here? You are correct, it's not supported. It's a wraper for JDBC connections, don't forget, not an actual XAResource implementation. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] 113th Try: Scoped J2EE Applications ... Please ve rify these few p ending diffs to org.jboss.deployment !
Jung , Dr. Christoph wrote: main branch means ... head revision, no tags or something? Any special command-line options for cvs? I´m not used to cvs anymore since we switched to perforce (no more strange effects if you accidently copy a directory including CVS folders ;-) Yeah, just the default branch, no -r flags, no tags. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 113th Try: Scoped J2EE Applications ... Please verify these few p ending diffs to org.jboss.deployment !
On Thu, May 17, 2001 at 07:17:34PM +0200, Jung , Dr. Christoph wrote: Hi there, I know that this *seemingly* theoretical topic appears every now and then on this list and people were already murmuring about the strange ideas that Marc, Rickard, Toby and me were hallucinating, but never found their way into the codebase. I though that it´s time to change that ;-) I´ve trashed all the ill prototypes that I´ve done and that were not quite intelligible (thx Marc and Toby at least for trying to understand that garbage). I actually quite liked it. Oh well. Instead, I´ve done a minimally invasive extension to the J2eeDeployer that comes already quite close to the component model that we use here at infor. I still want to see that whole mess rewritten, but I guess I should either do it myself or shut up about it. I say go ahead and commit your changes (on the main branch), preferably with some tests. Having tests will mean that rewriting the deployment stuff at some point in the future will be easier. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jar hierarchy
On Thu, May 17, 2001 at 08:29:17PM +0200, Peter Fagerlund wrote: In what jar file is org.jboss.jdbc located - I need to do a test run with the 2.2.1 binary distro. I added a stopService() method in the HypersonicDatabase.class that will be called by the MServer. jboss.jar, I think. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jar hierarchy
On Fri, May 18, 2001 at 03:55:50AM +0200, Georg Rehfeld wrote: Hi all, Peter Fagerlund asked: In what jar file is org.jboss.jdbc located - I need to do a test run with Toby Allsopp answered: jboss.jar, I think. yes, there it is. Please don't call me a Spammer, but may I suggest a shareware tool for the W98/NT/W2K users which helps me a lot in my daily work: 'Windows Commander' (http://www.ghisler.com/). The reason I name it here is: it can easily made to search all sorts of archives including Java JARs for files and contents of files. Archive and ftp handling is seemlessy integrated and the usability is tuned to the last keystroke, it's a really superb replacement against the explorer :-) If anybody is interested how to set up WC to search Java JAR archives, I can explain. #!/bin/sh for jarfile in `find $JBOSS_HOME -name '*.jar'`; do unzip -l $jarfile | fgrep -s org/jboss/jdbc echo $jarfile done You could do this with single find command, but it's ugly. If you're interested in this amazing tool, I can offer you a very competitive price :-) Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ResultSet.TYPE_SCROLL_INSENSITIVE second part
On Wed, May 16, 2001 at 10:09:14AM +0200, Oscar Radio wrote:
I'm trying to put a preparedStaement in TYPE_SCROLL_INSENSITIVE, but I
can't, looking in the source code of the pool I find this:
In the org.jboss.pool.jdbc.xa.XAClientConnection class:
public Statement createStatement(int resultSetType, int
resultSetConcurrency) throws SQLException {
if(con == null) throw new SQLException(CLOSED);
try {
StatementInPool st = new
StatementInPool(con.createStatement(resultSetType, resultSetConcurrency),
this);
statements.add(st);
return st;
} catch(SQLException e) {
setError(e);
throw e;
}
}
public PreparedStatement prepareStatement(String sql, int resultSetType,
int resultSetConcurrency) throws SQLException {
return prepareStatement(sql);
}
public PreparedStatement prepareStatement(String sql) throws
SQLException {
if(con == null) throw new SQLException(CLOSED);
try {
PreparedStatement ps =
(PreparedStatement)preparedStatementCache.useObject(sql);
if(ps == null)
throw new SQLException(Unable to create
PreparedStatement!);
PreparedStatementInPool wrapper = new
PreparedStatementInPool(ps, this, sql);
statements.add(wrapper);
return wrapper;
} catch(SQLException e) {
setError(e);
throw e;
}
}
This means that I can't make a preparedStaement TYPE_SCROLL_INSENSITIVE, but
I can do it with a createStatement?
It sure looks that way. I believe that the prepared statement cache is a
little misguided in some situations. Please log this as a bug at
SourceForge.
It is likely that the ability to disable the statement caching will be
implemented before this is fixed, so that should provide a work-around.
Toby.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-422932 ] connector module for J2eeDeployer
On Thu, May 10, 2001 at 01:11:45AM -0700, [EMAIL PROTECTED] wrote: Patches item #422932, was updated on 2001-05-10 01:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=422932group_id=22866 Category: JBossServer Group: v2.3 (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Claudio Vesco (cazzius) Assigned to: Nobody/Anonymous (nobody) Summary: connector module for J2eeDeployer Initial Comment: Hi! This is a patch file which permit the deployment of connector modules in EAR applications (application_1_3.dtd) You're a braver man than I. That J2eeDeployer code is horrible. Thanks for doing this. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: R: R: R: [JBoss-dev] CX + Castor
On Tue, May 08, 2001 at 09:29:38AM +0200, Vesco Claudio wrote: On Mon, May 07, 2001 at 05:39:30PM +0200, Vesco Claudio wrote: Problems: where is called org.opentools.minerva.connector.*ConnectionManager.enlistExistingConnect ion - I cant reuse an existing connection :-( The enlistExistingConnection method is part of the contract that will allow the same connection handle to participate in multiple transactions. This functionality is not currently implemented; it is on my to do list. What this means is that, for the moment, you must obtain a connection handle in the context of transaction in which you wish to use it. I think that this is a good practice in general anyway, but reusing a single connection handle is more convenient to code. javax.resource.spi.ManagedConnection.associateConnection never called :-) I cant share an already open connection :-( I'm not sure what you mean by this. Are you happy or sad about it? Can you describe the behaviour that you are seeing and then the behaviour that you would like to see? The 2 problems are correlated I think. My reference is the spec, in particular 6.11 Connection Association, but I must reread the spec public draft 2 (I only read pd1). I this moment I have another problem with jca-castor integration, when I have time, I analize better your to do list :-) - in these days I dont like to sleep too much :-) The current implementation is based on pfd1. If it is more compliant with pfd2 then that's purely accidental. There aren't many changes between pfd1 and pfd2, but there are some to do with connection association. Please let us know what you find. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] resource-ref resource-managers in jboss.xml
Scott M Stark wrote: Ok, I see some utility in that although a global search/replace is still easier for my money. It would be easy to allow for direct specification of the jndi binding under the session/resource-ref element via a jndi-name element while still allowing for the use of the resource-name indirection if desired. The content model would change from: !ELEMENT resource-ref (res-ref-name , resource-name) to !ELEMENT resource-ref (res-ref-name , (resource-name | jndi-name | res-url)) Sounds good to me. Maybe that will stem the flow of questions about this on jboss-user. Toby. My understanding is that the purpose of the double indirection is to make the case where you have many beans and many resources in the the one file more manageable. res-ref-name describes what the resource *does* resource-name describes what the resource is *called* res-jndi-name describes where the resource is *located* During development all of your resource might be located in the one DBMS, e.g. HSQL or something. In production you might choose to separate the inventory database to an external Oracle instance, but leave the product and accounts databases running somewhere else. I agree that the double indirection causes a lot of confusion. Perhaps we can make it optional? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: R: R: [JBoss-dev] CX + Castor
Vesco Claudio wrote: Thank you for the commiting... I have some problems to integrating Castor with jboss (minerva problems?)... Now I can deploy and redeploy rar with classloader isolation: I can add table, remove table in the ejb part and I redeploy the rar and I see the new access to db by Castor, jboss is always up and running ;-) There is some problems with reelinsting the resources + and shared connections :-( I think this is a minerva problem. I see and I kill these problems today :-) I'm very interested to hear about any problems you have with JBossCX or Minerva. I can't quite tell from the above whether you've resolved the problems or not, but please describe them either way. Toby. Hi, Claudio PS: my society is oriented to use a jdo implementation for implementing a rule system. I know there is another project, jbossrule, but I dont like too much. I'm sure you'll be called upon to explain that comment! :-) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: R: R: R: [JBoss-dev] CX + Castor
On Mon, May 07, 2001 at 05:39:30PM +0200, Vesco Claudio wrote: Problems: where is called org.opentools.minerva.connector.*ConnectionManager.enlistExistingConnect ion - I cant reuse an existing connection :-( The enlistExistingConnection method is part of the contract that will allow the same connection handle to participate in multiple transactions. This functionality is not currently implemented; it is on my to do list. What this means is that, for the moment, you must obtain a connection handle in the context of transaction in which you wish to use it. I think that this is a good practice in general anyway, but reusing a single connection handle is more convenient to code. javax.resource.spi.ManagedConnection.associateConnection never called :-) I cant share an already open connection :-( I'm not sure what you mean by this. Are you happy or sad about it? Can you describe the behaviour that you are seeing and then the behaviour that you would like to see? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.properties, let's deprecate it
On Mon, May 07, 2001 at 09:07:54PM -0400, marc fleury wrote: ok, there are a few things in JBoss properties that we need to remove. In the push to have a clean web install, we must not have anything in file system. Right now we still have this... ... That I believe is the hack from Aaron to get Oracle working? how do we integrate that in the JCA stuff? #jboss.xa.xidclass=oracle.jdbc.xa.OracleXid I believe that this is used by the transaction manager, not the connection pools, so it's not related to JCA. I see no reason for it to be in jbosss.properties rather than as an attribute on the TransactionManagerService. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.properties, let's deprecate it
On Mon, May 07, 2001 at 10:57:49PM -0400, marc fleury wrote: | That I believe is the hack from Aaron to get Oracle working? how do we | integrate that in the JCA stuff? | #jboss.xa.xidclass=oracle.jdbc.xa.OracleXid | |I believe that this is used by the transaction manager, not the connection |pools, so it's not related to JCA. I see no reason for it to be in |jbosss.properties rather than as an attribute on the |TransactionManagerService. Fair enough, it is Ole's domain? for some reason I remember Aaron getting something to work with it back in his Olliance days, could be wrong. I am not saying it is not useful (quite the contrary) just that this is the wrong place to define it. It should be in a jcml file, do you want to take a crack at it? Yeah, I think Aaron and Ole are the ones who understand the significance of it. I'll take a look and see what's involved in moving it. Toby. Note to self: actually do this. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] resource-ref resource-managers in jboss.xml
On Sun, May 06, 2001 at 08:03:42PM -0700, Scott M Stark wrote: We use a double indirection layer to resolve the JNDI name for an ejb-jar/resource-ref element and I don't see why this can't be handled by a single layer. For example, given a javax.sql.DataSource reference in an ejb-jar like ejb-jar enterprise-beans session ejb-nameTheSession/ejb-name ... resource-ref res-ref-namejdbc/MyDS/res-ref-name res-typejavax.sql.DataSource/res-type res-authContaner/res-auth /resource-ref /session /enterprise-beans /ejb-jar requires a jboss.xml descriptor like the following to map this to java:/DefaultDS jboss enterprise-beans session ejb-nameTheSession/ejb-name resource-ref res-ref-namejdbc/MyDS/res-ref-name resource-nameDefaultDS/resource-name /resource-ref /session /enterprise-beans resource-managers resource-manager res-class=javax.sql.DataSource res-nameDefaultDS/res-name res-jndi-namejava:/DefaultDS/res-jndi-name /resource-manager /resource-managers /jboss But the resource-managers/resource-manager really only specifies res-jndi-name value. Why not simply allow the following and drop the use of resource-managers? My understanding is that the purpose of the double indirection is to make the case where you have many beans and many resources in the the one file more manageable. res-ref-name describes what the resource *does* resource-name describes what the resource is *called* res-jndi-name describes where the resource is *located* During development all of your resource might be located in the one DBMS, e.g. HSQL or something. In production you might choose to separate the inventory database to an external Oracle instance, but leave the product and accounts databases running somewhere else. I agree that the double indirection causes a lot of confusion. Perhaps we can make it optional? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RFC: Add isolation level attribute in jboss.xml or jaws.xml?
danch wrote: 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)? What do mean by cover BMP and CMP entities as well as sessions? This can only apply to JDBC connections, right? Do you propose to set the isolation level when a connection handle is obtained by the bean? If so, this should probably be implemented using the same mechanism I have in mind to implement beans hanging onto connection handles across transactions. JBossCX defines the JBossConnectionListener interface for this purpose, although it is not currently used. The idea is that when a resource adapter gives out a connection handle, the app server is notified so that it can make sure it is participating in the correct transaction. It would be easy to extend that to any transaction-specific setup we wanted to do. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss bug or Tyrex bug or neither?
On Thu, May 03, 2001 at 05:46:47PM -0400, Anatoly Akkerman wrote: Hello, gurus I am still in the process of integrating Tyrex DTM with JBoss and here is my current challenge: I am trying to run Petstore in JBoss+Tyrex and running into problems, so I trace the same execution of Petstore in pristine JBoss with its native TM. Here is what I found. Petstore uses BMP Entity Beans and JBoss uses transaction synchronization objects to manage committing the changes to the database. What I found out, is that Tyrex commits transactions in a slightly different order than JBoss does. JBossTM order: 1) doBeforeCompletion() -- this invokes the sync objects and commits into the database 2) endResource() 3) change transaction status to COMMITTED when necessary Tyrex order: 1) set transaction status to COMMITTING 2) call beforeCompletion() -- this invokes the sync objects and causes an exception when EntitySynchronizationInterceptor tries to store the Entity bean and Minerva XAResource tries to enlist itself with the transaction which is now COMMITTING -- and IllegalStateException 3) the rest is irrelevant So, what are we to do here? It seems that Tyrex is not making any mistakes. Perhaps, we need to enlist the resource in advance with this transaction? According to my reading of the JTA spec, this is a Tyrex bug. AFAICT, enlisting a resource in beforeCompletion() should be fine. The relevent text from the documentation for the Synchronization interface is: The beforeCompletion method is called by the transaction manager prior to the start of the transaction completion process. This call is executed with the transaction context of the transaction that is being committed. The enlistResource method of Transaction says that it throws an IllegalStateException if: ... the transaction in the target object is in prepared state or the transaction is inactive. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Any objections to cut over to jboss-j2ee jars in main branch
Jay Walters wrote: Well how about jboss-j2ee.jar and jboss-jdbc-ext.jar? I am open to other suggestions as well... Sorry, the j2ee.jar you mention must be from the J2EE RI? I've never used it... Yes. Lucky you. j2ee.jar is anathema to JBoss. jboss-j2ee.jar works for me. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Any objections to cut over to jboss-j2ee jars in main branch
On Thu, Apr 26, 2001 at 06:47:36AM -0400, Jay Walters wrote: It looks like the jboss-j2ee stuff works defined as jboss compiles and runs my beans. I will run the jbosstest suite again and if all works I'd like to start going through all the sub-projects and replacing the sun jars with ours. Any objections? Nope, as long as you don't call any of the jars j2ee.jar. I can just imagine all of the I replaced your j2ee.jar with a newer one from Sun... questions. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Coding standards
I tried this a while back and ended up starting a flame war. The outcome was basically that if you code something, code it how you like. If you're maintaining something, leave it as it is unless you really hate it. While it's possible to get into indenting wars with this, I don't really see a problem. As far as I'm concerned, the only hard and fast rule is: either use only tabs or only spaces for indenting. You'll need to convince everyone that there is a problem before you can tell people how to indent their code. Toby. Jason Dillon wrote: Hello again, Over the past few months I have been looking over some different areas of the JBoss source and have found that the style and conventions in use are wildly divergent. I think that this project (and really any project were there are multiple developers involved) can benefit greatly from a common set of coding standards. ... ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Distributed Transaction Manager support (coming up)
Anatoly Akkerman wrote: Hi, For the past couple of weeks I've been integrating Tyrex DTM (tyrex.exolab.org) into JBoss. Things are coming along and in a few days I'll probably have a basic support for transaction propagation across 2 JBoss instances. I was wondering, how should I make my mods available (the code is really alpha) for the people who want to start working on it. The code also requires changes to the current JBoss implementation (in particular, TxInterceptorCMT and TxInterceptorBMT would rely on javax.transactions.TransactionManager interface to manage transactions, instead of using JBoss extensions to the API for thread association/disassociation. If it breaks things, you might want to create a CVS branch. Something like: cvs rtag Tyrex_BP jboss cvs rtag -b Tyrex_Branch jboss Then: cvs co -rTyrex_Branch jboss Then, put your changes in and commit. Later, when it's all working, you can do: cvs co jboss cd jboss cvs update -jTyrex_Branch and you should get an automated merge (which you'll need to fix manually). Unless I've screwed the whole concept up completely. Perhaps a resident CVS guru would care to comment? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource ConnectionFactoryLoader.java ConnectionManagerFactoryLoader.java
Jason Dillon wrote: Do you think it would make sence to modify the ConfigurationService to do this automatically when setting MBean attributes? I thought about that, but it's conceivable that the whitespace might be significant for some attribute. I can't think of a good example at the moment, though. I think we can tell the XML parser to discard this extra whitespace. Maybe that would be a clean way to do it? Maybe we should just do it and see what breaks? Thoughts? Toby. On Fri, 20 Apr 2001 [EMAIL PROTECTED] wrote: User: tobyallsopp Date: 01/04/20 01:15:38 Modified:src/main/org/jboss/resource Tag: Branch_2_2 ConnectionFactoryLoader.java ConnectionManagerFactoryLoader.java Log: Bug #416402. Trim leading/trailing whitespace from selected attribute values so that jboss.jcml can be formatted sanely. ___ 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
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
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
On Tue, Apr 17, 2001 at 01:50:16PM -0700, Scott M Stark wrote: I think it is a bug for 2.2 as I cannot run the current ENC naming tests that need to access the JMS queue/topic factories because of this issue. I'll update the change note to include more details. Ah, that makes sense. I just hope you're prepared for the flood of people who suddenly can't use their DataSources :-). Hopefully the change note tracker will help to avoid this. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/build build.xml
On Mon, Apr 16, 2001 at 12:39:52PM -0700, Jason Dillon wrote: That would be my preference as well, though I have run into some problems with ANT and CVS, where file that were marked for edit would cause the building of javadocs to fail. What does "marked for edit" mean? I can not seem to reproduce this behavior with the current build system/ant version, so I am going to change packages to "org.jboss.*". Does that wildcard pick up all of org.jboss, org.jboss.foo and org.jboss.foo.bar? If so, cool. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/build build.xml
Jason Dillon wrote: Is there any reason why we aren't specifying "org.jboss.*", for the packagenames attribute value? Well, my excuse is that I didn't read the docs for the Ant javadoc task. Using wildcards seems like a maintainability win to me. I say go right ahead. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Policy for what to include in stable (2.2.x) branches?
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? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Jboss-development digest, Vol 1 #111 - 4 msgs
For God's sake, man, trim your replies! Harishankar Nair wrote: [37kB of stuff] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-415321 ] RAR Instance Deployer for jbosscx
On Wed, Apr 11, 2001 at 11:23:11AM -0400, David Jencks wrote: OOPS! I inadvertantly broke the .jcml xml below while trying to add an explanatory comment. Sorry. Fixed below Would it make any sense to configure instances of AutoDeployer to look for specific extensions? So the next time we have a new deployer for .xyz files we set up a autodeployer to look only for them? I think it would make more sense to have AutoDeployer ask its configured deployer to decide, e.g. by returning a java.io.FilenameFilter. The algorithm would then be: 1) if the deployer has a FileFilter getDeployableFilenameFilter() method, use that to grab the filter, otherwise use a filter that accepts all files 2) Change all the hardcoded checks in AutoDeployer to if(filter.accept(url.getFile())) I'll commit this tonight if there are no objections. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
