[JBoss-dev] [ jboss-Bugs-431336 ] Problem with SecurityManager and Proxies

2001-06-08 Thread noreply

Bugs item #431336, was updated on 2001-06-08 00:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=431336&group_id=22866

Category: JBossServer
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with SecurityManager and Proxies

Initial Comment:
OS: sparc/Solaris 2.8
JDK: sun 1.3.0

users.properties:
mattw=password

roles.properties:
mattw=test-role,secure-test

my META-INF/jboss.xml:


 
java:/jaas/security-test
  
 
   SecurityTest
   SecurityTest
  
com.SSMB.jboss.SecurityTestSecurityProxy
 
  


I tried testing the security proxy above. I find I only
get proxies working if I have a security domain, for
which I need to be logged in (OK) - my client logs in
and tries to create the home interface. I get a null
pointer exception in the server. The problem appears to
be that in StatelessSessionInterceptor.invokeHome, it
does not set the EnterpriseContext like it does in
invoke(), and thus on line 148 of SecurityInterceptor,
where it attempt to do:
EJBContext ctx =
mi.getEnterpriseContext().getEJBContext();
in invokeHome, it dies.

I guess that there is not EnterpriseContext during
invocations on the home inbterface, so maybe it should
not be trying to retrieve it, or the Interceptor
invokeHome functions should look pretty much the same
as the invoke functions, setting the EnterpriseContext.

Great Looking Product. I'll have to use it more!
Matt

--

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

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



[JBoss-dev] CMP fields XML Serialization

2001-06-08 Thread Vincent Harcq

Hi,
In CMP Entity beans, fields that can not be mapped automaticaly to primitive
SQL type are
serialized and saved as Object in the database.  One problem is then if you
want to change the Object, you have to take care of Serialization
versions,...
everything is not possible here.  Another problem is if you want to give
access
to your db to a non Java world.
One solution for that could be to XMLize the object to a VARCHAR/String
format.
The power on changes of the Object will be more powerfull by implementation
of
method like "importXML" and "exportXML".

What do you think of a feature like that ?

What I try to avoidby using that is BMP , TopLink/Castor, XML/Object
Databases.

Vincent.


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



RE: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic

2001-06-08 Thread Sacha Labourey

Hello Oleg,

I agree with your idea that this setting should be optional. Nevertheless, I
do not think it is possible to do true transparent dynamic classloading and
not setting this URL in the stream but rather let the RMI marshaller
subsystem contact a JNDI name. Nevertheless, it would be still possible to
completly suppress the optional URL during the marshalling (i.e. getURLs
return an empty vector) and, in the client code, to set the appropriate rmi
system codebase properties such that the dynamic classloading can occurs.
The problem with this approach is that the client is only able to dynically
download code from a single source whereas with the "standard" way, you can
have as many sources as you want.

Cheers,



Sacha




> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part
> de Oleg Nitz
> Envoye : jeudi, 7 juin 2001 23:32
> A : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge
> network traffic
>
>
> Thanks Sacha, I understand the idea now.
> It didn't come to my mind, so I count it as a great one :-)
> Looking forward to see its implementation in CVS.
> I hope the http://... URL will be optional: if I don't use dynamic
> classloading, I don't want to have this overhead on each call.
> Even if I used it, I'd like the URL to be passed in some other
> way, not with
> each MarshalledObject instance, that would be still rather expensive IMHO.
> E.g. the URL could be available via JNDI.
>
> Regards,
>  Oleg
>
> On Thursday 07 June 2001 22:16, you wrote:
> > Hello Oleg,
> >
> > But I think that the getURLs() method of the new class (that
> will subclass
> > URLClassLoader), will only return the http://... URL from where
> code can be
> > downloaded. The method will not prompt every classloader in the
> chain for
> > their URLs.
> >
> > The goal of this new class is (almost) only to override the behaviour of
> > the getURLs method to return only a single URL.
> >
> > HTH. Cheers,
> >
> >
> >
> > Sacha
> >
> > > -Message d'origine-
> > > De : [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]De la
> part de Oleg
> > > Nitz
> > > Envoye : jeudi, 7 juin 2001 19:32
> > > A : Scott M Stark
> > > Objet : Re: [JBoss-dev] MarshalledObject + URLClassLoader =
> huge network
> > > traffic
> > >
> > >
> > > Hi Scott,
> > >
> > > Thanks for your answer.
> > > I am afraid you speak about another problem.
> > > At least I don't believe that the problem that I'm speaking about
> > > can be solved in a subclass of URLClassLoader.
> > > If MarshalledObject gets an object in the constructor,
> > > which is loaded by any subclass of URLClassLoader,
> > > MarshalledObject calls getURLs() on it and stores the result inside
> > > itself, so that the array of all URLs from client's classpath is sent
> > > to the server together with each minor parameter, and all URLs from
> > > the server's classpath are sent to client together with each return
> > > value (if its class is not in the system classpath).
> > > Just to make it clear: currently we are not going to use dynamic class
> > > loading at all, we have all needed classes on the client,
> > > we are anxious about the unnecessary network traffic.
> > > And this traffic is absolutely stupid, to be honest :-)
> > >
> > > Oleg
> > >
> > > Scott M Stark wrote:
> > > > This really should be fixed by having a new URLClassLoader subclass
> > > > that returns the java.rmi.server.codebase so that code can be
> > >
> > > properly downloaded
> > >
> > > > to the clients while still loading classes from the local urls.
> > >
> > > This fixes
> > >
> > > > the current
> > > > dynamic class loading problem. I have a solution based on
> what Vlad and
> > > > Sacha
> > > > had mentioned in their investigation of the problem that I'm
> > >
> > > going to commit
> > >
> > > > next
> > > > week.
> > > >
> > > > - Original Message -
> > > > From: "Oleg Nitz" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Thursday, June 07, 2001 9:27 AM
> > > > Subject: [JBoss-dev] MarshalledObject + URLClassLoader =
> huge network
> > > > traffic
> > > >
> > > >> Hi,
> > > >>
> > > >> We've noticed the enormous traffic between client and server.
> > > >> Investigation showed that the problem is in MarshalledObject:
> > > >> "...classes are annotated with a codebase URL from where
> the class can
> > > >> be loaded (if available)", which means that when the enclosed
> > > >> object was loaded via URLClassLoader, then the list of all
> URLs of the
> > > >> classloader is enclosed in the MarshalledObject instance.
> > > >> This list includes full names of all jar-files residing in
> the local
> > > >> filesystem, in any case they can't be used on the remote computer.
> > > >> In our project we use URLClassLoader in the client application,
> > > >> JBoss and underlying JMX library use it as well, the
> result is awful.
> > > >> My propo

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

