date:20010615




Hello Georg,
    Nope! That is what I 
thought as well. The bean *is* being loaded even with commit options A and B, 
for the same operation with the transactions settings remaining the 
same.
 
 
Vinay

  - Original Message - 
  From: 
  Georg 
  Rehfeld 
  To: [EMAIL PROTECTED] 
  
  Sent: Friday, June 15, 2001 1:02 AM
  Subject: Re: [JBoss-dev] ROWID Based 
  Update: Load Entity Before Store Entity
  Hi Vinay,> This basically means that even within the 
  same transaction the > rowid will be updated if the client attempts to 
  do an update > [or delete].> Do we now need to check for 
  rowid being null and falling back > to the primary key if it is not? I 
  had written some code for > this and was surprised that it was never 
  being called.  Which commit option was set for your entity bean? 
  If it were B or C, it's clear, that the instance is loaded within a TX, 
  butwith A and with B (outside TX) the load should NOT happen, thusthe 
  check for a null rowidValue would be 
  better.regardsGeorg ___   ___| + | 
  |__    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] Is Monday still a good 2.4 freeze date


This is just a suprious exception that can easily be cleaned up.
Its also just a feature freeze to create the 2.4 branch, not a 2.4
release build as Juha said. The first release on the 2.4 branch
will be a beta.

- Original Message -
From: "Vincent Harcq" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 12:20 AM
Subject: RE: [JBoss-dev] Is Monday still a good 2.4 freeze date


> Hi,
> IMHO, the re-deployment problem (see below) should stop you making a new
> release.
>
> For my part, I will test/validate the new DTD validation option as some
> elements are still missing from jaws.dtd (cmp-field is not defined).  I will
> take care of dtd corrections.
>
> Vincent.
>
> [Container Management Proxy] Destroyed
> [Default] javax.management.InstanceAlreadyExistsException:
> Management:container=bank/Account
> [Default]   at
> com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134
> )
> [Default]
> [Default]   at
> com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja
> va:
> [Default]
> [Default]   at
> com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
> [Default]
> [Default]   at
> org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:716)
> [Default]
> [Default]   at
> org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory.java:7
> 00)
> [Default]
> [Default]   at
> org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:599)
> [Default]
> [Default]   at
> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471)
> [Default]
> [Default]   at
> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366)
> [Default]
> [Default]   at
> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305)
> [Default]
> [Default]   at java.lang.reflect.Method.invoke(Native Method)
> [Default]
> [Default]   at
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
> [Default]
> [Default]   at
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
> [Default]
> [Default]   at
> org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
> [Default]
> [Default]   at
> org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467)
> [Default]
> [Default]   at
> org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
> [Default]
> [Default]   at java.lang.reflect.Method.invoke(Native Method)
> [Default]
> [Default]   at
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
> [Default]
> [Default]   at
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
> [Default]
> [Default]   at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379)
> [Default]
> [Default]   at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
> [Default]
> [Default]   at java.lang.Thread.run(Unknown Source)
> [Default]
>
> > -Message d'origine-
> > De : [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]De la part de
> > Scott M Stark
> > Envoyé : vendredi 15 juin 2001 2:24
> > À : JBoss Dev
> > Objet : [JBoss-dev] Is Monday still a good 2.4 freeze date
> >
> >
> > Is Monday still a good 2.4 freeze date for the features that will go into
> > the 2.4 release or is more time needed?
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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

Re: [JBoss-dev] JBoss on JBoss


I seem to agree with Jay. The web server in Tomcat sucks. It is very slow!

Vinay
- Original Message -
From: "Jay Walters" <[EMAIL PROTECTED]>
To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 1:34 AM
Subject: RE: [JBoss-dev] JBoss on JBoss


> I fail to see how serving .gif files from tomcat shows off jboss. i am all
> for using jboss to handle dynamic content on the site, just trying to
figure
> out why every  hit has to go there.  Is that how you expect people to use
it
>
> Cheers
>
> -Original Message-
> From: Schaefer, Andreas
> To: '[EMAIL PROTECTED]'
> Sent: 6/14/01 1:34 PM
> Subject: RE: [JBoss-dev] JBoss on JBoss
>
> What a question !
>
> How do you want to convince other people to use JBoss when
> you aren't going to use your own tool. Either JBoss is
> ready to be used in production and then we should use it.
>
> BTW We are going to create an interactive Survey which
> must store the info in a DB.
>
> Mad Andy
>
> > -Original Message-
> > From: Jay Walters [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 14, 2001 9:05 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: [JBoss-dev] JBoss on JBoss
> >
> >
> > Why the decision to remove apache and serve everything from tomcat?
> >
> > Cheers
> >
> > -Original Message-
> > From: marc fleury [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 14, 2001 11:50 AM
> > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
> > Sourceforge. Net
> > Subject: [JBoss-dev] JBoss on JBoss
> >
> >
> > since I am done porting the website and adding a few things,
> > it will run on
> > JBoss/Tomcat now.
> >
> > However not all is ported yet, most notably petstore is
> > finicky and the
> > order in which we deploy the ears is important (go figure).
> >
> > So bear with us and the website as we move all this online.
> > Also JIVE will
> > be installed and jboss-user going online soon.  Time to taste our own
> > medicine.  If we are going to evangelize on our technology we
> > better have
> > the track record *at home* to support it.
> >
> > Again for the next few days the website will be a little
> > messy and under
> > construction, thanks for your understanding,
> >
> > regards
> >
> > marcf
> >
> > _
> > Marc Fleury, Ph.D
> > [EMAIL PROTECTED]
> > _
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


___
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


I would have liked to have added the ROWID bit, but don't want to rush it
thru!

Vinay
- Original Message -
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 9:09 AM
Subject: Re: [JBoss-dev] Is Monday still a good 2.4 freeze date


> This is just a suprious exception that can easily be cleaned up.
> Its also just a feature freeze to create the 2.4 branch, not a 2.4
> release build as Juha said. The first release on the 2.4 branch
> will be a beta.
>
> - Original Message -
> From: "Vincent Harcq" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 12:20 AM
> Subject: RE: [JBoss-dev] Is Monday still a good 2.4 freeze date
>
>
> > Hi,
> > IMHO, the re-deployment problem (see below) should stop you making a new
> > release.
> >
> > For my part, I will test/validate the new DTD validation option as some
> > elements are still missing from jaws.dtd (cmp-field is not defined).  I
will
> > take care of dtd corrections.
> >
> > Vincent.
> >
> > [Container Management Proxy] Destroyed
> > [Default] javax.management.InstanceAlreadyExistsException:
> > Management:container=bank/Account
> > [Default]   at
> >
com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134
> > )
> > [Default]
> > [Default]   at
> >
com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja
> > va:
> > [Default]
> > [Default]   at
> >
com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
> > [Default]
> > [Default]   at
> >
org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:716)
> > [Default]
> > [Default]   at
> >
org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory.java:7
> > 00)
> > [Default]
> > [Default]   at
> >
org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:599)
> > [Default]
> > [Default]   at
> > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471)
> > [Default]
> > [Default]   at
> > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366)
> > [Default]
> > [Default]   at
> > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305)
> > [Default]
> > [Default]   at java.lang.reflect.Method.invoke(Native Method)
> > [Default]
> > [Default]   at
> > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
> > [Default]
> > [Default]   at
> > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
> > [Default]
> > [Default]   at
> > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
> > [Default]
> > [Default]   at
> >
org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467)
> > [Default]
> > [Default]   at
> > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
> > [Default]
> > [Default]   at java.lang.reflect.Method.invoke(Native Method)
> > [Default]
> > [Default]   at
> > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
> > [Default]
> > [Default]   at
> > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
> > [Default]
> > [Default]   at
org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379)
> > [Default]
> > [Default]   at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
> > [Default]
> > [Default]   at java.lang.Thread.run(Unknown Source)
> > [Default]
> >
> > > -Message d'origine-
> > > De : [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]De la part de
> > > Scott M Stark
> > > Envoyé : vendredi 15 juin 2001 2:24
> > > À : JBoss Dev
> > > Objet : [JBoss-dev] Is Monday still a good 2.4 freeze date
> > >
> > >
> > > Is Monday still a good 2.4 freeze date for the features that will go
into
> > > the 2.4 release or is more time needed?
> > >
> > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


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

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


  User: starksm 
  Date: 01/06/15 01:26:45

  Modified:src/build build.xml
  Log:
  Remove the SecurityAssociation class from the run.jar
  
  Revision  ChangesPath
  1.77  +1 -3  jboss/src/build/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/build/build.xml,v
  retrieving revision 1.76
  retrieving revision 1.77
  diff -u -r1.76 -r1.77
  --- build.xml 2001/06/12 08:07:37 1.76
  +++ build.xml 2001/06/15 08:26:45 1.77
  @@ -220,7 +220,6 @@
manifest="${etc.dir}/run.mf"
   >
   
  -
   
   
   
  @@ -235,12 +234,11 @@
   
   
   
  +
   
  -
   
   
   
  -
   
   
   
  
  
  

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

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


  User: starksm 
  Date: 01/06/15 01:26:01

  Modified:src/build build.xml
  Log:
  Initialize the SecurityAssociation server mode in JaasSecurityManagerService
  
  Revision  ChangesPath
  1.11  +4 -4  jbosssx/src/build/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jbosssx/src/build/build.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- build.xml 2001/06/13 01:53:22 1.10
  +++ build.xml 2001/06/15 08:26:01 1.11
  @@ -1,6 +1,6 @@

[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java JaasSecurityManagerService.java


  User: starksm 
  Date: 01/06/15 01:26:02

  Modified:src/main/org/jboss/security/plugins JaasSecurityManager.java
JaasSecurityManagerService.java
  Log:
  Initialize the SecurityAssociation server mode in JaasSecurityManagerService
  
  Revision  ChangesPath
  1.7   +54 -29
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
  
  Index: JaasSecurityManager.java
  ===
  RCS file: 
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JaasSecurityManager.java  2001/06/11 06:23:39 1.6
  +++ JaasSecurityManager.java  2001/06/15 08:26:02 1.7
  @@ -51,10 +51,12 @@
   
   @author Oleg Nitz
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.6 $
  +@version $Revision: 1.7 $
   */
   public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
   {
  +/** The authentication cache object.
  + */
   public static class DomainInfo
   {
   Subject subject;
  @@ -70,7 +72,7 @@
   the appName into the SecurityPolicy.
*/
   private String securityDomain;
  -/** A cache of DomainInfo objects.
  +/** A cache of DomainInfo objects keyd by Principal.
*/
   private CachePolicy domainCache;
   /** The custom JAAS policy. This may be null if a custom
  @@ -153,6 +155,12 @@
   this.domainCache = domainCache;
   }
   
  +public void flushCache()
  +{
  +if( domainCache != null )
  +domainCache.flush();
  +}
  +
   public void setSecurityPolicyName(String jndiName) throws NamingException
   {
   InitialContext ctx = new InitialContext();
  @@ -176,7 +184,14 @@
   return (Subject) activeSubject.get();
   }
   
  -/** Validate that the given credential is correct for principal.
  +/** Validate that the given credential is correct for principal. This first
  + will check the current CachePolicy object if one exists to see if the
  + user's cached credentials match the given credential. If there is no
  + credential cache or the cache information is invalid or does not match,
  + the user is authenticated against the JAAS login modules configured for
  + the security domain.
  +@param principal, the security domain principal attempting access
  +@param credential, the proof of identity offered by the principal
   @return true if the principal was authenticated, false otherwise.
*/
   public boolean isValid(Principal principal, Object credential)
  @@ -240,29 +255,6 @@
   DomainInfo info = null;
   if( domainCache != null )
   info = (DomainInfo) domainCache.get(principal);
  -if( info == null )
  -{/* If there is no domain cache then this subject mgr is being used
  - for role mapping only and the subject has been authenticated by
  - some other mgr. We have to authenticate against this domain to
  - obtain the subject roles and then restore the current subject.
  - */
  - try
  - {
  - Object credential = SecurityAssociation.getCredential();
  - if( authenticate(principal, credential) == false )
  - {/* The subject does not authenticate across domains,
  - we can't do role mapping */
  - System.out.println("Warning, "+securityDomain+" could not 
perform role mapping for: "+principal);
  - return false;
  - }
  - if( domainCache != null )
  - info = (DomainInfo) domainCache.get(principal);
  - }
  - finally
  - {
  - activeSubject.set(subject);
  - }
  -}
   
   Group roles = null;
   if( info != null )
  @@ -279,8 +271,37 @@
   }
   return hasRole;
   }
  +
  +/** Validates operational environment Principal against the specified
  +application domain role.
  +@param principal, the caller principal as known in the operation environment.
  +@param role, the application domain role that the principal is to be validated 
against.
  +@return true if the principal has the role, false otherwise.
  + */
  +public boolean doesUserHaveRole(Principal principal, Principal role)
  +{
  +boolean hasRole = false;
  +Subject subject = getActiveSubject();
  +if( subject != null )
  +{
  +DomainInfo info = null;
  +if( domainCache != null )
  +info = (DomainInfo) domainCache.get(principa

[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/callback SecurityAssociationHandler.java


  User: starksm 
  Date: 01/06/15 01:26:02

  Modified:src/main/org/jboss/security/auth/callback
SecurityAssociationHandler.java
  Log:
  Initialize the SecurityAssociation server mode in JaasSecurityManagerService
  
  Revision  ChangesPath
  1.3   +5 -4  
jbosssx/src/main/org/jboss/security/auth/callback/SecurityAssociationHandler.java
  
  Index: SecurityAssociationHandler.java
  ===
  RCS file: 
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/callback/SecurityAssociationHandler.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SecurityAssociationHandler.java   2001/05/20 03:29:29 1.2
  +++ SecurityAssociationHandler.java   2001/06/15 08:26:01 1.3
  @@ -24,7 +24,7 @@
   @see #handle(Callback[])
   
   @author  [EMAIL PROTECTED]
  -@version $Revision: 1.2 $
  +@version $Revision: 1.3 $
   */
   public class SecurityAssociationHandler implements CallbackHandler
   {
  @@ -75,13 +75,15 @@
   else if ( c instanceof NameCallback)
   {
   NameCallback nc = (NameCallback) c;
  -nc.setName(principal.getName());
  +if( principal != null )
  +nc.setName(principal.getName());
   }
   else if( c instanceof PasswordCallback )
   {
   PasswordCallback pc = (PasswordCallback) c;
   char[] password = getPassword();
  -pc.setPassword(password);
  +if( password != null )
  +pc.setPassword(password);
   }
   else
   {
  @@ -132,4 +134,3 @@
   return password;
   }
   }
  -
  
  
  

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

[JBoss-dev] CVS update: jboss/src/lib jboss-jaas.jar jbosssx.jar


  User: starksm 
  Date: 01/06/15 01:27:52

  Modified:src/lib  jboss-jaas.jar jbosssx.jar
  Log:
  Include updated JBossSX jars
  
  Revision  ChangesPath
  1.11  +55 -53jboss/src/lib/jboss-jaas.jar
  
<>
  
  
  1.11  +94 -87jboss/src/lib/jbosssx.jar
  
<>
  
  

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

[JBoss-dev] CVS update: jboss/src/client jbosssx-client.jar


  User: starksm 
  Date: 01/06/15 01:28:14

  Modified:src/client jbosssx-client.jar
  Log:
  Include updated JBossSX client jar
  
  Revision  ChangesPath
  1.8   +33 -31jboss/src/client/jbosssx-client.jar
  
<>
  
  

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

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


  User: starksm 
  Date: 01/06/15 01:30:10

  Modified:src/main/org/jboss Main.java
  Log:
  Remove the DocumentBuilderFactory.newInstance() call that simply loaded
  the current JAXP parser.
  
  Remove the SecurityAssociation.setServer() call and move it to the
  JaasSecurityManagerService.
  
  Revision  ChangesPath
  1.35  +1 -10 jboss/src/main/org/jboss/Main.java
  
  Index: Main.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- Main.java 2001/05/25 01:41:34 1.34
  +++ Main.java 2001/06/15 08:30:10 1.35
  @@ -22,17 +22,13 @@
   import javax.management.*;
   import javax.management.loading.*;
   
  -import javax.xml.parsers.DocumentBuilderFactory;
  -
  -import org.jboss.security.SecurityAssociation;
  -
   /**
*
*   @see 
*   @author Rickard Öberg ([EMAIL PROTECTED])
*   @author mailto:[EMAIL PROTECTED]";>Daniel O'Connor.
*   @author [EMAIL PROTECTED]
  - *   @version $Revision: 1.34 $
  + *   @version $Revision: 1.35 $
*/
   public class Main
   {
  @@ -111,9 +107,6 @@
 if (System.getProperty("java.security.manager") != null)

System.setSecurityManager((SecurityManager)Class.forName(System.getProperty("java.security.manager")).newInstance());
   
  -  // use thread-local principal and credential propagation
  -  SecurityAssociation.setServer();
  -
 // Start server - Main does not have the proper permissions
 AccessController.doPrivileged(new PrivilegedAction()
 {
  @@ -203,8 +196,6 @@
   else if (obj instanceof Throwable)
  ((Throwable)obj).printStackTrace(err);
}
  -
  - DocumentBuilderFactory.newInstance();
   
// Load configuration
server.invoke(new ObjectName(":service=Configuration"), 
"loadConfiguration", new Object[0], new String[0]);
  
  
  

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

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


  User: starksm 
  Date: 01/06/15 01:31:02

  Modified:src/main/org/jboss/ejb/plugins SecurityInterceptor.java
  Log:
  Add support for the EJB2.0 security-identity/run-as element
  
  Revision  ChangesPath
  1.17  +90 -9 jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java
  
  Index: SecurityInterceptor.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- SecurityInterceptor.java  2001/06/11 07:04:15 1.16
  +++ SecurityInterceptor.java  2001/06/15 08:31:02 1.17
  @@ -16,17 +16,19 @@
   import org.jboss.ejb.Container;
   import org.jboss.ejb.MethodInvocation;
   import org.jboss.logging.Logger;
  -
  +import org.jboss.metadata.BeanMetaData;
  +import org.jboss.metadata.SecurityIdentityMetaData;
   import org.jboss.security.EJBSecurityManager;
   import org.jboss.security.RealmMapping;
   import org.jboss.security.SecurityAssociation;
  +import org.jboss.security.SimplePrincipal;
   
   /** The SecurityInterceptor is where the EJB 2.0 declarative security model
  -is enforced.
  +is enforced. This is where the caller identity propagation is controlled as well.
   
   @author Oleg Nitz
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.16 $
  +@version $Revision: 1.17 $
   */
   public class SecurityInterceptor extends AbstractInterceptor
   {
  @@ -49,14 +51,25 @@
* @supplierQualifier identity mapping 
*/
   protected RealmMapping realmMapping;
  +protected Principal runAsRole;
   
   public SecurityInterceptor()
   {
   }
   
  +/** Called by the super class to set the container to which this interceptor
  + belongs. We obtain the security manager and runAs identity to use here.
  + */
   public void setContainer(Container container)
   {
   this.container = container;
  +BeanMetaData beanMetaData = container.getBeanMetaData();
  +SecurityIdentityMetaData secMetaData = 
beanMetaData.getSecurityIdentityMetaData();
  +if( secMetaData != null && secMetaData.getUseCallerIdentity() == false )
  +{
  +String roleName = secMetaData.getRunAsRoleName();
  +runAsRole = new SimplePrincipal(roleName);
  +}
   securityManager = container.getSecurityManager();
   realmMapping = container.getRealmMapping();
   }
  @@ -76,13 +89,51 @@
   {
   // Authenticate the subject and apply any declarative security checks
   checkSecurityAssociation(mi, true);
  -return getNext().invokeHome(mi);
  +/* If a run-as role was specified, push it so that any calls made
  + by this bean will have the runAsRole available for declarative
  + security checks.
  +*/
  +if( runAsRole != null )
  +{
  +SecurityAssociation.pushRunAsRole(runAsRole);
  +}
  +try
  +{
  +Object returnValue = getNext().invokeHome(mi);
  +return returnValue;
  +}
  +finally
  +{
  +if( runAsRole != null )
  +{
  +SecurityAssociation.popRunAsRole();
  +}
  +}
   }
   public Object invoke(MethodInvocation mi) throws Exception
   {
   // Authenticate the subject and apply any declarative security checks
   checkSecurityAssociation(mi, false);
  -return getNext().invoke(mi);
  +/* If a run-as role was specified, push it so that any calls made
  + by this bean will have the runAsRole available for declarative
  + security checks.
  +*/
  +if( runAsRole != null )
  +{
  +SecurityAssociation.pushRunAsRole(runAsRole);
  +}
  +try
  +{
  +Object returnValue = getNext().invoke(mi);
  +return returnValue;
  +}
  +finally
  +{
  +if( runAsRole != null )
  +{
  +SecurityAssociation.popRunAsRole();
  +}
  +}
   }
   
   /** The EJB 2.0 declarative security algorithm:
  @@ -93,9 +144,14 @@
   private void checkSecurityAssociation(MethodInvocation mi, boolean home)
   throws Exception
   {
  -// if this isn't ok, bean shouldn't deploy
  +Principal principal = mi.getPrincipal();
  +Object credential = mi.getCredential();
  +// If there is not a security manager then there is no authentication 
required
   if (securityManager == null)
   {
  +// Allow for the progatation of caller info to other beans
  +SecurityAssociation.setPrincipal( principal );
  +SecurityAssociation.setCredential( credential );
   return;
   }
   if (realmMapping

[JBoss-dev] CVS update: jbosstest/src/build/stylesheets summary1.xsl

2001-06-15 Thread kimptoc


  User: kimptoc 
  Date: 01/06/15 01:35:16

  Modified:src/build/stylesheets summary1.xsl
  Log:
  add disclaimer to daily test results mail
  
  Revision  ChangesPath
  1.4   +6 -0  jbosstest/src/build/stylesheets/summary1.xsl
  
  Index: summary1.xsl
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/build/stylesheets/summary1.xsl,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- summary1.xsl  2001/05/27 09:41:37 1.3
  +++ summary1.xsl  2001/06/15 08:35:16 1.4
  @@ -33,6 +33,12 @@
   
   See http://lubega.com for full details
   
  +NOTE: If there are any errors shown above - this mail is only highlighting 
  +them - it is NOT indicating that they are being looked at by anyone.
  +
  +It is assumed that whoever makes change(s) to jboss that 
  +break the test will be fixing the test or jboss, as appropriate!
  +
   
   
   
  
  
  

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

[JBoss-dev] CVS update: jbosstest/src/resources/security/META-INF ejb-jar.xml jboss-spec.xml


  User: starksm 
  Date: 01/06/15 01:48:25

  Modified:src/resources/security/META-INF ejb-jar.xml jboss-spec.xml
  Log:
  Add tests of the EJB2.0 security-identity/run-as element
  
  Revision  ChangesPath
  1.7   +85 -4 jbosstest/src/resources/security/META-INF/ejb-jar.xml
  
  Index: ejb-jar.xml
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/resources/security/META-INF/ejb-jar.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ejb-jar.xml   2001/06/14 23:57:13 1.6
  +++ ejb-jar.xml   2001/06/15 08:48:25 1.7
  @@ -55,13 +55,41 @@
   org.jboss.test.security.interfaces.StatelessSession
   StatelessSession
   
  -
  -Echo
  -Echo
  -
   
   
   
  +A secured trival echo session bean that uses PrivateEntity,
  +StatelessSession and itself via a runAs identity
  +RunAsStatelessSession
  +org.jboss.test.security.interfaces.StatelessSessionHome
  +org.jboss.test.security.interfaces.StatelessSession
  +org.jboss.test.security.ejb.StatelessSessionBean3
  +Stateless
  +Container
  +
  +ejb/Entity
  +Entity
  +org.jboss.test.security.interfaces.EntityHome
  +org.jboss.test.security.interfaces.Entity
  +PrivateEntity
  +
  +
  +ejb/Session
  +Session
  +org.jboss.test.security.interfaces.StatelessSessionHome
  +org.jboss.test.security.interfaces.StatelessSession
  +StatelessSession
  +
  +
  +Use a role that is not assigned to any users to
  +access restricted server side functionallity
  +
  +InternalRole
  +
  +
  +
  +
  +
   An unsecured trival echo session bean
   UnsecureStatelessSession
   org.jboss.test.security.interfaces.StatelessSessionHome
  @@ -104,6 +132,17 @@
   java.lang.String
   False
   
  +
  +A trival echo entity bean that should only be
  +accessible via other beans
  +PrivateEntity
  +org.jboss.test.security.interfaces.EntityHome
  +org.jboss.test.security.interfaces.Entity
  +org.jboss.test.security.ejb.EntityBeanImpl
  +Bean
  +java.lang.String
  +False
  +
   
   
   
  @@ -111,6 +150,12 @@
   The role required to invoke the echo method
   Echo
   
  +
  +The role used to prevent access to the PrivateEntity
  +bean from external users.
  +
  +InternalRole
  +
   
   
   
  @@ -141,6 +186,42 @@
   
   Entity
   *
  +
  +
  +
  +RunAsStatelessSession
  +create
  +
  +
  +RunAsStatelessSession
  +remove
  +  
  +
  +RunAsStatelessSession
  +echo
  +
  +
  +RunAsStatelessSession
  +forward
  +
  +
  +RunAsStatelessSession
  +noop
  +
  +
  +
  +
  +
  +InternalRole
  +
  +
  +PrivateEntity
  +*
  +
  +
  +
  +RunAsStatelessSession
  +excluded
   
   
   
  
  
  
  1.5   +21 -1 jbosstest/src/resources/security/META-INF/jboss-spec.xml
  
  Index: jboss-spec.xml
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/resources/security/META-INF/jboss-spec.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jboss-spec.xml2001/06/13 04:54:06 1.4
  +++ jboss-spec.xml2001/06/15 08:48:25 1.5
  @@ -1,6 +1,9 @@
   
   
  -
  +
   
   
   
  @@ -49,6 +52,10 @@
 spec.Entity
   
   
  +  PrivateEntity
  +  spec.PrivateEntity
  +
  +
 StatelessSession
 spec.StatelessSession
 Standard Stateless SessionBean
  @@ -60,6 +67,19 @@
 
   ejb/Entity
   spec.Entity
  +  
  +  
  +ejb/Session
  +spec.StatelessSession
  +  
  +
  +
  +  RunAsStatelessSession
  +  spec.RunAsStatelessSession
  +  Standard

[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/security/test TestEJBSpec.java


  User: starksm 
  Date: 01/06/15 01:48:25

  Modified:src/main/org/jboss/test/security/test TestEJBSpec.java
  Log:
  Add tests of the EJB2.0 security-identity/run-as element
  
  Revision  ChangesPath
  1.5   +42 -4 jbosstest/src/main/org/jboss/test/security/test/TestEJBSpec.java
  
  Index: TestEJBSpec.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/security/test/TestEJBSpec.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- TestEJBSpec.java  2001/06/12 07:58:41 1.4
  +++ TestEJBSpec.java  2001/06/15 08:48:25 1.5
  @@ -12,10 +12,10 @@
   import org.jboss.test.security.interfaces.StatelessSessionHome;
   
   /** Test of EJB spec conformace using the security-spec.jar
  -deployment unit.
  +deployment unit. These test the basic role based access model.
   
  -@author [EMAIL PROTECTED]
  -@version $Revision: 1.4 $
  +@author [EMAIL PROTECTED]
  +@version $Revision: 1.5 $
   */
   public class TestEJBSpec extends junit.framework.TestCase
   {
  @@ -122,7 +122,7 @@
   }
   catch(RemoteException e)
   {
  -System.out.println("StatelessSession.noop not allowed");
  +System.out.println("StatelessSession.noop failed as expected");
   }
   bean.remove();
   }
  @@ -178,6 +178,44 @@
   // This is what we expect
   }
   logout();
  +}
  +
  +/** This method tests the following call chains:
  +1. RunAsStatelessSession.echo() -> PrivateEntity.echo()
  +2. RunAsStatelessSession.noop() -> RunAsStatelessSession.excluded()
  +3. RunAsStatelessSession.forward() -> StatelessSession.echo()
  + 1. Should succeed because the run-as identity of RunAsStatelessSession
  + is valid for accessing PrivateEntity.
  + 2. Should succeed ecause the run-as identity of RunAsStatelessSession
  + is valid for accessing RunAsStatelessSession.excluded().
  + 3. Should fail because the run-as identity of RunAsStatelessSession
  + is not Echo.
  + */
  +public void testRunAs() throws Exception
  +{
  +login();
  +InitialContext jndiContext = new InitialContext();
  +Object obj = jndiContext.lookup("spec.RunAsStatelessSession");
  +obj = PortableRemoteObject.narrow(obj, StatelessSessionHome.class);
  +StatelessSessionHome home = (StatelessSessionHome) obj;
  +System.out.println("Found RunAsStatelessSession Home");
  +StatelessSession bean = home.create();
  +System.out.println("Created spec.RunAsStatelessSession");
  +System.out.println("Bean.echo('Hello') -> "+bean.echo("Hello"));
  +bean.noop();
  +System.out.println("Bean.noop(), ok");
  +
  +try
  +{
  +// This should not be allowed
  +bean.forward("Hello");
  +fail("Was able to call RunAsStatelessSession.forward");
  +}
  +catch(RemoteException e)
  +{
  +System.out.println("StatelessSession.forward failed as expected");
  +}
  +bean.remove();
   }
   
   /** Login as user scott using the conf.name login config or
  
  
  

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

[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/security/ejb StatelessSessionBean3.java


  User: starksm 
  Date: 01/06/15 01:48:25

  Added:   src/main/org/jboss/test/security/ejb
StatelessSessionBean3.java
  Log:
  Add tests of the EJB2.0 security-identity/run-as element
  
  Revision  ChangesPath
  1.1  
jbosstest/src/main/org/jboss/test/security/ejb/StatelessSessionBean3.java
  
  Index: StatelessSessionBean3.java
  ===
  package org.jboss.test.security.ejb;
  
  import java.rmi.RemoteException;
  import java.security.Principal;
  import javax.ejb.CreateException;
  import javax.ejb.EJBException;
  import javax.ejb.SessionBean;
  import javax.ejb.SessionContext;
  import javax.naming.InitialContext;
  
  import org.jboss.test.security.interfaces.Entity;
  import org.jboss.test.security.interfaces.EntityHome;
  import org.jboss.test.security.interfaces.StatelessSession;
  import org.jboss.test.security.interfaces.StatelessSessionHome;
  
  /** A SessionBean that accesses an Entity bean in its echo() method to test runAs
  identity propagation. It also access its own excluded() method to test that the runAs
  identity is also see on methods of this bean that are invoked through the
  remote interface.
  
  @author [EMAIL PROTECTED]
  @version $Revision: 1.1 $
  */
  public class StatelessSessionBean3 implements SessionBean
  {
  private SessionContext sessionContext;
  
  public void ejbCreate() throws RemoteException, CreateException
  {
  System.out.println("StatelessSessionBean3.ejbCreate() called");
  }
  
  public void ejbActivate() throws RemoteException
  {
  System.out.println("StatelessSessionBean3.ejbActivate() called");
  }
  
  public void ejbPassivate() throws RemoteException
  {
  System.out.println("StatelessSessionBean3.ejbPassivate() called");
  }
  
  public void ejbRemove() throws RemoteException
  {
  System.out.println("StatelessSessionBean3.ejbRemove() called");
  }
  
  public void setSessionContext(SessionContext context) throws RemoteException
  {
  sessionContext = context;
  }
  
  /** This method creates an instance of the entity bean bound under
   java:comp/env/ejb/Entity and then invokes its echo method. This
   method should be accessible by user's with a role of Echo, while
   the Entity bean should only be accessible by the runAs role.
   */
  public String echo(String arg)
  {
  System.out.println("StatelessSessionBean3.echo, arg="+arg);
  // This call should fail if the bean is not secured
  Principal p = sessionContext.getCallerPrincipal();
  System.out.println("StatelessSessionBean3.echo, callerPrincipal="+p);
  String echo = null;
  try
  {
  InitialContext ctx = new InitialContext();
  EntityHome home = (EntityHome) ctx.lookup("java:comp/env/ejb/Entity");
  Entity bean = home.findByPrimaryKey(arg);
  echo = bean.echo(arg);
  }
  catch(Exception e)
  {
  e.printStackTrace();
  e.fillInStackTrace();
  throw new EJBException(e);
  }
  return echo;
  }
  
  public String forward(String echoArg)
  {
  System.out.println("StatelessSessionBean3.forward, echoArg="+echoArg);
  String echo = null;
  try
  {
  InitialContext ctx = new InitialContext();
  StatelessSessionHome home = (StatelessSessionHome) 
ctx.lookup("java:comp/env/ejb/Session");
  StatelessSession bean = home.create();
  echo = bean.echo(echoArg);
  }
  catch(Exception e)
  {
  e.printStackTrace();
  e.fillInStackTrace();
  throw new EJBException(e);
  }
  return echo;
  }
  
  /** This method gets this bean's remote interface and invokes the
   excluded() method to test that the method is accessed as the
   runAs role.
   */
  public void noop()
  {
  System.out.println("StatelessSessionBean3.noop calling excluded...");
  StatelessSession myEJB = (StatelessSession) sessionContext.getEJBObject();
  try
  {
  myEJB.excluded();
  }
  catch(RemoteException e)
  {
  throw new EJBException("Failed to access excluded: "+e.detail);
  }
  }
  
  public void npeError()
  {
  System.out.println("StatelessSessionBean3.npeError");
  Object obj = null;
  obj.toString();
  }
  public void unchecked()
  {
  Principal p = sessionContext.getCallerPrincipal();
  System.out.println("StatelessSessionBean.unchecked, callerPrincipal="+p);
  }
  
  /** This method should be assigned access to the runAs role and no user
   should have this role.

RE: [JBoss-dev] Is Monday still a good 2.4 freeze date

2001-06-15 Thread Mike Swainston-Rainford

Aren't there still some errors in the jboss.dtd as well? If I remember 
correctly max-bean-life and overager-period are not defined.

I was trying to get the dtds corrected for the Together JBoss deployer and 
then submit them for incorporation in CVS but they are such a moving target 
I had to freeze them for 2.2.2 and include them with the deployer 
distribution to guarantee that the Together XML editor would open them OK. 
(I have what I believe are valid and complete DTDs for the 2.2 release - 
some of the comments need the wording tidying up but the structure is correct).

Is there an 'official' public URL for the dtd files. The documentation 
pages link to www.jboss.org/documentation/jboss.dtd and jaws.dtd is there 
as well. (jboss-web.dtd isn't) But I believe they are out of date with 
respect to the current 2.2.2 release (the debug element isn't mentioned in 
jaws.dtd for example).

In view of the major changes to the dtd betwixt 2.2 and 2.3/2.4 shouldn't 
there be a version number added to the files so that the 2.4 file is a 
different beast to the 2.2 file? The jboss.xml secure element has been 
sensibly renamed but its no longer backwards compatible with 2.2.

Maybe the dtd files should be put under www.jboss.org/dtds with a frozen 
version for Jboss 2.2.2 named jboss.dtd, jboss-web.dtd and jaws.dtd. The 
2.4 versions could be renamed jboss-1_1.dtd? jboss-2_4.dtd?

What problems would renaming the files cause in the development of JBoss? I 
don't think it would cause any major grief to users of JBoss - if they are 
using CVS they are going to expect some problems and inconsistencies :-)

I also think a very small tutorial example using all the XML files - 
application, web, ejb, jboss, jboss-web and jaws would be a useful addition 
to the documentation for developers new to ejb and/or jboss. The CDEjb 
example with the jsp stuff added is probably a good candidate (except for 
MDB). This needs a 2.2 version and then a 2.4 version to cover all the 
additional stuff.

BTW the cdejb with jsp example that I've got with the latest deployer 
generates all of the xml files from the Together diagrams. I'm planning on 
keeping this example up to date with the deployer - so I want to get a 2.4 
deployer plus example out that supports all the extras in the dtds. I was 
also going to retrofit/correct the Ant build scripts and .bat .sh files so 
that it can be used with or without Together ie put the generated .xml 
files into resources so that the Ant build.xml can use them.

If you think its sensible to provide the tutorial example I can start 
tidying it up/fixing it. If my updated versions of the dtds would be useful 
I can mail them.

Mike S-R

At 09:20 15/06/2001 +0200, you wrote:
>Hi,
>IMHO, the re-deployment problem (see below) should stop you making a new
>release.
>
>For my part, I will test/validate the new DTD validation option as some
>elements are still missing from jaws.dtd (cmp-field is not defined).  I will
>take care of dtd corrections.
>
>Vincent.
>
>[Container Management Proxy] Destroyed
>[Default] javax.management.InstanceAlreadyExistsException:
>Management:container=bank/Account
>[Default]   at
>com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134
>)
>[Default]
>[Default]   at
>com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja
>va:
>[Default]
>[Default]   at
>com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
>[Default]
>[Default]   at
>org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:716)
>[Default]
>[Default]   at
>org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory.java:7
>00)
>[Default]
>[Default]   at
>org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:599)
>[Default]
>[Default]   at
>org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471)
>[Default]
>[Default]   at
>org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366)
>[Default]
>[Default]   at
>org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305)
>[Default]
>[Default]   at java.lang.reflect.Method.invoke(Native Method)
>[Default]
>[Default]   at
>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
>[Default]
>[Default]   at
>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
>[Default]
>[Default]   at
>org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
>[Default]
>[Default]   at
>org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467)
>[Default]
>[Default]   at
>org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
>[Default]
>[Default]   at java.lang.reflect.Method.invoke(Native Method)
>[Default]
>[Default]   at
>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
>[Default]
>[Default]   at
>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
>[Default]
>[Default

RE: [JBoss-dev] [ jboss-Bugs-433264 ] EJX Writes Invalid jaws.xml

2001-06-15 Thread Mike Swainston-Rainford



is EJX going to be developed further? Is anyone currently working on it?
If it is to be developed further and on one is currently doing it do you 
want me to look at it?

Mike S-R

At 19:17 14/06/2001 -0400, you wrote:
>aaron...
>
>come on man...
>
>
>we all know ejx is an unfinished work... like every thing else the kid
>does...
>
>marc
>
>
>|-Original Message-
>|From: [EMAIL PROTECTED]
>|[mailto:[EMAIL PROTECTED]]On Behalf Of
>|[EMAIL PROTECTED]
>|Sent: Thursday, June 14, 2001 7:03 PM
>|To: [EMAIL PROTECTED]
>|Subject: [JBoss-dev] [ jboss-Bugs-433264 ] EJX Writes Invalid jaws.xml
>|
>|
>|Bugs item #433264, was updated on 2001-06-14 16:02
>|You can respond by visiting:
>|http://sourceforge.net/tracker/?func=detail&atid=376685&aid=433264&;
>|group_id=22866
>|
>|Category: None
>|Group: v2.2.2 (stable)
>|Status: Open
>|Resolution: None
>|Priority: 7
>|Submitted By: Aaron Mulder (ammulder)
>|Assigned to: Nobody/Anonymous (nobody)
>|Summary: EJX Writes Invalid jaws.xml
>|
>|Initial Comment:
>|The "ejx.jar" in the bin directory of 2.2.2 writes
>|invalid jaws.xml files.  Specifically, it includes all
>|the type mappings, which are redundant since
>|"standardjaws.xml" contains them all.  Further, they
>|are outdated: for example, there is a single "Oracle"
>|mapping instead of the correct "Oracle7" and "Oracle8"
>|mappings seen in "standardjaws.xml".  Further, the
>|MySQL mapping actually causes an exception during
>|deployment which prevents the entire EJB JAR from being
>|deployed, even if you're not using MySQL.
>|
>|To correct this, all the code that writes standard type
>|mappings into the jaws.xml file should be removed, so
>|that the only mapping written are the ones you have
>|manually defined in EJX.  Then EJX needs to know which
>|mappings are defined in standardjaws.xml so you can
>|still select a standard mapping from the drop-down list
>|on the main JAWS screen.
>|
>|
>|
>|--
>|
>|You can respond by visiting:
>|http://sourceforge.net/tracker/?func=detail&atid=376685&aid=433264&;
>|group_id=22866
>|
>|___
>|Jboss-development mailing list
>|[EMAIL PROTECTED]
>|http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-development


___
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

2001-06-15 Thread Vesco Claudio


My patches to implement JCA deployment are applied? :-)

> -Original Message-
> From: Scott M Stark [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 10:09 AM
> To:   [EMAIL PROTECTED]
> Subject:  Re: [JBoss-dev] Is Monday still a good 2.4 freeze date
> 
> This is just a suprious exception that can easily be cleaned up.
> Its also just a feature freeze to create the 2.4 branch, not a 2.4
> release build as Juha said. The first release on the 2.4 branch
> will be a beta.
> 
> - Original Message -
> From: "Vincent Harcq" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 12:20 AM
> Subject: RE: [JBoss-dev] Is Monday still a good 2.4 freeze date
> 
> 
> > Hi,
> > IMHO, the re-deployment problem (see below) should stop you making a
> new
> > release.
> >
> > For my part, I will test/validate the new DTD validation option as
> some
> > elements are still missing from jaws.dtd (cmp-field is not defined).
> I will
> > take care of dtd corrections.
> >
> > Vincent.
> >
> > [Container Management Proxy] Destroyed
> > [Default] javax.management.InstanceAlreadyExistsException:
> > Management:container=bank/Account
> > [Default]   at
> >
> com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.ja
> va:134
> > )
> > [Default]
> > [Default]   at
> >
> com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerI
> mpl.ja
> > va:
> > [Default]
> > [Default]   at
> >
> com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.jav
> a:388)
> > [Default]
> > [Default]   at
> >
> org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java
> :716)
> > [Default]
> > [Default]   at
> >
> org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory.
> java:7
> > 00)
> > [Default]
> > [Default]   at
> >
> org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:5
> 99)
> > [Default]
> > [Default]   at
> > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471)
> > [Default]
> > [Default]   at
> > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366)
> > [Default]
> > [Default]   at
> > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305)
> > [Default]
> > [Default]   at java.lang.reflect.Method.invoke(Native Method)
> > [Default]
> > [Default]   at
> >
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:162
> 8)
> > [Default]
> > [Default]   at
> >
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:152
> 3)
> > [Default]
> > [Default]   at
> >
> org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
> > [Default]
> > [Default]   at
> >
> org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:4
> 67)
> > [Default]
> > [Default]   at
> > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
> > [Default]
> > [Default]   at java.lang.reflect.Method.invoke(Native Method)
> > [Default]
> > [Default]   at
> >
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:162
> 8)
> > [Default]
> > [Default]   at
> >
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:152
> 3)
> > [Default]
> > [Default]   at
> org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379)
> > [Default]
> > [Default]   at
> org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
> > [Default]
> > [Default]   at java.lang.Thread.run(Unknown Source)
> > [Default]
> >
> > > -Message d'origine-
> > > De : [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]De la part
> de
> > > Scott M Stark
> > > Envoyé : vendredi 15 juin 2001 2:24
> > > À : JBoss Dev
> > > Objet : [JBoss-dev] Is Monday still a good 2.4 freeze date
> > >
> > >
> > > Is Monday still a good 2.4 freeze date for the features that will
> go into
> > > the 2.4 release or is more time needed?
> > >
> > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development

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

RE: [JBoss-dev] JBoss on JBoss


and you gonna run it for me? unless you put your work on the line, don't put
your mouth and opinions in front

I just realized I updated the cvs and the procedures wiped out the current
cvs so we REALLY have to make the switch now... prematurely but so it
goes...

that is when I close my eyes and take a leap of faith.

Tomcat better not let me down... you guys better help if Tomcat does go
down...

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
|Vinay Menon
|Sent: Friday, June 15, 2001 4:12 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] JBoss on JBoss
|
|
|I seem to agree with Jay. The web server in Tomcat sucks. It is very slow!
|
|Vinay
|- Original Message -
|From: "Jay Walters" <[EMAIL PROTECTED]>
|To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>;
|<[EMAIL PROTECTED]>
|Sent: Friday, June 15, 2001 1:34 AM
|Subject: RE: [JBoss-dev] JBoss on JBoss
|
|
|> I fail to see how serving .gif files from tomcat shows off
|jboss. i am all
|> for using jboss to handle dynamic content on the site, just trying to
|figure
|> out why every  hit has to go there.  Is that how you expect people to use
|it
|>
|> Cheers
|>
|> -Original Message-
|> From: Schaefer, Andreas
|> To: '[EMAIL PROTECTED]'
|> Sent: 6/14/01 1:34 PM
|> Subject: RE: [JBoss-dev] JBoss on JBoss
|>
|> What a question !
|>
|> How do you want to convince other people to use JBoss when
|> you aren't going to use your own tool. Either JBoss is
|> ready to be used in production and then we should use it.
|>
|> BTW We are going to create an interactive Survey which
|> must store the info in a DB.
|>
|> Mad Andy
|>
|> > -Original Message-
|> > From: Jay Walters [mailto:[EMAIL PROTECTED]]
|> > Sent: Thursday, June 14, 2001 9:05 AM
|> > To: '[EMAIL PROTECTED]'
|> > Subject: RE: [JBoss-dev] JBoss on JBoss
|> >
|> >
|> > Why the decision to remove apache and serve everything from tomcat?
|> >
|> > Cheers
|> >
|> > -Original Message-
|> > From: marc fleury [mailto:[EMAIL PROTECTED]]
|> > Sent: Thursday, June 14, 2001 11:50 AM
|> > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
|> > Sourceforge. Net
|> > Subject: [JBoss-dev] JBoss on JBoss
|> >
|> >
|> > since I am done porting the website and adding a few things,
|> > it will run on
|> > JBoss/Tomcat now.
|> >
|> > However not all is ported yet, most notably petstore is
|> > finicky and the
|> > order in which we deploy the ears is important (go figure).
|> >
|> > So bear with us and the website as we move all this online.
|> > Also JIVE will
|> > be installed and jboss-user going online soon.  Time to taste our own
|> > medicine.  If we are going to evangelize on our technology we
|> > better have
|> > the track record *at home* to support it.
|> >
|> > Again for the next few days the website will be a little
|> > messy and under
|> > construction, thanks for your understanding,
|> >
|> > regards
|> >
|> > marcf
|> >
|> > _
|> > Marc Fleury, Ph.D
|> > [EMAIL PROTECTED]
|> > _
|> >
|> >
|> >
|> > ___
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|> >
|> > ___
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|> >
|>
|>
|> ___
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|> ___
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|___
|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] Is Monday still a good 2.4 freeze date

2001-06-15 Thread Vincent Harcq


Please send you version of good dtds, I can review them as well.
Or better : post them on sourceforge.
Thanks.
Vincent.

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Mike
> Swainston-Rainford
> Envoyé : vendredi 15 juin 2001 11:46
> À : [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] Is Monday still a good 2.4 freeze date
>
>
> Aren't there still some errors in the jboss.dtd as well? If I remember
> correctly max-bean-life and overager-period are not defined.
>
> I was trying to get the dtds corrected for the Together JBoss
> deployer and
> then submit them for incorporation in CVS but they are such a
> moving target
> I had to freeze them for 2.2.2 and include them with the deployer
> distribution to guarantee that the Together XML editor would open
> them OK.
> (I have what I believe are valid and complete DTDs for the 2.2 release -
> some of the comments need the wording tidying up but the
> structure is correct).
>
> Is there an 'official' public URL for the dtd files. The documentation
> pages link to www.jboss.org/documentation/jboss.dtd and jaws.dtd is there
> as well. (jboss-web.dtd isn't) But I believe they are out of date with
> respect to the current 2.2.2 release (the debug element isn't
> mentioned in
> jaws.dtd for example).
>
> In view of the major changes to the dtd betwixt 2.2 and 2.3/2.4 shouldn't
> there be a version number added to the files so that the 2.4 file is a
> different beast to the 2.2 file? The jboss.xml secure element has been
> sensibly renamed but its no longer backwards compatible with 2.2.
>
> Maybe the dtd files should be put under www.jboss.org/dtds with a frozen
> version for Jboss 2.2.2 named jboss.dtd, jboss-web.dtd and jaws.dtd. The
> 2.4 versions could be renamed jboss-1_1.dtd? jboss-2_4.dtd?
>
> What problems would renaming the files cause in the development
> of JBoss? I
> don't think it would cause any major grief to users of JBoss - if
> they are
> using CVS they are going to expect some problems and inconsistencies :-)
>
> I also think a very small tutorial example using all the XML files -
> application, web, ejb, jboss, jboss-web and jaws would be a
> useful addition
> to the documentation for developers new to ejb and/or jboss. The CDEjb
> example with the jsp stuff added is probably a good candidate (except for
> MDB). This needs a 2.2 version and then a 2.4 version to cover all the
> additional stuff.
>
> BTW the cdejb with jsp example that I've got with the latest deployer
> generates all of the xml files from the Together diagrams. I'm
> planning on
> keeping this example up to date with the deployer - so I want to
> get a 2.4
> deployer plus example out that supports all the extras in the dtds. I was
> also going to retrofit/correct the Ant build scripts and .bat .sh
> files so
> that it can be used with or without Together ie put the generated .xml
> files into resources so that the Ant build.xml can use them.
>
> If you think its sensible to provide the tutorial example I can start
> tidying it up/fixing it. If my updated versions of the dtds would
> be useful
> I can mail them.
>
> Mike S-R
>
> At 09:20 15/06/2001 +0200, you wrote:
> >Hi,
> >IMHO, the re-deployment problem (see below) should stop you making a new
> >release.
> >
> >For my part, I will test/validate the new DTD validation option as some
> >elements are still missing from jaws.dtd (cmp-field is not
> defined).  I will
> >take care of dtd corrections.
> >
> >Vincent.
> >
> >[Container Management Proxy] Destroyed
> >[Default] javax.management.InstanceAlreadyExistsException:
> >Management:container=bank/Account
> >[Default]   at
> >com.sun.management.jmx.RepositorySupport.addMBean(RepositorySuppo
> rt.java:134
> >)
> >[Default]
> >[Default]   at
> >com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanSe
> rverImpl.ja
> >va:
> >[Default]
> >[Default]   at
> >com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImp
> l.java:388)
> >[Default]
> >[Default]   at
> >org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory
> .java:716)
> >[Default]
> >[Default]   at
> >org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFac
> tory.java:7
> >00)
> >[Default]
> >[Default]   at
> >org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:599)
> >[Default]
> >[Default]   at
> >org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471)
> >[Default]
> >[Default]   at
> >org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366)
> >[Default]
> >[Default]   at
> >org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305)
> >[Default]
> >[Default]   at java.lang.reflect.Method.invoke(Native Method)
> >[Default]
> >[Default]   at
> >com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
> >[Default]
> >[Default]   at
> >com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
> >[Default]
> >[Default]   a

[JBoss-dev] FW: All EJB2.0 security features are in main


Amid the panic, there are some VERY VERY good news indeed,

congratulations Scott, this is amazing work... JAAS based security is
definitely a VERY strong point of JBoss adoption in high-end environments.

regards

marcf

|-Original Message-
|From: Scott M Stark [mailto:[EMAIL PROTECTED]]
|Sent: Friday, June 15, 2001 4:59 AM
|To: marc fleury
|Subject: All EJB2.0 security features are in main
|
|
|I have integrated support for all of the new EJB2.0 security features
|into main for the 2.4 release.
|
|



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

RE: [JBoss-dev] [ jboss-Bugs-433264 ] EJX Writes Invalid jaws.xml


|   Well, you might want to finish it by the time my book comes out...
|:)

Alright go ahead and give them your plug :) what are you writing about these
days Aaron... (oh yeah wrox?)

|   I thought there was a grand effort to unify the metadata models
|between EJX and JBoss and produce an updated EJX.  Did that get dropped?

talk to the kiddo :(

|Is there any interest in having a functional GUI deployment descriptor
|editor?  Erin tells me it's easier to XSLT the WebLogic DDs, but I'm not
|convinced... :)

Say hello to Erin, great meeting her at J1.  Also YES there is great
interest in a GUI for JBoss. Editin the dd is one, the management is going
to be an absolute killer.

That is TYPICALLY something I see making a killing as a add-on...

regards

marcf

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



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

RE: [JBoss-dev] JBoss on JBoss


Really, I was just asking the question.  You're doing it differently than I
would and I want to understand why.

Sounds like two things

(1) Hey why use apache is tomcat can serve static content.  Plus seems
like you made a bunch of stuff into jsps.
(2) Pure java and some other 4th gen (JBoss 3.0) philosophical stuff.

Thanks for telling us why.

Don't worry about Tomcat, we can always go with Jetty!

Cheers

-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 9:02 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBoss on JBoss


and you gonna run it for me? unless you put your work on the line, don't put
your mouth and opinions in front

I just realized I updated the cvs and the procedures wiped out the current
cvs so we REALLY have to make the switch now... prematurely but so it
goes...

that is when I close my eyes and take a leap of faith.

Tomcat better not let me down... you guys better help if Tomcat does go
down...

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
|Vinay Menon
|Sent: Friday, June 15, 2001 4:12 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] JBoss on JBoss
|
|
|I seem to agree with Jay. The web server in Tomcat sucks. It is very slow!
|
|Vinay
|- Original Message -
|From: "Jay Walters" <[EMAIL PROTECTED]>
|To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>;
|<[EMAIL PROTECTED]>
|Sent: Friday, June 15, 2001 1:34 AM
|Subject: RE: [JBoss-dev] JBoss on JBoss
|
|
|> I fail to see how serving .gif files from tomcat shows off
|jboss. i am all
|> for using jboss to handle dynamic content on the site, just trying to
|figure
|> out why every  hit has to go there.  Is that how you expect people to use
|it
|>
|> Cheers
|>
|> -Original Message-
|> From: Schaefer, Andreas
|> To: '[EMAIL PROTECTED]'
|> Sent: 6/14/01 1:34 PM
|> Subject: RE: [JBoss-dev] JBoss on JBoss
|>
|> What a question !
|>
|> How do you want to convince other people to use JBoss when
|> you aren't going to use your own tool. Either JBoss is
|> ready to be used in production and then we should use it.
|>
|> BTW We are going to create an interactive Survey which
|> must store the info in a DB.
|>
|> Mad Andy
|>
|> > -Original Message-
|> > From: Jay Walters [mailto:[EMAIL PROTECTED]]
|> > Sent: Thursday, June 14, 2001 9:05 AM
|> > To: '[EMAIL PROTECTED]'
|> > Subject: RE: [JBoss-dev] JBoss on JBoss
|> >
|> >
|> > Why the decision to remove apache and serve everything from tomcat?
|> >
|> > Cheers
|> >
|> > -Original Message-
|> > From: marc fleury [mailto:[EMAIL PROTECTED]]
|> > Sent: Thursday, June 14, 2001 11:50 AM
|> > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
|> > Sourceforge. Net
|> > Subject: [JBoss-dev] JBoss on JBoss
|> >
|> >
|> > since I am done porting the website and adding a few things,
|> > it will run on
|> > JBoss/Tomcat now.
|> >
|> > However not all is ported yet, most notably petstore is
|> > finicky and the
|> > order in which we deploy the ears is important (go figure).
|> >
|> > So bear with us and the website as we move all this online.
|> > Also JIVE will
|> > be installed and jboss-user going online soon.  Time to taste our own
|> > medicine.  If we are going to evangelize on our technology we
|> > better have
|> > the track record *at home* to support it.
|> >
|> > Again for the next few days the website will be a little
|> > messy and under
|> > construction, thanks for your understanding,
|> >
|> > regards
|> >
|> > marcf
|> >
|> > _
|> > Marc Fleury, Ph.D
|> > [EMAIL PROTECTED]
|> > _
|> >
|> >
|> >
|> > ___
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|> >
|> > ___
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|> >
|>
|>
|> ___
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|> ___
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



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

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

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


  User: starksm 
  Date: 01/06/15 07:19:07

  Modified:src/main/org/jboss/metadata BeanMetaData.java
SecurityIdentityMetaData.java
  Log:
  Add support for the security-identity tag
  
  Revision  ChangesPath
  1.23  +2 -2  jboss/src/main/org/jboss/metadata/BeanMetaData.java
  
  Index: BeanMetaData.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/BeanMetaData.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- BeanMetaData.java 2001/06/11 06:16:50 1.22
  +++ BeanMetaData.java 2001/06/15 14:19:06 1.23
  @@ -28,7 +28,7 @@
*   @author Peter Antman ([EMAIL PROTECTED])
*   @author Daniel OConnor ([EMAIL PROTECTED])
*   @author [EMAIL PROTECTED]
  - *   @version $Revision: 1.22 $
  + *   @version $Revision: 1.23 $
*/
   public abstract class BeanMetaData extends MetaData {
   // Constants -
  @@ -165,7 +165,7 @@
}
   
   public String getSecurityProxy() { return securityProxy; }
  -private SecurityIdentityMetaData getSecurityIdentityMetaData()
  +public SecurityIdentityMetaData getSecurityIdentityMetaData()
   {
   return securityIdentity;
   }
  
  
  
  1.2   +9 -2  jboss/src/main/org/jboss/metadata/SecurityIdentityMetaData.java
  
  Index: SecurityIdentityMetaData.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/metadata/SecurityIdentityMetaData.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SecurityIdentityMetaData.java 2001/06/10 07:46:16 1.1
  +++ SecurityIdentityMetaData.java 2001/06/15 14:19:06 1.2
  @@ -13,14 +13,14 @@
   /** The meta data object for the security-identity element.
   The security-identity element specifies whether the callers security
   identity is to be used for the execution of the methods of the enterprise
  -bean or whether a specific run-as identity is to be used. It
  +bean or whether a specific run-as role is to be used. It
   contains an optional description and a specification of the security
   identity to be used.
   
   Used in: session, entity, message-driven
   
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.1 $
  +@version $Revision: 1.2 $
   */
   public class SecurityIdentityMetaData extends MetaData
   {
  @@ -40,10 +40,15 @@
   return description;
   }
   
  +/**
  + */
   public boolean getUseCallerIdentity()
   {
   return useCallerIdentity;
   }
  +/** Get the run-as security identity. This is the principal to be used for
  + the run-as identity of an enterprise bean in terms of its security role.
  + */
   public String getRunAsRoleName()
   {
   return runAsRoleName;
  @@ -64,10 +69,12 @@
   if( callerIdent != null )
   {
   useCallerIdentity = true;
  +System.out.println("SecurityIdentity, useCallerIdentity");
   }
   else
   {
   runAsRoleName = getElementContent(getUniqueChild(runAs, "role-name"));
  +System.out.println("SecurityIdentity, runAsRoleName="+runAsRoleName);
   }
}
   
  
  
  

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/security SecurityAssociation.java


  User: starksm 
  Date: 01/06/15 07:22:03

  Modified:src/main/org/jboss/security SecurityAssociation.java
  Log:
  Add support for implementation of the EJB2.0 run-as
  
  Revision  ChangesPath
  1.4   +64 -12jboss/src/main/org/jboss/security/SecurityAssociation.java
  
  Index: SecurityAssociation.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/security/SecurityAssociation.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SecurityAssociation.java  2001/06/12 08:00:43 1.3
  +++ SecurityAssociation.java  2001/06/15 14:22:03 1.4
  @@ -8,6 +8,7 @@
   package org.jboss.security;
   
   import java.security.Principal;
  +import java.util.ArrayList;
   
   /** The SecurityAssociation class maintains the security principal and
   credentials. This can be done on either a singleton basis or a thread
  @@ -31,27 +32,29 @@
   
   @author Daniel O'Connor ([EMAIL PROTECTED])
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.3 $
  +@version $Revision: 1.4 $
   */
   public final class SecurityAssociation
   {
   private static boolean server;
   private static Principal principal;
   private static Object credential;
  -private static ThreadLocal thread_principal;
  -private static ThreadLocal thread_credential;
  +private static ThreadLocal threadPrincipal;
  +private static ThreadLocal threadCredential;
  +private static RunAsThreadLocalStack threadRunAsStacks = new 
RunAsThreadLocalStack();
  +
   static
   {
   boolean useThreadLocal = 
Boolean.getBoolean("org.jboss.security.SecurityAssociation.ThreadLocal");
   if( useThreadLocal )
   {
  -thread_principal = new ThreadLocal();
  -thread_credential = new ThreadLocal();
  +threadPrincipal = new ThreadLocal();
  +threadCredential = new ThreadLocal();
   }
   else
   {
  -thread_principal = new InheritableThreadLocal();
  -thread_credential = new InheritableThreadLocal();
  +threadPrincipal = new InheritableThreadLocal();
  +threadCredential = new InheritableThreadLocal();
   }
   }
   
  @@ -61,7 +64,7 @@
   public static Principal getPrincipal()
   {
 if (server)
  -return (Principal) thread_principal.get();
  +return (Principal) threadPrincipal.get();
 else
   return principal;
   }
  @@ -74,7 +77,7 @@
   public static Object getCredential()
   {
 if (server)
  -return thread_credential.get();
  +return threadCredential.get();
 else
   return credential;
   }
  @@ -85,7 +88,7 @@
   public static void setPrincipal( Principal principal )
   {
 if (server)
  -thread_principal.set( principal );
  +threadPrincipal.set( principal );
 else
   SecurityAssociation.principal = principal;
   }
  @@ -98,11 +101,28 @@
   public static void setCredential( Object credential )
   {
 if (server)
  -thread_credential.set( credential );
  +threadCredential.set( credential );
 else
   SecurityAssociation.credential = credential;
   }
   
  +/**
  + */
  +public static void pushRunAsRole(Principal runAsRole)
  +{
  +threadRunAsStacks.push(runAsRole);
  +}
  +public static Principal popRunAsRole()
  +{
  +Principal runAsRole = threadRunAsStacks.pop();
  +return runAsRole;
  +}
  +public static Principal peekRunAsRole()
  +{
  +Principal runAsRole = threadRunAsStacks.peek();
  +return runAsRole;
  +}
  +
   /** Set the server mode of operation. When the server property has
   been set to true, the security information is maintained in thread local
   storage. This should be called to enable property security semantics
  @@ -113,5 +133,37 @@
   {
 server = true;
   }
  -}
   
  +/**
  + */
  +private static class RunAsThreadLocalStack extends ThreadLocal
  +{
  +protected Object initialValue()
  +{
  +return new ArrayList();
  +}
  +void push(Principal runAs)
  +{
  +ArrayList stack = (ArrayList) super.get();
  +stack.add(runAs);
  +}
  +Principal pop()
  +{
  +ArrayList stack = (ArrayList) super.get();
  +Principal runAs = null;
  +int lastIndex = stack.size() - 1;
  +if( lastIndex >= 0 )
  +runAs = (Principal) stack.remove(lastIndex);
  +return runAs;
  +}
  +Principal peek()
  +{
  +ArrayList stack = (ArrayList) super.get();
  +Principal runAs = null;
  +int lastIndex = stack.size() - 1;

Re: [JBoss-dev] JBoss on JBoss


am not arguing about why we can't use Apache. Just saying that after a lot
of benchmarking and stuff the web server on tomcat was lacking. It has
nothing to do with me running the site!

as for tomcat - go ahead! I can help in whatever way I can ... but the
performance on 8080 sucks! I stand by that.

Vinay
- Original Message -
From: "marc fleury" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 2:02 PM
Subject: RE: [JBoss-dev] JBoss on JBoss


> and you gonna run it for me? unless you put your work on the line, don't
put
> your mouth and opinions in front
>
> I just realized I updated the cvs and the procedures wiped out the current
> cvs so we REALLY have to make the switch now... prematurely but so it
> goes...
>
> that is when I close my eyes and take a leap of faith.
>
> Tomcat better not let me down... you guys better help if Tomcat does go
> down...
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
> |Vinay Menon
> |Sent: Friday, June 15, 2001 4:12 AM
> |To: [EMAIL PROTECTED]
> |Subject: Re: [JBoss-dev] JBoss on JBoss
> |
> |
> |I seem to agree with Jay. The web server in Tomcat sucks. It is very
slow!
> |
> |Vinay
> |- Original Message -
> |From: "Jay Walters" <[EMAIL PROTECTED]>
> |To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>;
> |<[EMAIL PROTECTED]>
> |Sent: Friday, June 15, 2001 1:34 AM
> |Subject: RE: [JBoss-dev] JBoss on JBoss
> |
> |
> |> I fail to see how serving .gif files from tomcat shows off
> |jboss. i am all
> |> for using jboss to handle dynamic content on the site, just trying to
> |figure
> |> out why every  hit has to go there.  Is that how you expect people to
use
> |it
> |>
> |> Cheers
> |>
> |> -Original Message-
> |> From: Schaefer, Andreas
> |> To: '[EMAIL PROTECTED]'
> |> Sent: 6/14/01 1:34 PM
> |> Subject: RE: [JBoss-dev] JBoss on JBoss
> |>
> |> What a question !
> |>
> |> How do you want to convince other people to use JBoss when
> |> you aren't going to use your own tool. Either JBoss is
> |> ready to be used in production and then we should use it.
> |>
> |> BTW We are going to create an interactive Survey which
> |> must store the info in a DB.
> |>
> |> Mad Andy
> |>
> |> > -Original Message-
> |> > From: Jay Walters [mailto:[EMAIL PROTECTED]]
> |> > Sent: Thursday, June 14, 2001 9:05 AM
> |> > To: '[EMAIL PROTECTED]'
> |> > Subject: RE: [JBoss-dev] JBoss on JBoss
> |> >
> |> >
> |> > Why the decision to remove apache and serve everything from tomcat?
> |> >
> |> > Cheers
> |> >
> |> > -Original Message-
> |> > From: marc fleury [mailto:[EMAIL PROTECTED]]
> |> > Sent: Thursday, June 14, 2001 11:50 AM
> |> > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
> |> > Sourceforge. Net
> |> > Subject: [JBoss-dev] JBoss on JBoss
> |> >
> |> >
> |> > since I am done porting the website and adding a few things,
> |> > it will run on
> |> > JBoss/Tomcat now.
> |> >
> |> > However not all is ported yet, most notably petstore is
> |> > finicky and the
> |> > order in which we deploy the ears is important (go figure).
> |> >
> |> > So bear with us and the website as we move all this online.
> |> > Also JIVE will
> |> > be installed and jboss-user going online soon.  Time to taste our own
> |> > medicine.  If we are going to evangelize on our technology we
> |> > better have
> |> > the track record *at home* to support it.
> |> >
> |> > Again for the next few days the website will be a little
> |> > messy and under
> |> > construction, thanks for your understanding,
> |> >
> |> > regards
> |> >
> |> > marcf
> |> >
> |> > _
> |> > Marc Fleury, Ph.D
> |> > [EMAIL PROTECTED]
> |> > _
> |> >
> |> >
> |> >
> |> > ___
> |> > Jboss-development mailing list
> |> > [EMAIL PROTECTED]
> |> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> |> >
> |> > ___
> |> > Jboss-development mailing list
> |> > [EMAIL PROTECTED]
> |> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> |> >
> |>
> |>
> |> ___
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |> http://lists.sourceforge.net/lists/listinfo/jboss-development
> |>
> |> ___
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |> http://lists.sourceforge.net/lists/listinfo/jboss-development
> |
> |
> |___
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.s

RE: [JBoss-dev] JBoss on JBoss

2001-06-15 Thread Bill Burke


Off Topic,

Is Jetty better?  We're using Jetty and were considering moving to Tomcat
because it seemed the user base was higher.

Let me know,

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jay
> Walters
> Sent: Friday, June 15, 2001 9:45 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] JBoss on JBoss
>
>
> Really, I was just asking the question.  You're doing it
> differently than I
> would and I want to understand why.
>
> Sounds like two things
>
> (1)   Hey why use apache is tomcat can serve static content.  Plus seems
> like you made a bunch of stuff into jsps.
> (2)   Pure java and some other 4th gen (JBoss 3.0) philosophical stuff.
>
> Thanks for telling us why.
>
> Don't worry about Tomcat, we can always go with Jetty!
>
> Cheers
>
> -Original Message-
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 9:02 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] JBoss on JBoss
>
>
> and you gonna run it for me? unless you put your work on the
> line, don't put
> your mouth and opinions in front
>
> I just realized I updated the cvs and the procedures wiped out the current
> cvs so we REALLY have to make the switch now... prematurely but so it
> goes...
>
> that is when I close my eyes and take a leap of faith.
>
> Tomcat better not let me down... you guys better help if Tomcat does go
> down...
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
> |Vinay Menon
> |Sent: Friday, June 15, 2001 4:12 AM
> |To: [EMAIL PROTECTED]
> |Subject: Re: [JBoss-dev] JBoss on JBoss
> |
> |
> |I seem to agree with Jay. The web server in Tomcat sucks. It is
> very slow!
> |
> |Vinay
> |- Original Message -
> |From: "Jay Walters" <[EMAIL PROTECTED]>
> |To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>;
> |<[EMAIL PROTECTED]>
> |Sent: Friday, June 15, 2001 1:34 AM
> |Subject: RE: [JBoss-dev] JBoss on JBoss
> |
> |
> |> I fail to see how serving .gif files from tomcat shows off
> |jboss. i am all
> |> for using jboss to handle dynamic content on the site, just trying to
> |figure
> |> out why every  hit has to go there.  Is that how you expect
> people to use
> |it
> |>
> |> Cheers
> |>
> |> -Original Message-
> |> From: Schaefer, Andreas
> |> To: '[EMAIL PROTECTED]'
> |> Sent: 6/14/01 1:34 PM
> |> Subject: RE: [JBoss-dev] JBoss on JBoss
> |>
> |> What a question !
> |>
> |> How do you want to convince other people to use JBoss when
> |> you aren't going to use your own tool. Either JBoss is
> |> ready to be used in production and then we should use it.
> |>
> |> BTW We are going to create an interactive Survey which
> |> must store the info in a DB.
> |>
> |> Mad Andy
> |>
> |> > -Original Message-
> |> > From: Jay Walters [mailto:[EMAIL PROTECTED]]
> |> > Sent: Thursday, June 14, 2001 9:05 AM
> |> > To: '[EMAIL PROTECTED]'
> |> > Subject: RE: [JBoss-dev] JBoss on JBoss
> |> >
> |> >
> |> > Why the decision to remove apache and serve everything from tomcat?
> |> >
> |> > Cheers
> |> >
> |> > -Original Message-
> |> > From: marc fleury [mailto:[EMAIL PROTECTED]]
> |> > Sent: Thursday, June 14, 2001 11:50 AM
> |> > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
> |> > Sourceforge. Net
> |> > Subject: [JBoss-dev] JBoss on JBoss
> |> >
> |> >
> |> > since I am done porting the website and adding a few things,
> |> > it will run on
> |> > JBoss/Tomcat now.
> |> >
> |> > However not all is ported yet, most notably petstore is
> |> > finicky and the
> |> > order in which we deploy the ears is important (go figure).
> |> >
> |> > So bear with us and the website as we move all this online.
> |> > Also JIVE will
> |> > be installed and jboss-user going online soon.  Time to taste our own
> |> > medicine.  If we are going to evangelize on our technology we
> |> > better have
> |> > the track record *at home* to support it.
> |> >
> |> > Again for the next few days the website will be a little
> |> > messy and under
> |> > construction, thanks for your understanding,
> |> >
> |> > regards
> |> >
> |> > marcf
> |> >
> |> > _
> |> > Marc Fleury, Ph.D
> |> > [EMAIL PROTECTED]
> |> > _
> |> >
> |> >
> |> >
> |> > ___
> |> > Jboss-development mailing list
> |> > [EMAIL PROTECTED]
> |> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> |> >
> |> > ___
> |> > Jboss-development mailing list
> |> > [EMAIL PROTECTED]
> |> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> |> >
> |>
> |>
> |> ___
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |> http://lists.sourceforge.net/lists/listinfo/jboss-development
> |>
> |> ___
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |> htt

Re: [JBoss-dev] Is Monday still a good 2.4 freeze date


The dtd was fixed yesterday. All official dtds are in the jboss cvs
module under src/resources/org/jboss/metadata.

I'll fork new versions of the dtds that have changed since 2.2 and
label then with a 2_4(jboss_2_4.dtd, jaws_2_4.dtd). The only change
this entails is adding additional local entity resolver paths as far as
I can see. The only place the name shows up is in the DOCTYPE statement
of the deployment descriptor. There is no reference to jboss.dtd, jaws.dtd
in the codebase.

Sure, create a comprehensive example. The users are begging for one.

- Original Message - 
From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 2:45 AM
Subject: RE: [JBoss-dev] Is Monday still a good 2.4 freeze date


Aren't there still some errors in the jboss.dtd as well? If I remember 
correctly max-bean-life and overager-period are not defined.

I was trying to get the dtds corrected for the Together JBoss deployer and 
then submit them for incorporation in CVS but they are such a moving target 
I had to freeze them for 2.2.2 and include them with the deployer 
distribution to guarantee that the Together XML editor would open them OK. 
(I have what I believe are valid and complete DTDs for the 2.2 release - 
some of the comments need the wording tidying up but the structure is correct).

Is there an 'official' public URL for the dtd files. The documentation 
pages link to www.jboss.org/documentation/jboss.dtd and jaws.dtd is there 
as well. (jboss-web.dtd isn't) But I believe they are out of date with 
respect to the current 2.2.2 release (the debug element isn't mentioned in 
jaws.dtd for example).

In view of the major changes to the dtd betwixt 2.2 and 2.3/2.4 shouldn't 
there be a version number added to the files so that the 2.4 file is a 
different beast to the 2.2 file? The jboss.xml secure element has been 
sensibly renamed but its no longer backwards compatible with 2.2.



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

RE: [JBoss-dev] JBoss on JBoss


I have no basis to make any comment, I've never even tried to start Jetty.
Just suggesting we have two bundles for download, if the Tomcat one is not
suitable for some reason, I would try Jetty next.

Tomcat is in general a slow servlet engine, but my experience was comparing
it with COTS servlet engines not other open source ones, and that is
somewhat dated by now.  I do not know how much improvement they have made in
the 3.2 releases, though people seem to think there is a good amount.

One issue with Apache/Tomcat and the connector in the middle is that you've
got another network hop in the middle of processing servlet requests.  I am
not sure how much that slows it down vs any speedup of static content
serving.

My previous employer, an internet startup, used Java webserver for a long
time, before moving to Apache/Resin.  We didn't have tons of traffic ~200K
page views/day over 2-3 PIII 450 boxes but they were never too busy, so I am
sure a pure Java solution will work.

Of course how do you do CGI or PHP using Tomcat? (he he)

Cheers

-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 10:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBoss on JBoss


Off Topic,

Is Jetty better?  We're using Jetty and were considering moving to Tomcat
because it seemed the user base was higher.

Let me know,

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jay
> Walters
> Sent: Friday, June 15, 2001 9:45 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] JBoss on JBoss
>
>
> Really, I was just asking the question.  You're doing it
> differently than I
> would and I want to understand why.
>
> Sounds like two things
>
> (1)   Hey why use apache is tomcat can serve static content.  Plus seems
> like you made a bunch of stuff into jsps.
> (2)   Pure java and some other 4th gen (JBoss 3.0) philosophical stuff.
>
> Thanks for telling us why.
>
> Don't worry about Tomcat, we can always go with Jetty!
>
> Cheers
>
> -Original Message-
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 9:02 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] JBoss on JBoss
>
>
> and you gonna run it for me? unless you put your work on the
> line, don't put
> your mouth and opinions in front
>
> I just realized I updated the cvs and the procedures wiped out the current
> cvs so we REALLY have to make the switch now... prematurely but so it
> goes...
>
> that is when I close my eyes and take a leap of faith.
>
> Tomcat better not let me down... you guys better help if Tomcat does go
> down...
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
> |Vinay Menon
> |Sent: Friday, June 15, 2001 4:12 AM
> |To: [EMAIL PROTECTED]
> |Subject: Re: [JBoss-dev] JBoss on JBoss
> |
> |
> |I seem to agree with Jay. The web server in Tomcat sucks. It is
> very slow!
> |
> |Vinay
> |- Original Message -
> |From: "Jay Walters" <[EMAIL PROTECTED]>
> |To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>;
> |<[EMAIL PROTECTED]>
> |Sent: Friday, June 15, 2001 1:34 AM
> |Subject: RE: [JBoss-dev] JBoss on JBoss
> |
> |
> |> I fail to see how serving .gif files from tomcat shows off
> |jboss. i am all
> |> for using jboss to handle dynamic content on the site, just trying to
> |figure
> |> out why every  hit has to go there.  Is that how you expect
> people to use
> |it
> |>
> |> Cheers
> |>
> |> -Original Message-
> |> From: Schaefer, Andreas
> |> To: '[EMAIL PROTECTED]'
> |> Sent: 6/14/01 1:34 PM
> |> Subject: RE: [JBoss-dev] JBoss on JBoss
> |>
> |> What a question !
> |>
> |> How do you want to convince other people to use JBoss when
> |> you aren't going to use your own tool. Either JBoss is
> |> ready to be used in production and then we should use it.
> |>
> |> BTW We are going to create an interactive Survey which
> |> must store the info in a DB.
> |>
> |> Mad Andy
> |>
> |> > -Original Message-
> |> > From: Jay Walters [mailto:[EMAIL PROTECTED]]
> |> > Sent: Thursday, June 14, 2001 9:05 AM
> |> > To: '[EMAIL PROTECTED]'
> |> > Subject: RE: [JBoss-dev] JBoss on JBoss
> |> >
> |> >
> |> > Why the decision to remove apache and serve everything from tomcat?
> |> >
> |> > Cheers
> |> >
> |> > -Original Message-
> |> > From: marc fleury [mailto:[EMAIL PROTECTED]]
> |> > Sent: Thursday, June 14, 2001 11:50 AM
> |> > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
> |> > Sourceforge. Net
> |> > Subject: [JBoss-dev] JBoss on JBoss
> |> >
> |> >
> |> > since I am done porting the website and adding a few things,
> |> > it will run on
> |> > JBoss/Tomcat now.
> |> >
> |> > However not all is ported yet, most notably petstore is
> |> > finicky and the
> |> > order in which we deploy the ears is important (go figure).
> |> >
> |> > So bear with us and the website as we move all this online.
> |> > Also JIVE will
> |>

RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


Hey, looks good and runs good.

One sore spot, tried the search documentation feature looking for db2 and
oracle and got a 404 error back both times.

Great work Marc.  Now we can eat our down dogfood...

Cheers

-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 11:10 AM
To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
Sourceforge. Net
Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


A big, sloppy, thank you thank you thank you to the French Brigade at
Telecom Paris for being alert and helping out in "firefighter" mode.
Sebastien fixed it..

Sebastien you the man, discreet as ever, but there when it really really
counts...

thanks man...

so anyway... jboss.org is back online and it is all running on JBoss/Tomcat.
Pure JSP etc etc...

thanks to those who helped out and regards

marcf

PS: come on come on go try it out already !

_
Marc Fleury, Ph.D
[EMAIL PROTECTED]
_



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

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

Re: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


Looks good  Marc!

The following like does not work :
http://www.jboss.org/documentation/ECperf.html


Vinay
- Original Message -
From: "marc fleury" <[EMAIL PROTECTED]>
To: "Jboss-Development@Lists. Sourceforge. Net"
<[EMAIL PROTECTED]>; "Jboss-User@Lists. Sourceforge.
Net" <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 4:09 PM
Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


> A big, sloppy, thank you thank you thank you to the French Brigade at
> Telecom Paris for being alert and helping out in "firefighter" mode.
> Sebastien fixed it..
>
> Sebastien you the man, discreet as ever, but there when it really really
> counts...
>
> thanks man...
>
> so anyway... jboss.org is back online and it is all running on
JBoss/Tomcat.
> Pure JSP etc etc...
>
> thanks to those who helped out and regards
>
> marcf
>
> PS: come on come on go try it out already !
>
> _
> Marc Fleury, Ph.D
> [EMAIL PROTECTED]
> _
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


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

RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


works for me 

I go to the documentation page, enter db2 and search and I get the right
stuff back...

when I click on it it takes me to the documentation.

what gives?

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jay
|Walters
|Sent: Friday, June 15, 2001 11:13 AM
|To: '[EMAIL PROTECTED]'
|Subject: RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
|
|
|Hey, looks good and runs good.
|
|One sore spot, tried the search documentation feature looking for db2 and
|oracle and got a 404 error back both times.
|
|Great work Marc.  Now we can eat our down dogfood...
|
|Cheers
|
|-Original Message-
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Friday, June 15, 2001 11:10 AM
|To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
|Sourceforge. Net
|Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
|
|
|A big, sloppy, thank you thank you thank you to the French Brigade at
|Telecom Paris for being alert and helping out in "firefighter" mode.
|Sebastien fixed it..
|
|Sebastien you the man, discreet as ever, but there when it really really
|counts...
|
|thanks man...
|
|so anyway... jboss.org is back online and it is all running on
|JBoss/Tomcat.
|Pure JSP etc etc...
|
|thanks to those who helped out and regards
|
|marcf
|
|PS: come on come on go try it out already !
|
|_
|Marc Fleury, Ph.D
|[EMAIL PROTECTED]
|_
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



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

[JBoss-dev] CVS update: newsite CVSAdmin.html cvs.jsp

User: starksm
Date: 01/06/15 08:51:56

Modified:.cvs.jsp
Added: .CVSAdmin.html
Log:
Added the CVS admin policies document to the cvs.jsp page

Revision ChangesPath
1.2 +64 -61newsite/cvs.jsp

Index: cvs.jsp
===
RCS file: /cvsroot/jboss/newsite/cvs.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- cvs.jsp 2001/06/14 17:33:38 1.1
+++ cvs.jsp 2001/06/15 15:51:56 1.2
@@ -1,61 +1,64 @@
-
-
-
-
-
-
-
-
- JBOSS IS DEVELOPED PUBLICLY
- JBoss is a free implementation of the J2EE interfaces from
SUN. Our code is co-developed and the source is freely available. You
- can either get the code in a zip format to browse it or, if you
- plan on working with the source tree, you can set up a
CVS environment
- on your machine.
-
- We thank sourceforge.net for hosting our CVS. http://sourceforge.net";> http://sourceforge.net/sflogo.php?group_id=22866"; width="88" height="31"
border="0" alt="SourceForge Logo">
-SOURCE CODE
-http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/";>Browse the source on-line
- Download a daily updated snapshot of the sources (ZIP archive)
-
-CVS ENVIRONMENT
- To browse the source tree you will need a CVS client.
If you don't have one already installed on your machine you can download http://www.jcvs.org/";>jCVS, the CVS client in java. jCVS will
work on any platform including Linux. However we recommend the native Linux tools or
try http://www.wincvs.org";>winCVS if you are based on a
win32 platform.
- Settings for anonymous browsing:
- CVSROOT is
-:pserver:[EMAIL PROTECTED]:/cvsroot/jboss
- password is blank (type enter)
-Settings for developer access:
- You have to use SSH:
- export CVS_RSH=ssh
- CVSROOT is
-:ext:@cvs.jboss.sourceforge.net:/cvsroot/jboss
-For further explanations see http://sourceforge.net/cvs/?group_id=22866";>instructions at sourceforge
-
- MODULES
- The following modules are available for browsing:
-
-
jboss: the main jboss tree
-
jbosssx: the default security implementation
-
contrib: 3rd party contribution to jboss
-
jbosstest: the testsuite for jboss
-
zoap: an alternative SOAP based invocation
-
ejx: the gui front end of jboss
-
jnp: the JNDI implementation
-
zola: the application model
-
jbossmq: the JMS implementation
-
jbosscx: the JCA implementation
-
jbosspool: generic object pool. A fork from Aaron Mulder's Minerva
-
jboss-j2ee: J2EE core classes
-
manual: JBoss manual
-
-
- More information on Build and Source
- What is Ant?Ant is a Java based build tool. In theory it is
kind of like make without makes wrinkles.
- Why? Why another build tool when there is already make,
gnumake, nmake, jam, and others? Because, they are limited to the OS, or at least the
OS type such as Unix, that you are working on. Makefiles are inherently evil as well.
- Ant is different. Instead a model where it is extended with
shell based commands, it is extended using Java classes. Instead of writing shell
commands, the configuration files are XML based calling out a target tree where
various tasks get executed. Each task is run by an object which implements a
particular Task interface. Granted, this removes some of the expressive power that is
inherent by being able to construct a shell command such as `find . -name foo -exec rm
{}` but it gives you the ability to be cross platform. To work anywhere and
everywhere. And hey, if you really need to execute a shell command, Ant has an exec
rule that allows different commands t

RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


all the documentation IS A MESS because of the "documentation/manual" mess.

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
|Vinay Menon
|Sent: Friday, June 15, 2001 11:44 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
|
|
|Looks good  Marc!
|
|The following like does not work :
|http://www.jboss.org/documentation/ECperf.html
|
|
|Vinay
|- Original Message -
|From: "marc fleury" <[EMAIL PROTECTED]>
|To: "Jboss-Development@Lists. Sourceforge. Net"
|<[EMAIL PROTECTED]>; "Jboss-User@Lists. Sourceforge.
|Net" <[EMAIL PROTECTED]>
|Sent: Friday, June 15, 2001 4:09 PM
|Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
|
|
|> A big, sloppy, thank you thank you thank you to the French Brigade at
|> Telecom Paris for being alert and helping out in "firefighter" mode.
|> Sebastien fixed it..
|>
|> Sebastien you the man, discreet as ever, but there when it really really
|> counts...
|>
|> thanks man...
|>
|> so anyway... jboss.org is back online and it is all running on
|JBoss/Tomcat.
|> Pure JSP etc etc...
|>
|> thanks to those who helped out and regards
|>
|> marcf
|>
|> PS: come on come on go try it out already !
|>
|> _
|> Marc Fleury, Ph.D
|> [EMAIL PROTECTED]
|> _
|>
|>
|>
|> ___
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



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

[JBoss-dev] ejbStore() delay seems to be a serious problem


Hello all,

I have spent the past few hours reading up on other people with similar
problems to mine. So I am familiar with what the EJB spec says (somewhat
related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect to
when a Bean is required to write its data out to persistent storage.
However, this seems to be counterintuitive and is a serious problem for
operations that manipulate multiple data sources.

The flaw is that the Container writes changes out to persistent storage
immediately for remove() (ejbRemove()) and create() (ejbCreate())
operations, however, it doesn't write changes out for other Bean business
methods until the commit() section of the transaction.

Take the following method from my Stateless SessionBean (transaction set to
Required for the SSB and for the two CMP beans that it is manipulating)

public Integer runTest(Integer creditCardID, Integer newBillingAddressID)
throws EJBException
{

  CreditCardHome cch =
(CreditCardHome)TradeIMEJBTools.getHome("blah/CreditCardHome",CreditCardHome
.class);
  MemberCompanyAddressHome mcah =
(MemberCompanyAddressHome)TradeIMEJBTools.getHome("blah/MemberCompanyAddress
Home",MemberCompanyAddressHome.class);

  try
  {
CreditCard cc = cch.findByPrimaryKey(creditCardID);
CreditCardRecord ccr = cc.getRecord();

//Get the address that this credit card is currently pointing to
MemberCompanyAddress mca = mcah.findByPrimaryKey(new
MemberCompanyAddressPK(ccr.billing_address_id));

//Change the address to a different one
ccr.billing_address_id = newBillingAddressID.intValue();

//Write the changes to the bean object
cc.setRecord(ccr);

//Remove the old address
mca.remove();

return null;


  }
  catch(Exception e)
  {
System.out.println("Error creating record!" + e);
throw new EJBException("Failure creating records!");
  }
}

Here's what the average guy would think that this does to the DB:

BEGIN;

SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
{creditCardID}

oldBillingAddressID = {previousQuery}.billing_address_id

UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
credit_card_id = {creditCardID}

DELETE FROM member_company_address WHERE member_company_address_id =
{oldBillingAddressID}

COMMIT;

But in fact, the order of operations are as follows:

BEGIN;

SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
{creditCardID}

oldBillingAddressID = {previousQuery}.billing_address_id

DELETE FROM member_company_address WHERE member_company_address_id =
{oldBillingAddressID}

UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
credit_card_id = {creditCardID}

COMMIT;

This is a serious problem ... Weblogic has implemented a
"delay-updates-until-end-of-tx" parameter to add to the deployment
descriptor to allow a developer to override this behavior... Is there any
chance that the same can be done to JBOSS? Borland App Server supposedly has
something similar ... If not, does anyone have any way to work around this
problem without writing my own BMP beans and calling ejbStore() manually
after each business method to the bean? Ideally, it would be nice to also
have a parameter to add to the deployment descriptor to force an ejbLoad()
before each business method ... I understand all of the performance
implications of doing such things, this is why it seems like it needs to be
part of each beans deployment descriptor rather than a global setting for
all entity beans.

I looked at the Interceptor classes in the org.jboss.ejb.plugins directory
and feel that it is beyond my capability to actually implement a fix myself.
However, I would be happy to test any changes that are implemented and write
a section of documention on how to use the new feature.

Thanks in advance

-Dave


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

Re: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


The form that is produced by a doc search has a bad navigation frame.
Apparently this is the old navigation bar that is being cached by
search.freefind.com?



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

RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT

2001-06-15 Thread Tahir Awan


Marc,

http://www.jboss.org/documentation/files
and 
http://www.jboss.org/documentation/migration.jsp
also giving error.

Tahir


> -Original Message-
> From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 11:44 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
> 
> 
> Looks good  Marc!
> 
> The following like does not work :
> http://www.jboss.org/documentation/ECperf.html
> 
> 
> Vinay
> - Original Message -
> From: "marc fleury" <[EMAIL PROTECTED]>
> To: "Jboss-Development@Lists. Sourceforge. Net"
> <[EMAIL PROTECTED]>; "Jboss-User@Lists. 
> Sourceforge.
> Net" <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 4:09 PM
> Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
> 
> 
> > A big, sloppy, thank you thank you thank you to the French 
> Brigade at
> > Telecom Paris for being alert and helping out in "firefighter" mode.
> > Sebastien fixed it..
> >
> > Sebastien you the man, discreet as ever, but there when it 
> really really
> > counts...
> >
> > thanks man...
> >
> > so anyway... jboss.org is back online and it is all running on
> JBoss/Tomcat.
> > Pure JSP etc etc...
> >
> > thanks to those who helped out and regards
> >
> > marcf
> >
> > PS: come on come on go try it out already !
> >
> > _
> > Marc Fleury, Ph.D
> > [EMAIL PROTECTED]
> > _
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> 

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

[JBoss-dev] broken link

2001-06-15 Thread Tahir Awan


One more broken link
http://www.jboss.org/business/lists.html

Tahir

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

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


  User: starksm 
  Date: 01/06/15 09:14:08

  Modified:src/resources/org/jboss/metadata jboss.dtd
  Added:   src/resources/org/jboss/metadata jboss_2_4.dtd
  Log:
  Freeze the jboss.dtd at the 2.2 version
  Move the main version to jboss_2_4.dtd
  
  Revision  ChangesPath
  1.12  +40 -90jboss/src/resources/org/jboss/metadata/jboss.dtd
  
  Index: jboss.dtd
  ===
  RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss.dtd,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- jboss.dtd 2001/06/13 01:17:31 1.11
  +++ jboss.dtd 2001/06/15 16:14:08 1.12
  @@ -1,13 +1,17 @@
   
   
  -
  -
   
  -
  +
   
   
  -
  +
   
  -
   
   
  @@ -116,7 +116,7 @@
 
 Used in: jboss
 -->
  -
  +
   
   
  -
  +
   
   
  -
  -
  -
  -
  +
   
   
   
   
  @@ -175,7 +164,7 @@
 configurations. If none is provided, jboss will automatically use the
 right standard configuration, see container-configurations.
 
  -  Used in: entity, session, and message-driven
  +  Used in: entity and session
 -->
   
   
  @@ -184,7 +173,7 @@
just an object that implements methods in the home or remote interface
of an EJB without implementating any common interface.
   
  -  Used in: entity, session, and message-driven
  + Used in: entity and session
   -->
   
   
  @@ -194,7 +183,7 @@
 provide a ejb-link element in ejb-jar.xml, but you provide a jndi-name
 in jboss.xml
  
  -  Used in: entity, session, and message-driven
  +  Used in: entity, session
 -->
   
   
  @@ -218,33 +207,6 @@
   -->
   
   
  -
  -
  -
  -
  -
  -
  -
  -
  +
   
   
  -
  +
   
   
  -
  +
   
   
   
  @@ -596,14 +565,10 @@
   
  -
  +
   
   
  -
  -
  -
   
  @@ -694,7 +654,7 @@
 This option is only used for entity container configurations.
   
 The commit-option element tells the container which option to use for 
transactions.
  -  Its value must be A, B C, or D. 
  +  Its value must be A, B or C. 
   
 - option A: the entiry instance has exclusive access to the database. The 
instance 
 stays ready after a transaction.
  @@ -702,9 +662,6 @@
 The state is loaded before the next transaction.
 - option C: same as B, except the container does not keep the instance after 
commit: 
 a passivate is immediately performed after the commit.
  -
  -  - option D: a lazy update. default is every 30 secs.
  -   can be updated with 
 
 See ejb1.1 specification for details (p118).
   
  @@ -713,15 +670,9 @@
   
   
   
  -
  -
  -
  @@ -730,8 +681,7 @@
   
  
  
  
  1.1  jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd
  
  Index: jboss_2_4.dtd
  ===
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

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

[JBoss-dev] ejbStore() delay seems to be a serious problem


Hello all,

I have spent the past few hours reading up on other people with similar
problems to mine. So I am familiar with what the EJB spec says (somewhat
related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect to
when a Bean is required to write its data out to persistent storage.
However, this seems to be counterintuitive and is a serious problem for
operations that manipulate multiple data sources.

The flaw is that the Container writes changes out to persistent storage
immediately for remove() (ejbRemove()) and create() (ejbCreate())
operations, however, it doesn't write changes out for other Bean business
methods until the commit() section of the transaction.

Take the following method from my Stateless SessionBean (transaction set to
Required for the SSB and for the two CMP beans that it is manipulating)

public Integer runTest(Integer creditCardID, Integer newBillingAddressID)
throws EJBException
{

  CreditCardHome cch =
(CreditCardHome)TradeIMEJBTools.getHome("blah/CreditCardHome",CreditCardHome
.class);
  MemberCompanyAddressHome mcah =
(MemberCompanyAddressHome)TradeIMEJBTools.getHome("blah/MemberCompanyAddress
Home",MemberCompanyAddressHome.class);

  try
  {
CreditCard cc = cch.findByPrimaryKey(creditCardID);
CreditCardRecord ccr = cc.getRecord();

//Get the address that this credit card is currently pointing to
MemberCompanyAddress mca = mcah.findByPrimaryKey(new
MemberCompanyAddressPK(ccr.billing_address_id));

//Change the address to a different one
ccr.billing_address_id = newBillingAddressID.intValue();

//Write the changes to the bean object
cc.setRecord(ccr);

//Remove the old address
mca.remove();

return null;


  }
  catch(Exception e)
  {
System.out.println("Error creating record!" + e);
throw new EJBException("Failure creating records!");
  }
}

Here's what the average guy would think that this does to the DB:

BEGIN;

SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
{creditCardID}

oldBillingAddressID = {previousQuery}.billing_address_id

UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
credit_card_id = {creditCardID}

DELETE FROM member_company_address WHERE member_company_address_id =
{oldBillingAddressID}

COMMIT;

But in fact, the order of operations are as follows:

BEGIN;

SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
{creditCardID}

oldBillingAddressID = {previousQuery}.billing_address_id

DELETE FROM member_company_address WHERE member_company_address_id =
{oldBillingAddressID}

UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
credit_card_id = {creditCardID}

COMMIT;

This is a serious problem ... Weblogic has implemented a
"delay-updates-until-end-of-tx" parameter to add to the deployment
descriptor to allow a developer to override this behavior... Is there any
chance that the same can be done to JBOSS? Borland App Server supposedly has
something similar ... If not, does anyone have any way to work around this
problem without writing my own BMP beans and calling ejbStore() manually
after each business method to the bean? Ideally, it would be nice to also
have a parameter to add to the deployment descriptor to force an ejbLoad()
before each business method ... I understand all of the performance
implications of doing such things, this is why it seems like it needs to be
part of each beans deployment descriptor rather than a global setting for
all entity beans.

I looked at the Interceptor classes in the org.jboss.ejb.plugins directory
and feel that it is beyond my capability to actually implement a fix myself.
However, I would be happy to test any changes that are implemented and write
a section of documention on how to use the new feature.

Thanks in advance

-Dave


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

Re: [JBoss-dev] ejbStore() delay seems to be a serious problem


Why is this a serious problem? The weblogic docs for the flag you mention
indicate the commit is still not done until the end of the transaction and
that you would only notice this if your db allows for uncommitted reads.

From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164
Using delay-updates-until-end-of-tx to Change ejbStore() Behavior

By default, WebLogic Server updates the persistent store of all beans in a transaction 
only at the completion (commit) of the
transaction. This generally improves performance by avoiding unnecessary updates and 
repeated calls to ejbStore().

If your datastore uses an isolation level of READ_UNCOMMITTED, you may want to allow 
other database users to view the intermediate
results of in-progress transactions. In this case, the default WebLogic Server 
behavior of updating the datastore only at
transaction completion may be unacceptable.

You can disable the default behavior by using the delay-updates-until-end-of-tx 
deployment element. When you set this element to
"false," WebLogic Server calls ejbStore() after each method call, rather than at the 
conclusion of the transaction.

Note: Setting delay-updates-until-end-of-tx to false does not cause database updates 
to be "committed" to the database after each
method invoke; they are only sent to the database. Updates are committed or rolled 
back in the database only at the conclusion of
the transaction.



- Original Message -
From: "David Esposito" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 9:01 AM
Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem


> Hello all,
>
> I have spent the past few hours reading up on other people with similar
> problems to mine. So I am familiar with what the EJB spec says (somewhat
> related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect to
> when a Bean is required to write its data out to persistent storage.
> However, this seems to be counterintuitive and is a serious problem for
> operations that manipulate multiple data sources.
>



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

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


  User: starksm 
  Date: 01/06/15 10:00:54

  Modified:src/resources/org/jboss/metadata jaws.dtd
  Added:   src/resources/org/jboss/metadata jaws_2_4.dtd
  Log:
  Freeze the jaws.dtd at the 2.2 version
  
  Move the main versio to jaws_2_4.dtd
  
  Revision  ChangesPath
  1.6   +7 -54 jboss/src/resources/org/jboss/metadata/jaws.dtd
  
  Index: jaws.dtd
  ===
  RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws.dtd,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jaws.dtd  2001/06/13 06:52:18 1.5
  +++ jaws.dtd  2001/06/15 17:00:54 1.6
  @@ -1,73 +1,26 @@
   
   
  -
  -
  -
  -
  +
  +
   
   
  -
   
   
  -
   
   
  -
  -
  +
   
  -
   
   
  -
  -
  +
   
  -
   
   
  -
   
   
  -
   
  
  
  
  1.1  jboss/src/resources/org/jboss/metadata/jaws_2_4.dtd
  
  Index: jaws_2_4.dtd
  ===
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

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

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


  User: starksm 
  Date: 01/06/15 10:03:12

  Modified:src/main/org/jboss/metadata XmlFileLoader.java
  Log:
  Add local resolution from "-//JBoss//DTD JAWS 2.4//EN" to "jaws_2_4.dtd"
  Add local resolution from "-//JBoss//DTD JBOSS 2.4//EN" to "jboss_2_4.dtd"
  
  Revision  ChangesPath
  1.15  +3 -1  jboss/src/main/org/jboss/metadata/XmlFileLoader.java
  
  Index: XmlFileLoader.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/XmlFileLoader.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- XmlFileLoader.java2001/06/14 23:42:21 1.14
  +++ XmlFileLoader.java2001/06/15 17:03:12 1.15
  @@ -35,7 +35,7 @@
*   @author mailto:[EMAIL PROTECTED]";>Wolfgang Werner
*   @author mailto:[EMAIL PROTECTED]";>Darius Davidavicius
*   @author mailto:[EMAIL PROTECTED]";>Scott Stark
  - *   @version $Revision: 1.14 $
  + *   @version $Revision: 1.15 $
*/
   public class XmlFileLoader {
// Constants -
  @@ -259,7 +259,9 @@
   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");
  +registerDTD("-//JBoss//DTD JAWS 2.4//EN", "jaws_2_4.dtd");
   registerDTD("-//JBoss//DTD JBOSS//EN","jboss.dtd");
  +registerDTD("-//JBoss//DTD JBOSS 2.4//EN","jboss_2_4.dtd");
}
   
   /**
  
  
  

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

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


He wants the update SQL to execute before the remove SQL?  The commit isn't
the issue, it's the order of operations.

What does the spec say about when remove() needs to execute the SQL?

My question would be, if the bean has been removed should the persistence
manager still be trying to update it?  I can understand that one might want
to somehow consider side effects, such as a database trigger so maybe one
can't optimize out the update.

Cheers

-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 12:38 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem


Why is this a serious problem? The weblogic docs for the flag you mention
indicate the commit is still not done until the end of the transaction and
that you would only notice this if your db allows for uncommitted reads.



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

RE: [JBoss-dev] No storeEntity before ejbFind


Sorry, I have been out for a while.
Just wanted to say that 
Read committed is the default and was the only
automatic isolation level provided before Oracle
Release 7.3.
And Read committed is still the default which doesn't
let anybody even within the transaction see the
updated changes.

However, you are right, they added Serializable after
7.3 which you have to set up as the isolation level,
which allows you within a transaction see the changes
you have made.
And it is only in this mode that you can.
Of course, SQLPlus is Oracle specific which by the way
uses SQLNet and not some JDBC-ODBC driver, and has 
serializable settings.

Oracle does advise Read Committed as isolation setting
, therefore i have rarely seen companies use anything
but that... 
Sorry, if i caused confusion..

--- David Jencks <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Hey guys, think a minute.  What transaction
> isolation means is _other_
> transactions can't see your work until you commit. 
> Of course _your_
> transaction can see everything you've done.  If
> you're working with say the
> oracle interactive interface and insert a record in
> a table, if you query
> the table you can see it right away, you don't have
> to commit first. 
> _other_ people can't see it until you commit.  This
> has nothing to do with
> xa or anything else.
> 
> [although there is a related issue with "tightly
> coupled" and "loosely
> coupled" transaction branches in xa: loosely coupled
> means different
> branches of the same transaction can't see each
> others work.  This should
> only arise when several transaction managers are
> using the same global
> transaction against the same resource, and the
> XAResources can't agree that
> they are using the same resource.  Maybe this is
> what you guys are thinking
> of, but this should only be a potential problem with
> distributed jboss]
> 
> I'm pretty sure someone else complained about this a
> couple of weeks ago,
> although I can't find the reference - they  were
> modifying an entity, then
> doing a finder method returning a collection
> including the "just modified"
> bean, except they weren't seeing the modifications.
> 
> In my opinion, if this requirement was not present
> in ejb 1.1, is was a
> serious requirements bug, encouraging logically
> inconsistent behaviour from
> the container.
> 
> Thanks, Bill.
> 
> david jencks
> 
> On 2001.06.14 15:49:34 -0400 marc fleury wrote:
> > |I have been working with databases for a long
> time,
> > |and particularly with Oracle, I am not aware that
> this
> > |can happen, whether in transaction or not, before
> > |commit, nobody can see the updated table period
> in the
> > |database..
> > 
> > well that is my point precisely, it seems to imply
> that the updates
> > "before
> > the commit" are seen by connections enrolled in
> the SAME transaction
> > THROUGH
> > THE DATABASE  and frankly  I am a bit
> skeptical as to the level of
> > support for these features in the db or even if
> they exist at all or are
> > just "wishful features" (heck they don't even
> support 2pc and xa
> > right)...
> > 
> > so this smells of "teen spirit" to me... by
> requiring "inflight"
> > visibility
> > of the changed records they put a difficult
> requirement on the db drivers
> > and I don't see it working well.
> > 
> > They could have just required lock steps, as in
> first commit the changes
> > (and the db can follow that semantic) and then
> issue your findBy as just
> > another query...
> > 
> > I am no db expert (they are rare these days) but
> it strikes me as a
> > misguided requirement.
> > 
> > Bill for example couldn't you get the same
> functionality with the
> > serialiazed commits? Is this functionality that
> you couldn't get
> > otherwise?
> > you are the first one to require this feature (and
> you are savvy enough
> > to
> > scratch your itch so that is cool but still I
> wonder...)
> > 
> > but the REAL question is "is it true that you
> cannot see changed tables
> > from
> > a connection participating in the SAME transaction
> that changed it in the
> > first place?"
> > 
> > regards
> > 
> > marcf
> > 
> > |
> > |I don't know much about XA, it having its own set
> of
> > |rules though.
> > |
> >
> |__
> > |Do You Yahoo!?
> > |Spot the hottest trends in music, movies, and
> more.
> > |http://buzz.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
> > 
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
http://lists.sourceforge.net/lists/listinfo/jboss-development


___

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


That's what I want ... I don't want the data to be committed, I just need it
to be visible by other operations that occur under the same transaction
context. In my example in my email, I neglected to mention what actually
happens when you execute my block of code:

The database throws a hemorrhage because there is a non-cascading delete RI
constraint between the member_company_address table and the credit_card
table. The situation would be even more serious if the constraint WERE
cascading (ON DELETE CASCADE) ... In that case, the remove() method on my
address object would actually remove the credit_card record in the DB that
JBOSS had its hands on. ... Both of which would be avoided if the UPDATE to
the credit_card record had happened immediately when i issued my setXXX()
method on the remote object ..

I am surprised that I am the only one that has raised this particular
example. It seems like it's something that people would do every day.

I could come up with several other illustrative examples of where this is a
problem ... but I think this one is the simplest to understand ...

-Dave

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Friday, June 15, 2001 12:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> Why is this a serious problem? The weblogic docs for the flag you mention
> indicate the commit is still not done until the end of the transaction and
> that you would only notice this if your db allows for uncommitted reads.
>
> From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164
> Using delay-updates-until-end-of-tx to Change ejbStore() Behavior
>
> By default, WebLogic Server updates the persistent store of all
> beans in a transaction only at the completion (commit) of the
> transaction. This generally improves performance by avoiding
> unnecessary updates and repeated calls to ejbStore().
>
> If your datastore uses an isolation level of READ_UNCOMMITTED,
> you may want to allow other database users to view the intermediate
> results of in-progress transactions. In this case, the default
> WebLogic Server behavior of updating the datastore only at
> transaction completion may be unacceptable.
>
> You can disable the default behavior by using the
> delay-updates-until-end-of-tx deployment element. When you set
> this element to
> "false," WebLogic Server calls ejbStore() after each method call,
> rather than at the conclusion of the transaction.
>
> Note: Setting delay-updates-until-end-of-tx to false does not
> cause database updates to be "committed" to the database after each
> method invoke; they are only sent to the database. Updates are
> committed or rolled back in the database only at the conclusion of
> the transaction.
>
>
>
> - Original Message -
> From: "David Esposito" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 9:01 AM
> Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> > Hello all,
> >
> > I have spent the past few hours reading up on other people with similar
> > problems to mine. So I am familiar with what the EJB spec says (somewhat
> > related to the "diamond" scenario (11.7.1 of the EJB Spec))
> with respect to
> > when a Bean is required to write its data out to persistent storage.
> > However, this seems to be counterintuitive and is a serious problem for
> > operations that manipulate multiple data sources.
> >
>
>
>
> ___
> 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] ejbStore() delay seems to be a serious problem


The behavior you'd get by setting that flag to false in weblogic would 
also allow him to not break referential integrity in the case of his 
transaction.

Scott M Stark wrote:

> Why is this a serious problem? The weblogic docs for the flag you mention
> indicate the commit is still not done until the end of the transaction and
> that you would only notice this if your db allows for uncommitted reads.
> 
> From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164
> Using delay-updates-until-end-of-tx to Change ejbStore() Behavior
> 
> By default, WebLogic Server updates the persistent store of all beans in a 
>transaction only at the completion (commit) of the
> transaction. This generally improves performance by avoiding unnecessary updates and 
>repeated calls to ejbStore().
> 
> If your datastore uses an isolation level of READ_UNCOMMITTED, you may want to allow 
>other database users to view the intermediate
> results of in-progress transactions. In this case, the default WebLogic Server 
>behavior of updating the datastore only at
> transaction completion may be unacceptable.
> 
> You can disable the default behavior by using the delay-updates-until-end-of-tx 
>deployment element. When you set this element to
> "false," WebLogic Server calls ejbStore() after each method call, rather than at the 
>conclusion of the transaction.
> 
> Note: Setting delay-updates-until-end-of-tx to false does not cause database updates 
>to be "committed" to the database after each
> method invoke; they are only sent to the database. Updates are committed or rolled 
>back in the database only at the conclusion of
> the transaction.
> 
> 
> 
> - Original Message -
> From: "David Esposito" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 9:01 AM
> Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem
> 
> 
> 
>>Hello all,
>>
>>I have spent the past few hours reading up on other people with similar
>>problems to mine. So I am familiar with what the EJB spec says (somewhat
>>related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect to
>>when a Bean is required to write its data out to persistent storage.
>>However, this seems to be counterintuitive and is a serious problem for
>>operations that manipulate multiple data sources.
>>
>>
> 
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> 




Confidential e-mail for addressee only.  Access to this e-mail by anyone else is 
unauthorized.
If you have received this message in error, please notify the sender immediately by 
reply e-mail 
and destroy the original communication.

RE: [JBoss-dev] No storeEntity before ejbFind


You are still confused Gina, if you go into SQL*Plus and type the following

create table foo ( x varchar(32));
set autocommit off;
insert into foo values ('gina');
select * from foo;

you will see the value just inserted and you are in the middle of the
transaction.  Rollback will clean out the table...

This has always been (V4-V8i) and will always be... otherwise how would
after triggers work for example.  There is a freaky option in Oracle they
put in just to blow out the TPC-A benchmark, discrete transactions, that
doesn't let you read changes during the transaction.

Cheers
Jay

-Original Message-
From: Gina Hagg [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 1:15 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] No storeEntity before ejbFind


Sorry, I have been out for a while.
Just wanted to say that 
Read committed is the default and was the only
automatic isolation level provided before Oracle
Release 7.3.
And Read committed is still the default which doesn't
let anybody even within the transaction see the
updated changes.

However, you are right, they added Serializable after
7.3 which you have to set up as the isolation level,
which allows you within a transaction see the changes
you have made.
And it is only in this mode that you can.
Of course, SQLPlus is Oracle specific which by the way
uses SQLNet and not some JDBC-ODBC driver, and has 
serializable settings.

Oracle does advise Read Committed as isolation setting
, therefore i have rarely seen companies use anything
but that... 
Sorry, if i caused confusion..

--- David Jencks <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Hey guys, think a minute.  What transaction
> isolation means is _other_
> transactions can't see your work until you commit. 
> Of course _your_
> transaction can see everything you've done.  If
> you're working with say the
> oracle interactive interface and insert a record in
> a table, if you query
> the table you can see it right away, you don't have
> to commit first. 
> _other_ people can't see it until you commit.  This
> has nothing to do with
> xa or anything else.
> 
> [although there is a related issue with "tightly
> coupled" and "loosely
> coupled" transaction branches in xa: loosely coupled
> means different
> branches of the same transaction can't see each
> others work.  This should
> only arise when several transaction managers are
> using the same global
> transaction against the same resource, and the
> XAResources can't agree that
> they are using the same resource.  Maybe this is
> what you guys are thinking
> of, but this should only be a potential problem with
> distributed jboss]
> 
> I'm pretty sure someone else complained about this a
> couple of weeks ago,
> although I can't find the reference - they  were
> modifying an entity, then
> doing a finder method returning a collection
> including the "just modified"
> bean, except they weren't seeing the modifications.
> 
> In my opinion, if this requirement was not present
> in ejb 1.1, is was a
> serious requirements bug, encouraging logically
> inconsistent behaviour from
> the container.
> 
> Thanks, Bill.
> 
> david jencks
> 
> On 2001.06.14 15:49:34 -0400 marc fleury wrote:
> > |I have been working with databases for a long
> time,
> > |and particularly with Oracle, I am not aware that
> this
> > |can happen, whether in transaction or not, before
> > |commit, nobody can see the updated table period
> in the
> > |database..
> > 
> > well that is my point precisely, it seems to imply
> that the updates
> > "before
> > the commit" are seen by connections enrolled in
> the SAME transaction
> > THROUGH
> > THE DATABASE  and frankly  I am a bit
> skeptical as to the level of
> > support for these features in the db or even if
> they exist at all or are
> > just "wishful features" (heck they don't even
> support 2pc and xa
> > right)...
> > 
> > so this smells of "teen spirit" to me... by
> requiring "inflight"
> > visibility
> > of the changed records they put a difficult
> requirement on the db drivers
> > and I don't see it working well.
> > 
> > They could have just required lock steps, as in
> first commit the changes
> > (and the db can follow that semantic) and then
> issue your findBy as just
> > another query...
> > 
> > I am no db expert (they are rare these days) but
> it strikes me as a
> > misguided requirement.
> > 
> > Bill for example couldn't you get the same
> functionality with the
> > serialiazed commits? Is this functionality that
> you couldn't get
> > otherwise?
> > you are the first one to require this feature (and
> you are savvy enough
> > to
> > scratch your itch so that is cool but still I
> wonder...)
> > 
> > but the REAL question is "is it true that you
> cannot see changed tables
> > from
> > a connection participating in the SAME transaction
> that changed it in the
> > first place?"
> > 
> > regards
> > 
> > marcf
> > 
> > |
> > |I don't know much about XA, it having its own set
> of
> > |rules though.

Re: [JBoss-dev] ejbStore() delay seems to be a serious problem

He's not removing the modified bean: he's removing a bean that the 
modified bean used to refer to. The issue is that the remove causes a 
data change immediately, while the table behind the modified bean still 
has the foreign key for the row that's being removed. This violates 
referential integrity - boom!

I thought of suggesting that he put the 'setRecord' method into a 
RequiresNew transaction, but that would break his transactional 
semantics (and might deadlock him). I suppose he could just break the 
remove into a separate transaction, but logically, the code he has is 
exactly what makes sense as a single transaction.

Jay Walters wrote:

> He wants the update SQL to execute before the remove SQL?  The commit isn't
> the issue, it's the order of operations.
> 
> What does the spec say about when remove() needs to execute the SQL?
> 
> My question would be, if the bean has been removed should the persistence
> manager still be trying to update it?  I can understand that one might want
> to somehow consider side effects, such as a database trigger so maybe one
> can't optimize out the update.
> 
> Cheers
> 
> -Original Message-
> From: Scott M Stark [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 12:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
> 
> 
> Why is this a serious problem? The weblogic docs for the flag you mention
> indicate the commit is still not done until the end of the transaction and
> that you would only notice this if your db allows for uncommitted reads.
> 
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> 

Confidential e-mail for addressee only.  Access to this e-mail by anyone else is 
unauthorized.
If you have received this message in error, please notify the sender immediately by 
reply e-mail 
and destroy the original communication.

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


Sorry.  Ok so I'll read a little slower next time.

Now that you've explained it, how would it work to use database RI
underneath an EJB application.  If the bean is in memory but disappears from
the database that isn't all that good.  If he's using commit option C, then
next client to reference the bean will get what?  Object does not exist when
they try to execute a method on the bean?

Cheers

-Original Message-
From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 1:38 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem


He's not removing the modified bean: he's removing a bean that the 
modified bean used to refer to. The issue is that the remove causes a 
data change immediately, while the table behind the modified bean still 
has the foreign key for the row that's being removed. This violates 
referential integrity - boom!



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

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


  User: starksm 
  Date: 01/06/15 11:00:17

  Modified:src/main/org/jboss/logging Log4jService.java
  Log:
  Check the configuration file for a .xml extension and if it exists, use
  the DOMConfigurator rather than PropertyConfigurator
  
  Revision  ChangesPath
  1.7   +12 -3 jboss/src/main/org/jboss/logging/Log4jService.java
  
  Index: Log4jService.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/Log4jService.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Log4jService.java 2001/05/04 06:08:08 1.6
  +++ Log4jService.java 2001/06/15 18:00:17 1.7
  @@ -21,6 +21,7 @@
   import org.apache.log4j.Category;
   import org.apache.log4j.NDC;
   import org.apache.log4j.PropertyConfigurator;
  +import org.apache.log4j.xml.DOMConfigurator;
   
   /** This is a JMX MBean that provides three features:
   1., It initalizes the log4j framework from the log4j properties format file
  @@ -38,7 +39,7 @@
   @author mailto:[EMAIL PROTECTED]";>Fulco Muriglio
   @author [EMAIL PROTECTED]
   @author mailto:[EMAIL PROTECTED]";>David Jencks
  -@version $Revision: 1.6 $
  +@version $Revision: 1.7 $
   */
   public class Log4jService implements Log4jServiceMBean, NotificationListener,
   MBeanRegistration
  @@ -104,6 +105,8 @@
   */
   public void start() throws Exception
   {
  +// See if this is an xml configuration file
  +boolean isXML = configurationPath.endsWith(".xml");
   // Make sure the config file can be found
   ClassLoader loader = Thread.currentThread().getContextClassLoader();
   URL url = loader.getResource(configurationPath);
  @@ -113,11 +116,17 @@
   {
   // configurationPath is a file path
   String path = url.getFile();
  -PropertyConfigurator.configureAndWatch(path, 1000*refreshPeriod);
  +if( isXML )
  +DOMConfigurator.configureAndWatch(path, 1000*refreshPeriod);
  +else
  +PropertyConfigurator.configureAndWatch(path, 1000*refreshPeriod);
   }
   else
   {
  -PropertyConfigurator.configure(url);
  +if( isXML )
  +DOMConfigurator.configure(url);
  +else
  +PropertyConfigurator.configure(url);
   }
   this.category = Category.getRoot();
   category.info("Started Log4jService, config="+url);
  
  
  

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

[JBoss-dev] CVS update: jboss/src/lib log4j.jar


  User: starksm 
  Date: 01/06/15 11:02:43

  Modified:src/lib  log4j.jar
  Log:
  Update to log4j 1.1.2
  
  Revision  ChangesPath
  1.3   +646 -524  jboss/src/lib/log4j.jar
  
<>
  
  

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

Re: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT

2001-06-15 Thread Aaron Mulder


Just a note for people seeing problems that everyhting still
looked broken until I did a "shift-reload" and got "index.jsp" instead of
"index.html" and then magically the site started working again.

Aaron

On Fri, 15 Jun 2001, marc fleury wrote:
> A big, sloppy, thank you thank you thank you to the French Brigade at
> Telecom Paris for being alert and helping out in "firefighter" mode.
> Sebastien fixed it..
>
> Sebastien you the man, discreet as ever, but there when it really really
> counts...
>
> thanks man...
>
> so anyway... jboss.org is back online and it is all running on JBoss/Tomcat.
> Pure JSP etc etc...
>
> thanks to those who helped out and regards
>
> marcf
>
> PS: come on come on go try it out already !
>
> _
> Marc Fleury, Ph.D
> [EMAIL PROTECTED]
> _
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


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

Re: [JBoss-dev] No storeEntity before ejbFind

Jay Walters wrote:

> You are still confused Gina, if you go into SQL*Plus and type the following
> 
> create table foo ( x varchar(32));
> set autocommit off;
> insert into foo values ('gina');
> select * from foo;
> 
> you will see the value just inserted and you are in the middle of the
> transaction.  Rollback will clean out the table...
> 
> This has always been (V4-V8i) and will always be... otherwise how would
> after triggers work for example.  

Or RI?

Confidential e-mail for addressee only.  Access to this e-mail by anyone else is 
unauthorized.
If you have received this message in error, please notify the sender immediately by 
reply e-mail 
and destroy the original communication.

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


Here's an example to further illustrate why delayed ejbStore() is
problematic.

What about a situation where you keep a 'bucket' in a table to improve the
performance of your application. For example, you keep a
"current_account_balance" in your User table rather than doing a
SUM(transaction_amount) on your Transactions table each time you need an
account balance.

In a Session Bean, I should be allowed to do something like the following
(very roughly pseudocoded):

TransactionBean t = transHome.findByPK(xxx);

t.setTransactionAmount(765.99);

DataSource ds = (DataSource)lookup("MyDS");
Connection con = ds.getConnection();
Statement stat = con.createStatement();

ResultSet rs = stat.executeQuery("SELECT SUM(transaction_amount) AS total
FROM Transactions WHERE user_id = 444");

UserBean u = userHome.findByPK(444);

u.setCurrentAccountBalance(rs.next().getFloat("total"));


Something like that ... In the above case (i've tried it in several areas in
my app), the SELECT() statement is still reading the old data because the
Container hasn't written the changes out ... Of course, I MUST ensure that
this happens in a transaction so that in case there is a problem, I don't
end up with unsynchronized data ..

(I use this example to point out that it's not just that ejbRemove happens
immediately ... making ejbRemove delay as well would not fix the situation i
just described)

-Dave



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of danch
> (Dan Christopherson)
> Sent: Friday, June 15, 2001 1:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> He's not removing the modified bean: he's removing a bean that the
> modified bean used to refer to. The issue is that the remove causes a
> data change immediately, while the table behind the modified bean still
> has the foreign key for the row that's being removed. This violates
> referential integrity - boom!
>
> I thought of suggesting that he put the 'setRecord' method into a
> RequiresNew transaction, but that would break his transactional
> semantics (and might deadlock him). I suppose he could just break the
> remove into a separate transaction, but logically, the code he has is
> exactly what makes sense as a single transaction.
>
> Jay Walters wrote:
>
> > He wants the update SQL to execute before the remove SQL?  The
> commit isn't
> > the issue, it's the order of operations.
> >
> > What does the spec say about when remove() needs to execute the SQL?
> >
> > My question would be, if the bean has been removed should the
> persistence
> > manager still be trying to update it?  I can understand that
> one might want
> > to somehow consider side effects, such as a database trigger so
> maybe one
> > can't optimize out the update.
> >
> > Cheers
> >
> > -Original Message-
> > From: Scott M Stark [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, June 15, 2001 12:38 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
> >
> >
> > Why is this a serious problem? The weblogic docs for the flag
> you mention
> > indicate the commit is still not done until the end of the
> transaction and
> > that you would only notice this if your db allows for uncommitted reads.
> >
> > 
> >
> > ___
> > 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] ejbStore() delay seems to be a serious problem

David Esposito wrote:

> 
> I am surprised that I am the only one that has raised this particular
> example. It seems like it's something that people would do every day.
> 

Actually it's far more common for people to complain about behavior 
closer to what you want - "Why is ejbStore being called so often?" when 
they access an entity directly from their client code.

-danch

Confidential e-mail for addressee only.  Access to this e-mail by anyone else is 
unauthorized.
If you have received this message in error, please notify the sender immediately by 
reply e-mail 
and destroy the original communication.

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


I am wondering how many people are using declarative RI and entity beans?  I
am sure the DBAs like the RI stuff in the database, but EJB seems to like to
be the only game in town - for example leaving it up to the container to
issue the SQL in whatever order it wants.

Cheers

-Original Message-
From: David Esposito [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 1:30 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


That's what I want ... I don't want the data to be committed, I just need it
to be visible by other operations that occur under the same transaction
context. In my example in my email, I neglected to mention what actually
happens when you execute my block of code:

The database throws a hemorrhage because there is a non-cascading delete RI
constraint between the member_company_address table and the credit_card
table. The situation would be even more serious if the constraint WERE
cascading (ON DELETE CASCADE) ... In that case, the remove() method on my
address object would actually remove the credit_card record in the DB that
JBOSS had its hands on. ... Both of which would be avoided if the UPDATE to
the credit_card record had happened immediately when i issued my setXXX()
method on the remote object ..

I am surprised that I am the only one that has raised this particular
example. It seems like it's something that people would do every day.

I could come up with several other illustrative examples of where this is a
problem ... but I think this one is the simplest to understand ...

-Dave

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Friday, June 15, 2001 12:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> Why is this a serious problem? The weblogic docs for the flag you mention
> indicate the commit is still not done until the end of the transaction and
> that you would only notice this if your db allows for uncommitted reads.
>
> From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164
> Using delay-updates-until-end-of-tx to Change ejbStore() Behavior
>
> By default, WebLogic Server updates the persistent store of all
> beans in a transaction only at the completion (commit) of the
> transaction. This generally improves performance by avoiding
> unnecessary updates and repeated calls to ejbStore().
>
> If your datastore uses an isolation level of READ_UNCOMMITTED,
> you may want to allow other database users to view the intermediate
> results of in-progress transactions. In this case, the default
> WebLogic Server behavior of updating the datastore only at
> transaction completion may be unacceptable.
>
> You can disable the default behavior by using the
> delay-updates-until-end-of-tx deployment element. When you set
> this element to
> "false," WebLogic Server calls ejbStore() after each method call,
> rather than at the conclusion of the transaction.
>
> Note: Setting delay-updates-until-end-of-tx to false does not
> cause database updates to be "committed" to the database after each
> method invoke; they are only sent to the database. Updates are
> committed or rolled back in the database only at the conclusion of
> the transaction.
>
>
>
> - Original Message -
> From: "David Esposito" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 9:01 AM
> Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> > Hello all,
> >
> > I have spent the past few hours reading up on other people with similar
> > problems to mine. So I am familiar with what the EJB spec says (somewhat
> > related to the "diamond" scenario (11.7.1 of the EJB Spec))
> with respect to
> > when a Bean is required to write its data out to persistent storage.
> > However, this seems to be counterintuitive and is a serious problem for
> > operations that manipulate multiple data sources.
> >
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


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

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

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


  User: starksm 
  Date: 01/06/15 11:33:46

  Modified:src/main/org/jboss/ejb/plugins SessionObjectInputStream.java
  Log:
  Implement the patch for Bug #432610 by overriding resolveProxyClass to
  use the application class loader.
  
  Revision  ChangesPath
  1.4   +28 -4 
jboss/src/main/org/jboss/ejb/plugins/SessionObjectInputStream.java
  
  Index: SessionObjectInputStream.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/SessionObjectInputStream.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SessionObjectInputStream.java 2000/12/07 15:44:24 1.3
  +++ SessionObjectInputStream.java 2001/06/15 18:33:46 1.4
  @@ -18,6 +18,7 @@
   import java.lang.reflect.Method;
   import java.lang.reflect.Field;
   import java.lang.reflect.InvocationTargetException;
  +import java.lang.reflect.Proxy;
   import java.rmi.RemoteException;
   import java.rmi.ServerException;
   import java.util.Collection;
  @@ -47,7 +48,8 @@
*   @see org.jboss.ejb.plugins.SessionObjectOutputStream
*   @author Rickard Öberg ([EMAIL PROTECTED])
*   @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
  - *   @version $Revision: 1.3 $
  + *   @author [EMAIL PROTECTED]
  + *   @version $Revision: 1.4 $
*/
   class SessionObjectInputStream
extends ObjectInputStream
  @@ -98,8 +100,12 @@
 return obj;
  }
  
  -   protected Class resolveClass(ObjectStreamClass v) throws IOException, 
ClassNotFoundException {
  -  try {
  +   /** Override the ObjectInputStream implementation to use the application class 
loader
  +*/
  +   protected Class resolveClass(ObjectStreamClass v) throws IOException, 
ClassNotFoundException
  +   {
  +  try
  +  {
// use the application classloader to resolve the class
return appCl.loadClass(v.getName());

  @@ -108,5 +114,23 @@
return super.resolveClass(v);
 }
  }
  -  
  +
  +   /** Override the ObjectInputStream implementation to use the application class 
loader
  +*/
  +   protected Class resolveProxyClass(String[] interfaces) throws IOException, 
ClassNotFoundException
  +   {
  +   Class clazz = null;
  +   Class[] ifaceClasses = new Class[interfaces.length];
  +   for(int i = 0; i < interfaces.length; i ++)
  +   ifaceClasses[i] = Class.forName(interfaces[i], false, appCl);
  +   try
  +   {
  +   clazz = Proxy.getProxyClass(appCl, ifaceClasses);
  +   }
  +   catch(IllegalArgumentException e)
  +   {
  +   throw new ClassNotFoundException("Failed to resolve proxy class", e);
  +   }
  +   return clazz;
  +   }
   }
  
  
  

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

Re: [JBoss-dev] ejbStore() delay seems to be a serious problem

I think in this example, though, you're mixing paradigms too much. If 
you want to write SQL in session beans, go ahead. If you want to use 
entity beans as an object layer over the database, do that. You will 
have to be very carefull in mixing them this way.

EJBs are intended to be an Java/OO technology - I'd expect 
to do the summation in the Java space, not the SQL one. 
Will that perform well enough? It depends on the sizes of your datasets 
and how you define 'well enough'.

I think this is another case of the various trade-offs in the EJB spec - 
Its a distributed object component technology, and dismays the RDB folks 
sometimes, but a lot of it seems aimed so squarly at relational storage 
on the backend that it bothers the OO purists at other times.

Imagine if the default behavior were for the ejb container to perform 
store after every method call - people would flog the database to death 
calling individual getters and setters! Adding an option to perform 
ejbStore inline would need to have a fairly fine degree of granularity - 
per method, I think.

David Esposito wrote:

> Here's an example to further illustrate why delayed ejbStore() is
> problematic.
> 
> What about a situation where you keep a 'bucket' in a table to improve the
> performance of your application. For example, you keep a
> "current_account_balance" in your User table rather than doing a
> SUM(transaction_amount) on your Transactions table each time you need an
> account balance.
> 
> In a Session Bean, I should be allowed to do something like the following
> (very roughly pseudocoded):
> 
> TransactionBean t = transHome.findByPK(xxx);
> 
> t.setTransactionAmount(765.99);
> 
> DataSource ds = (DataSource)lookup("MyDS");
> Connection con = ds.getConnection();
> Statement stat = con.createStatement();
> 
> ResultSet rs = stat.executeQuery("SELECT SUM(transaction_amount) AS total
> FROM Transactions WHERE user_id = 444");
> 
> UserBean u = userHome.findByPK(444);
> 
> u.setCurrentAccountBalance(rs.next().getFloat("total"));
> 
> 
> Something like that ... In the above case (i've tried it in several areas in
> my app), the SELECT() statement is still reading the old data because the
> Container hasn't written the changes out ... Of course, I MUST ensure that
> this happens in a transaction so that in case there is a problem, I don't
> end up with unsynchronized data ..
> 
> (I use this example to point out that it's not just that ejbRemove happens
> immediately ... making ejbRemove delay as well would not fix the situation i
> just described)
> 
> -Dave

Confidential e-mail for addressee only.  Access to this e-mail by anyone else is 
unauthorized.
If you have received this message in error, please notify the sender immediately by 
reply e-mail 
and destroy the original communication.

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


  User: starksm 
  Date: 01/06/15 11:51:26

  Modified:src/main/org/jboss/metadata SecurityIdentityMetaData.java
  Log:
  Remove tmp debugging statements
  
  Revision  ChangesPath
  1.3   +1 -3  jboss/src/main/org/jboss/metadata/SecurityIdentityMetaData.java
  
  Index: SecurityIdentityMetaData.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/metadata/SecurityIdentityMetaData.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SecurityIdentityMetaData.java 2001/06/15 14:19:06 1.2
  +++ SecurityIdentityMetaData.java 2001/06/15 18:51:26 1.3
  @@ -20,7 +20,7 @@
   Used in: session, entity, message-driven
   
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.2 $
  +@version $Revision: 1.3 $
   */
   public class SecurityIdentityMetaData extends MetaData
   {
  @@ -69,12 +69,10 @@
   if( callerIdent != null )
   {
   useCallerIdentity = true;
  -System.out.println("SecurityIdentity, useCallerIdentity");
   }
   else
   {
   runAsRoleName = getElementContent(getUniqueChild(runAs, "role-name"));
  -System.out.println("SecurityIdentity, runAsRoleName="+runAsRoleName);
   }
}
   
  
  
  

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

RE: [JBoss-dev] No storeEntity before ejbFind


what am i confused about?
Read Committed is the default option in Oracle for
database access, and don't compare your jdbc driver
access to sql plus..
Read Committed doesn't let you see your own committed
data, but serializable does.
Why am i confused Jay?

--- Jay Walters <[EMAIL PROTECTED]> wrote:
> You are still confused Gina, if you go into SQL*Plus
> and type the following
> 
> create table foo ( x varchar(32));
> set autocommit off;
> insert into foo values ('gina');
> select * from foo;
> 
> you will see the value just inserted and you are in
> the middle of the
> transaction.  Rollback will clean out the table...
> 
> This has always been (V4-V8i) and will always be...
> otherwise how would
> after triggers work for example.  There is a freaky
> option in Oracle they
> put in just to blow out the TPC-A benchmark,
> discrete transactions, that
> doesn't let you read changes during the transaction.
> 
> Cheers
> Jay
> 
> -Original Message-
> From: Gina Hagg [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 1:15 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] No storeEntity before
> ejbFind
> 
> 
> Sorry, I have been out for a while.
> Just wanted to say that 
> Read committed is the default and was the only
> automatic isolation level provided before Oracle
> Release 7.3.
> And Read committed is still the default which
> doesn't
> let anybody even within the transaction see the
> updated changes.
> 
> However, you are right, they added Serializable
> after
> 7.3 which you have to set up as the isolation level,
> which allows you within a transaction see the
> changes
> you have made.
> And it is only in this mode that you can.
> Of course, SQLPlus is Oracle specific which by the
> way
> uses SQLNet and not some JDBC-ODBC driver, and has 
> serializable settings.
> 
> Oracle does advise Read Committed as isolation
> setting
> , therefore i have rarely seen companies use
> anything
> but that... 
> Sorry, if i caused confusion..
> 
> --- David Jencks <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> > Hey guys, think a minute.  What transaction
> > isolation means is _other_
> > transactions can't see your work until you commit.
> 
> > Of course _your_
> > transaction can see everything you've done.  If
> > you're working with say the
> > oracle interactive interface and insert a record
> in
> > a table, if you query
> > the table you can see it right away, you don't
> have
> > to commit first. 
> > _other_ people can't see it until you commit. 
> This
> > has nothing to do with
> > xa or anything else.
> > 
> > [although there is a related issue with "tightly
> > coupled" and "loosely
> > coupled" transaction branches in xa: loosely
> coupled
> > means different
> > branches of the same transaction can't see each
> > others work.  This should
> > only arise when several transaction managers are
> > using the same global
> > transaction against the same resource, and the
> > XAResources can't agree that
> > they are using the same resource.  Maybe this is
> > what you guys are thinking
> > of, but this should only be a potential problem
> with
> > distributed jboss]
> > 
> > I'm pretty sure someone else complained about this
> a
> > couple of weeks ago,
> > although I can't find the reference - they  were
> > modifying an entity, then
> > doing a finder method returning a collection
> > including the "just modified"
> > bean, except they weren't seeing the
> modifications.
> > 
> > In my opinion, if this requirement was not present
> > in ejb 1.1, is was a
> > serious requirements bug, encouraging logically
> > inconsistent behaviour from
> > the container.
> > 
> > Thanks, Bill.
> > 
> > david jencks
> > 
> > On 2001.06.14 15:49:34 -0400 marc fleury wrote:
> > > |I have been working with databases for a long
> > time,
> > > |and particularly with Oracle, I am not aware
> that
> > this
> > > |can happen, whether in transaction or not,
> before
> > > |commit, nobody can see the updated table period
> > in the
> > > |database..
> > > 
> > > well that is my point precisely, it seems to
> imply
> > that the updates
> > > "before
> > > the commit" are seen by connections enrolled in
> > the SAME transaction
> > > THROUGH
> > > THE DATABASE  and frankly  I am a bit
> > skeptical as to the level of
> > > support for these features in the db or even if
> > they exist at all or are
> > > just "wishful features" (heck they don't even
> > support 2pc and xa
> > > right)...
> > > 
> > > so this smells of "teen spirit" to me... by
> > requiring "inflight"
> > > visibility
> > > of the changed records they put a difficult
> > requirement on the db drivers
> > > and I don't see it working well.
> > > 
> > > They could have just required lock steps, as in
> > first commit the changes
> > > (and the db can follow that semantic) and then
> > issue your findBy as just
> > > another query...
> > > 
> > > I am no db expert (they are rare these days) but
> > it strikes me as a
> > > misguided requirement.
>

RE: [JBoss-dev] No storeEntity before ejbFind


Just this excerpt from
http://technet.oracle.com/doc/server.815/a67781/c23cnsis.htm

Oracle offers the read committed and serializable
isolation levels, as well as a read-only mode that is
not part
of SQL92. Read committed is the default and was the
only automatic isolation level provided before Oracle
Release 7.3. The read committed and serializable
isolation levels are discussed more fully in "How
Oracle
Manages Data Concurrency and Consistency". 





--- Jay Walters <[EMAIL PROTECTED]> wrote:
> You are still confused Gina, if you go into SQL*Plus
> and type the following
> 
> create table foo ( x varchar(32));
> set autocommit off;
> insert into foo values ('gina');
> select * from foo;
> 
> you will see the value just inserted and you are in
> the middle of the
> transaction.  Rollback will clean out the table...
> 
> This has always been (V4-V8i) and will always be...
> otherwise how would
> after triggers work for example.  There is a freaky
> option in Oracle they
> put in just to blow out the TPC-A benchmark,
> discrete transactions, that
> doesn't let you read changes during the transaction.
> 
> Cheers
> Jay
> 
> -Original Message-
> From: Gina Hagg [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 1:15 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] No storeEntity before
> ejbFind
> 
> 
> Sorry, I have been out for a while.
> Just wanted to say that 
> Read committed is the default and was the only
> automatic isolation level provided before Oracle
> Release 7.3.
> And Read committed is still the default which
> doesn't
> let anybody even within the transaction see the
> updated changes.
> 
> However, you are right, they added Serializable
> after
> 7.3 which you have to set up as the isolation level,
> which allows you within a transaction see the
> changes
> you have made.
> And it is only in this mode that you can.
> Of course, SQLPlus is Oracle specific which by the
> way
> uses SQLNet and not some JDBC-ODBC driver, and has 
> serializable settings.
> 
> Oracle does advise Read Committed as isolation
> setting
> , therefore i have rarely seen companies use
> anything
> but that... 
> Sorry, if i caused confusion..
> 
> --- David Jencks <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> > Hey guys, think a minute.  What transaction
> > isolation means is _other_
> > transactions can't see your work until you commit.
> 
> > Of course _your_
> > transaction can see everything you've done.  If
> > you're working with say the
> > oracle interactive interface and insert a record
> in
> > a table, if you query
> > the table you can see it right away, you don't
> have
> > to commit first. 
> > _other_ people can't see it until you commit. 
> This
> > has nothing to do with
> > xa or anything else.
> > 
> > [although there is a related issue with "tightly
> > coupled" and "loosely
> > coupled" transaction branches in xa: loosely
> coupled
> > means different
> > branches of the same transaction can't see each
> > others work.  This should
> > only arise when several transaction managers are
> > using the same global
> > transaction against the same resource, and the
> > XAResources can't agree that
> > they are using the same resource.  Maybe this is
> > what you guys are thinking
> > of, but this should only be a potential problem
> with
> > distributed jboss]
> > 
> > I'm pretty sure someone else complained about this
> a
> > couple of weeks ago,
> > although I can't find the reference - they  were
> > modifying an entity, then
> > doing a finder method returning a collection
> > including the "just modified"
> > bean, except they weren't seeing the
> modifications.
> > 
> > In my opinion, if this requirement was not present
> > in ejb 1.1, is was a
> > serious requirements bug, encouraging logically
> > inconsistent behaviour from
> > the container.
> > 
> > Thanks, Bill.
> > 
> > david jencks
> > 
> > On 2001.06.14 15:49:34 -0400 marc fleury wrote:
> > > |I have been working with databases for a long
> > time,
> > > |and particularly with Oracle, I am not aware
> that
> > this
> > > |can happen, whether in transaction or not,
> before
> > > |commit, nobody can see the updated table period
> > in the
> > > |database..
> > > 
> > > well that is my point precisely, it seems to
> imply
> > that the updates
> > > "before
> > > the commit" are seen by connections enrolled in
> > the SAME transaction
> > > THROUGH
> > > THE DATABASE  and frankly  I am a bit
> > skeptical as to the level of
> > > support for these features in the db or even if
> > they exist at all or are
> > > just "wishful features" (heck they don't even
> > support 2pc and xa
> > > right)...
> > > 
> > > so this smells of "teen spirit" to me... by
> > requiring "inflight"
> > > visibility
> > > of the changed records they put a difficult
> > requirement on the db drivers
> > > and I don't see it working well.
> > > 
> > > They could have just required lock steps, as in
> > first commit the changes
> > > (and the db c

Re: [JBoss-dev] ejbStore() delay seems to be a serious problem

2001-06-15 Thread David Jencks


Hi,

Well, another possibility would be ketting your db vendor to check fk
constraints only on transaction boundaries, which would imho make the most
sense, however in the real world, Bill Burke just added (to cvs/2.3-2.4 I
think) some code that forces the container to store all modifications
before executing any finder methods. You could in your example leverage
this feature by:

get ccr.
remember address id
change address id
find old address from remembered address id (forces write of the change you
just made)
remove old address.

I don't know if you can always rearrange your operations to avoid extra
finder calls, but presumably you can always make an extra one to force
writes.

It is possible that I have misinterpreted his code and you have to find an
entity bean of the same class as the one you changed, but I don't think
this is the case.  

david jencks


On 2001.06.15 12:01:09 -0400 David Esposito wrote:
> Hello all,
> 
> I have spent the past few hours reading up on other people with similar
> problems to mine. So I am familiar with what the EJB spec says (somewhat
> related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect
> to
> when a Bean is required to write its data out to persistent storage.
> However, this seems to be counterintuitive and is a serious problem for
> operations that manipulate multiple data sources.
> 
> The flaw is that the Container writes changes out to persistent storage
> immediately for remove() (ejbRemove()) and create() (ejbCreate())
> operations, however, it doesn't write changes out for other Bean business
> methods until the commit() section of the transaction.
> 
> Take the following method from my Stateless SessionBean (transaction set
> to
> Required for the SSB and for the two CMP beans that it is manipulating)
> 
> public Integer runTest(Integer creditCardID, Integer newBillingAddressID)
> throws EJBException
> {
> 
>   CreditCardHome cch =
> (CreditCardHome)TradeIMEJBTools.getHome("blah/CreditCardHome",CreditCardHome
> .class);
>   MemberCompanyAddressHome mcah =
> (MemberCompanyAddressHome)TradeIMEJBTools.getHome("blah/MemberCompanyAddress
> Home",MemberCompanyAddressHome.class);
> 
>   try
>   {
> CreditCard cc = cch.findByPrimaryKey(creditCardID);
> CreditCardRecord ccr = cc.getRecord();
> 
> //Get the address that this credit card is currently pointing to
> MemberCompanyAddress mca = mcah.findByPrimaryKey(new
> MemberCompanyAddressPK(ccr.billing_address_id));
> 
> //Change the address to a different one
> ccr.billing_address_id = newBillingAddressID.intValue();
> 
> //Write the changes to the bean object
> cc.setRecord(ccr);
> 
> //Remove the old address
> mca.remove();
> 
> return null;
> 
> 
>   }
>   catch(Exception e)
>   {
> System.out.println("Error creating record!" + e);
> throw new EJBException("Failure creating records!");
>   }
> }
> 
> Here's what the average guy would think that this does to the DB:
> 
> BEGIN;
> 
> SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> {creditCardID}
> 
> oldBillingAddressID = {previousQuery}.billing_address_id
> 
> UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> credit_card_id = {creditCardID}
> 
> DELETE FROM member_company_address WHERE member_company_address_id =
> {oldBillingAddressID}
> 
> COMMIT;
> 
> But in fact, the order of operations are as follows:
> 
> BEGIN;
> 
> SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> {creditCardID}
> 
> oldBillingAddressID = {previousQuery}.billing_address_id
> 
> DELETE FROM member_company_address WHERE member_company_address_id =
> {oldBillingAddressID}
> 
> UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> credit_card_id = {creditCardID}
> 
> COMMIT;
> 
> This is a serious problem ... Weblogic has implemented a
> "delay-updates-until-end-of-tx" parameter to add to the deployment
> descriptor to allow a developer to override this behavior... Is there any
> chance that the same can be done to JBOSS? Borland App Server supposedly
> has
> something similar ... If not, does anyone have any way to work around
> this
> problem without writing my own BMP beans and calling ejbStore() manually
> after each business method to the bean? Ideally, it would be nice to also
> have a parameter to add to the deployment descriptor to force an
> ejbLoad()
> before each business method ... I understand all of the performance
> implications of doing such things, this is why it seems like it needs to
> be
> part of each beans deployment descriptor rather than a global setting for
> all entity beans.
> 
> I looked at the Interceptor classes in the org.jboss.ejb.plugins
> directory
> and feel that it is beyond my capability to actually implement a fix
> myself.
> However, I would be happy to test any changes that are implemented and
> write
> a section of documention on how to use the new feature.
> 
> Thanks in advance
> 
> -Dave
> 
> 
>

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem

I agree completely with you ... I knew when I wrote the original message
that there would be some strong opinions from both sides of the aisle... I'm
obviously shaded to the RDB side of the aisle mostly because I realize that
there are major performance benefits to letting the database do the work ...
For large applications where a particular entity may have millions of
records, it's impractical to assert that keeping all of the business logic
in the Java space is the best choice.

There are a few ways to handle this and each has its pros and cons. The
unfortunate part of this not being addressed in the bean spec is that each
Container provider will implement their own solution to this problem ... I'm
not a super big fan of Weblogic's solution, but it's better than nothing ...

A) Implement a hack to the Remote interface so that if there is a load() or
store() method in the remote interface, this will trigger the appropriate
ejbLoad (loadEntity) or ejbStore (storeEntity) actions ... (similar to the
way that remove() triggers the ejbRemove (removeEntity) method)

Pros: This will give developers the highest level of control over how the
bean is synchronized with persistent storage ... We will also maintain a
level of caching at the bean layer which would be better than the weblogic
solution .. (i.e. When there isn't a need to synchronize with the DB, we can
use the current Container behavior of keeping the data cached until commit)

Cons: It means that our application (client) code has to be JBOSS specific
...

B) Implement a change to the deployment descriptor similar to Weblogic's

Pros: This keeps the details out of the application (client) and in the
hands of the Container. If this is addressed in a future bean spec or there
is some consensus on how to deal with this in the future, less code changes
and regression testing will be neccessary

Cons: This will lead to a performance drop for the 90% of the cases where I
use my particular bean and this problem DOESN'T manifest itself ... Our
general policy is to only have one getXX() method and one setXX() method for
a bean that reads and writes all of the fields in one shot (to minimize RMI
overhead) but does increase the overall network load  ... so in our case,
this wouldn't really be a major performance issue because most of the beans
only have one "setter"  ...

C) Do nothing

Pros: Zero development time ... Keeps the OO purists happy

Cons: It will make us rethink our use of JBOSS and EJBs, and either move to
Weblogic, or abandon EJBs entirely ...

Personally, I would be satisfied with solution A or B ... ;) ... Solution B
is somewhat more desireable for the purists in the room because it leaves
the details of persistence out of the application developer's hands (well,
not completely, they would still have to add the flag to th deployment
descriptor, but they wouldn't have to worry about "should i force a store()
after these set operations?") ... Solution A is somewhat problematic because
there are some backwards compatibility issues ...

Anyway ... I appreciate everyone's input to this issue as it is a pretty
significant roadblock for our project... We have been very impressed with
the quality of JBOSS and we have made very positive comments to our fellow
Weblogicians about the JBOSS ...

-Dave

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of danch
> (Dan Christopherson)
> Sent: Friday, June 15, 2001 2:39 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> I think in this example, though, you're mixing paradigms too much. If
> you want to write SQL in session beans, go ahead. If you want to use
> entity beans as an object layer over the database, do that. You will
> have to be very carefull in mixing them this way.
>
> EJBs are intended to be an Java/OO technology - I'd expect
> to do the summation in the Java space, not the SQL one.
> Will that perform well enough? It depends on the sizes of your datasets
> and how you define 'well enough'.
>
> I think this is another case of the various trade-offs in the EJB spec -
> Its a distributed object component technology, and dismays the RDB folks
> sometimes, but a lot of it seems aimed so squarly at relational storage
> on the backend that it bothers the OO purists at other times.
>
> Imagine if the default behavior were for the ejb container to perform
> store after every method call - people would flog the database to death
> calling individual getters and setters! Adding an option to perform
> ejbStore inline would need to have a fairly fine degree of granularity -
> per method, I think.
>
>
> David Esposito wrote:
>
> > Here's an example to further illustrate why delayed ejbStore() is
> > problematic.
> >
> > What about a situation where you keep a 'bucket' in a table to
> improve the
> > performance of your application. For example, you keep a
> > "current_account_balance" in your User table rather

RE: [JBoss-dev] No storeEntity before ejbFind

2001-06-15 Thread David Jencks


Hi,
sorry to nitpick, however my experience with Oracle's implementation of
read committed is that all operations done in a transaction are definitely
visible within that transaction.  They are not visible to other
transactions until you commit.  This is the standard industry wide meaning
of read committed.  Can you imagine using a database where you couldn't
verify the effects of your work until after you had committed them?
david jencks

On 2001.06.15 13:14:50 -0400 Gina Hagg wrote:
> Sorry, I have been out for a while.
> Just wanted to say that 
> Read committed is the default and was the only
> automatic isolation level provided before Oracle
> Release 7.3.
> And Read committed is still the default which doesn't
> let anybody even within the transaction see the
> updated changes.
> 
> However, you are right, they added Serializable after
> 7.3 which you have to set up as the isolation level,
> which allows you within a transaction see the changes
> you have made.
> And it is only in this mode that you can.
> Of course, SQLPlus is Oracle specific which by the way
> uses SQLNet and not some JDBC-ODBC driver, and has 
> serializable settings.
> 
> Oracle does advise Read Committed as isolation setting
> , therefore i have rarely seen companies use anything
> but that... 
> Sorry, if i caused confusion..
> 
> --- David Jencks <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> > Hey guys, think a minute.  What transaction
> > isolation means is _other_
> > transactions can't see your work until you commit. 
> > Of course _your_
> > transaction can see everything you've done.  If
> > you're working with say the
> > oracle interactive interface and insert a record in
> > a table, if you query
> > the table you can see it right away, you don't have
> > to commit first. 
> > _other_ people can't see it until you commit.  This
> > has nothing to do with
> > xa or anything else.
> > 
> > [although there is a related issue with "tightly
> > coupled" and "loosely
> > coupled" transaction branches in xa: loosely coupled
> > means different
> > branches of the same transaction can't see each
> > others work.  This should
> > only arise when several transaction managers are
> > using the same global
> > transaction against the same resource, and the
> > XAResources can't agree that
> > they are using the same resource.  Maybe this is
> > what you guys are thinking
> > of, but this should only be a potential problem with
> > distributed jboss]
> > 
> > I'm pretty sure someone else complained about this a
> > couple of weeks ago,
> > although I can't find the reference - they  were
> > modifying an entity, then
> > doing a finder method returning a collection
> > including the "just modified"
> > bean, except they weren't seeing the modifications.
> > 
> > In my opinion, if this requirement was not present
> > in ejb 1.1, is was a
> > serious requirements bug, encouraging logically
> > inconsistent behaviour from
> > the container.
> > 
> > Thanks, Bill.
> > 
> > david jencks



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

RE: [JBoss-dev] No storeEntity before ejbFind


Well I am hoping I am just confused and have misunderstood you.

It appeared that you said JDBC connections and Sql*plus ones were different,
and that a if I perform an insert inside a transaction using JDBC that
within the same transaction I would not be able to read the row inserted.

If in fact you did say that there are two things which are significant.
First, the server does not distinguish by client type and both SQL*Plus and
JDBC drivers look essentially the same to it.  They both use the same wire
protocol to speak with the server.

On the second issue, read committed has to do with other transactions.  Run
the embedded JDBC program... you might need to fix up the connection URL.

import java.sql.*;   // JDBC classes
public class Foo {
public static void main( String[] args ) throws SQLException {
// Get connection to the database
DriverManager.registerDriver( new oracle.jdbc.driver.OracleDriver()
);
Connection con = DriverManager.getConnection(
"jdbc:oracle:thin:@localhost:1521:ORCL", "scott", "tiger" );

/*  Create the table */
Statement stmt = con.createStatement();
  stmt.execute( "CREATE TABLE FOO ( X VARCHAR2(32))" );

  con.setAutoCommit( false );
stmt.executeUpdate( "INSERT INTO FOO VALUES ('Gina')" );

/* Won't see Gina here! */
ResultSet rs = stmt.executeQuery( "SELECT X FROM FOO" );
System.out.println( "Gina says see nothing" );
while( rs.next() ) {
System.out.println( "Oh oh, Found " + rs.getString( 1 ));
}
rs.close();

con.rollback();

/* Won't see Gina here for sure! */
rs = stmt.executeQuery( "SELECT X FROM FOO" );
System.out.println( "Won't find anything here!" );
while( rs.next() ) {
System.out.println( "Found " + rs.getString( 1 ));
}

/* All done, drop the table */
  stmt.execute( "DROP TABLE FOO" );
}
}  

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

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


Actually Oracle will do this, are you using Oracle?  You can change the
constraint checking to be deferred until commit.

-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 3:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem


Hi,

Well, another possibility would be ketting your db vendor to check fk
constraints only on transaction boundaries, which would imho make the most
sense, however in the real world, Bill Burke just added (to cvs/2.3-2.4 I
think) some code that forces the container to store all modifications
before executing any finder methods. You could in your example leverage
this feature by:

get ccr.
remember address id
change address id
find old address from remembered address id (forces write of the change you
just made)
remove old address.

I don't know if you can always rearrange your operations to avoid extra
finder calls, but presumably you can always make an extra one to force
writes.

It is possible that I have misinterpreted his code and you have to find an
entity bean of the same class as the one you changed, but I don't think
this is the case.  

david jencks


On 2001.06.15 12:01:09 -0400 David Esposito wrote:
> Hello all,
> 
> I have spent the past few hours reading up on other people with similar
> problems to mine. So I am familiar with what the EJB spec says (somewhat
> related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect
> to
> when a Bean is required to write its data out to persistent storage.
> However, this seems to be counterintuitive and is a serious problem for
> operations that manipulate multiple data sources.
> 
> The flaw is that the Container writes changes out to persistent storage
> immediately for remove() (ejbRemove()) and create() (ejbCreate())
> operations, however, it doesn't write changes out for other Bean business
> methods until the commit() section of the transaction.
> 
> Take the following method from my Stateless SessionBean (transaction set
> to
> Required for the SSB and for the two CMP beans that it is manipulating)
> 
> public Integer runTest(Integer creditCardID, Integer newBillingAddressID)
> throws EJBException
> {
> 
>   CreditCardHome cch =
>
(CreditCardHome)TradeIMEJBTools.getHome("blah/CreditCardHome",CreditCardHome
> .class);
>   MemberCompanyAddressHome mcah =
>
(MemberCompanyAddressHome)TradeIMEJBTools.getHome("blah/MemberCompanyAddress
> Home",MemberCompanyAddressHome.class);
> 
>   try
>   {
> CreditCard cc = cch.findByPrimaryKey(creditCardID);
> CreditCardRecord ccr = cc.getRecord();
> 
> //Get the address that this credit card is currently pointing to
> MemberCompanyAddress mca = mcah.findByPrimaryKey(new
> MemberCompanyAddressPK(ccr.billing_address_id));
> 
> //Change the address to a different one
> ccr.billing_address_id = newBillingAddressID.intValue();
> 
> //Write the changes to the bean object
> cc.setRecord(ccr);
> 
> //Remove the old address
> mca.remove();
> 
> return null;
> 
> 
>   }
>   catch(Exception e)
>   {
> System.out.println("Error creating record!" + e);
> throw new EJBException("Failure creating records!");
>   }
> }
> 
> Here's what the average guy would think that this does to the DB:
> 
> BEGIN;
> 
> SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> {creditCardID}
> 
> oldBillingAddressID = {previousQuery}.billing_address_id
> 
> UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> credit_card_id = {creditCardID}
> 
> DELETE FROM member_company_address WHERE member_company_address_id =
> {oldBillingAddressID}
> 
> COMMIT;
> 
> But in fact, the order of operations are as follows:
> 
> BEGIN;
> 
> SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> {creditCardID}
> 
> oldBillingAddressID = {previousQuery}.billing_address_id
> 
> DELETE FROM member_company_address WHERE member_company_address_id =
> {oldBillingAddressID}
> 
> UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> credit_card_id = {creditCardID}
> 
> COMMIT;
> 
> This is a serious problem ... Weblogic has implemented a
> "delay-updates-until-end-of-tx" parameter to add to the deployment
> descriptor to allow a developer to override this behavior... Is there any
> chance that the same can be done to JBOSS? Borland App Server supposedly
> has
> something similar ... If not, does anyone have any way to work around
> this
> problem without writing my own BMP beans and calling ejbStore() manually
> after each business method to the bean? Ideally, it would be nice to also
> have a parameter to add to the deployment descriptor to force an
> ejbLoad()
> before each business method ... I understand all of the performance
> implications of doing such things, this is why it seems like it needs to
> be
> part of each beans deployment descriptor rather than a global setting for
> all entity beans.
> 
> I looked at the

RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT


7:28am  up 30 days,  9:51,  4 users,  load average: 0.08, 0.03, 0.00
103 processes: 102 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  1.1% user,  3.0% system,  0.0% nice, 95.2% idle
CPU1 states:  0.4% user,  0.4% system,  0.0% nice, 98.2% idle
Mem:  1036004K av,  563048K used,  472956K free,   22644K shrd,  194308K
buff
Swap: 1028120K av, 840K used, 1027280K free  306432K
cached


Hey we talk a lot about speed and times and we all get so focused and all...
and then INTEL and Moore give us goodness...

this is with 6 concurrent java queries (taken a second ago) on people
looking for stuff on jboss... and the load is not much.  It seems that for
JBoss.org the Tomcat stuff is going to be "ok" (or so we hope)

marcf


|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jay
|Walters
|Sent: Friday, June 15, 2001 11:13 AM
|To: '[EMAIL PROTECTED]'
|Subject: RE: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
|
|
|Hey, looks good and runs good.
|
|One sore spot, tried the search documentation feature looking for db2 and
|oracle and got a 404 error back both times.
|
|Great work Marc.  Now we can eat our down dogfood...
|
|Cheers
|
|-Original Message-
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Friday, June 15, 2001 11:10 AM
|To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists.
|Sourceforge. Net
|Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
|
|
|A big, sloppy, thank you thank you thank you to the French Brigade at
|Telecom Paris for being alert and helping out in "firefighter" mode.
|Sebastien fixed it..
|
|Sebastien you the man, discreet as ever, but there when it really really
|counts...
|
|thanks man...
|
|so anyway... jboss.org is back online and it is all running on
|JBoss/Tomcat.
|Pure JSP etc etc...
|
|thanks to those who helped out and regards
|
|marcf
|
|PS: come on come on go try it out already !
|
|_
|Marc Fleury, Ph.D
|[EMAIL PROTECTED]
|_
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



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

[JBoss-dev] CVS update: newsite/manual adv_config.html architecture.html clients.html config.html deploying.html developing.html dtds.html ejx.html examples.html extending.html future.html index.html install.html intro.html jboss-petstore.tgz jms.html license.html managing.html manual.css msjetenginejawstypemapping.txt msjetenginejawstypemappingforjdbcodbc.txt references.html start_stop.html support.html third_party.html trouble.html unix_start.html warning.html


  User: mnf999  
  Date: 01/06/15 13:19:15

  Removed: manual   adv_config.html architecture.html clients.html
config.html deploying.html developing.html
dtds.html ejx.html examples.html extending.html
future.html index.html install.html intro.html
jboss-petstore.tgz jms.html license.html
managing.html manual.css
msjetenginejawstypemapping.txt
msjetenginejawstypemappingforjdbcodbc.txt
references.html start_stop.html support.html
third_party.html trouble.html unix_start.html
warning.html
  Log:
  Removing "manual" stuff

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

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem


Unfortunately, I'm using PostGres ...

Is implementing a Weblogic-style solution very complicated? especially now
that there is the finder solution implemented by Bill Burke? I'd prefer not
to have hacky code all over my app just to deal with something that can be
set externally ..

-Dave

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jay
> Walters
> Sent: Friday, June 15, 2001 3:44 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> Actually Oracle will do this, are you using Oracle?  You can change the
> constraint checking to be deferred until commit.
>
> -Original Message-
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 3:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> Hi,
>
> Well, another possibility would be ketting your db vendor to check fk
> constraints only on transaction boundaries, which would imho make the most
> sense, however in the real world, Bill Burke just added (to cvs/2.3-2.4 I
> think) some code that forces the container to store all modifications
> before executing any finder methods. You could in your example leverage
> this feature by:
>
> get ccr.
> remember address id
> change address id
> find old address from remembered address id (forces write of the
> change you
> just made)
> remove old address.
>
> I don't know if you can always rearrange your operations to avoid extra
> finder calls, but presumably you can always make an extra one to force
> writes.
>
> It is possible that I have misinterpreted his code and you have to find an
> entity bean of the same class as the one you changed, but I don't think
> this is the case.
>
> david jencks
>
>
> On 2001.06.15 12:01:09 -0400 David Esposito wrote:
> > Hello all,
> >
> > I have spent the past few hours reading up on other people with similar
> > problems to mine. So I am familiar with what the EJB spec says (somewhat
> > related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect
> > to
> > when a Bean is required to write its data out to persistent storage.
> > However, this seems to be counterintuitive and is a serious problem for
> > operations that manipulate multiple data sources.
> >
> > The flaw is that the Container writes changes out to persistent storage
> > immediately for remove() (ejbRemove()) and create() (ejbCreate())
> > operations, however, it doesn't write changes out for other
> Bean business
> > methods until the commit() section of the transaction.
> >
> > Take the following method from my Stateless SessionBean (transaction set
> > to
> > Required for the SSB and for the two CMP beans that it is manipulating)
> >
> > public Integer runTest(Integer creditCardID, Integer
> newBillingAddressID)
> > throws EJBException
> > {
> >
> >   CreditCardHome cch =
> >
> (CreditCardHome)TradeIMEJBTools.getHome("blah/CreditCardHome",Cred
> itCardHome
> > .class);
> >   MemberCompanyAddressHome mcah =
> >
> (MemberCompanyAddressHome)TradeIMEJBTools.getHome("blah/MemberComp
> anyAddress
> > Home",MemberCompanyAddressHome.class);
> >
> >   try
> >   {
> > CreditCard cc = cch.findByPrimaryKey(creditCardID);
> > CreditCardRecord ccr = cc.getRecord();
> >
> > //Get the address that this credit card is currently pointing to
> > MemberCompanyAddress mca = mcah.findByPrimaryKey(new
> > MemberCompanyAddressPK(ccr.billing_address_id));
> >
> > //Change the address to a different one
> > ccr.billing_address_id = newBillingAddressID.intValue();
> >
> > //Write the changes to the bean object
> > cc.setRecord(ccr);
> >
> > //Remove the old address
> > mca.remove();
> >
> > return null;
> >
> >
> >   }
> >   catch(Exception e)
> >   {
> > System.out.println("Error creating record!" + e);
> > throw new EJBException("Failure creating records!");
> >   }
> > }
> >
> > Here's what the average guy would think that this does to the DB:
> >
> > BEGIN;
> >
> > SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> > {creditCardID}
> >
> > oldBillingAddressID = {previousQuery}.billing_address_id
> >
> > UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> > credit_card_id = {creditCardID}
> >
> > DELETE FROM member_company_address WHERE member_company_address_id =
> > {oldBillingAddressID}
> >
> > COMMIT;
> >
> > But in fact, the order of operations are as follows:
> >
> > BEGIN;
> >
> > SELECT billing_addres_id FROM credit_card WHERE credit_card_id =
> > {creditCardID}
> >
> > oldBillingAddressID = {previousQuery}.billing_address_id
> >
> > DELETE FROM member_company_address WHERE member_company_address_id =
> > {oldBillingAddressID}
> >
> > UPDATE credit_card SET billing_address_id = {newBillingAddressID} WHERE
> > credit_card_id = {creditCardID}
> >
> > COMMIT;
> >
> > This is a serious problem ... Weblogic has implemented a
> > "delay-updates-

[JBoss-dev] CVS update: newsite/doco_files - New directory


  User: mnf999  
  Date: 01/06/15 14:18:58

  newsite/doco_files - New directory

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

[JBoss-dev] CVS update: newsite/doco_files JBoss-ECperf-patch-001.zip blackbox-tx.rar blackbox-xa.rar cdEJB.tar.gz cdEJB.zip connector-1_0-ea-src.zip interestEJB.tar.gz interestEJB.zip jaas-howto.zip petstore-1.1.1-patch.zip rmh_jboss.zip


  User: mnf999  
  Date: 01/06/15 14:19:51

  Added:   doco_files JBoss-ECperf-patch-001.zip blackbox-tx.rar
blackbox-xa.rar cdEJB.tar.gz cdEJB.zip
connector-1_0-ea-src.zip interestEJB.tar.gz
interestEJB.zip jaas-howto.zip
petstore-1.1.1-patch.zip rmh_jboss.zip
  Log:
  The files for the documentation
  
  Revision  ChangesPath
  1.1  newsite/doco_files/JBoss-ECperf-patch-001.zip
  
<>
  
  
  1.1  newsite/doco_files/blackbox-tx.rar
  
<>
  
  
  1.1  newsite/doco_files/blackbox-xa.rar
  
<>
  
  
  1.1  newsite/doco_files/cdEJB.tar.gz
  
<>
  
  
  1.1  newsite/doco_files/cdEJB.zip
  
<>
  
  
  1.1  newsite/doco_files/connector-1_0-ea-src.zip
  
<>
  
  
  1.1  newsite/doco_files/interestEJB.tar.gz
  
<>
  
  
  1.1  newsite/doco_files/interestEJB.zip
  
<>
  
  
  1.1  newsite/doco_files/jaas-howto.zip
  
<>
  
  
  1.1  newsite/doco_files/petstore-1.1.1-patch.zip
  
<>
  
  
  1.1  newsite/doco_files/rmh_jboss.zip
  
<>
  
  

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

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


  User: starksm 
  Date: 01/06/15 14:54:20

  Modified:src/main/org/jboss/logging Log.java
  Log:
  Add check to prevent invalid console appender configurations from
  creating infinite looping.
  Add NDC.push()/NDC.pop() usage in the Log setLog()/unsetLog() methods
  
  Revision  ChangesPath
  1.12  +5 -1  jboss/src/main/org/jboss/logging/Log.java
  
  Index: Log.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/Log.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Log.java  2001/04/25 04:09:21 1.11
  +++ Log.java  2001/06/15 21:54:20 1.12
  @@ -13,11 +13,13 @@
   import java.util.*;
   import javax.management.*;
   
  +import org.apache.log4j.NDC;
  +
   /** The legacy JBoss logging framework base class.
* @deprecated, As of JBoss 2.3, replaced by the org.apache.log4j framework
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
  - * @version $Revision: 1.11 $
  + * @version $Revision: 1.12 $
*/
   public abstract class Log
   {
  @@ -63,6 +65,7 @@
 {
s.push(log);
 }
  +  NDC.push(log.source.toString());
  }
   
  public static void unsetLog()
  @@ -73,6 +76,7 @@
s.pop();
if (s.size() == 0)
   currentLog.set(null);
  + NDC.pop();
 }
  }
   
  
  
  

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

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


  User: starksm 
  Date: 01/06/15 14:54:20

  Modified:src/main/org/jboss/logging/log4j CategoryStream.java
ConsoleAppender.java
  Log:
  Add check to prevent invalid console appender configurations from
  creating infinite looping.
  Add NDC.push()/NDC.pop() usage in the Log setLog()/unsetLog() methods
  
  Revision  ChangesPath
  1.3   +40 -4 jboss/src/main/org/jboss/logging/log4j/CategoryStream.java
  
  Index: CategoryStream.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/log4j/CategoryStream.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CategoryStream.java   2001/05/22 22:12:57 1.2
  +++ CategoryStream.java   2001/06/15 21:54:20 1.3
  @@ -6,6 +6,7 @@
*/
   package org.jboss.logging.log4j;
   
  +import java.io.IOException;
   import java.io.PrintStream;
   
   import org.apache.log4j.Category;
  @@ -16,12 +17,14 @@
   the log4j Categories. Examples include capturing System.out/System.err writes.
   
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.2 $
  +@version $Revision: 1.3 $
   */
   public class CategoryStream extends PrintStream
   {
   private Category category;
   private Priority priority;
  +private boolean inWrite;
  +private boolean issuedWarning;
   
   /** Redirect logging to the indicated category using Priority.INFO
   */
  @@ -40,19 +43,52 @@
   }
   public void println(String msg)
   {
  -category.log(priority, msg);
  +if( msg == null )
  +msg = "null";
  +byte[] bytes = msg.getBytes();
  +write(bytes, 0, bytes.length);
   }
   public void println(Object msg)
   {
  -category.log(priority, msg);
  +if( msg == null )
  +msg = "null";
  +byte[] bytes = msg.toString().getBytes();
  +write(bytes, 0, bytes.length);
  +}
  +public void write(byte b)
  +{
  +byte[] bytes = {b};
  +write(bytes, 0, 1);
   }
  -public void write(byte[] b, int off, int len)
  +public synchronized void write(byte[] b, int off, int len)
   {
  +if( inWrite == true )
  +{
  +/* There is a configuration error that is causing looping. Most
  + likely there are two console appenders so just return to prevent
  + spinning.
  +*/
  +if( issuedWarning == false )
  +{
  +String msg = "ERROR: invalid console appender config detected, 
console stream is looping";
  +try
  +{
  +out.write(msg.getBytes());
  +}
  +catch(IOException e)
  +{
  +}
  +issuedWarning = true;
  +}
  +return;
  +}
  +inWrite = true;
   // Remove the end of line chars
   while( len > 0 && (b[len-1] == '\n' || b[len-1] == '\r') && len > off )
   len --;
   
   String msg = new String(b, off, len);
   category.log(priority, msg);
  +inWrite = false;
   }
   }
  
  
  
  1.2   +2 -2  jboss/src/main/org/jboss/logging/log4j/ConsoleAppender.java
  
  Index: ConsoleAppender.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/logging/log4j/ConsoleAppender.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ConsoleAppender.java  2001/05/11 02:50:29 1.1
  +++ ConsoleAppender.java  2001/06/15 21:54:20 1.2
  @@ -19,7 +19,7 @@
   system via a category named Default.
   
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.1 $
  +@version $Revision: 1.2 $
   */
   public class ConsoleAppender extends AppenderSkeleton
   {
  @@ -61,8 +61,8 @@
   {
   String msg = this.layout.format(event);
   if( event.priority == Priority.ERROR )
  -out.print(msg);
  -else
   err.print(msg);
  +else
  +out.print(msg);
   }
   }
  
  
  

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

RE: [JBoss-dev] No storeEntity before ejbFind

and, this is from the same page as before.
http://technet.oracle.com/doc/server.815/a67781/c23cnsis.htm#2570

Oracle Isolation Levels 

Oracle provides three transaction isolation levels: 

read committed  
This is the default transaction isolation level. Each
query executed by a transaction sees only data that
was committed before the query (not the transaction)
began. An Oracle query will never read dirty
(uncommitted) data.
Because Oracle does not prevent other transactions
from modifying the data read by a query, that data may
be changed by other transactions between two
executions of the query. Thus, a transaction that
executes a given query twice may experience both
nonrepeatable read and phantoms.  

serializable transactions  
Serializable transactions see only those changes that
were committed at the time the transaction began, plus
those changes made by the transaction itself through
INSERT, UPDATE, and DELETE statements. Serializable
transactions do not experience nonrepeatable reads or
phantoms.

read-only  
Read-only transactions see only those changes that
were committed at the time the transaction began and
do not allow INSERT, UPDATE, and DELETE statements.

--- Jay Walters <[EMAIL PROTECTED]> wrote:
> Well I am hoping I am just confused and have
> misunderstood you.
> 
> It appeared that you said JDBC connections and
> Sql*plus ones were different,
> and that a if I perform an insert inside a
> transaction using JDBC that
> within the same transaction I would not be able to
> read the row inserted.
> 
> If in fact you did say that there are two things
> which are significant.
> First, the server does not distinguish by client
> type and both SQL*Plus and
> JDBC drivers look essentially the same to it.  They
> both use the same wire
> protocol to speak with the server.
> 
> On the second issue, read committed has to do with
> other transactions.  Run
> the embedded JDBC program... you might need to fix
> up the connection URL.
> 
> import java.sql.*;   // JDBC classes
> public class Foo {
> public static void main( String[] args ) throws
> SQLException {
> // Get connection to the database
>   DriverManager.registerDriver( new
> oracle.jdbc.driver.OracleDriver()
> );
> Connection con =
> DriverManager.getConnection(
> "jdbc:oracle:thin:@localhost:1521:ORCL", "scott",
> "tiger" );
> 
> /*  Create the table */
>   Statement stmt = con.createStatement();
>   stmt.execute( "CREATE TABLE FOO ( X
> VARCHAR2(32))" );
> 
>   con.setAutoCommit( false );
>   stmt.executeUpdate( "INSERT INTO FOO VALUES
> ('Gina')" );
> 
>   /* Won't see Gina here! */
>   ResultSet rs = stmt.executeQuery( "SELECT X FROM
> FOO" );
>   System.out.println( "Gina says see nothing" );
>   while( rs.next() ) {
>   System.out.println( "Oh oh, Found " +
> rs.getString( 1 ));
>   }
>   rs.close();
> 
>   con.rollback();
> 
>   /* Won't see Gina here for sure! */
>   rs = stmt.executeQuery( "SELECT X FROM FOO" );
>   System.out.println( "Won't find anything here!" );
>   while( rs.next() ) {
>   System.out.println( "Found " + rs.getString( 1
> ));
>   }
> 
>   /* All done, drop the table */
>   stmt.execute( "DROP TABLE FOO" );
> }
> }  
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
http://lists.sourceforge.net/lists/listinfo/jboss-development

__
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

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

[JBoss-dev] CVS update: newsite CVSAdmin.html


  User: mnf999  
  Date: 01/06/15 15:23:28

  Removed: .CVSAdmin.html
  Log:
  Moving it to JSP format

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

[JBoss-dev] CVS update: newsite CVSAdmin.jsp


  User: mnf999  
  Date: 01/06/15 15:24:03

  Added:   .CVSAdmin.jsp
  Log:
  Putting the JSP format online
  
  Revision  ChangesPath
  1.1  newsite/CVSAdmin.jsp
  
  Index: CVSAdmin.jsp
  ===
  
  
   
  
  
  
  INTRODUCTION
  This document describes the JBoss CVS administration policies for managing
  the sourceforge cvs repository. Comments or questions regarding these polcies
  should be directed to the mailto:[EMAIL PROTECTED]";>jboss-development mailing 
list
  
  
  CREATING AND MANAGING RELEASE BRANCHES
  The CVS branching and release management proceedures are outlined in this section.
  All development of new features occurs on the main trunk. Releases are done on
  branches off of the main trunk.
  Release Numbering
  Releases are tracked using CVS tags that have the following forms:
  
Final Binary Releases: 
JBoss_..
Beta Binary Releases: 
Rel_...
Development Binary Releases(optional): 
JBoss_..
Alpha Development Builds(optional): 
Rel_...
  
  A final binary release is a tested and approved release of the JBoss 
server. The major and
  minor version numbers are fixed for a given branch. The minor version number is 
always even
  on a release branch. Example final release tags are: JBoss_2_2_0, JBoss_2_2_1, 
JBoss_2_4_13,
  JBoss_3_0_0
  
  
  A beta binary release is a candidate final release that is being made available for 
testing.
  The major and minor version numbers are fixed for a given branch. The patch number 
is one
  greater than the current final binary. The build number indicates the number of 
patches that
  have been incorporated into the candidate release. For example, if the latest final
  release is JBoss_2_2_0, then next beta binary release patch number will be 1 and
  build numbers will start at 1. A build number of 0 is used to tag the previous
  final release code. So, if JBoss_2_2_0 were the latest final release, and three
  fixes were incorported into the 2.2 branch, there would be beta binary release tags
  of Rel_2_2_1_0, Rel_2_2_1_1 Rel_2_2_1_2, Rel_2_2_1_3. The idea is that beta binary
  releases are building to the next final binary release, in this case JBoss_2_2_1.
  
  A development binary release is an alpha release of the JBoss 
server. It
  is a snapshot of the functionallity in the main trunk at some point in time.
  The major version number is >= the latest final binary release. The minor version 
number is 1 greater
  than the latest final binary release minor version number. This means that minor 
versions
  of development binaries will always be odd. Example development binary releases are:
  JBoss_2_3_0, JBoss_2_3_1, JBoss_2_5_13, JBoss_3_1_0
  
  
  A alpha development build is a patch beyond a development binary release.
  The patch number is one greater than the current development binary. The build number
  indicates the number of patches that have been incorporated into the candidate build.
  For example, if the latest development build is JBoss_2_3_0, then next alpha build
  patch number will be 1 and build numbers will start at 1. A build number of 0 is used
  to tag the previous devlopment build code. So, if JBoss_2_3_0 were the latest 
development build,
  and three fixes were incorported into the main trunk, there would be alpha release 
tags
  of Rel_2_3_1_0, Rel_2_3_1_1 Rel_2_3_1_2, Rel_2_3_1_3. The idea is that alpha
  builds are leading to the next development build, in this case JBoss_2_3_1.
  
  
  EXAMPLE RELEASE SCENARIOS
  Consider events 1-12 in blue on the following figure:
  
  
  
  Prior to event 1, the latest alpha development build is Rel_2_1_0_57. At this
  point it is decided to create a new binary release.
  
  Event 1 is the creation of a 2.2 branch. It is labeled with a branch tag of 
Branch_2_2. This fixes the
  major version to 2 and the minor version to 2 for all tags on this branch.
  
  Event 2 is the creation of a Rel_2_2_0_0 beta release tag in the branch. It serves as
  an alias to the state of the main branch at the time the 2.2 branch was created.
  
  Event 3 is the creation of a Rel_2_3_0_0 alpha release tag on the main trunk. It
  it is also an alias to the state of the main branch at the time of the 2.2 branch
  creation.
  
  Event 4 is the integration of the first patch/change into the 2.2 branch. After
  the code is commited the Rel_2_2_0_1 tag is applied.
  
  Event 5 is the release of the initial 2.2 branch binary. The release is tagged
  as JBoss_2_2_0 as well as Rel_2_2_1_0 to start the next beta series.
  
  Event 6 is the integration of the first patch/change after the 2.2.0 binary
  release. After the code is commited the Rel_2_2_1_1 tag is applied.
  
  Event 7 is the release of the second 2.2 branch binary. The release is tagged
  as JBoss_2_2_1 as well

[JBoss-dev] CVS update: newsite jboss-zola.html


  User: mnf999  
  Date: 01/06/15 15:34:39

  Removed: .jboss-zola.html
  Log:
  long live zola

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

[JBoss-dev] CVS update: newsite CVSAdmin.jsp


  User: mnf999  
  Date: 01/06/15 15:37:56

  Modified:.CVSAdmin.jsp
  Log:
  looking good on the 
  
  Revision  ChangesPath
  1.2   +9 -7  newsite/CVSAdmin.jsp
  
  Index: CVSAdmin.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/CVSAdmin.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CVSAdmin.jsp  2001/06/15 22:24:03 1.1
  +++ CVSAdmin.jsp  2001/06/15 22:37:56 1.2
  @@ -5,17 +5,18 @@
   
   
   INTRODUCTION
  -This document describes the JBoss CVS administration policies for managing
  +This document describes the JBoss CVS administration policies for 
managing
   the sourceforge cvs repository. Comments or questions regarding these polcies
   should be directed to the mailto:[EMAIL PROTECTED]";>jboss-development mailing 
list
   
   
   CREATING AND MANAGING RELEASE BRANCHES
  -The CVS branching and release management proceedures are outlined in this section.
  +The CVS branching and release management proceedures are outlined 
in this section.
   All development of new features occurs on the main trunk. Releases are done on
   branches off of the main trunk.
  -Release Numbering
  -Releases are tracked using CVS tags that have the following forms:
  +
  +RELEASE NUMBERING
  +Releases are tracked using CVS tags that have the following forms:
   
Final Binary Releases: 
JBoss_..
Beta Binary Releases: 
Rel_...
  @@ -59,7 +60,7 @@
   
   
   EXAMPLE RELEASE SCENARIOS
  -Consider events 1-12 in blue on the following figure:
  +Consider events 1-12 in blue on the following figure:
   
   
   
  @@ -111,7 +112,7 @@
   CVS TASK HOWTO
   
   CHECKING CODE INTO THE MAIN TRUNK
  -New features and bug fixes on unreleased code should go into the main trunk
  +New features and bug fixes on unreleased code should go into the 
main trunk
   which is the latest development branch. The steps for doing this are:
   
   Checkout the target module in which the changes are to be made. For example
  @@ -133,6 +134,7 @@
   
   
   CREATING A NEW BINARY RELEASE BRANCH
  +
   
   
   Perform a clean check out of the jboss main branch without any tags to select the
  @@ -164,7 +166,7 @@
   
   
   CHECKING IN A PATCH ON A RELEASE BRANCH
  -When you have changes that need to go into the codebase of a release branch,
  +When you have changes that need to go into the codebase of a 
release branch,
   you need to check out that branch and make the changes. So for example,
   if you need to add a patch the the 2.2 branch of the example cvs structure
   above, you need to first check out the 2.2 branch using the Branch_2_2 tag.
  
  
  

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

[JBoss-dev] CVS update: newsite jboss-jbossSX.jsp


  User: mnf999  
  Date: 01/06/15 15:51:56

  Added:   .jboss-jbossSX.jsp
  Log:
  The new format of JSP for the security file... let's start telling the world about 
it... it absolutely rocks!
  
  Revision  ChangesPath
  1.1  newsite/jboss-jbossSX.jsp
  
  Index: jboss-jbossSX.jsp
  ===
  
  
   
  
  
  
  JBOSSSX STATE-OF-THE-ART JAAS BASED SECURITY SERVICE



  
  JBossSX is a security service integration layer that support both 
non-JAAS and JAAS based security.
  
   J2EE provides for a limited role based declarative security model, 
but does not specify
how roles are obtained from the operation environment. This is 
an implementation detail left
to the application server. JBossSX provides this 
implementation layer and a great deal more.


  JBossSX was originaly started under the leadership of Dan O'Connor, 
and Oleg Nitz.
Since then, JBossSX has added addition JAAS support and is now 
lead by Scott Stark with
continued help from Oleg Nitz.  Scott has really turned this 
into a world class project on its own and you will find in our product security 
features that you won't find anywhere else no matter how much you are willing to pay.
  



  FEATURES

  
  
Secure authentication of users via JAAS login modules.
Extensible authentication of users via JAAS login modules.
Support for custom per method authentication of users via 
integration with the
  EJB container method interceptor.
Support for JAAS Subject based authorization of users.
Flexible mapping from legacy security systems to JAAS Subject 
based permissions.
  
  


  MAILING LISTS

   The JBossSX mailing list is the jboss-user 
  list. 


  DISTRIBUTION AND CVS

  JBossSX is integrated with the core JBoss/Server. 
  CVS module is jbosssx

  
  
  
  
  

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

[JBoss-dev] CVS update: newsite jboss-jbossmail.jsp jboss-jetty.html


  User: mnf999  
  Date: 01/06/15 15:54:51

  Modified:.jboss-jbossmail.jsp jboss-jetty.html
  Log:
  more link updates
  
  Revision  ChangesPath
  1.2   +4 -4  newsite/jboss-jbossmail.jsp
  
  Index: jboss-jbossmail.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/jboss-jbossmail.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jboss-jbossmail.jsp   2001/06/14 17:33:38 1.1
  +++ jboss-jbossmail.jsp   2001/06/15 22:54:50 1.2
  @@ -55,10 +55,10 @@
HOWTO

 
  - 
  - A complete how-to for JBoss/JBossMail 
was contributed by Simone Bordet and 
  - mailto:[EMAIL PROTECTED]";>Michel de Groot and can be found
  - here. 
  + 
  + A complete how-to for JBoss/JBossMail was contributed by Simone 
  +  Bordet and mailto:[EMAIL PROTECTED]";>Michel de Groot 
  +  and can be found here. 

   
   
  
  
  
  1.2   +7 -8  newsite/jboss-jetty.html
  
  Index: jboss-jetty.html
  ===
  RCS file: /cvsroot/jboss/newsite/jboss-jetty.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jboss-jetty.html  2001/06/14 17:38:31 1.1
  +++ jboss-jetty.html  2001/06/15 22:54:50 1.2
  @@ -148,16 +148,15 @@
   In case you don't want to read all the J2EE spec, here is a brief summary
   of what you have to do:
   
  -
  -Write your beans and package them in an ejb-jar file. You don't
  -have to do anything special here. See the manual
  -for details on how to package beans for jboss.
  + Write your beans and package them in an ejb-jar file. You don't 
have 
  +  to do anything special here. See the manual 
  +  for details on how to package beans for jboss.
   
    
  -
  -Write your servlets/JSPs and package them in a war file. 
  -Add a Class-Path attribute to your war files MANIFEST.MF file to reference your 
beans package. 
  -For detailed information on that see: J2eeDeployment Howto. 
  + Write your servlets/JSPs and package them in a war file. Add 
  +  a Class-Path attribute to your war files MANIFEST.MF file to reference 
  +  your beans package. For detailed information on that see: J2eeDeployment 
  +  Howto. 
   Assuming you have a bean deployed under the jndi name "myBean", the calls to this
   bean from your servlets will look like that: 
   
  
  
  

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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/util FinderResults.java


  User: danch   
  Date: 01/06/15 16:59:08

  Modified:src/main/org/jboss/util FinderResults.java
  Log:
  Clean up of stuff left over in CMPPersistenceManager from 1st round finder 
optimization: my test (1000 entities) now completes in about 8.7 seconds - cached was 
6.4 seconds
  
  Revision  ChangesPath
  1.2   +0 -8  jboss/src/main/org/jboss/util/FinderResults.java
  
  Index: FinderResults.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/FinderResults.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- FinderResults.java2001/05/27 00:49:16 1.1
  +++ FinderResults.java2001/06/15 23:59:08 1.2
  @@ -22,8 +22,6 @@
  
  private Object[] queryArgs;
  
  -   private Map entities;
  -   
  /** Constructor taking the collection of keys to hold and the query data. 
   */
  public FinderResults(Collection keys, Object queryData, Object finder, Object[] 
args) {
  @@ -46,12 +44,6 @@
  }
  public Object[] getQueryArgs() {
 return queryArgs;
  -   }
  -   public Map getEntityMap() {
  -  return entities;
  -   }
  -   public void setEntityMap(Map entities) {
  -  this.entities = entities;
  }
  
  public int size() {
  
  
  

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

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

2001-06-15 Thread patriot1burke


  User: patriot1burke
  Date: 01/06/15 16:35:05

  Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
  Log:
  We can't rely on the EnterpriseContext to provide PassivationJob
  with a valid key because it may get freed to the InstancePool, then
  reused before the PassivationJob executes.
  
  So, PassivationJob's constructor now requires the EnterpriseContext's key
  as a parameter.
  
  Revision  ChangesPath
  1.8   +21 -6 jboss/src/main/org/jboss/ejb/plugins/AbstractInstanceCache.java
  
  Index: AbstractInstanceCache.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractInstanceCache.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- AbstractInstanceCache.java2001/06/11 19:52:26 1.7
  +++ AbstractInstanceCache.java2001/06/15 23:35:05 1.8
  @@ -56,7 +56,8 @@
* 
*
* @author Simone Bordet ([EMAIL PROTECTED])
  - * @version $Revision: 1.7 $
  + * @author Bill Burke
  + * @version $Revision: 1.8 $
*/
   public abstract class AbstractInstanceCache
implements InstanceCache, XmlLoadable, Monitorable, MetricsConstants
  @@ -592,13 +593,16 @@
Object key = getKey(bean);
if (m_passivationJobs.get(key) == null)
{
  - // Create the passivation job
  - PassivationJob job = new PassivationJob(bean)
  + // (Bill Burke) We can't rely on the EnterpriseContext 
to provide PassivationJob
  + // with a valid key because it may get freed to the 
InstancePool, then
  + // reused before the PassivationJob executes.
  + //
  + PassivationJob job = new PassivationJob(bean, key)
{
public void execute() throws Exception
{
  - EnterpriseContext ctx = 
getEnterpriseContext();
  - Object id = getKey(ctx);
  + EnterpriseContext ctx = 
this.getEnterpriseContext();
  + Object id = this.getKey();
   
if (id == null)
{
  @@ -762,16 +766,27 @@
   abstract class PassivationJob implements Executable
   {
private EnterpriseContext m_context;
  + private Object m_key;
private boolean m_cancelled;
private boolean m_executed;
   
  - PassivationJob(EnterpriseContext ctx)
  + PassivationJob(EnterpriseContext ctx, Object key)
{
m_context = ctx;
  + m_key = key;
}
   
public abstract void execute() throws Exception;
   
  +/**
  +  * (Bill Burke) We can't rely on the EnterpriseContext to provide 
PassivationJob
  +  * with a valid key because it may get freed to the InstancePool, then
  +  * reused before the PassivationJob executes.
  +  */
  +final Object getKey()
  +{
  + return m_key;
  + }
/**
 * Returns the EnterpriseContext associated with this passivation job,
 * so the bean that will be passivated.
  
  
  

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

[JBoss-dev] CVS update: newsite cvs.jsp

User: mnf999
Date: 01/06/15 15:52:35

Modified:.cvs.jsp
Log:
new links

Revision ChangesPath
1.3 +65 -64newsite/cvs.jsp

Index: cvs.jsp
===
RCS file: /cvsroot/jboss/newsite/cvs.jsp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- cvs.jsp 2001/06/15 15:51:56 1.2
+++ cvs.jsp 2001/06/15 22:52:35 1.3
@@ -1,64 +1,65 @@
-
-
-
-
-
-
-
-
- JBOSS IS DEVELOPED PUBLICLY
- JBoss is a free implementation of the J2EE interfaces from
SUN. Our code is co-developed and the source is freely available. You
- can either get the code in a zip format to browse it or, if you
- plan on working with the source tree, you can set up a
CVS environment
- on your machine.
-
- We thank sourceforge.net for hosting our CVS. http://sourceforge.net";> http://sourceforge.net/sflogo.php?group_id=22866"; width="88" height="31"
border="0" alt="SourceForge Logo">
-SOURCE CODE
-http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/";>Browse the source on-line
- Download a daily updated snapshot of the sources (ZIP archive)
-
-CVS ENVIRONMENT
- To browse the source tree you will need a CVS client.
If you don't have one already installed on your machine you can download http://www.jcvs.org/";>jCVS, the CVS client in java. jCVS will
work on any platform including Linux. However we recommend the native Linux tools or
try http://www.wincvs.org";>winCVS if you are based on a
win32 platform.
- Settings for anonymous browsing:
- CVSROOT is
-:pserver:[EMAIL PROTECTED]:/cvsroot/jboss
- password is blank (type enter)
-Settings for developer access:
- You have to use SSH:
- export CVS_RSH=ssh
- CVSROOT is
-:ext:@cvs.jboss.sourceforge.net:/cvsroot/jboss
-For further explanations see http://sourceforge.net/cvs/?group_id=22866";>instructions at sourceforge
-
- MODULES
- The following modules are available for browsing:
-
-
jboss: the main jboss tree
-
jbosssx: the default security implementation
-
contrib: 3rd party contribution to jboss
-
jbosstest: the testsuite for jboss
-
zoap: an alternative SOAP based invocation
-
ejx: the gui front end of jboss
-
jnp: the JNDI implementation
-
zola: the application model
-
jbossmq: the JMS implementation
-
jbosscx: the JCA implementation
-
jbosspool: generic object pool. A fork from Aaron Mulder's Minerva
-
jboss-j2ee: J2EE core classes
-
manual: JBoss manual
-
-
- CVS Administration Polcies
- For our policies on CVS versioning and branching see: CVS Admin.
-
- More information on Build and Source
- What is Ant?Ant is a Java based build tool. In theory it is
kind of like make without makes wrinkles.
- Why? Why another build tool when there is already make,
gnumake, nmake, jam, and others? Because, they are limited to the OS, or at least the
OS type such as Unix, that you are working on. Makefiles are inherently evil as well.
- Ant is different. Instead a model where it is extended with
shell based commands, it is extended using Java classes. Instead of writing shell
commands, the configuration files are XML based calling out a target tree where
various tasks get executed. Each task is run by an object which implements a
particular Task interface. Granted, this removes some of the expressive power that is
inherent by being able to construct a shell command such as `find . -name foo -exec rm
{}` but it gives you the ability to be cross platform. To work anywhere and
everywhere. And hey, if you really need to execute a shell command, Ant has an exec
rule that

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

2001-06-15 Thread patriot1burke


  User: patriot1burke
  Date: 01/06/15 16:37:05

  Modified:src/main/org/jboss/ejb/plugins
EntityInstanceInterceptor.java
  Log:
  If an exception has been thrown, DO NOT remove the ctx from the InstanceCache
  if the ctx has been registered in an InstanceSynchronization.
  InstanceSynchronization will remove the key for us.
  
  Revision  ChangesPath
  1.30  +6 -2  
jboss/src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java
  
  Index: EntityInstanceInterceptor.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- EntityInstanceInterceptor.java2001/06/11 19:52:26 1.29
  +++ EntityInstanceInterceptor.java2001/06/15 23:37:05 1.30
  @@ -45,7 +45,7 @@
   *   @author Rickard Öberg ([EMAIL PROTECTED])
   *   @author mailto:[EMAIL PROTECTED]";>Marc Fleury
   *   @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
  -*   @version $Revision: 1.29 $
  +*   @version $Revision: 1.30 $
   */
   public class EntityInstanceInterceptor
   extends AbstractInterceptor
  @@ -293,7 +293,11 @@
ctx.setTransaction(null);
}

  - if (exceptionThrown)
  + // If an exception has been thrown, DO NOT remove the ctx
  + // if the ctx has been registered in an InstanceSynchronization.
  + // InstanceSynchronization will remove the key for us
  + if (exceptionThrown && 
  + (tx == null || (mi.getTransaction() != null && 
!((EntityEnterpriseContext)ctx).isInvoked( 
{
// Discard instance
// EJB 1.1 spec 12.3.1
  
  
  

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

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


  User: danch   
  Date: 01/06/15 16:59:07

  Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
  Log:
  Clean up of stuff left over in CMPPersistenceManager from 1st round finder 
optimization: my test (1000 entities) now completes in about 8.7 seconds - cached was 
6.4 seconds
  
  Revision  ChangesPath
  1.21  +7 -31 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
  
  Index: CMPPersistenceManager.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- CMPPersistenceManager.java2001/06/04 20:46:42 1.20
  +++ CMPPersistenceManager.java2001/06/15 23:59:07 1.21
  @@ -46,7 +46,8 @@
   *
   *   @see 
   *   @author mailto:[EMAIL PROTECTED]";>Marc Fleury
  -*   @version $Revision: 1.20 $
  +*   @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
  +*   @version $Revision: 1.21 $
   */
   public class CMPPersistenceManager
   implements EntityPersistenceManager {
  @@ -299,44 +300,19 @@
  return ((EntityCache) con.getInstanceCache()).createCacheKey(id);
   }
   
  +/** find multiple entities */
   public Collection findEntities(Method finderMethod, Object[] args, 
EntityEnterpriseContext ctx)
   throws Exception 
   {
  // The store will find the id and return a collection of PrimaryKeys
  FinderResults ids = store.findEntities(finderMethod, args, ctx);
  -
  -   AbstractInstanceCache cache = (AbstractInstanceCache)con.getInstanceCache();
  -   Map contextMap = new HashMap();
  -   ArrayList keyList = new ArrayList();
  -   Iterator idEnum = ids.iterator();
  -   while(idEnum.hasNext()) {
  -  Object key = idEnum.next();
  -  Object cacheKey = ((EntityCache)cache).createCacheKey(key);
  -  keyList.add(cacheKey);
  -   
  -  Sync mutex = (Sync)cache.getLock(cacheKey);
  -  try
  -  {
  - mutex.acquire();
  -
  - // Get context
  - ctx = (EntityEnterpriseContext)cache.get(cacheKey);
  - // if ctx has a transaction, we skip it - either it's our Tx
  - //or we plain don't want to block here.
  - if (ctx.getTransaction() == null) {
  -contextMap.put(key, ctx);
  - } 
  -  } catch (InterruptedException ignored) {
  -  } finally {
  - mutex.release();
  -  }
  -   }
  -   
  -   ids.setEntityMap(contextMap);
  
  store.loadEntities(ids);
   
  -   return keyList;
  +   // Note: for now we just return the keys - RabbitHole should return the
  +   //   finderResults so that the invoker layer can extend this back 
  +   //   giving the client an OO 'cursor'
  +   return ids.getAllKeys();
   }
   
   /*
  
  
  

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

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


  User: danch   
  Date: 01/06/15 16:59:07

  Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCLoadEntitiesCommand.java
  Log:
  Clean up of stuff left over in CMPPersistenceManager from 1st round finder 
optimization: my test (1000 entities) now completes in about 8.7 seconds - cached was 
6.4 seconds
  
  Revision  ChangesPath
  1.3   +1 -2  
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntitiesCommand.java
  
  Index: JDBCLoadEntitiesCommand.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntitiesCommand.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JDBCLoadEntitiesCommand.java  2001/06/13 06:52:17 1.2
  +++ JDBCLoadEntitiesCommand.java  2001/06/15 23:59:07 1.3
  @@ -41,7 +41,7 @@
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
* @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson)
  - * @version $Revision: 1.2 $
  + * @version $Revision: 1.3 $
*/
   public class JDBCLoadEntitiesCommand
  extends JDBCLoadEntityCommand
  @@ -84,7 +84,6 @@
  protected Object handleResult(ResultSet rs, Object argOrArgs) throws Exception
  {
 FinderResults keys = (FinderResults)((Object[])argOrArgs)[0];
  -  Map instances = keys.getEntityMap();
 while (rs.next())
 {
Object key = createKey(rs);
  
  
  

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

[JBoss-dev] CVS update: newsite doco.jsp faq.jsp


  User: mnf999  
  Date: 01/06/15 15:53:57

  Modified:.doco.jsp faq.jsp
  Log:
  new links  trying to sort out the manual/doco mess
  
  Revision  ChangesPath
  1.2   +6 -6  newsite/doco.jsp
  
  Index: doco.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/doco.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- doco.jsp  2001/06/14 17:33:38 1.1
  +++ doco.jsp  2001/06/15 22:53:57 1.2
  @@ -12,8 +12,8 @@
   THE MANUAL
   The manual contains all the documentation a user needs to install, 
configure and run JBoss. It also includes a quick start section and helps you to make 
your first steps with JBoss. There are two versions, one for the users and the one for 
the contributors:
   
  -   Manual - online HTML 
  -version : Nice layout, chunked into small, fast loading pages.
  +   Manual - online HTML version 
  +: Nice layout, chunked into small, fast loading pages.
   
   Manual - CVS module for contributors : 
   Our environment for building the manual locally and developing new documentation 
can be obtained from the
  @@ -34,13 +34,13 @@
   
   THE FILES
   From time to time the manual mentions that you can download a file 
which may contain some source code, preconfigured packages or examples. Get the name 
of the file you want to download from the manual and select it from the following link:
  -Download files mentioned 
in the manual.
  -
  +Download files mentioned in 
  +  the manual. 
   WORK IN PROGRESS
   The following documents are still "work in progress". They will be 
probably moved into then manual upon completion.
   
  -Running ECperf on 
JBoss
  -  Migrating to JBoss 
2.2
  +  Running ECperf on JBoss
  +  Migrating to JBoss 2.2
   
   

  
  
  
  1.3   +23 -28newsite/faq.jsp
  
  Index: faq.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/faq.jsp,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- faq.jsp   2001/06/14 17:33:38 1.2
  +++ faq.jsp   2001/06/15 22:53:57 1.3
  @@ -7,9 +7,8 @@
   
   

  +FAQ CONTENTS
   
  - FAQ CONTENTS
  -
   JBoss is an Open Source, standards-compliant, Enterprise JavaBeans 
Application Server implemented in 100% Pure Java.The JBoss organization is working to 
deliver JBoss as the premier Enterprise Java application server for the Java 2 
Enterprise Edition platform. JBoss will be delivered under the LGPL licence. 
   

  @@ -55,11 +54,11 @@
   Are there any functional differences 
between jdk1.2 and jdk1.3 ? 
   Any benchmark or performance 
metrics available? 
   How do I get my client working from a 
remote machine ? 
  - EJX won't start, what's wrong ? 
  +EJX won't start, what's wrong ? 
   
   
   
 
  -BEAN 
DEVELOPERS QUESTIONS
  +BEAN DEVELOPERS QUESTIONS
   
   How can I run my EJB jar in JBoss 
?
   Is a programmer guide available for 
JBoss ?
  @@ -67,7 +66,7 @@
   How do I access beans in a 
different jar ?
   
   
  -SERVER 
ADMINISTRATION QUESTIONS
  +SERVER ADMINISTRATION QUESTIONS
   
   How is JBoss started ?
   How do I cleanly shutdown JBoss ?
  @@ -83,7 +82,7 @@
   
   
   
  -'CONTAINER DEVELOPER QUESTIONS
  +CONTAINER DEVELOPER QUESTIONS
   
   Where can I find technical specs 
for the JBoss server ?
   How can I contribute to JBoss 
?
  @@ -370,7 +369,8 @@
   Back to FAQ  
Contents 
   
   Is a programmer's guide available for JBoss 
?
  -Yes, take a look at the JBoss 2.0 documentation.
  +Yes, take a look at the JBoss 
  +  2.0 documentation.
   
   Back to FAQ 
   
  @@ -535,26 +535,24 @@
How do I configure [Database Type] with JBoss ?
   

  -
  -Refer to the Manual, 
  -
  -which has examples 
   
  -for many common databases and procedures 
  +
  +Refer to the Manual, 
  +  which has examples for many common 
  +  databases and procedures for 
  +  the rest.
   
  -for the rest.
  -

   
  -Back to FAQ 
  +
  +Back to FAQ 
Contents 
   
  -Contents 
  -
Is a DTD available for jaws.xml ?
   

   
  -Yes.
  +
  +Yes.
   

   
  @@ -566,7 +564,8 @@

[JBoss-dev] CVS update: newsite jboss-petstore.jsp jboss-projects.jsp jboss-tomcat.jsp


  User: mnf999  
  Date: 01/06/15 15:55:53

  Modified:.jboss-petstore.jsp jboss-projects.jsp
jboss-tomcat.jsp
  Log:
  update the doco mess
  
  Revision  ChangesPath
  1.2   +3 -5  newsite/jboss-petstore.jsp
  
  Index: jboss-petstore.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/jboss-petstore.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jboss-petstore.jsp2001/06/14 17:33:38 1.1
  +++ jboss-petstore.jsp2001/06/15 22:55:53 1.2
  @@ -66,8 +66,6 @@
   DISTRIBUTION


  -The JBoss Pet Store is currently
  - being distributed as the Pet Store patch. 
  -
  -
  -
  +
  +The JBoss Pet Store is currently being distributed as the Pet 
  +  Store patch.  
  
  
  
  1.2   +2 -2  newsite/jboss-projects.jsp
  
  Index: jboss-projects.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/jboss-projects.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jboss-projects.jsp2001/06/14 17:33:38 1.1
  +++ jboss-projects.jsp2001/06/15 22:55:53 1.2
  @@ -19,7 +19,7 @@
   
 JBossTX 
   
  -  JBossSX
  +  JBossSX
   
 JBossSOAP
   
  @@ -92,7 +92,7 @@
   
   JBossSX -- SECURITY SERVICE (JAAS based)

  - 
  + 
As an enterprise-ready system, JBoss comes with a security 
framework.  Based on JAAS the implementation from SUN and IBM, JBossSX is fully 
functional security framework for your enterprise applications.  Integrated with 
JBossServer, JBossSX provides transparent propagation of credentials in our framework. 
   JBossGUI
   
  
  
  
  1.2   +7 -4  newsite/jboss-tomcat.jsp
  
  Index: jboss-tomcat.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/jboss-tomcat.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jboss-tomcat.jsp  2001/06/14 17:33:38 1.1
  +++ jboss-tomcat.jsp  2001/06/15 22:55:53 1.2
  @@ -225,12 +225,15 @@
   
   In case you don't want to read all the J2EE 
spec, here is a brief summary of what you have to do:
   
  -Write your beans and package them in an ejb-jar file.
  - You don't have to do anything special here. See the manual for details on how to package beans 
for JBoss.
  +
  +  Write your beans and package them in an ejb-jar file. You don't have to 
  +do anything special here. See the manual 
  +for details on how to package beans for JBoss.
    
   Write your servlets/JSPs and package them in a war 
file.
  - Add a Class-Path attribute to your war files MANIFEST.MF 
file
  -to reference your beans package. for detailed information 
on that see: J2eeDeployment 
Howto. 
  +Add a Class-Path attribute to your war files MANIFEST.MF file to reference 
  +your beans package. for detailed information on that see: J2eeDeployment 
  +Howto. 
   Assuming you have a bean deployed under the jndi name 
"myBean", the calls to this bean from your servlets will look like that:
   MyBeanHome home = (MyBeanHome)new 
InitialContext().lookup("myBean");
   MyBean bean = home.create();
  
  
  

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

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


  User: danch   
  Date: 01/06/15 17:49:32

  Modified:src/docs customizingjaws.xml
  Log:
  added doc for read-ahead option
  
  Revision  ChangesPath
  1.8   +42 -0 manual/src/docs/customizingjaws.xml
  
  Index: customizingjaws.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/docs/customizingjaws.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- customizingjaws.xml   2001/06/02 08:09:08 1.7
  +++ customizingjaws.xml   2001/06/16 00:49:32 1.8
  @@ -442,6 +442,48 @@
We strongly suggest you use SQL92 as default query 
language. T-SQL is provided for ease-of-use if you have existing T-SQL queries.

   
  +  
  + Advanced options for declared finders
  + Author:
  +
  +   Dan
  +   Christopherson
  +
  +[EMAIL PROTECTED] or [EMAIL PROTECTED]
  + 
  + As of JBoss version 2.3 beta (6/15/2001), it is possible to request
  + that JAWS preload data for all entities selected by a declared finder. This
  + avoids a performance problem where the database will be queried separately
  + to load data for each bean returned by the finder. To activate this 
  + optimization, simply add true to
  + your finder declaration. Note that as of the same version, you can override
  + this option for the autogenerated findAll method as well.
  + 
  + This is an example jaws.xml showing use of this 
option
  + 
  +  

Custom finders coded in your beans
Author: 
  
  
  

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

[JBoss-dev] CVS update: newsite ECPerf.html migration.jsp

User: mnf999
Date: 01/06/15 15:58:06

Added: .ECPerf.html migration.jsp
Log:
Adding the new files

Revision ChangesPath
1.1 newsite/ECPerf.html

Index: ECPerf.html
===
HowTo: Running ECperf on JBoss

Introduction
ECperf is a standard test application for J2EE servers.

This page is preliminary documentation of a Work in Process.
We expect to have JBoss running ECperf by May 1, 2001, June 1 at the latest.
Please post your experiences with ECperf and JBoss to the jboss-user mailing list.

Installation & Configuration

Download ECperf
You can get the test from
http://java.sun.com/j2ee/ecperf/download.html";>Sun's ECperf Download
Page. Download it and unpack it anywhere. The root directory is referred to
below as $ECPERF_HOME.

Download the JBoss ECperf patch file
The patch currently contains:

Tools to build Cloudscape Database
JBoss deployment descriptors
Contributed ANT build and JRun deployment

The patch is currently available from www.jboss.org/documentation/files/JBoss-ECperf-patch-001.zip.

Copy the patch file to a temporary directory and unzip it. The patch
contains a zip file. Unzip the file in your $ECPERF_HOME directory.

1.1 newsite/migration.jsp

Index: migration.jsp
===

GENERAL STRATEGY
Do not erase your old JBoss installation before you
have the new one up and running with your application. Is also a good
thing to make new
backups of all the files you love before you start to upgrade :-).

You could try using your old configuration files, changing some values
and adding all the needed new configuration values. But in most cases it
is better to start with the new configuration files that ship with the
distribution and reapply your changes to these files.
The following step should be taken for every upgrade
of the JBoss server:

On the side of the client you need to replace the jars you copied
from the JBoss distribution. Replace these jars with the new versions
of these jars. The new versions of the jars can be found in the client/ directory of
the
distribution.

MIGRATION FROM 2.0 TO 2.2

For converting your JDBC datasource configuration read the section
"Upgrading from JBoss 2.0 FINAL" in the JDBC chapter of the manual please.
If you provided a jboss.xml file with your jar you should change the
value of to
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker . It is no
longer needed to select jrmp12 or jrmp13 since JBoss should
select the correct version for you automatically.
There are more jar archives for the client side now. At
least you need to copy the following archives and include them
into the CLASSPATH at the client side: jboss-client.jar, jbosssx-client.jar
and jnp-client.jar. Depending on what functionality
you use in your client you may need to include additional archives from
the jboss/client/ directory.

MIGRATION FROM PRE2.1 TO 2.2

If you were using message driven beans (MDB) you should change
to

and
to

(by Torsten Terp)

MIGRATION FROM 2.2 TO 2.2.1

If you were using CastorJDO module, you should get
the new version of
it and move its configuration from jboss.conf to
jboss.jcml. See detailed descripion of the configuraton
here (a tip: the order and
the meaning of parameters wasn't changed).

PLEASE HELP
At the moment these instructions are far away from
being complete. Please send a detailed description of the steps
which are not yet included here but which you needed to take for
your migration to one of the JBoss mailing
lists. Use a subject like "Migration from 2.x to 2.y" and
send it either to JBOSS-USER or JBOSS-DOCS. Your contribution
will then be added to these instructions. Thank you.

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

[JBoss-dev] CVS update: newsite/doco_files jaws.dtd jboss.dtd


  User: mnf999  
  Date: 01/06/15 15:58:06

  Added:   doco_files jaws.dtd jboss.dtd
  Log:
  Adding the new files
  
  Revision  ChangesPath
  1.1  newsite/doco_files/jaws.dtd
  
  Index: jaws.dtd
  ===
  
  
  
  
  
  
  
  


  
  


  
  


  
  
  
  
  


  

  
  
  
  
  
  
  
  
  
  
  


  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  
  
  
  


  
  


  



  
  
  
  
  
  
  


  
  
  
  
  
  
  
  
  
  
  
  
  1.1  newsite/doco_files/jboss.dtd
  
  Index: jboss.dtd
  ===
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

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

RE: [JBoss-dev] No storeEntity before ejbFind

2001-06-15 Thread Bill Burke


Gina,

Why don't you bring up a SQL*PLUS window and try it yourself instead of
quoting Oracle manuals.  My own experiments with SQL*PLUS and jdbc DO NOT
verify your claims.  BTW, I'm on Oracle 8.1.7.  Maybe older versions work
differently.

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Gina
> Hagg
> Sent: Friday, June 15, 2001 5:53 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] No storeEntity before ejbFind
>
>
> and, this is from the same page as before.
> http://technet.oracle.com/doc/server.815/a67781/c23cnsis.htm#2570
>
> Oracle Isolation Levels
>
> Oracle provides three transaction isolation levels:
>
> read committed
> This is the default transaction isolation level. Each
> query executed by a transaction sees only data that
> was committed before the query (not the transaction)
> began. An Oracle query will never read dirty
> (uncommitted) data.
> Because Oracle does not prevent other transactions
> from modifying the data read by a query, that data may
> be changed by other transactions between two
> executions of the query. Thus, a transaction that
> executes a given query twice may experience both
> nonrepeatable read and phantoms.
>
> serializable transactions
> Serializable transactions see only those changes that
> were committed at the time the transaction began, plus
> those changes made by the transaction itself through
> INSERT, UPDATE, and DELETE statements. Serializable
> transactions do not experience nonrepeatable reads or
> phantoms.
>
> read-only
> Read-only transactions see only those changes that
> were committed at the time the transaction began and
> do not allow INSERT, UPDATE, and DELETE statements.
>
> --- Jay Walters <[EMAIL PROTECTED]> wrote:
> > Well I am hoping I am just confused and have
> > misunderstood you.
> >
> > It appeared that you said JDBC connections and
> > Sql*plus ones were different,
> > and that a if I perform an insert inside a
> > transaction using JDBC that
> > within the same transaction I would not be able to
> > read the row inserted.
> >
> > If in fact you did say that there are two things
> > which are significant.
> > First, the server does not distinguish by client
> > type and both SQL*Plus and
> > JDBC drivers look essentially the same to it.  They
> > both use the same wire
> > protocol to speak with the server.
> >
> > On the second issue, read committed has to do with
> > other transactions.  Run
> > the embedded JDBC program... you might need to fix
> > up the connection URL.
> >
> > import java.sql.*;   // JDBC classes
> > public class Foo {
> > public static void main( String[] args ) throws
> > SQLException {
> > // Get connection to the database
> > DriverManager.registerDriver( new
> > oracle.jdbc.driver.OracleDriver()
> > );
> > Connection con =
> > DriverManager.getConnection(
> > "jdbc:oracle:thin:@localhost:1521:ORCL", "scott",
> > "tiger" );
> >
> > /*  Create the table */
> > Statement stmt = con.createStatement();
> >   stmt.execute( "CREATE TABLE FOO ( X
> > VARCHAR2(32))" );
> >
> >   con.setAutoCommit( false );
> > stmt.executeUpdate( "INSERT INTO FOO VALUES
> > ('Gina')" );
> >
> > /* Won't see Gina here! */
> > ResultSet rs = stmt.executeQuery( "SELECT X FROM
> > FOO" );
> > System.out.println( "Gina says see nothing" );
> > while( rs.next() ) {
> > System.out.println( "Oh oh, Found " +
> > rs.getString( 1 ));
> > }
> > rs.close();
> >
> > con.rollback();
> >
> > /* Won't see Gina here for sure! */
> > rs = stmt.executeQuery( "SELECT X FROM FOO" );
> > System.out.println( "Won't find anything here!" );
> > while( rs.next() ) {
> > System.out.println( "Found " + rs.getString( 1
> > ));
> > }
> >
> > /* All done, drop the table */
> >   stmt.execute( "DROP TABLE FOO" );
> > }
> > }
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> __
> Do You Yahoo!?
> Spot the hottest trends in music, movies, and more.
> http://buzz.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] No storeEntity before ejbFind


I'd have to say not only the manuals, but the big TP/database books stink on
this one.  No where does it state that changes made within an ACID
transaction are visible within the transaction, and that ANSI isolation
levels effect other transactions.  It implies this, but not clearly enough
for our friend.

Really, take our word for it, or try the program or SQL scripts I sent.
Otherwise give it a rest, we're not a bunch of yahoots.

Cheers

-Original Message-
From: Bill Burke
To: [EMAIL PROTECTED]
Sent: 6/15/01 7:49 PM
Subject: RE: [JBoss-dev] No storeEntity before ejbFind

Gina,

Why don't you bring up a SQL*PLUS window and try it yourself instead of
quoting Oracle manuals.  My own experiments with SQL*PLUS and jdbc DO
NOT
verify your claims.  BTW, I'm on Oracle 8.1.7.  Maybe older versions
work
differently.

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
Gina
> Hagg
> Sent: Friday, June 15, 2001 5:53 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] No storeEntity before ejbFind
>
>
> and, this is from the same page as before.
> http://technet.oracle.com/doc/server.815/a67781/c23cnsis.htm#2570
>
> Oracle Isolation Levels
>
> Oracle provides three transaction isolation levels:
>
> read committed
> This is the default transaction isolation level. Each
> query executed by a transaction sees only data that
> was committed before the query (not the transaction)
> began. An Oracle query will never read dirty
> (uncommitted) data.
> Because Oracle does not prevent other transactions
> from modifying the data read by a query, that data may
> be changed by other transactions between two
> executions of the query. Thus, a transaction that
> executes a given query twice may experience both
> nonrepeatable read and phantoms.
>
> serializable transactions
> Serializable transactions see only those changes that
> were committed at the time the transaction began, plus
> those changes made by the transaction itself through
> INSERT, UPDATE, and DELETE statements. Serializable
> transactions do not experience nonrepeatable reads or
> phantoms.
>
> read-only
> Read-only transactions see only those changes that
> were committed at the time the transaction began and
> do not allow INSERT, UPDATE, and DELETE statements.
>
> --- Jay Walters <[EMAIL PROTECTED]> wrote:
> > Well I am hoping I am just confused and have
> > misunderstood you.
> >
> > It appeared that you said JDBC connections and
> > Sql*plus ones were different,
> > and that a if I perform an insert inside a
> > transaction using JDBC that
> > within the same transaction I would not be able to
> > read the row inserted.
> >
> > If in fact you did say that there are two things
> > which are significant.
> > First, the server does not distinguish by client
> > type and both SQL*Plus and
> > JDBC drivers look essentially the same to it.  They
> > both use the same wire
> > protocol to speak with the server.
> >
> > On the second issue, read committed has to do with
> > other transactions.  Run
> > the embedded JDBC program... you might need to fix
> > up the connection URL.
> >
> > import java.sql.*;   // JDBC classes
> > public class Foo {
> > public static void main( String[] args ) throws
> > SQLException {
> > // Get connection to the database
> > DriverManager.registerDriver( new
> > oracle.jdbc.driver.OracleDriver()
> > );
> > Connection con =
> > DriverManager.getConnection(
> > "jdbc:oracle:thin:@localhost:1521:ORCL", "scott",
> > "tiger" );
> >
> > /*  Create the table */
> > Statement stmt = con.createStatement();
> >   stmt.execute( "CREATE TABLE FOO ( X
> > VARCHAR2(32))" );
> >
> >   con.setAutoCommit( false );
> > stmt.executeUpdate( "INSERT INTO FOO VALUES
> > ('Gina')" );
> >
> > /* Won't see Gina here! */
> > ResultSet rs = stmt.executeQuery( "SELECT X FROM
> > FOO" );
> > System.out.println( "Gina says see nothing" );
> > while( rs.next() ) {
> > System.out.println( "Oh oh, Found " +
> > rs.getString( 1 ));
> > }
> > rs.close();
> >
> > con.rollback();
> >
> > /* Won't see Gina here for sure! */
> > rs = stmt.executeQuery( "SELECT X FROM FOO" );
> > System.out.println( "Won't find anything here!" );
> > while( rs.next() ) {
> > System.out.println( "Found " + rs.getString( 1
> > ));
> > }
> >
> > /* All done, drop the table */
> >   stmt.execute( "DROP TABLE FOO" );
> > }
> > }
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> __
> Do You Yahoo!?
> Spot the hottest trends in music, movies, and more.
> http://buzz.yahoo.com/
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/

[JBoss-dev] Interactive survey