2001-06-08 Thread vharcq

  User: vharcq  
  Date: 01/06/08 01:40:29

  Modified:src/main/org/jboss/metadata XmlFileLoader.java
  Log:
  1. Add Localresolver for ejb 2.0 DTD
  2. getLocalClass should return null for MDB else Exception during
  MDB deployment
  
  Revision  ChangesPath
  1.13  +6 -5  jboss/src/main/org/jboss/metadata/XmlFileLoader.java
  
  Index: XmlFileLoader.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/XmlFileLoader.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- XmlFileLoader.java2001/03/06 11:41:06 1.12
  +++ XmlFileLoader.java2001/06/08 08:40:29 1.13
  @@ -34,7 +34,7 @@
*   @see 
*   @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
*   @author mailto:[EMAIL PROTECTED]";>Wolfgang Werner
  - *   @version $Revision: 1.12 $
  + *   @version $Revision: 1.13 $
*/
   public class XmlFileLoader {
// Constants -
  @@ -127,7 +127,7 @@
   
// Protected -
public static Document getDocument(URL url) throws DeploymentException {
  - 
  +
 try {
return getDocument (url.openStream());
 } catch (IOException _ioe) {
  @@ -135,9 +135,9 @@
 }
}
   
  - public static Document getDocument(InputStream _in) throws DeploymentException 
  + public static Document getDocument(InputStream _in) throws DeploymentException
  {
  - try 
  + try
 {
Reader in = new InputStreamReader(_in);
   
  @@ -145,7 +145,7 @@
DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
EntityResolver er = new LocalResolver();
docBuilder.setEntityResolver(er);
  - Document doc = docBuilder.parse(_in);
  + Document doc = docBuilder.parse(_in);
return doc;
} catch (SAXParseException e) {
   
System.out.println(e.getMessage()+":"+e.getColumnNumber()+":"+e.getLineNumber());
  @@ -172,6 +172,7 @@
   
public LocalResolver() {
registerDTD("-//Sun Microsystems, Inc.//DTD Enterprise 
JavaBeans 1.1//EN", "ejb-jar.dtd");
  +registerDTD("-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 
2.0//EN", "ejb-jar_2_0.dtd");
registerDTD("-//Sun Microsystems, Inc.//DTD J2EE Application 
1.2//EN", "application_1_2.dtd");
registerDTD("-//Sun Microsystems, Inc.//DTD Connector 
1.0//EN", "connector_1_0.dtd");
registerDTD("-//JBoss//DTD JAWS//EN", "jaws.dtd");
  
  
  

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



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

2001-06-08 Thread vharcq

  User: vharcq  
  Date: 01/06/08 01:40:29

  Modified:src/main/org/jboss/ejb MessageDrivenContainer.java
  Log:
  1. Add Localresolver for ejb 2.0 DTD
  2. getLocalClass should return null for MDB else Exception during
  MDB deployment
  
  Revision  ChangesPath
  1.6   +114 -114  jboss/src/main/org/jboss/ejb/MessageDrivenContainer.java
  
  Index: MessageDrivenContainer.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/MessageDrivenContainer.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- MessageDrivenContainer.java   2001/06/04 15:16:08 1.5
  +++ MessageDrivenContainer.java   2001/06/08 08:40:29 1.6
  @@ -25,13 +25,13 @@
   
   /**
   *   MessageDrivenContainer, based on the StatelessSessionContainer
  -*   
  +*
   *   @see 
   *   @author Peter Antman ([EMAIL PROTECTED])
   *   @author Rickard Öberg ([EMAIL PROTECTED])
   *   @author Marc Fleury
   *   @author Daniel OConnor ([EMAIL PROTECTED])
  -*   @version $Revision: 1.5 $
  +*   @version $Revision: 1.6 $
   *extends StatelessSessionContainer
   */
   public class MessageDrivenContainer
  @@ -43,98 +43,98 @@
   
   // This is the container invoker for this container
   protected ContainerInvoker containerInvoker;
  -
  +
   // This is the instancepool that is to be used
   protected InstancePool instancePool;
  -
  +
   // This is the first interceptor in the chain. The last interceptor must be 
provided by the container itself
   protected Interceptor interceptor;
  -
  +
   // Static 
  -
  +
   // Constructors --
  -
  +
   // Public 
  -public void setContainerInvoker(ContainerInvoker ci) 
  -{ 
  +public void setContainerInvoker(ContainerInvoker ci)
  +{
   if (ci == null)
   throw new IllegalArgumentException("Null invoker");
  -
  -this.containerInvoker = ci; 
  +
  +this.containerInvoker = ci;
   ci.setContainer(this);
   }
  -
  -public ContainerInvoker getContainerInvoker() 
  -{ 
  -return containerInvoker; 
  +
  +public ContainerInvoker getContainerInvoker()
  +{
  +return containerInvoker;
   }
  -
  +
   public LocalContainerInvoker getLocalContainerInvoker()
   {
  return localContainerInvoker;
  -}  
  -
  -public void setInstancePool(InstancePool ip) 
  -{ 
  +}
  +
  +public void setInstancePool(InstancePool ip)
  +{
  if (ip == null)
   throw new IllegalArgumentException("Null pool");
  -
  -   this.instancePool = ip; 
  +
  +   this.instancePool = ip;
  ip.setContainer(this);
   }
   
  -public InstancePool getInstancePool() 
  -{ 
  -return instancePool; 
  -}
  -
  -public void addInterceptor(Interceptor in) 
  -{ 
  +public InstancePool getInstancePool()
  +{
  +return instancePool;
  +}
  +
  +public void addInterceptor(Interceptor in)
  +{
  if (interceptor == null)
  {
 interceptor = in;
  } else
  {
  -  
  +
 Interceptor current = interceptor;
 while ( current.getNext() != null)
 {
current = current.getNext();
 }
  - 
  +
 current.setNext(in);
  }
   }
  -
  -public Interceptor getInterceptor() 
  -{ 
  -return interceptor; 
  +
  +public Interceptor getInterceptor()
  +{
  +return interceptor;
   }
  - 
  +
   /* ContainerInvokerContainer - not needed, should we skip inherit this
* or just throw Error??
*/
   public Class getHomeClass()
   {
  -   throw new Error("Not valid for MessageDriven beans");
  +   throw new Error("HomeClass not valid for MessageDriven beans");
   }
  -
  +
   public Class getRemoteClass()
   {
  -   throw new Error("Not valid for MessageDriven beans");
  +   throw new Error("RemoteClass not valid for MessageDriven beans");
   }
  -
  -public Class getLocalClass() 
  +
  +public Class getLocalClass()
   {
  -   throw new Error("Not valid for MessageDriven beans");
  +return null;
   }
  -   
  -public Class getLocalHomeClass() 
  +
  +public Class getLocalHomeClass()
   {
  -   throw new Error("Not valid for MessageDriven beans");
  +   throw new Error("LocalHomeClass not valid for MessageDriven beans");
   }
  -
  -
  +
  +
   // Container implementation - overridden here --
   public void init()
   throws Exception
  

[JBoss-dev] FYI: Interesting newsletter *was* WG: 2001-06-07 TJSN [022] - Classloaders Revisited: "Hotdeploy"

2001-06-08 Thread Jung , Dr. Christoph

A friend of mine (he´s a real Java crack located in ZA!) edits a newsletter
series
that might be of interest for you and other people from the JBoss
development 
community. 

I was so free to compile some of our classloading thoughts to a (hopefully)
didactic
example ... 

If you are interested, subscribe and ask him to send the back-issue archive
... 
he had already and still has a lot of ill ideas (switching over objects,
virtual methods) 
that he distributes in that open manner. 

Best,
CGJ

-Ursprüngliche Nachricht-
Von: Heinz Kabutz [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 7. Juni 2001 23:53
Betreff: 2001-06-07 TJSN [022] - Classloaders Revisited: "Hotdeploy"


2001-06-07 TJSN [022] - Classloaders Revisited: "Hotdeploy"

Welcome to the 22nd issue of "The Java(tm) Specialists'
Newsletter", sponsored by infor business solutions AG, an ERP
company based in Germany (http://www.infor.de).  Many thanks go
to Christoph Jung for again making an excellent contribution to
"The Java(tm) Specialists' Newsletter" by taking the time to
write about some of the advanced things he's busy with.  This is
the longest newsletter so far, and also the most in-depth.  Don't
start expecting the same quality when I write ;-), in fact, I
might skip next week's letter to give you some time to digest
this one.

As always, I would like to ask you to forward this newsletter to
anybody you know who might be interested in Java.  Please also
remember that if you are a beginner in Java, some of these news-
letters will go over your head.  Don't give up!


 The minimalist application server
 Or
   Classloading revisited
  C.G.Jung (mailto:[EMAIL PROTECTED])
Sponsored by
infor business solutions AG
http://www.infor.de
 --

A few weeks ago, I was in the middle of an ICQ chat with
our admired Dr. Kabutz when he suddenly uttered a definite
"hi, hi" which took me by surprise as it was different to
the ubiquitous "emoticons" or smileys that I am used to.
Nevertheless, I was immediately able to catch the thousands
of denotations that this very special textual laughter was
transporting.  In this case, the semantics can be very well
subsumed by the German term "verschmitzt" which is difficult
to translate to English but would probably be a combination of
"roguish", "twisty", "experienced" and "savvy".  Similarly,
"ha, ha" (a very open reaction to a joke) and "ho, ho"
(kind of patronizing Santa Claus stance) are able to express
much more context than any smiley construction I know of,
at a minimum overhead of bandwidth. Measurements using WinZip
have shown verbose laughter statistically being only 5% more
expensive than its certainly poorer smiley counterpart.

And now ... I hope you kept a copy of newsletter 18 where Heinz
illuminated us with the insight that class identity in the
virtual machine is quite independent of even fully-qualified
class names.  The magical constructs that he used for his
investigations were the java.lang.ClassLoader and suitable
derivatives, such as the java.net.URLCLassloader. These are,
amongst other innovations of the Java(tm) 2 Runtime, indeed
a fascinating subject for experimentation.

Classes and ClassLoaders


Perhaps you found that having several classes called "A" in your
java.exe was not very useful.  On the contrary, it probably
required quite an effort to keep the various sources and class
files of that newsletter in separate directories.  However, I
would like to demonstrate how this rather theoretical possibility
has significant practical value when it comes to building real
programs that are able to simultaneously host multiple Java
applications.  The most well known examples of such programs are
found in the J2EE(tm) application servers.

For this purpose, let us briefly revisit what the head of Maximum
Solutions Ltd., by the way, one of the best Java consultancies I
know of ;-) [hk: hoho], has demonstrated to our surprised eyes
and what may be already apparent from the terminology:  A
java.lang.ClassLoader is an object that is used to locate
external resources (such as *.class file placed in a directory or
zipped into a jar-file) and to import the contained byte code for
constructing java.lang.Class instances at runtime.

Each java.lang.Class in the JVM is hence associated with its
so-called "defining classloader" that has imported it and that
can be obtained using the Class.getClassLoader() method. For
example, regard the following classes stock.Warehouse (interface
to a mono-product warehouse exposing a reservation method) and
sales.Order (remotely connects/links to a warehouse to satisfy
the order in quantities of size "bunch").

// stock/Warehouse.java
package stock;
/** Sample remote interface that is linked by sales.Order. */
public interface Warehouse extends java.rmi.Remote {
  /** Reserve

[JBoss-dev] Using SYBASE with JBoss

2001-06-08 Thread Celik Tuna

Hi, 
   We have problem with jaws. 
   Jaws doesn't support TINYINT and SHORTINT with
Sybase. In our application, TINYINT columns must be
converted to Byte. 

   Is it possible to use TINYINT in Sybase for JBoss? 

enjoy,

Omer Tuna CELIK 




__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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



RE: [JBoss-dev] CMP fields XML Serialization

2001-06-08 Thread Bill Burke

Can you plug-in how a CMP field is stored in the database?  If not, this
would be the best first step.

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Vincent Harcq
> Sent: Friday, June 08, 2001 3:23 AM
> To: Dev JBoss
> Subject: [JBoss-dev] CMP fields XML Serialization
>
>
> Hi,
> In CMP Entity beans, fields that can not be mapped automaticaly
> to primitive
> SQL type are
> serialized and saved as Object in the database.  One problem is
> then if you
> want to change the Object, you have to take care of Serialization
> versions,...
> everything is not possible here.  Another problem is if you want to give
> access
> to your db to a non Java world.
> One solution for that could be to XMLize the object to a VARCHAR/String
> format.
> The power on changes of the Object will be more powerfull by
> implementation
> of
> method like "importXML" and "exportXML".
>
> What do you think of a feature like that ?
>
> What I try to avoidby using that is BMP , TopLink/Castor, XML/Object
> Databases.
>
> Vincent.
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>



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



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

2001-06-08 Thread sparre

  User: sparre  
  Date: 01/06/08 07:59:35

  Modified:src/bin  mdbtest.bat mdbtest.sh
  Log:
  Made standalone mdb-test work,
  and killed unneded standalone mdb-test dependency on testbean-test.
  
  Revision  ChangesPath
  1.2   +1 -1  jbosstest/src/bin/mdbtest.bat
  
  Index: mdbtest.bat
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/bin/mdbtest.bat,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- mdbtest.bat   2001/02/14 03:49:59 1.1
  +++ mdbtest.bat   2001/06/08 14:59:35 1.2
  @@ -1 +1 @@
  -java -Djava.security.policy=jar:file:../lib/testbeantest.jar!/client.policy 
-Djava.security.manager -classpath 
../lib/mdbtest.jar;../lib/jbossmq-client.jar;../lib/jms.jar;../lib/jnp-client.jar 
org.jboss.test.mdb.test.Main %1 %2 %3 %4 %5 %6
  +java -Djava.security.policy=jar:file:../lib/mdbtest.jar!/client.policy 
-Djava.security.manager -classpath 
../lib/mdbtest.jar;../lib/jbossmq-client.jar;../lib/jms.jar;../lib/jnp-client.jar 
junit.swingui.TestRunner org.jboss.test.mdb.test.Main %1 %2 %3 %4 %5 %6
  
  
  
  1.3   +1 -1  jbosstest/src/bin/mdbtest.sh
  
  Index: mdbtest.sh
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/bin/mdbtest.sh,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mdbtest.sh2001/02/14 20:26:26 1.2
  +++ mdbtest.sh2001/06/08 14:59:35 1.3
  @@ -1,3 +1,3 @@
   #!/bin/sh
   
  -java -Djava.security.policy=jar:file:../lib/testbeantest.jar!/client.policy 
-Djava.security.manager -classpath 
../lib/mdbtest.jar:../lib/jbossmq-client.jar:../lib/jms.jar:../lib/jnp-client.jar 
org.jboss.test.mdb.test.Main $*
  +java -Djava.security.policy=jar:file:../lib/mdbtest.jar!/client.policy 
-Djava.security.manager -classpath 
../lib/mdbtest.jar:../lib/jbossmq-client.jar:../lib/jms.jar:../lib/jnp-client.jar 
junit.swingui.TestRunner org.jboss.test.mdb.test.Main $*
  
  
  

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



[JBoss-dev] CVS update: jbosstest/src/build/subprojects build-mdb.xml

2001-06-08 Thread sparre

  User: sparre  
  Date: 01/06/08 07:59:36

  Modified:src/build/subprojects build-mdb.xml
  Log:
  Made standalone mdb-test work,
  and killed unneded standalone mdb-test dependency on testbean-test.
  
  Revision  ChangesPath
  1.2   +1 -1  jbosstest/src/build/subprojects/build-mdb.xml
  
  Index: build-mdb.xml
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/build-mdb.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build-mdb.xml 2001/05/05 20:54:05 1.1
  +++ build-mdb.xml 2001/06/08 14:59:36 1.2
  @@ -28,7 +28,7 @@
   
   
   http://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] CMP fields XML Serialization

2001-06-08 Thread Vincent Harcq

Hi,
I will look at this idea, by having a new jdbc-type in jaws.xml for which
parameters can be set that tells Jaws how to insert/retrieve
attribute/field.
But I still want to keep it simple and keep the constraint one cmp field /
one database field.
Regards.
Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Bill
> Burke
> Envoyé : vendredi 8 juin 2001 16:51
> À : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] CMP fields XML Serialization
>
>
> Can you plug-in how a CMP field is stored in the database?  If not, this
> would be the best first step.
>
> Bill
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Vincent Harcq
> > Sent: Friday, June 08, 2001 3:23 AM
> > To: Dev JBoss
> > Subject: [JBoss-dev] CMP fields XML Serialization
> >
> >
> > Hi,
> > In CMP Entity beans, fields that can not be mapped automaticaly
> > to primitive
> > SQL type are
> > serialized and saved as Object in the database.  One problem is
> > then if you
> > want to change the Object, you have to take care of Serialization
> > versions,...
> > everything is not possible here.  Another problem is if you want to give
> > access
> > to your db to a non Java world.
> > One solution for that could be to XMLize the object to a VARCHAR/String
> > format.
> > The power on changes of the Object will be more powerfull by
> > implementation
> > of
> > method like "importXML" and "exportXML".
> >
> > What do you think of a feature like that ?
> >
> > What I try to avoidby using that is BMP , TopLink/Castor, XML/Object
> > Databases.
> >
> > Vincent.
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


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


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



Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic

2001-06-08 Thread Joseph Dane


on a related note, can someone comment on dynaimc code downloading
problem and the proposed solution?  I just recently started checking
out JBoss, and have generally been impressed.  but the fact that
dynamic downloading just plain doesn't work is really, *really*,
unfortunate.

-- 

joe

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



[JBoss-dev] [ jboss-Bugs-431478 ] EJX breaks with cloudscape in lib\ext

2001-06-08 Thread noreply

Bugs item #431478, was updated on 2001-06-08 13:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=431478&group_id=22866

Category: None
Group: v2.2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJX  breaks with cloudscape in lib\ext

Initial Comment:
I am setting us JBOSS to use the Cloudscape database 
distributed with J2EE1.2.1.  I copied the 2.2mb 
cloudscape.jar from %J2EE_HOME%\lib to %JBOSS_HOME%
\lib\ext so it would be automatically added to the 
classpath.

After this, I could not create a new xml configuration 
in ejx using the File:New menu.  Loading an xml file 
using the File:Load menu generates a dialog with the 
message "Could not load file:null".  ejx returned to 
normal behavior after removing cloudscape.jar from 
lib\ext. 

I thought the problem might be memory related since 
cloudscape.jar is gigantic.  I maunally launched the 
Main.clas directly with java setting -Xms32m and -
Xmx256m and got the same behavior.  

My system
=
Win2000k
jdk1.3.0_02 (j2ee 1.2.1 cloudscape)
Tecra 8100 laptop - 750 PIII, 512mb ram



--

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

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



Re: [JBoss-dev] Fast Updates Based on Row ID

2001-06-08 Thread K.V. Vinay Menon

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?

Vinay
- Original Message -
From: "danch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 07, 2001 6:32 AM
Subject: Re: [JBoss-dev] Fast Updates Based on Row ID


> K.V. Vinay Menon wrote:
>
> > Dan Ch,
> > Well as you might have noticed the code will work as usual if the
> > rowid-column field is not specified in jaws.xml. If it is specified, it
will
> > then be used instead of the primary key. I am not sure of how other
> > databases work with rowids which is why jaws will still default to
normal
> > behaviour.
>
> I think i'd rather have a flag on the JAWS entity to turn on
> 'oracle-tuned-updates' than just indicating the name of the rowid
> column. That way people will be less likely to turn it on for other
> databases.
>
>
> > Do you think we are in a position to submit the source? I'd have
rather
> > sent the modified source files for peer review in case I have goofed up!
> > And *then* committed changes. Do you have the time to spare?
>
> I think we've gotten a pretty good peer review already. However, with
> the insert issue and the change Georg points out later (detect empty
> rowIDValue and fall back on primary key) I think you should probably
> work those ideas into the code and post again. Are you on the JBossCMP
> mailing list? Perhaps we should move this discussion there.
>
>
>
> ___
> 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] Option D in SynchronizationInterceptor

2001-06-08 Thread K.V. Vinay Menon



Hi,
  Why is the 
validContexts in the new option D enabled EntitySynchronizationInterceptor *NOT* 
synchrnoized. Will you really have a thread safe implementation in that case? 
I'd sent out an implementation of the soft ball cache refresh option sometime 
back [which I never got time to check in!!] and that was after finally 
persuading Marc that we had to synchronise the hashset. Also, 
 
a. the hashset is unique anyway why check for 
presence! 
b. there will be only one ctx per bean [correct me 
if i am wrong]. 
 
    Also then we'd planned to have 
it as a separate class that could be fit into the inteceptor stack if 
required.
 
Vinay
 
Vinay


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

2001-06-08 Thread gropi

  User: gropi   
  Date: 01/06/08 18:15:32

  Modified:src/docs jdbc-database.xml
  Log:
  changed all occurences of OracleDS to OracleDB in JAWS configuration.
  Thanks to David Filiatrault for pointing this out.
  
  Revision  ChangesPath
  1.7   +4 -4  manual/src/docs/jdbc-database.xml
  
  Index: jdbc-database.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/jdbc-database.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jdbc-database.xml 2001/04/01 02:14:14 1.6
  +++ jdbc-database.xml 2001/06/09 01:15:32 1.7
  @@ -193,8 +193,8 @@

Pool configuration MBean example for Oracle

Re: [JBoss-dev] Unspecified transaction context always rollback - bug?

2001-06-08 Thread Georg Rehfeld

Hi Gerald,

> >> While following the recent "LOCKING-WAITING" threads I've been
> >> experimenting/tuning my beans for concurrency by turning reentrant
on
> >> and setting TX_SUPPORTS.  Great improvement!
> ...
> Tell me about it... Friday is my last day of work and I've got to hand
this
> project over to a couple beginner Java programmers, yet I've spent all
> afternoon "tuning" and looking through the jboss source and there's plenty
> more coding to do.

So hopefully this message doesn't come too late?

> I had implemented isModified shortly after realizing that every get was
> executing ejbStore - while keeping jboss moderately busy, postgresql would
> eat 30% cpu executing updates!

Ok, I see.

> I was wrong about the getters (only the setters cause isModified to return
> true...), however the finders still cause rolledback selects (no real
problem,
> just silly looking).

No real problem sounds good.

> From your original mail:
> This may arguably be a bug because the EJB specification (11.6.3) doesn't
> define what the container should do, but after reading it, I get the
feeling
> that it shouldn't rollback.

I agree mostly, but then 11.6.3 is really annoyingly unspecific,
allows the container to do almost anything (there is a "the
list is not inclusive of all possible strategies" sentence)
and leaves the bean developer in the wet ("the enterprise bean
must be written conservatively not to rely on any particular
Container behavior.")

> It looks as though jboss implemented the first
> "possible strategy":
>
>   * The Container may execute the method and access the underlying
resource
> managers without a transaction context.

I had a look at TxInterceptorCMT.java and you seem to be right,
the business/home method is invoked without any transaction
context (when requested by Supports, Never and NotSupported) and
there seems to be no attempt to set autocommit to true ... and as
there is no active transaction at all JBoss CAN'T do a rollback
after method invocation.

So the rollback you see in your debug log must come from somewhere
else, might be from your JDBC driver?

> Potentially elsewhere in the app, a similar taglib could execute some
finders,
> then invoke "incrementVisits" without a transaction, which would cause
> isModified to return true, then ejbStore would execute the update, but
jboss
> would rollback (and the bean instance would still have the new values that
> weren't commited to the database).

As I just told, I don't think JBoss is rolling back, it would be
too stupid to do that and leave the out of sync instance in memory,
hey, there may be some subtile errors in JBoss still, but no
sillyness.

But I agree, it might be best to set autocommit to true, would
avoid problems with drivers not knowing how to handle statements
without a TX and should be fairly easy to be implemented (at
least for the gurus here on the list).

As I said before you should NEVER attempt to write a bean
outside a TX, as there is no guarantee at all, that any EJB
server (including JBoss) will actually call ejbStore() (see
spec 9.1.7.1).

9.1.7.1 suggests DB access in the business methods instead, this
should work, if autocommit were on and the bean were not reentrant.

But I would suggest another schema:

- use commit option B

- have your getters and finders Supports

- have your create/remove and setters Required

- mark the bean as reentrant

- access your Entity beans through a Session bean facade
  to have declarative Transaction attributes (and business logic);
  alternatively use UserTransaction in your clients (does NOT
  work with JBoss 2.2.2 yet, but only with the CVS version)

- read without TX for pure display purposes, where reliability
  isn't that important, you gain advantage from JBoss caching
  the beans state with option B and without TX

- write within a TX, option B forces ejbLoad() before the
  business method executes and you have reliable data to
  modify; if your modification depends on the actual state
  you are free to first read the state then calc and write
  the state all within one and the same TX from the session
  bean

my very best 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



Re: [JBoss-dev] Fast Updates Based on Row ID

2001-06-08 Thread Georg Rehfeld

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-dev] jboss daily test results

2001-06-08 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   71



Successful tests:  60

Errors:1

Failures:  10



[time of test: 9 June 2001 2:50]

See http://lubega.com for full details




DETAILS OF ERRORS



Suite:   org.jboss.test.cts.test.AllJUnitTests
Test:testRemoveSessionObject
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: [EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when remove-ing 
a session object, detail:java.rmi.ServerException: RemoteException occurred in server 
thread; nested exception is:   javax.transaction.TransactionRolledbackException: Could 
not activate; nested exception is:   java.io.FileNotFoundException: 
[EMAIL PROTECTED]
 (No such file or directory); nested exception is:   java.rmi.NoSuchObjectException: 
Could not activate; nested exception is:   java.io.FileNotFoundException: 
[EMAIL PROTECTED]
 (No such file or directory)
Stack Trace:
junit.framework.AssertionFailedError: [EJB 1.1, p42, section 5.3.2] Expected 
'RemoveException' when remove-ing a session object, detail:java.rmi.ServerException: 
RemoteException occurred in server thread; nested exception is: 
javax.transaction.TransactionRolledbackException: Could not activate; nested 
exception is: 
java.io.FileNotFoundException: 
[EMAIL PROTECTED]
 (No such file or directory); nested exception is: 
java.rmi.NoSuchObjectException: Could not activate; nested exception is: 
java.io.FileNotFoundException: 
[EMAIL PROTECTED]
 (No such file or directory)
at junit.framework.Assert.fail(Assert.java:143)
at 
org.jboss.test.cts.test.StatefulSessionTest.testRemoveSessionObject(StatefulSessionTest.java:188)
at java.lang.reflect.Method.invoke(Native Method)
at junit.framework.TestCase.runTest(TestCase.java:155)
at junit.framework.TestCase.runBare(TestCase.java:129)
at junit.framework.TestResult$1.protect(TestResult.java:100)
at junit.framework.TestResult.runProtected(TestResult.java:117)
at junit.framework.TestResult.run(TestResult.java:103)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.run(TestSuite.java:144)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342)

-



Suite:   org.jboss.test.cts.test.AllJUnitTests
Test:testProbeBeanContext
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: Caught an unknown exception in testProbeBeanContex
Stack Trace:
junit.framework.AssertionFailedError: Caught an unknown exception in 
testProbeBeanContex
at junit.framework.Assert.fail(Assert.java:143)
at 
org.jboss.test.cts.test.StatefulSessionTest.testProbeBeanContext(StatefulSessionTest.java:467)
at java.lang.reflect.Method.invoke(Native Method)
at junit.framework.TestCase.runTest(TestCase.java:155)
at junit.framework.TestCase.runBare(TestCase.java:129)
at junit.framework.TestResult$1.protect(TestResult.java:100)
at junit.framework.TestResult.runProtected(TestResult.java:117)
at junit.framework.TestResult.run(TestResult.java:103)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.run(TestSuite.java:144)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342)

-



Suite:   org.jboss.test.cts.test.AllJUnitTests
Test:testEjbRemove
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: 
RemoteException occurred in server thread; nested exception is:   
javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; 
nested exception is:   javax.ejb.NoSuchEntityException: Instance 007 not found in 
database.
Stack Trace:
junit.framework.AssertionFailedError: Got Exception: expecting 
NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server 
thread; nested exception is: 
javax.transaction.TransactionRolledbackException: Instance 007 not found in 
database.; nested exception is: 
javax.ejb.NoSuchEntityException: Instance 007 not found in database.
at junit.framework.Assert.fail(Assert.java:143)
at org.jboss.test.cts.test.BmpTest.testEjbRemove(BmpTest.java:224)
at java.lang.reflect.Method.invoke(Native Method)
at junit.framework.TestCase.runTest(TestCase.java:155)

Re: [JBoss-dev] Option D in SynchronizationInterceptor

2001-06-08 Thread Georg Rehfeld

Hi again,

> K.V. Vinay Menon wrote:
>
> Why is the validContexts in the new option D enabled
> EntitySynchronizationInterceptor *NOT* synchrnoized. Will you
> really have a thread safe implementation in that case? I'd sent
> out an implementation of the soft ball cache refresh option
> sometime back [which I never got time to check in!!] and that was
> after finally persuading Marc that we had to synchronise the
> hashset. 

As far as I remember Marc was never really conscious of synchronization
in this case, worst case that can happen in a race between looking
for a ctx and adding to/clearing the hashset would be the lookup
failing, thus synchronizing an instance earlier than neccessary.

On the other hand the docs explicitely require synchronization on
HashSet, I don't know what happens in a race between adding and
clearing the set, maybe some internal structure will break. Though
I could look at the implementation, I believe it's better to do 
NOT, but stick with the docs, as the implementation might change
without notice!

Also, 
> 
> a. the hashset is unique anyway why check for presence! 

Don't exactly know what you mean, but the HashSet is only used for
commit option D and the class handles A,B,C also.

> b. there will be only one ctx per bean [correct me if i am wrong]. 

Do you mean one ctx per bean CLASS? No, the ctx has i.e. the transaction
and the security settings attached, so there is one context per
bean INSTANCE, isn't it?

> Also then we'd planned to have it as a separate class that could
> be fit into the inteceptor stack if required.

Was surprised too, but then the additional code is really only
a few lines and the semantics seem far more clear to me with
this solution (i.e. the switch (commitOption) in afterCompletion()).

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



Re: [JBoss-dev] Fast Updates Based on Row ID

2001-06-08 Thread danch

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] Using SYBASE with JBoss

2001-06-08 Thread David Jencks

Hi,
I know nothing of Sybase, I just wanted to make sure you have studied the
type mapping for jaws. See the documentation, Customizing Jaws/defining a
type mapping.  See also StandardJaws.xml.

david jencks

On 2001.06.08 08:04:12 -0400 Celik Tuna wrote:
> Hi, 
>We have problem with jaws. 
>Jaws doesn't support TINYINT and SHORTINT with
> Sybase. In our application, TINYINT columns must be
> converted to Byte. 
> 
>Is it possible to use TINYINT in Sybase for JBoss? 
> 
> enjoy,
> 
> Omer Tuna CELIK 
> 
> 
> 
> 
> __
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35 
> a year!  http://personal.mail.yahoo.com/
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> 


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



Re: [JBoss-dev] Fast Updates Based on Row ID

2001-06-08 Thread Georg Rehfeld

Hi Dan and Vinay,

> 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.

Oops, I forgot about that. But Vinay is right, a stable ROWID 
might be present in several other databases already or in future.

The 'insert ... select into' syntax today seems to be Oracle 8
specific (remember, Oracle 7 does not have it), but could make it
into some standard? At least one and the other are not too closely
related, this syntax especially can get back whatever you want
from the just inserted row, not only the ROWID, but even some
sequence value, some expression list to be more general.

And other DB's having a stable ROWID ain't lost, as Vinay's code
now falls back to the PK when a ROWID value isn't available.

So I suggest 'stable-rowid-column' (including good docs) and
a new tag 'insert-select-list' specifying a comma separated list
of expressions to select from the inserted row and an appropriate
number of placeholders for the result after a semicolon.
(Or better, feel free to define the syntax, you got the idea).

bye, my very best 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-dev] Possible spec violation in jbosspool...XAConnectionManager

2001-06-08 Thread David Jencks

Hi,

In the org.jboss.pool.connector.XAConnectionManager AllocateConnection
method, line 64

con = (ManagedConnection)pool.getObject(new
ConnectionParameters(subj, info));

a connection is retrieved from the pool and accepted without further
inquiry.  

However, in j2ee_connector-1_0-pfd2-spec.pfd, section 5.8.2 Scenario:
Connection Matching, it appears to me to indicate that the the application
server/pool should select a set of candidate managed connections from the
pool, and use the matchManagedConnections method on the
ManagedConnectionFactory to actually pick the one to use.  (a) Anyone
(toby?) agree with me? (b) Anyone working on this? a &!b => I will work on
a patch.

Thanks
david jencks


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



Re: [JBoss-dev] Possible spec violation in jbosspool...XAConnectionManager--OOPS sorry

2001-06-08 Thread David Jencks

Hi,
I realized I hadn't looked through enough code, and sure enough found the
matchManagedConnections call in ManagedConnectionPoolFactory.

Sorry for the disturbance.
david jencks

On 2001.06.09 01:55:21 -0400 David Jencks wrote:
> Hi,
> 
> In the org.jboss.pool.connector.XAConnectionManager AllocateConnection
> method, line 64
> 
> con = (ManagedConnection)pool.getObject(new
> ConnectionParameters(subj, info));
> 
> a connection is retrieved from the pool and accepted without further
> inquiry.  
> 
> However, in j2ee_connector-1_0-pfd2-spec.pfd, section 5.8.2 Scenario:
> Connection Matching, it appears to me to indicate that the the
> application
> server/pool should select a set of candidate managed connections from the
> pool, and use the matchManagedConnections method on the
> ManagedConnectionFactory to actually pick the one to use.  (a) Anyone
> (toby?) agree with me? (b) Anyone working on this? a &!b => I will work
> on
> a patch.
> 
> Thanks
> david jencks
> 
> 
> ___
> 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