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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 23:55:41

  Removed: src/main/org/jboss/test/security/test
EJBAccessUnitTestCase.java
ProjRepositoryUnitTestCase.java
SecurityProxyUnitTestCase.java
  Log:
  Remove the non-standard security tests

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



[JBoss-dev] CVS update: newsite/src/docs/developers/guide buildsystem-faq.jsp

2001-11-20 Thread Jason Dillon

  User: user57  
  Date: 01/11/20 23:16:57

  Modified:src/docs/developers/guide buildsystem-faq.jsp
  Log:
   o Added a section to the faq on module hooks.
  
  Revision  ChangesPath
  1.3   +71 -1 newsite/src/docs/developers/guide/buildsystem-faq.jsp
  
  Index: buildsystem-faq.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/developers/guide/buildsystem-faq.jsp,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- buildsystem-faq.jsp   2001/11/21 03:21:09 1.2
  +++ buildsystem-faq.jsp   2001/11/21 07:16:57 1.3
  @@ -1,5 +1,5 @@
   
  -
  +
   
  
   
  @@ -19,6 +19,7 @@
   
   
Why can't I use ant directly?
  + What are hooks?
  
   
   
  @@ -44,6 +45,75 @@
   
   See the Build System Guide 
  for more details.
  +
  +[Contents]
  +
  +What are hooks?
  +
  +If you have looked through a build/build.xml file, you may have
  +   noticed a section dealing with module hooks.  Just what are those hooks
  +   anyways?
  +
  +Well, a hook is basically a callback target.  Well
  +   what does that mean?  The best way to explain the hook concept is probably
  +   to explain what it is used for, or more precisely why these mysterious
  +   bits exist in the build system.
  +
  +The build system is a dynamic and modular beast.  Modules comes, modules
  +   go.  Modules can exists in a project but not be executed due to
  +   the default configuration, or the user may have decided to only run a
  +   specific module list or module group.  Because the list of executed modules
  +   is so dynamic the build system needed a method to execute module specific
  +   actions when those modules were actually exectute, or rather only
  +   when they are executed.  In comes module hooks.
  +
  +Hooks are simply targets named in a specific fasion which will
  +   be executed before and/or after the module is executed (as specified by
  +   the module executor... the bit which executes the list modules, and the
  +   existance of the target as specified by the hook naming convention).
  +
  +So what do these hooks really do?  Well, currently hooks are only used to
  +   pull the output of a given module and place it in the correct
  +   project release location under the build/output directory.
  +
  +The hooks define the module name, as well as the target which is called
  +   on the module to allow differing behavior based on the target specified
  +   by the user.  This is used to only pull the files which were actually
  +   generated by the current module execution.
  +
  +For example, consider the difference between the all and 
  +   most targets.  The first should generate all of the possible
  +   files that a module has to offer, while the latter should only generate
  +   files that are essential or gennerally useful.  most probably
  +   will not build API docs or other supplemental bits, where all
  +   will.
  +
  +Since a single hook that collects all of these outputs would probably
  +   fail unless the all target is invoked, a hook is defined for
  +   each target.
  +
  +These hooks may have a relationship which allows re-use of task elements.
  +   Currently all projects define hooks for the all and most
  +   targets, where the all hooks depends on the most hook.
  +   This is done because the all target will perform the
  +   same functionality of the most target or it will simply call or
  +   depend on it, and thus it is safe to collect the files from the 
  +   most durring calls to all.  The opposite is NOT
  +   true however.  When the most target is called, it is not safe
  +   to assume that the files generated from calls to all exist.
  +
  +With any luck that all makes sense to you now.  If now just remeber that
  +   hooks are used to pull output from modules and generated
  +   the release structure for a project.  For each module that exists in a
  +   project and generates output, hooks should be defined in the
  +   projects build/build.xml file which copy the generated files
  +   from module to project output.
  +
  +If you are a adding support for a new module, or changing an existing
  +   hook, please make sure that you test all of the targets which
  +   will trigger the hook to be called before commiting the changes.  Your
  +   fellow developers will appreciate the extra time you took to test that
  +   everything works... even if they don't show it =)
   
   [Contents]
   
  
  
  

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



[JBoss-dev] Automated JBoss Testsuite Results

2001-11-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   188



Successful tests:  152

Errors:24

Failures:  12





[time of test: 21 November 2001 6:28 GMT]
[java.version: 1.3.1]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.3.1-b24]
[java.vm.name: Java HotSpot(TM) Server VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-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!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.  Its easy, just run the target 
'run-basic-testsuite' from the main build.xml.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



Re: [JBoss-dev] Marshalling exceptions on optimized calls

2001-11-20 Thread Scott M Stark


Because if its local call that can't be optimized and there is an
application exception that is returned without marshalling the
exception handler code can see a ClassCastException due to
different class loaders.

Even without a potential class loader issue, all values including
exceptions need to adhere to the RMI copy semantics if optimization
is off or else we risk exposing component internal state that may be
associated with the exception.

- Original Message -
From: "marc fleury" <[EMAIL PROTECTED]>
To: "Jboss-Development@Lists. Sourceforge. Net"
<[EMAIL PROTECTED]>
Sent: Tuesday, November 20, 2001 9:08 PM
Subject: [JBoss-dev] Marshalling exceptions on optimized calls


> GenericProxy.invokeContainer(O,M,O)
>
> we have if (optimize && isLocal)
>
> and then else
> if local marshaling of exception (ca line 369)
>
> I remember there was a reason why we do this but I can't remember it and
> can't rebuild it as I rewrite these classes.  Does anyone remember?
>
> marcf
>
> 
> Marc Fleury
> President
> JBoss Group, LLC
> 
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>


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



[JBoss-dev] Automated JBoss Testsuite Results

2001-11-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   173



Successful tests:  139

Errors:22

Failures:  12





[time of test: 21 November 2001 5:31 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1-FCS]
[java.vm.name: Classic VM]
[java.vm.info: green threads, nojit]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-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!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.  Its easy, just run the target 
'run-basic-testsuite' from the main build.xml.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



[JBoss-dev] JSR-77 Update

2001-11-20 Thread Andreas Schaefer

Hi Geeks

Today I added a new update to the JSR-77 update which
should give you an idea how JSR-77 will work. It contains:
- type=J2EEManagement (management domain)
- type=J2EEServer (JBoss server instance meaning the logical server)
- type=Node (computer box meaning the physical server)

J2EEManagement contains a list of servers which in turn contain
the link to its parent the J2EEManagement as so on for the Node
where the J2EEServer is the parent.

Future roadmap for this week:
- adding applications (EAR,JAR,WAR files)
- adding JVMs
- adding resources like JNDI, JMS, JDBC etc.
- making the JSR-77 JavaDoc available
Most will work dynamically or at least create static instance which then
can be adjusted by the component owner. Note that most of the components
are not finished and therefore you cannot rely on their implementation right
now (except what I finished).

To test the JSR-77 code just do to jboss-service.xml in /conf/default and
uncomment the first MBean after the Webservice.

Have fun

x
Andreas Schaefer
Senior Consultant
JBoss Group, LLC
x


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



[JBoss-dev] Marshalling exceptions on optimized calls

2001-11-20 Thread marc fleury

GenericProxy.invokeContainer(O,M,O)

we have if (optimize && isLocal)

and then else
if local marshaling of exception (ca line 369)

I remember there was a reason why we do this but I can't remember it and
can't rebuild it as I rewrite these classes.  Does anyone remember?

marcf


Marc Fleury
President
JBoss Group, LLC



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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/management/j2ee NodeMBean.java IpAddress.java J2EEManagedObject.java J2EEServer.java Node.java SingleJBossServerManagement.java

2001-11-20 Thread Andreas Schaefer

  User: schaefera
  Date: 01/11/20 20:50:53

  Modified:src/main/org/jboss/management/j2ee IpAddress.java
J2EEManagedObject.java J2EEServer.java Node.java
SingleJBossServerManagement.java
  Added:   src/main/org/jboss/management/j2ee NodeMBean.java
  Log:
  Added a Node to JSR-77 implementation and added the mbean example to
  jboss-service.xml to test it.
  
  Revision  ChangesPath
  1.3   +1 -1  jboss/src/main/org/jboss/management/j2ee/IpAddress.java
  
  Index: IpAddress.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/IpAddress.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- IpAddress.java2001/11/20 07:01:39 1.2
  +++ IpAddress.java2001/11/21 04:50:53 1.3
  @@ -40,7 +40,7 @@
  {
 super( "IpAddress", pName, pNode );
 if( pAddress == null || pAddress.length() == 0 ) {
  - throw new InvalidParameterException( "There driver must always be defined" 
);
  + throw new InvalidParameterException( "There IP-Address must always be 
defined" );
 }
 mAddress = pAddress;
  }
  
  
  
  1.3   +3 -7  jboss/src/main/org/jboss/management/j2ee/J2EEManagedObject.java
  
  Index: J2EEManagedObject.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/J2EEManagedObject.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- J2EEManagedObject.java2001/11/20 07:01:39 1.2
  +++ J2EEManagedObject.java2001/11/21 04:50:53 1.3
  @@ -162,7 +162,6 @@
  }
  
  public void postRegister( java.lang.Boolean pRegistrationDone ) {
  -  super.postRegister( pRegistrationDone );
 System.out.println( "J2EEManagedObject.postRegister(), parent: " + mParent );
 if( pRegistrationDone.booleanValue() && mParent != null ) {
try {
  @@ -173,15 +172,12 @@
  new Object[] { mName },
  new String [] { ObjectName.class.getName() }
   );
  +super.postRegister( pRegistrationDone );
}
catch( JMException jme ) {
   jme.printStackTrace();
  -/*
  -throw new InvalidParentException(
  -   "Problem to notify the parent about its new child",
  -   jme
  -);
  -*/
  +// Stop it because of the error
  +super.postRegister( new Boolean( false ) );
}
 }
  }
  
  
  
  1.2   +21 -78jboss/src/main/org/jboss/management/j2ee/J2EEServer.java
  
  Index: J2EEServer.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/J2EEServer.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- J2EEServer.java   2001/11/20 07:01:39 1.1
  +++ J2EEServer.java   2001/11/21 04:50:53 1.2
  @@ -2,6 +2,7 @@
   
   import java.util.ArrayList;
   import java.util.Arrays;
  +import java.util.Hashtable;
   import java.util.List;
   
   import javax.management.MalformedObjectNameException;
  @@ -28,8 +29,6 @@
  
  private List mNodes = new ArrayList();
  
  -   private List mPorts = new ArrayList();
  -   
  private List mJVMs = new ArrayList();
  
  private String mJ2eeVendor = null;
  @@ -38,12 +37,13 @@
  // Constructors
  // -
  
  -   public J2EEServer( String pName, ObjectName pDomain )
  +   public J2EEServer( String pName, ObjectName pDomain, String pJ2eeVendor )
 throws
MalformedObjectNameException,
InvalidParentException
  {
 super( "J2EEServer", pName, pDomain );
  +  mJ2eeVendor = pJ2eeVendor;
  }
  
  public J2EEServer(
  @@ -52,7 +52,6 @@
 ObjectName[] pApplications,
 ObjectName[] pResources,
 ObjectName[] pNodes,
  -  ObjectName[] pPorts,
 ObjectName[] pJVMs,
 String pJ2eeVendor
  )
  @@ -64,7 +63,6 @@
 mApplications.addAll( Arrays.asList( pApplications ) );
 mResources.addAll( Arrays.asList( pResources ) );
 mNodes.addAll( Arrays.asList( pNodes ) );
  -  mPorts.addAll( Arrays.asList( pPorts ) );
 mJVMs.addAll( Arrays.asList( pJVMs ) );
 mJ2eeVendor = pJ2eeVendor;
  }
  @@ -73,22 +71,10 @@
  // Properties (Getters/Setters)
  // -  
   
  -   /**
  -   * @return The actual list of Applications deployed on this server. The
  -   *  list is never null but maybe empty.
  -   **/
  public ObjectName[] getApplications() {
 return (ObjectName[]) mApplications.to

[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss-service.xml

2001-11-20 Thread Andreas Schaefer

  User: schaefera
  Date: 01/11/20 20:50:53

  Modified:src/etc/conf/default jboss-service.xml
  Log:
  Added a Node to JSR-77 implementation and added the mbean example to
  jboss-service.xml to test it.
  
  Revision  ChangesPath
  1.15  +9 -1  jboss/src/etc/conf/default/jboss-service.xml
  
  Index: jboss-service.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss-service.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jboss-service.xml 2001/11/19 06:58:56 1.14
  +++ jboss-service.xml 2001/11/21 04:50:53 1.15
  @@ -7,7 +7,7 @@
   
   
   
  -
  +
   
   
   true
  +  
  +
  +  
  +  
  +  
  +
  +  
 
   
 
  
  
  

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



[JBoss-dev] CVS update: thirdparty/sun/jsr77/lib jsr77.jar

2001-11-20 Thread Andreas Schaefer

  User: schaefera
  Date: 01/11/20 20:50:54

  Modified:sun/jsr77/lib jsr77.jar
  Log:
  Added a Node to JSR-77 implementation and added the mbean example to
  jboss-service.xml to test it.
  
  Revision  ChangesPath
  1.4   +8 -7  thirdparty/sun/jsr77/lib/jsr77.jar
  
<>
  
  

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



[JBoss-dev] Deployment question (classpath)

2001-11-20 Thread David Maplesden

Hi All, well Hi David Jencks mostly I guess ;-),

With the new deployment system I have started deploying my application by
simply deploying the *service.xml file and including all the jars it uses in
a  element.

This works very well, I can easily keep all my jars together in a lib
directory and the *service.xml file is easily available for editing and
redeploying.  There is one draw back though.  I have several *.properties
files used by my service that need to also be added to the classpath.
Currently the only way I can find to do this is by putting them in one of
the jars, however I would like to be able to simply place them in my lib
directory (which is specified by my codebase attribute of the classpath
element) so that I can edit them and then redeploy the *service.xml to have
the changes take effect.

I think that in general the ability to add directories to the classpath as
well as jars would be very useful to developers.

Currently if a classpath element is specified with a codebase attribute but
no archives attribute the directory specified by the codebase is searched
for jars which are added to the classpath, I would prefer it if the
directory itself were simply added.

So my questions are:

1) Is there a way to add a simple directory to the classpath of a service?
2) If not, is there a good reason why not?
3) If there is no good reason why not then how difficult do you think this
would be to add?
4) Would you have time to do it, or do you want me to have a hack at it?

Thanks 
David

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001
 

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



RE: [JBoss-dev] Re: Is there a dtd for jbosscmp-jdbc.xml files?

2001-11-20 Thread Dain Sundstrom

> Here is a dtd that may work for jbosscmp-jdbc, based on a 
> large example
> Dain sent me.
> 
>  Except for a couple of "description" typos, the psgml parser 
> apparently
> not liking empty elements and one question, I think it agrees 
> with the doc
> Dain sent.  2 things:
> 
> - There is one 
>   
>   zip
> 
>   
> 
> 
> Is column-name really optional?

Yep, it is optional.
 
> - I think there may be a problem with correlating between elements, I
> haven't thought about it hard enough to decide:
>  (foreign-key-mapping | table-mapping))>

Correct.
 
>  (ejb-relationship-role, 
> ejb-relationship-role)?>

Correct.
 
>   read-only, time-out, select-for-update,
>  pk-constraint, ejb-relationship-role*)>

Should be:



>  (ejb-relationship-role-name,
>  (foreign-key-fields | 
> table-key-fields))>
> 
> 
> 
> Is the foreign-key-mapping choice correlated with the 
> foreign-key-fields
> choice?

yes. I guess that is impossible to enforce with a dtd. I'll think about how
changing it.

> Also, can you set up a 3-way table-mapping with more than 2
> ejb-relationship-role?
no 
> 
> 
> thanks
> david jencks
> 

Thanks for the work.  I'll read the DTD over in detail later.

-dain

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



[JBoss-dev] Automated JBoss Testsuite Results

2001-11-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   188



Successful tests:  152

Errors:24

Failures:  12





[time of test: 21 November 2001 3:59 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1-FCS]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-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!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.  Its easy, just run the target 
'run-basic-testsuite' from the main build.xml.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



[JBoss-dev] CVS update: newsite/src/docs printable.css

2001-11-20 Thread Jason Dillon

  User: user57  
  Date: 01/11/20 19:42:08

  Modified:src/docs printable.css
  Log:
   o forgot to save file before commit =(
  
  Revision  ChangesPath
  1.2   +5 -0  newsite/src/docs/printable.css
  
  Index: printable.css
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/printable.css,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- printable.css 2001/11/21 03:21:08 1.1
  +++ printable.css 2001/11/21 03:42:08 1.2
  @@ -2,5 +2,10 @@
* Style Sheet for printable pages on the JBoss Users website.
*/
   
  -/* $Id: printable.css,v 1.1 2001/11/21 03:21:08 user57 Exp $ */
  +/* $Id: printable.css,v 1.2 2001/11/21 03:42:08 user57 Exp $ */
   
  +.code, .command, .output { 
  +   background-color: #ff;
  +   color: #00;
  +   border-color: #00;
  +}
  
  
  

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



[JBoss-dev] CVS update: newsite/src/docs printable.css head.jsp index.jsp main.css navigation.jsp slogan.jsp

2001-11-20 Thread Jason Dillon

  User: user57  
  Date: 01/11/20 19:21:09

  Modified:src/docs head.jsp index.jsp main.css navigation.jsp
slogan.jsp
  Added:   src/docs printable.css
  Log:
   o consolidated common styles from /developers into /main.css
 only specifying those colors that changed in /develoeprs/main.css
   o added styles for commonly used tags (A, P, DIV, ...)
   o changed guide/* to use new terse tagging (no need for class attribute
 on everything to get the right look)
   o spruced up the styles for command output, source code and commands
 (which are mostly used in the guides)
   o added [Printable Version] button to each page, which will render the
 current page content (not the navbar or the big jboss header image)
 using a stripped down style which is suitable for printing the current
 page.
   o Added [Top] button to bottom of each page (next to [Home]) which will
 take you to the top of the page.
   o Marked "Quick Start" and "Guides" as "New"
   o Marked all new guides as "New"
  
  Revision  ChangesPath
  1.9   +36 -16newsite/src/docs/head.jsp
  
  Index: head.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/head.jsp,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- head.jsp  2001/11/10 00:37:27 1.8
  +++ head.jsp  2001/11/21 03:21:08 1.9
  @@ -2,32 +2,52 @@
   
   
   
  -  JBoss - WORLD CLASS J2EE TECHNOLOGIES IN OPEN SOURCE
  - 
  +   JBoss - WORLD CLASS J2EE TECHNOLOGIES IN OPEN SOURCE
  +   
  
  
  
  
  -   
  -
  +   
   
  -
  +   <% if (request.getParameter("printable") != null) { %>
  +   
  +   <% } %>
  +
   
   
  - 
  +
  +<% if (request.getParameter("printable") == null) { %>
  +
  +
  +
  +
  +
   
  - 
  - 
  - 
  - 
  - 
  +   
  +   
  +  
  + 
  +   
   
   
  -
   
  - 
  - 
  - 
  - 
  +   
  +   
  +   
  +   
   
   
  +<% } else { %>
  +
  +
  +
  +
  +
  +
  +   
  +  
  +
  +
  +
  +<% } %>
  \ No newline at end of file
  
  
  
  1.31  +4 -4  newsite/src/docs/index.jsp
  
  Index: index.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/index.jsp,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- index.jsp 2001/11/10 18:20:30 1.30
  +++ index.jsp 2001/11/21 03:21:08 1.31
  @@ -64,7 +64,7 @@
   Read more.  

   
  -NEW SELL JBOSS TO YOUR BOSS
  +SELL JBOSS TO YOUR BOSS NEW
   
   "Selling to the IT man" becomes your job as JBoss massively crosses over into the 
mainstream IT sphere.
   Feel free to use the JBoss powerpoint presentation we have prepared for you.
  @@ -72,13 +72,13 @@
   TCO you can achieve with JBoss and JBoss Group. 
   Read more
   
  -NEW INTERVIEW WITH MARC FLEURY
  +INTERVIEW WITH MARC FLEURY NEW
   JBoss founder and lead developer, Marc Fleury, responds in bulk to 
questions 
   he receives every day concerning JBoss, JBoss Group and his vision of the future of 
the J2EE marketplace.
   Read more
   
   
  -NEW JBOSS SUCCESS STORY OF THE MONTH!
  +JBOSS SUCCESS STORY OF THE MONTH! NEW
   "Just through you'd like to know that the United States Department 
of Labor's Office of the 
   Chief Financial Officer uses JBoss to process about $3.0M worth of financial 
transactions yearly in one 
   application alone. There are several other legacy applications scheduled for 
migration.  By using
  @@ -144,7 +144,7 @@
   -- Michele Rosen, Research Manager, IDC
   
   RECESSION-PROOF YOUR IT BUDGET WITH JBOSS™
  -
  +
   Gartner says "Don't overspend on application server technology" (http://www.nwfusion.com/news/2001/0821gartnerapp.html";>read here).  
   Don't be among the companies they predict could waste $2B between now and 2003.  
They recommend free alternatives. 
   The JBoss organization, a worldwide group of 1000 developers, brings you 
  
  
  
  1.8   +95 -30newsite/src/docs/main.css
  
  Index: main.css
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- main.css  2001/11/19 23:00:22 1.7
  +++ main.css  2001/11/21 03:21:08 1.8
  @@ -1,17 +1,78 @@
   /**
  - * Style Sheet for the JBoss Users website.
  + * CSS Style Sheet for the JBoss website.
*/
   
  -/* $Id: main.css,v 1.7 2001/11/19 23:00:22 user57 Exp $ */
  +/* $Id: main.css,v 1.8 2001/11/21 03:21:08 user57 Exp $ */
   
  -.linkhead {
  +BODY { 
  font-family: Arial,serif;
  +   font-size: 13px; 
  +   color: #00; 
  +}
  +
  +P, DIV, TBODY, TD, LI, DD {
  +   font-size: 13px; 
  +   color: #00; 
  +}
  +
  +THEAD, TH, DT { 
  +   font-weight: bold; 
  +}
  +
  +A { 
  +   color: #003399;
  +}
  +A:hover { 
  +   color: #336633;
  +   text-decoration: underline;
  +

[JBoss-dev] CVS update: newsite/src/docs/developers webstyle.jsp cvs.jsp head.jsp index.jsp main.css navigation.jsp slogan.jsp

2001-11-20 Thread Jason Dillon

  User: user57  
  Date: 01/11/20 19:21:09

  Modified:src/docs/developers cvs.jsp head.jsp index.jsp main.css
navigation.jsp slogan.jsp
  Added:   src/docs/developers webstyle.jsp
  Log:
   o consolidated common styles from /developers into /main.css
 only specifying those colors that changed in /develoeprs/main.css
   o added styles for commonly used tags (A, P, DIV, ...)
   o changed guide/* to use new terse tagging (no need for class attribute
 on everything to get the right look)
   o spruced up the styles for command output, source code and commands
 (which are mostly used in the guides)
   o added [Printable Version] button to each page, which will render the
 current page content (not the navbar or the big jboss header image)
 using a stripped down style which is suitable for printing the current
 page.
   o Added [Top] button to bottom of each page (next to [Home]) which will
 take you to the top of the page.
   o Marked "Quick Start" and "Guides" as "New"
   o Marked all new guides as "New"
  
  Revision  ChangesPath
  1.13  +143 -155  newsite/src/docs/developers/cvs.jsp
  
  Index: cvs.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/developers/cvs.jsp,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- cvs.jsp   2001/11/20 21:34:47 1.12
  +++ cvs.jsp   2001/11/21 03:21:09 1.13
  @@ -1,166 +1,154 @@
   
  +
   
  
   
   
  -   
  +
   
  -   JBOSS IS DEVELOPED PUBLICLY
  +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 a daily snapshot of the sources to browse or if you 
  -  plan on working with the source tree directly, you can set up a CVS 
  -  environment on your machine.
  -
  -
  -
  -   SOURCE CODE
  -
  -   
  -  Source code is available from CVS or 
  -  a nightly updated CVS snapshot.
  -
  -   
  -  NIGHTLY SNAPSHOTS
  -
  -   
  -  Snapshots are only made for the latest development branches, so if you
  -  need a specific branch you will need to use CVS to get at it.
  -
  -   
  -  Browse the available snapshots
  -  or select one of the following:
  -   
  -  jboss-all
  - [zip]
  - [tgz]
  -  jboss-mq
  - [zip]
  - [tgz]
  -  jboss-plugins
  - [zip]
  - [tgz]
  -   
  -
  -   
  -  CVS
  -
  -   
  -  Our CVS repository (amoung other things) is hosted by our friends at
  -  http://sourceforge.net";>
  - http://sourceforge.net/sflogo.php?group_id=22866"; border="0" 
alt="SourceForge" align="absmiddle">.
  -
  -   
  -  The repository is available for online
  -  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/";> 
browsing.
  -  Please note that the structure of the actual repository is 
  -  different than the project layout of a checked out CVS module.
  -
  -   
  -  CVS ENVIRONMENT
  -
  -   
  -  To download the source tree from CVS 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:
  -
  -   
  -  This provides READ-ONLY access to the repository.
  -  The CVSROOT is
  -  
  - :pserver:[EMAIL PROTECTED]:/cvsroot/jboss
  -  
  -   
  -  The password is blank (just press enter).
  -
  -   
  -  Settings for developer access:
  -
  -   
  -  This provides READ-WRITE access to the repository.  You will
  -  need to use SSH, have a SourceForge account and be a valid member
  -  of the jboss project.
  -
  -   
  -  CVSROOT is
  -  
  - 
:ext:@cvs.jboss.sourceforge.net:/cvsroot/jboss
  -  
  -
  -   
  -  For further explanations see 
  -  http://sourceforge.net/cvs/?group_id=22866";>instructions 
  -  at SourceForge.
  - 
  -   CVS MODULES
  -
  -   
  -  Below is a list of the currently supported modules.  These modules are 
  -  created via http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/jboss/CVSROOT/modules?rev=1.72";>CVSROOT/modules,
 
  -  so look there for more information about how they work.
  -
  -   
  -   
  -  jboss-all
  -  Everything required to build JBoss.
  -
  -  jboss-mq
  -  The JBossMQ standalone server.
  -
  -  jboss-plugins
  -  Plugins to the JBoss server.
  -
  -  tools
  -  Tools for building modules.
  -
  -  thirdparty
  -  Thridparty 

[JBoss-dev] Automated JBoss Testsuite Results

2001-11-20 Thread chris



JBoss daily test results

SUMMARY

Number of tests run:   188



Successful tests:  150

Errors:25

Failures:  13





[time of test: 21 November 2001 3:12 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
[java.vm.version: 1.3.0]
[java.vm.name: Classic VM]
[java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)]
[os.name: Linux]
[os.arch: x86]
[os.version: 2.4.9-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!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



PS BEFORE you commit, run the test suite.  Its easy, just run the target 
'run-basic-testsuite' from the main build.xml.

PPS Come on people - there were a few days back in July 2001 when we had ZERO tests 
failing!

Oh, and thanks - remember we love you too!



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



[JBoss-dev] CVS update: newsite/src/docs/common picateam.jsp

2001-11-20 Thread Jason Dillon

  User: user57  
  Date: 01/11/20 18:42:55

  Modified:src/docs/common picateam.jsp
  Log:
   o randomly setting the image alignment to "left" or "right" to spice up
 things a little bit more =)
  
  Revision  ChangesPath
  1.4   +6 -5  newsite/src/docs/common/picateam.jsp
  
  Index: picateam.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/common/picateam.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- picateam.jsp  2001/11/17 04:19:12 1.3
  +++ picateam.jsp  2001/11/21 02:42:55 1.4
  @@ -36,7 +36,7 @@
"dain.jpg"
   };
   
  - String[] names = {
  +String[] names = {
"Marc Fleury, USA",
"Scott Stark, USA",
"Anatoly Akkerman, USA",
  @@ -74,9 +74,10 @@
   };
   
   java.util.Random random = new java.util.Random();
  -
   %>
  +<% int select = new Float(random.nextFloat()*people.length).intValue(); %>
   
  -   
  -alt="<%= names[select] %>" src="/pictures/<%= people[select] %>">
  +   " 
  +border="1" hspace="10" vspace="3"
  +alt="<%= names[select] %>"
  +src="/pictures/<%= people[select] %>">
  
  
  

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



[JBoss-dev] Re: [jboss-docs] Is the build system too complicated?

2001-11-20 Thread Jason Dillon

I have not found an easy way to provide this common setup/initialization 
stuff as a resource.  Perhaps if I could tell the JAXP parser to read a 
resource file when parsing this could be done, but that would require the 
Ant entity hooks to be installed to handle that.

Perhaps they have done that, perhaps I could sway them todo it... though my 
previous attempts to do so has failed (too much *ucking voting).

If you can think of a way please let me know.

Thanks for your feedback!

--jason


On Tue, 20 Nov 2001, David Jencks wrote:

> It has often seemed to me that there is substantial duplication between the
> setup parts of the module level build.xml files.  I sure haven't figured
> out a clue of a way to reduce this, but if it could be done, it might make
> the files a little less intimidating.  In light of the vast improvement
> over the preceding build "system", this is a hardly visible quibble.
> 
> david jencks
> 
> On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
> > Please let me know if you think that the build system is too complicated,
> > or 
> > if there is some part of the system which is too complicated.
> > 
> > --jason
> > 
> > 
> > 
> > ---
> > Subscribe: [EMAIL PROTECTED]
> > Unsubscribe:[EMAIL PROTECTED]
> > Archive: http://groups.yahoo.com/group/jboss-docs/ 
> > 
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > 
> > 
> > 
> > 
> > 
> 
>  Yahoo! Groups Sponsor -~-->
> Universal Inkjet Refill Kit $29.95
> Refill any ink cartridge for less!
> Includes black and color ink.
> http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
> -~->
> 
> ---
> Subscribe: [EMAIL PROTECTED]
> Unsubscribe:[EMAIL PROTECTED]
> Archive: http://groups.yahoo.com/group/jboss-docs/ 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 


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



[JBoss-dev] Re: Is there a dtd for jbosscmp-jdbc.xml files?

2001-11-20 Thread David Jencks

Here is a dtd that may work for jbosscmp-jdbc, based on a large example
Dain sent me.

 Except for a couple of "description" typos, the psgml parser apparently
not liking empty elements and one question, I think it agrees with the doc
Dain sent.  2 things:

- There is one 

zip




Is column-name really optional?

- I think there may be a problem with correlating between elements, I
haven't thought about it hard enough to decide:










Is the foreign-key-mapping choice correlated with the foreign-key-fields
choice?

Also, can you set up a 3-way table-mapping with more than 2
ejb-relationship-role?



thanks
david jencks









































































































 





































































































































































[JBoss-dev] Re: [jboss-docs] Is the build system too complicated?

2001-11-20 Thread David Jencks

It has often seemed to me that there is substantial duplication between the
setup parts of the module level build.xml files.  I sure haven't figured
out a clue of a way to reduce this, but if it could be done, it might make
the files a little less intimidating.  In light of the vast improvement
over the preceding build "system", this is a hardly visible quibble.

david jencks

On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
> Please let me know if you think that the build system is too complicated,
> or 
> if there is some part of the system which is too complicated.
> 
> --jason
> 
> 
>  Yahoo! Groups Sponsor -~-->
> Universal Inkjet Refill Kit $29.95
> Refill any ink cartridge for less!
> Includes black and color ink.
> http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/9rHolB/TM
> -~->
> 
> ---
> Subscribe: [EMAIL PROTECTED]
> Unsubscribe:[EMAIL PROTECTED]
> Archive: http://groups.yahoo.com/group/jboss-docs/ 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 
> 
> 
> 
> 

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



Re: [JBoss-dev] redesigning J2EE packaging

2001-11-20 Thread Scott M Stark

I agree that we need to much better notion of what constitutes an
application
deployment, and I would generalize this into the concept of application
domains. Not that your necessarily implying this, but focusing on a single
XML file as the centerpiece is not a fundamental design criterion. I'm all
for
supporting the import of an application domain definition using a single
XML descriptor, but that is just an implementation detail.

The fundamental API we should be looking to support is a meta data driven
object model that is independent of any particular serialized form. The
most general containing component should be a distributed application
domain into which clustering, security, services, and components fit.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: "Anatoly Akkerman" <[EMAIL PROTECTED]>
To: "JBoss-Dev" <[EMAIL PROTECTED]>
Sent: Tuesday, November 20, 2001 12:02 PM
Subject: [JBoss-dev] redesigning J2EE packaging


>
> Hi,
>
> I've been observing some of the recent threads on the list and reflected
> on my current project. Mark has mentioned something of the sort that j2ee
> packaging sucks. I certainly agree.
>
> Here is what seems to be a better design that is consistent with JBoss
> philosophy. Please, don't flame, these are just ideas for discussion.
>
> Deploying anything is just giving 1 xml file to a deployer. No more
> multiple files (Richard mentioned that a few days ago, just use XML
> namespaces and whatever else is needed to glue the pieces together). This
> single XML file has all the necessary information about the item being
> deployed:
>
> For services this would be whatever is now in jboss-service.xml
> For j2ee modules/applications the file would contain sections with
> standard j2ee metadata, jboss-specific metadata, jaws, whatever.
>
> And, I think the crucial part for all of the above , is the
> packaging/scoping information which specifies;
> 1) CL scoping for this deployable entity
> 2) any module-specific class library URLs
> 3) file archive URLs
>
> Here is my look at it. CL Scoping is just a service that JBoss provides
> which ought to be configurable. No more 'implied' derivations of module
> dependencies from awkward MANIFEST.MF Class-Path: entries (though this can
> still be supported). It ought to be configured through standard XML
> descriptors, like any other service.
>
> Scope:
> keeps scope-wise global class library repository
> libraries can be added to the scope/removed/updated
>
> Modules:
> deployed in a scope
> specify libraries it depends on (from the Scope)
> additional libraries/ file archives
>
> I want to be able to just give all the jar library URLs to my personal
> Scope and then deploy only the XML descriptors of j2ee modules.
>
> So, to accomplish this, in this new architecture, one might prepare
> ('deploy') a new Scope with whatever libraries he may want to use. (Say,
> by creating an xml files with the scope description and library URLs that
> need to be made available in this scope)
>
> Then deploy modules in that scope by just giving xml files describing
> these modules. It may also be important to include additional library /
> file archive URLs at module deploy time in that same xml file. For example
> when deploying a WAR, one would necessarily have to provide the WAR file
> archive with jsps, taglibs, whatever else which is not obtained through
> standard classloading mechanisms, so a URL of this archive can be placed
> into the xml.
>
> Nice things about this:
> - no hard coded xml descriptor names (like META-INF/ejb-jar.xml,
>   WEB-INF/web.xml)
> - unified configuration of underlying services in one file
> - package libraries/classes whichever way you want just make them
>   available to the underlying CL through scope definition or
>   module description
> - no more messing with MANIFEST.MF, jarring/unjarring just
>   to modify descriptors, yak...
>
> My current project would benefit tremendously in trimming down
> packaging/unpackaging complexity if this architecture was in place. Do
> others think this may be useful?
>
> -
> Anatoly Akkerman
> Computer Science Dept.
> Courant Institute of Mathematical Sciences, NYU
> 715 Broadway, #719  Tel: 212 998-3493
> New York, NY 10003  Fax: 212 995-4123
> -
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>


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



RE: [JBoss-dev] Re: Is there a dtd for jbosscmp-jdbc.xml files?

2001-11-20 Thread Ignacio Coloma

Send it to the list for the records, please.

If you find problems generating the DTD say so.

Ignacio.

> I think XML spy can do this.  Send me the XML and I'll try tonight.
> 
> Regards,
> Hiram



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



[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool/connector ManagedConnectionPoolFactory.java

2001-11-20 Thread Doug Ferguson

  User: thedug  
  Date: 01/11/20 15:48:44

  Modified:src/main/org/jboss/pool/connector Tag: Branch_2_4
ManagedConnectionPoolFactory.java
  Log:
  factory.destroy is now implemented to destroy the managed connection.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.1.1.2.1 +14 -0 
jbosspool/src/main/org/jboss/pool/connector/Attic/ManagedConnectionPoolFactory.java
  
  Index: ManagedConnectionPoolFactory.java
  ===
  RCS file: 
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/connector/Attic/ManagedConnectionPoolFactory.java,v
  retrieving revision 1.1.1.1
  retrieving revision 1.1.1.1.2.1
  diff -u -r1.1.1.1 -r1.1.1.1.2.1
  --- ManagedConnectionPoolFactory.java 2001/05/15 07:58:24 1.1.1.1
  +++ ManagedConnectionPoolFactory.java 2001/11/20 23:48:44 1.1.1.1.2.1
  @@ -48,6 +48,20 @@
   }
   
   /**
  + * Permanently closes an object, after it is removed from the pool.  The
  + * object will not be returned to the pool - after this, it is gone.  This
  + * is called when the pool shrinks, and when the pool is shut down.
  + */
  +public void deleteObject(Object pooledObject) {
  +try{
  +((ManagedConnection)pooledObject).destroy();
  +}catch(Exception e) {
  +log.println("deleteObject(): Unable to destroy ManagedConnection: "+e);
  +}
  +
  +}
  +
  +/**
* Creates a new ManagedConnection with the specified
* parameters.
*/
  
  
  

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



RE: [JBoss-dev] Current CVS build.

2001-11-20 Thread Dain Sundstrom

I updated about 20 minutes ago and it works fine for me.

-dain

> -Original Message-
> From: Dave Smith [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 4:58 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] Current CVS build.
> 
> 
> When running a JBOSS build from CVS Nov 20, 17:00 EST it now does not 
> start. Here is the starting sequence. (It shuts down by itself). The 
> config files did work with the build from 2 days ago.
> 
> ./run.sh
> ==
> ==
>   JBoss Bootstrap Environment
> 
>   JAVA: /usr/j2sdk1.3.0/bin/java
> 
>   JAVA_OPTS: -hotspot -Djboss.boot.loader.name=run.sh 
> -Djava.library.path=/home/dave/import/com/candata/bbx 
> -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.
jaxp.DocumentBuilderFactoryImpl 
> -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.S
AXParserFactoryImpl
> 
>   CLASSPATH: /home/dave/j/bin/run.jar:
> 
> ==
> ==
> 
> [GPA] Microkernel ClassLoaders and Libraries initialized
> Libraries adding URLClassLoader 2012031725 key URL 
> file:/home/dave/j/conf/default/
> Libraries adding URLClassLoader -1231209341 key URL 
> file:/home/dave/j/lib/ext/log4j.jar
> Libraries adding URLClassLoader -1729047754 key URL 
> file:/home/dave/j/lib/ext/jboss-spine.jar
> [root] Started Log4jService, 
> config=file:/home/dave/j/conf/default/log4j.properties
> [GPA] General Purpose Architecture [GPA]
> [GPA] Java version: 1.3.0,Blackdown Java-Linux Team
> [GPA] Java VM: Java HotSpot(TM) Client VM 
> Blackdown-1.3.0-FCS,Blackdown 
> Java-Linux Team
> [GPA] OS-System: Linux 2.2.16,i386
> [GPA] JBoss Version : 3.0.0alpha(200109280911)
> [GPA] JBoss start time : Tue Nov 20 17:47:19 EST 2001
> [GPA] localDir : /home/dave/j
> [GPA] installationURL : file:/home/dave/j/
> [GPA] configuration : file:/home/dave/j/conf/default/
> [GPA] libraries : file:/home/dave/j/lib/ext/
> [GPA] local patch directory:
> [GPA] Oh, and remember we love you
> [Shutdown] Shutdown hook added
> [ServiceController] Controller MBean online
> [ServiceDeployer] Starting
> [ServiceDeployer] Found a temp directory left over from a 
> previous run - 
> deleting it.
> [ServiceDeployer] Temporary deploy directory is 
> /home/dave/j/tmp/deploy/ServiceDeployer
> [ServiceDeployer] Started
> [Default] JBoss 3.0.0alpha(200109280911) [RABBIT-HOLE] Started in 
> 0m:1s:193ms
> [Shutdown] Shutting down all services
> [Default] Shutting down
> [ServiceController] Stopping 1 services
> [ServiceController] Stopped 0 services
> [Shutdown] Shutdown complete
> [Default] Shutdown complete
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 

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



[JBoss-dev] Current CVS build.

2001-11-20 Thread Dave Smith

When running a JBOSS build from CVS Nov 20, 17:00 EST it now does not 
start. Here is the starting sequence. (It shuts down by itself). The 
config files did work with the build from 2 days ago.

./run.sh

  JBoss Bootstrap Environment

  JAVA: /usr/j2sdk1.3.0/bin/java

  JAVA_OPTS: -hotspot -Djboss.boot.loader.name=run.sh 
-Djava.library.path=/home/dave/import/com/candata/bbx 
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
 
-Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl

  CLASSPATH: /home/dave/j/bin/run.jar:



[GPA] Microkernel ClassLoaders and Libraries initialized
Libraries adding URLClassLoader 2012031725 key URL 
file:/home/dave/j/conf/default/
Libraries adding URLClassLoader -1231209341 key URL 
file:/home/dave/j/lib/ext/log4j.jar
Libraries adding URLClassLoader -1729047754 key URL 
file:/home/dave/j/lib/ext/jboss-spine.jar
[root] Started Log4jService, 
config=file:/home/dave/j/conf/default/log4j.properties
[GPA] General Purpose Architecture [GPA]
[GPA] Java version: 1.3.0,Blackdown Java-Linux Team
[GPA] Java VM: Java HotSpot(TM) Client VM Blackdown-1.3.0-FCS,Blackdown 
Java-Linux Team
[GPA] OS-System: Linux 2.2.16,i386
[GPA] JBoss Version : 3.0.0alpha(200109280911)
[GPA] JBoss start time : Tue Nov 20 17:47:19 EST 2001
[GPA] localDir : /home/dave/j
[GPA] installationURL : file:/home/dave/j/
[GPA] configuration : file:/home/dave/j/conf/default/
[GPA] libraries : file:/home/dave/j/lib/ext/
[GPA] local patch directory:
[GPA] Oh, and remember we love you
[Shutdown] Shutdown hook added
[ServiceController] Controller MBean online
[ServiceDeployer] Starting
[ServiceDeployer] Found a temp directory left over from a previous run - 
deleting it.
[ServiceDeployer] Temporary deploy directory is 
/home/dave/j/tmp/deploy/ServiceDeployer
[ServiceDeployer] Started
[Default] JBoss 3.0.0alpha(200109280911) [RABBIT-HOLE] Started in 
0m:1s:193ms
[Shutdown] Shutting down all services
[Default] Shutting down
[ServiceController] Stopping 1 services
[ServiceController] Stopped 0 services
[Shutdown] Shutdown complete
[Default] Shutdown complete


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



Re: [JBoss-dev] ObjectPool - Invalidate On Error

2001-11-20 Thread David Jencks

On 2001.11.20 16:37:28 -0500 "Ferguson, Doug" wrote:
> So it appears that the ConnectionInPool is getting removed from the pool 
> but is inner connection is never getting closed. 
> 
> I am thinking that the best approach is to obtain the JDBC connection
> by calling getUnderlyingConnection. then call close() on that connection

The ManagedConnection destroy should be called -- this (at least in 3, for
the local transaction wrapper) calls con.close().  Can you navigate to the
managed connection?

thanks 
david jencks
> 
> If I get the ok. I will do this and check it in.
> 
> d./
> 
> -Original Message-
> From: Ferguson, Doug [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 2:28 PM
> To: jBoss Dev (E-mail)
> Subject: [JBoss-dev] ObjectPool - Invalidate On Error
> 
> 
> We have just noticed that whenever our code throws a SQLException, 
> the connection pool continues to grow.  Apparently the connections 
> that get "invalidated" aren't ever cleaned up. These grow until Oracle
> bails. I am looking at ObjectPool right now to see if I can figure it
> out.
> 
> If anybody already knows about this, please let me know.
> 
> Thanks,
> d.
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 

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



[JBoss-dev] Re: [jboss-docs] Is the build system too complicated?

2001-11-20 Thread Jason Dillon

I think I am going to split off the running (jboss, testsuite, whatever) 
bits into scripts (probably generated by the build system), which developers 
could then use to run things.  This will allow for greater flexiblity (such 
as redirecting or not) and will simplify the build.xml files.

Thanks for the feedback!

--jason


On Tue, 20 Nov 2001, Andreas Schaefer wrote:

> No, the build system is great for me. The only thing I have some problems with
> is to run JBoss through the build system because it does not send the output
> to the console.
> But compared to the old system it is great (good work well done).
> 
> Andy
>   - Original Message - 
>   From: Jason Dillon 
>   To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] 
>   Sent: Tuesday, November 20, 2001 1:43 PM
>   Subject: [jboss-docs] Is the build system too complicated?
> 
> 
>   Please let me know if you think that the build system is too complicated, or 
>   if there is some part of the system which is too complicated.
> 
>   --jason
> 
> 
> Yahoo! Groups Sponsor 
>   ADVERTISEMENT
>  
>
>
> 
>   ---
>   Subscribe: [EMAIL PROTECTED]
>   Unsubscribe:[EMAIL PROTECTED]
>   Archive: http://groups.yahoo.com/group/jboss-docs/ 
> 
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 
> 
> 


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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Hunter Hillegas

Okay.

Your file works and gives me an error that it can't find 'MyDS'. I'll have
to go back through and see where I screwed up.

Thanks everyone for their input and that bug report can be closed as it does
not apply.

Hunter

> From: Dain Sundstrom <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 16:22:46 -0600
> To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Torsten Schlumm
> <[EMAIL PROTECTED]>, JBoss Dev
> <[EMAIL PROTECTED]>
> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> 
> 
> 
>  
> java:/MyDS
> true
> true
> true
> true
> false
> 300
> false
> true
> foreign-key
>  
> 


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



RE: [JBoss-dev] ObjectPool - Invalidate On Error

2001-11-20 Thread Ignacio Coloma

I'm having a (related?) issue. When I hot-redeploy several times I end up
with no available connections on mysql and the ear cannot deploy. My app
only uses CMP, and even if I call no bean and only redeploy three or four
times I get the same error. I have to bounce the server back. No problem
since hot-redeploy is for development, but I don't think it's good.

I think it's already posted as a bug from some time ago.


[22:24:21,403,CanplasticaMySQLDS] Unable to create ManagedConnection:
javax.resource.ResourceException: Unable to create DB connection for url:
jdbc:mysql://localhost/can
plastica, user: , exception: java.sql.SQLException: Server configuration
denies access to data sourc
e
at
org.jboss.resource.adapter.jdbc.local.JDBCManagedConnectionFactory.createMan
agedConnectio
n(JDBCManagedConnectionFactory.java:392)
at
org.jboss.resource.connectionmanager.ManagedConnectionPoolFactory.createObje
ct(ManagedCon
nectionPoolFactory.java:77)
at org.jboss.pool.ObjectPool.createNewObject(ObjectPool.java:1007)
at org.jboss.pool.ObjectPool.getObject(ObjectPool.java:667)
at
org.jboss.resource.connectionmanager.SharedLocalConnectionManager.allocateCo
nnection(Shar
edLocalConnectionManager.java:124)
at
org.jboss.resource.adapter.jdbc.JDBCDataSource.getConnection(JDBCDataSource.
java:110)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getConnection(JDBCStoreManag
er.java:303)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartCommand
.java:62)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.jav
a:41)
at
org.jboss.ejb.plugins.cmp.CMPStoreManager.start(CMPStoreManager.java:142)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:
137)
at
org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java
:186)
at org.jboss.ejb.EntityContainer.start(EntityContainer.java:404)
at org.jboss.ejb.Application.start(Application.java:200)
at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:381)
at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:307)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:28)
at java.lang.reflect.Method.invoke(Method.java:327)
at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at
org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:467)
at
org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:444)
at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:215)

> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]En nombre de
> Ferguson, Doug
> Enviado el: martes, 20 de noviembre de 2001 21:37
> Para: jBoss Dev (E-mail)
> Asunto: RE: [JBoss-dev] ObjectPool - Invalidate On Error
>
>
> So it appears that the ConnectionInPool is getting removed from the pool
> but is inner connection is never getting closed.
>
> I am thinking that the best approach is to obtain the JDBC connection
> by calling getUnderlyingConnection. then call close() on that connection
>
> If I get the ok. I will do this and check it in.
>
> d./
>
> -Original Message-
> From: Ferguson, Doug [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 2:28 PM
> To: jBoss Dev (E-mail)
> Subject: [JBoss-dev] ObjectPool - Invalidate On Error
>
>
> We have just noticed that whenever our code throws a SQLException,
> the connection pool continues to grow.  Apparently the connections
> that get "invalidated" aren't ever cleaned up. These grow until Oracle
> bails. I am looking at ObjectPool right now to see if I can figure it out.
>
> If anybody already knows about this, please let me know.
>
> Thanks,
> d.
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>


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



RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Dain Sundstrom

With this exact jbosscmp-jdbc.xml file 




   
  java:/MyDS
  true
  true
  true
  true
  false
  300
  false
  true
  foreign-key
   


I get the following log messages:

[2001-11-20 16:17:22,229,CMP,DEBUG] Loading standardjbosscmp-jdbc.xml :
file:/ho
me/dain/work/jboss/jboss-all/build/output/jboss-3.0.0alpha/conf/default/stan
dard
jbosscmp-jdbc.xml
[2001-11-20 16:17:22,418,Default,INFO] Entity = A_EJB java:/DefaultDS null
[2001-11-20 16:17:22,437,CMP,DEBUG]
jar:file:/home/dain/work/jboss/jboss-all/bui
ld/output/jboss-3.0.0alpha/deploy/Default/relationship.ear/ejb1002.jar!/META
-INF
/jbosscmp-jdbc.xml found. Overriding defaults
[2001-11-20 16:17:22,452,Default,INFO] Entity = A_EJB java:/MyDS
java:/DefaultDS

Notice that the datasource name changes correctly.

Try my exact xml. If it does not work, try getting the current source.  If
that does not work, check your jar file.

-dain

> -Original Message-
> From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 3:59 PM
> To: Torsten Schlumm; JBoss Dev
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> 
> Sorta... I can see that the datasource now starts properly.
> 
> Still, my jar is trying to use DefaultDS instead of the 
> 'Groundswell' ds I
> defined...
> 
> > From: Torsten Schlumm <[EMAIL PROTECTED]>
> > Date: Tue, 20 Nov 2001 21:49:31 + (GMT)
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> > 
> > 
> > David,
> > 
> > updating wasn't the problem but the ..-service.xml
> > I simply didn't see one line
> > 
> > JBOSS-SYSTEM:service=Hypersonic
> > 
> > which I forgot to delete (I used
> > thehsqldb-default-service.xml as a template).
> > 
> > Sorry, it was completely my fault. Thanks anyway.
> > 
> > Cheers
> > Torsten
> > 
> > PS: does that help you, Hunter, in any way??
> > 
> > 
> > __
> > Do You Yahoo!?
> > Everything you'll ever need on one web page from News and 
> Sport to Email and
> > Music Charts
> > http://uk.my.yahoo.com
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 

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



[JBoss-dev] CVS update: jboss/src/etc/conf/default hsqldb-default-service.xml

2001-11-20 Thread David Jencks

  User: d_jencks
  Date: 01/11/20 14:15:23

  Modified:src/etc/conf/default hsqldb-default-service.xml
  Log:
  Added some warning comments about the anonymous mbean-ref to hsqldb
  
  Revision  ChangesPath
  1.5   +5 -1  jboss/src/etc/conf/default/hsqldb-default-service.xml
  
  Index: hsqldb-default-service.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/hsqldb-default-service.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- hsqldb-default-service.xml2001/11/15 06:27:28 1.4
  +++ hsqldb-default-service.xml2001/11/20 22:15:23 1.5
  @@ -7,7 +7,7 @@
   
   
   
  -
  +
   
   
   
  @@ -31,6 +31,10 @@
   java:/TransactionManager
   
   
  +
   JBOSS-SYSTEM:service=Hypersonic
   
   JCA:service=RARDeployment,name=Minerva 
JDBC LocalTransaction ResourceAdapter
  
  
  

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



[JBoss-dev] [ jboss-Bugs-478090 ] EJBLocalHome interface NOT passivateable

2001-11-20 Thread noreply

Bugs item #478090, was opened at 2001-11-04 13:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=478090&group_id=22866

Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Levart (plevart)
>Assigned to: Andreas Schaefer (schaefera)
Summary: EJBLocalHome interface NOT passivateable

Initial Comment:
The EJB 2.0 spec says about SFSBs (in 7.4.1, page 71) that 
references to EJBLocalHome interfaces can be left in the 
non-transient fields to be passivated by the container.

Well, I get following exception thrown when my SFSB gets 
passivated:

PassivatorQueue [ERROR] EXCEPTION
java.rmi.ServerException: Could not passivate; nested 
exception is:
java.io.NotSerializableException: 
org.jboss.ejb.plugins.local.BaseLocalContainerInvoker$HomeProxy
java.io.NotSerializableException: 
org.jboss.ejb.plugins.local.BaseLocalContainerInvoker$HomeProxy
at 
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148)
at 
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
at 
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
at 
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
at 
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
at 
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at 
org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:286)
at 
org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:68)
at 
org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractInstanceCache.java:711)
at 
org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:199)
at java.lang.Thread.run(Thread.java:484)




--

Comment By: Peter Levart (plevart)
Date: 2001-11-04 14:51

Message:
Logged In: YES 
user_id=346981

The place where this is missing from are 
org.jboss.ejb.plugins.SessionObjectInputStream and 
org.jboss.ejb.plugins.SessionObjectOutputStream but for them to 
be able to serialize/deserialize local interfaces some support has 
to be added to the framework. I propose the following:

Create 4 new interfaces that will be used internally by the JBoss:

//
// analogue to javax.ejb.Handle but for local interfaces
//
public interface LocalHandle extends java.io.Serializable {

// obtain EJBLocalObject reference represented by this 
handle
public EJBLocalObject getEJBLocalObject();
}


//
// analogue to javax.ejb.HomeHandle but for local interfaces
//
public interface LocalHomeHandle extends java.io.Serializable {

// obtain EJBLocalHome reference represented by this 
handle
public EJBLocalHome getEJBLocalHome();
}


//
// extension to javax.ejb.EJBLocalObject interface that adds a 
method to obtain a handle
//
public interface EJBossLocalObject extends 
javax.ejb.EJBLocalObject {

// obtain a LocalHandle for this EJBossLocalObject
public LocalHandle getLocalHandle();
}


//
// extension to javax.ejb.EJBLocalHome interface that adds a 
method to obtain a handle
//
public interface EJBossLocalHome extends 
javax.ejb.EJBLocalHome {

// obtain a LocalHomeHandle for this EJBossLocalHome
public LocalHomeHandle getLocalHomeHandle();
}


... then use EJBossLocalObject & EJBossLocalHome for the 
various implementation classes internally in JBoss instead of 
standard EJBLocalObject & EJBLocalHome (for proxies) and create 
some analogues implementations of LocalHandle and 
LocalHomeHandle interfaces as done with remote interfaces in 
org.jboss.ejb.plugins.jrmp package...



--

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

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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Hunter Hillegas

Sorta... I can see that the datasource now starts properly.

Still, my jar is trying to use DefaultDS instead of the 'Groundswell' ds I
defined...

> From: Torsten Schlumm <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 21:49:31 + (GMT)
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> 
> David,
> 
> updating wasn't the problem but the ..-service.xml
> I simply didn't see one line
> 
> JBOSS-SYSTEM:service=Hypersonic
> 
> which I forgot to delete (I used
> thehsqldb-default-service.xml as a template).
> 
> Sorry, it was completely my fault. Thanks anyway.
> 
> Cheers
> Torsten
> 
> PS: does that help you, Hunter, in any way??
> 
> 
> __
> Do You Yahoo!?
> Everything you'll ever need on one web page from News and Sport to Email and
> Music Charts
> http://uk.my.yahoo.com


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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Torsten Schlumm


David,

updating wasn't the problem but the ..-service.xml
I simply didn't see one line

JBOSS-SYSTEM:service=Hypersonic

which I forgot to delete (I used
thehsqldb-default-service.xml as a template).

Sorry, it was completely my fault. Thanks anyway.

Cheers
Torsten

PS: does that help you, Hunter, in any way??


__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music 
Charts
http://uk.my.yahoo.com

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



[JBoss-dev] [ jboss-Bugs-456467 ] Add in URLWizzard fails for top files

2001-11-20 Thread noreply

Bugs item #456467, was opened at 2001-08-29 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=456467&group_id=22866

Category: JBossServer
Group: None
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Peter Antman (pra)
Assigned to: Andreas Schaefer (schaefera)
Summary: Add in URLWizzard fails for top files

Initial Comment:
The add() method in URLWizzard, used to download and
pack directorys into a jar file fails with files in the
top directory. 

For example the directory structure

META-INF/jboss.xml
MyClass.class

Will in the resulting jar-file look:

META_INF/jboss.xml
/MyClass.class

An extra "/" is appended for all files in the top dir.

The following line does the jobb:

_jout.putNextEntry (new ZipEntry(_prefix +
"/" + content[i].getName ()));

But for files in the top dir _prefix will be blank, and
the extra "/" will destroy the possibility of looking
it up in the classpath.

One possible solution is:

String sep = (_prefix.equals("") ? "" : "/");
jout.putNextEntry (new ZipEntry(_prefix + sep +
content[i].getName ()))

But someone wich knows the ins and outs of the deployer
stuff should probably fix it.

//Peter

--

>Comment By: Andreas Schaefer (schaefera)
Date: 2001-11-20 13:45

Message:
Logged In: YES 
user_id=70434

Fixed on the current CVS Head as well as on Branch 2.4.4.

Andy

--

Comment By: Andreas Schaefer (schaefera)
Date: 2001-11-20 12:51

Message:
Logged In: YES 
user_id=70434

Fixed on the current CVS Head as well as on Branch 2.4.4.

Andy

--

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

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



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

2001-11-20 Thread Andreas Schaefer

  User: schaefera
  Date: 01/11/20 13:43:53

  Modified:src/main/org/jboss/deployment URLWizzard.java
  Log:
  Took the fix for bug #456467 in current CVS.
  
  Revision  ChangesPath
  1.9   +8 -2  jboss/src/main/org/jboss/deployment/URLWizzard.java
  
  Index: URLWizzard.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/URLWizzard.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- URLWizzard.java   2001/08/03 17:15:42 1.8
  +++ URLWizzard.java   2001/11/20 21:43:53 1.9
  @@ -33,7 +33,8 @@
   * Very scratchy! Any improvements are welcome!
   *  
   *@author Daniel Schulze <[EMAIL PROTECTED]>
  -*@version $Revision: 1.8 $
  +*@author Andreas Schaefer <[EMAIL PROTECTED]>
  +*@version $Revision: 1.9 $
   */
   public class URLWizzard
   {
  @@ -121,7 +122,12 @@
}
else
{
  -_jout.putNextEntry (new ZipEntry(_prefix + "/" + content[i].getName 
()));
  +// If no prefix then no '/' necessary
  +_jout.putNextEntry(
  +   new ZipEntry(
  +  ( "".equals( _prefix ) ? "" : _prefix + "/" ) + 
content[i].getName()
  +   )
  +);
   FileInputStream in = new FileInputStream (content[i]);
   write (in, _jout);
   in.close ();
  
  
  

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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread David Jencks

I think you need to remove the anonymous mbean-ref unless you actually have
a mbean named JBOSS-SYSTEM:service=PostgreSQL.  If you do, what does it do?
 If not, your ConnectionFactoryLoader will never get started since it is
waiting for an mbean you have no plans to create, ever.

The original anonymous mbean-ref was needed because jboss is starting the
embedded hsqldb server itself, and it doesn't make sense to start up the
ConnectionFactory until the db is available.  However, with an external db
in a separate process, you are unlikely to be starting it with an mbean.

david jencks

On 2001.11.20 14:46:08 -0500 Hunter Hillegas wrote:
> Are we sure that the datasource name in jbosscmp-jdbc.xml is even being
> checked properly?
> 
> I gave my config another look and it seems correct. Here are is the
> console
> log output:
> 
> [11:43:51,571,AutoDeployer] Auto deploy of
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqldb-default-serv
> ice.xml
> [11:43:51,602,Default] Libraries adding URLClassLoader 1240345370 key URL
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
> [11:43:51,647,ServiceCreator] About to create the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> [11:43:51,653,ServiceCreator] Created the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> 
> And the file:
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
>   
>   
>   
>   
> 
> name="JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell">
>  name="ManagedConnectionFactoryProperties">ConnectionURL=jdbc:postgresql://lo
> calhost/groundswell
>   DriverClass=org.postgresql.Driver
>   UserName=postgres
>   Password=""
> Groundswell
>  name="TransactionManagerName">java:/TransactionManager
> 
> 
> JBOSS-SYSTEM:service=PostgreSQL
> 
>  name="ResourceAdapterName">JCA:service=RARDeployment,name=Minerva JDBC
> LocalTransaction ResourceAdapter
>  name="ConnectionManagerFactoryLoaderName">JCA:service=ConnectionManagerFacto
> ryLoader,name=MinervaSharedLocalCMFactory
> #
>   #Wed Aug 15 16:17:29 EDT 2001
>   MinSize=0
>   MaxSize=10
>   BlockingTimeoutMillis=5000
>   IdleTimeoutMinutes=30
>   CleanupIntervalMinutes=10
>   MaxIdleTimeoutPercent=1.0
> 
> 
>   org.jboss.resource.security.ManyToOnePrincipalMapping
>
>  name="PrincipalMappingProperties">UserName=postgres
>   
> 
> 
> 
> > From: David Jencks <[EMAIL PROTECTED]>
> > Date: Tue, 20 Nov 2001 13:48:05 -0500
> > To: Torsten Schlumm <[EMAIL PROTECTED]>
> > Cc: Hunter Hillegas <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> > 
> > Have you guys included the latest updates to the
> ConnectionFactoryLoader
> > configuration format? The hsqldb example has been updated, the manual
> > likewise for mysql and postgres.  If updating is not the problem, could
> you
> > post your cfl config? does DefaultDS get started properly on your
> system?
> > 
> > Thanks
> > david jencks
> > 
> > On 2001.11.20 12:57:30 -0500 Torsten Schlumm wrote:
> >> Hunter,
> >> 
> >> I've seen the same thing with mySQL today (it did work with the CVS
> >> sources
> >> from about 3 weeks ago).
> >> 
> >> After having a closer look at the list of registered MBeans
> >> (localhost:8082)
> >> I found it (at least something :)
> >> My mysqlDS was perfectly registered but not started. After starting it
> by
> >> hand no problems anymore - deployment works.
> >> 
> >> If that still doesn't work for you I could also send you the relevant
> >> files
> >> from my setup/beans.
> >> 
> >> I will also try to work out why the bloody thing doesn't get started.
> >> Anyone any ideas??
> >> 
> >> Cheers
> >> Torsten
> >> 
> >> 
> >> 
> >> 
> >> On Mon, 19 Nov 2001 16:06:25 -0800
> >> Hunter Hillegas <[EMAIL PROTECTED]> wrote:
> >> 
> >>> So far nothing from this end.
> >>> 
> >>> If you get a chance to look at or if anyone else has any ideas,
> please
> >> chime
> >>> in?
> >>> 
> >>> Is no one else running Rabbit Hole with PostgreSQL and 2.0 EJB?
> >>> 
>  From: Dain Sundstrom <[EMAIL PROTECTED]>
>  Date: Mon, 19 Nov 2001 16:14:21 -0600
>  To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain Sundstrom
>  <[EMAIL PROTECTED]>, JBoss Dev
> > <[EMAIL PROTECTED]>
>  Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>  The ds jndi name is loaded in the metadata object of entities in the
>  ...plulgin.cmp.jdbc.metadata package.  Then the ds is looked up in
> >> the
>  JDBCStoreManager init method. Finally it is used in the JDBCCommand
> >> object.
>  
>  -dain
>  
> > -Original Message-
> > From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 19, 2001 3:50 PM
> > To: Dain Sundstrom; JBoss Dev
> > Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> > 
> > 
> > I haven't dug around in the source yet. If you can give me a
> > po

RE: [JBoss-dev] ObjectPool - Invalidate On Error

2001-11-20 Thread Ferguson, Doug

So it appears that the ConnectionInPool is getting removed from the pool 
but is inner connection is never getting closed. 

I am thinking that the best approach is to obtain the JDBC connection
by calling getUnderlyingConnection. then call close() on that connection

If I get the ok. I will do this and check it in.

d./

-Original Message-
From: Ferguson, Doug [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 20, 2001 2:28 PM
To: jBoss Dev (E-mail)
Subject: [JBoss-dev] ObjectPool - Invalidate On Error


We have just noticed that whenever our code throws a SQLException, 
the connection pool continues to grow.  Apparently the connections 
that get "invalidated" aren't ever cleaned up. These grow until Oracle
bails. I am looking at ObjectPool right now to see if I can figure it out.

If anybody already knows about this, please let me know.

Thanks,
d.

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

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



[JBoss-dev] Is the build system too complicated?

2001-11-20 Thread Jason Dillon

Please let me know if you think that the build system is too complicated, or 
if there is some part of the system which is too complicated.

--jason


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



RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Torsten Schlumm

Hunter,

try to remove the line

JBOSS-SYSTEM:service=PostgreSQL

from your postgres-service.xml (or however it's
called). I think that should solve the problem.
If I understand the whole process right then
this means the datasource thingy depends on a
service 'PostgreSQL' and therefore doesn't start
until this service is available. But it never will
be, because it doesn't exist. In the default setup
'DefaultDS' depends on 'Hypersonic' - therefore you
have the line

JBOSS-SYSTEM:service=Hypersonic

And because the hypersonic db gets started by JBoss


  1476
  true
  default
  false


the thing works. You don't need that with external
db's

If this was complete nonsense shoot me and call me
an idiot - or the other way round (David ??)

Tell me if it works, Hunter.

Cheers
Torsten



__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music 
Charts
http://uk.my.yahoo.com

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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Hunter Hillegas

Okay, maybe I made a mistake. Still, I'm not sure exactly where.

I don't get that message in my log file...

Still, I have a file called 'jbosscmp-jdbc.xml' in my META-INF directory of
my jar file, along with a jboss.xml file and a ejb-jar.xml file...

Hunter

> From: Dain Sundstrom <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 15:20:04 -0600
> To: "'Dave Smith'" <[EMAIL PROTECTED]>, Hunter Hillegas
> <[EMAIL PROTECTED]>
> Cc: Dain Sundstrom <[EMAIL PROTECTED]>, David Jencks
> <[EMAIL PROTECTED]>, Torsten Schlumm
> <[EMAIL PROTECTED]>, JBoss Dev
> <[EMAIL PROTECTED]>
> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> This section of code is called three times.
> 1) defaults section of standardjbosscmp-jdbc.xml
> 2) defaults section of jbosscmp-jdbc.xml
> 3) entity section for each entity specified in jbosscmp-jdbc.xml
> 
> The first time it will be null.
> 
> Are you getting a message like in your DEBUG log like this:
> 
> [2001-11-20 15:16:06,113,CMP,DEBUG]
> jar:file:/home/dain/work/jboss/jboss-all/bui
> ld/output/jboss-3.0.0alpha/deploy/Default/relationship.ear/ejb1003.jar!/META
> -INF
> /jbosscmp-jdbc.xml found. Overriding defaults
> 
> If you are not, the jbosscmp-jdbc.xml (NOT jboss-cmp-jdbc.xml) file is in
> the wrong place or something like that.
> 
> I tested this and it worked fine for me.
> 
> -dain
> 
>> -Original Message-
>> From: Dave Smith [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, November 20, 2001 3:13 PM
>> To: Hunter Hillegas
>> Cc: Dain Sundstrom; David Jencks; Torsten Schlumm; JBoss Dev
>> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>> 
>> 
>> Weird. So this has to point to either the
>> standardjbosscmp-jdbc.xml or
>> jbosscmp-jdbc.xml. What's really strange is the default is null. This
>> should come from standardjbosscmp-jdbc.xml. What else is
>> strange is that 
>> it thinks in jboss-cmp-jdbc.xml for each entity you have a datasource
>> element. Maybee grabbing the wrong standard config?
>> 
>> 
>> Hunter Hillegas wrote:
>> 
>>> I'm not so sure. Despite having my jbosscmp-jdbc.xml file
>> included, I get
>>> this on the console as it deploys my beans after I made
>> Dave's change:
>>> 
>>> [13:02:37,433,Default] Entity = ProductAttribute
>> java:/DefaultDS null
>>> [13:02:37,437,Default] Entity = Product java:/DefaultDS null
>>> [13:02:37,439,Default] Entity = Order java:/DefaultDS null
>>> [13:02:37,443,Default] Entity = OrderLineItem java:/DefaultDS null
>>> [13:02:37,445,Default] Entity = ProductLineItem java:/DefaultDS null
>>> [13:02:37,448,Default] Entity = ProductGroup java:/DefaultDS null
>>> 
>>> It's apparently trying to use DefaultDS even though I
>> explicitly tell it not
>>> to in the jbosscmp-jdbc.xml file...
>>> 
>>> If your config is working correctly, I'm stumped!
>>> 
>>> 
 From: Dain Sundstrom <[EMAIL PROTECTED]>
 Date: Tue, 20 Nov 2001 14:56:24 -0600
 To: "'Dave Smith'" <[EMAIL PROTECTED]>, Hunter Hillegas
 <[EMAIL PROTECTED]>
 Cc: David Jencks <[EMAIL PROTECTED]>, Torsten Schlumm
 <[EMAIL PROTECTED]>, JBoss Dev
 <[EMAIL PROTECTED]>
 Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
 
 Funny.  I just did that but in
 org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager line 110 where the
 datasource is looked up. And it successfully looks up my
>> new datasource. I
 think you have a different problem. I changed the name of
>> the hypersonic
 data source. May be the problem is your postgresql driver setup.
 
 -dain
 
 
> -Original Message-
> From: Dave Smith [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 2:41 PM
> To: Hunter Hillegas
> Cc: David Jencks; Torsten Schlumm; JBoss Dev
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> 
> Well if you want to get down and dirty in
> jboss/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/
> JDBCEntityMetaData.java
> line 336 is where it sets the datasouce for each entity. On
> line 343 you 
> could add
> System.out.println("Enity = "+entityName+" "+dataSourceNameString+"
> "+defaultValues.getDataSourceName());
> 
> 
> That should give you the datasource the entity is bound to.
> 
> 
> 
> Hunter Hillegas wrote:
> 
> 
>> Are we sure that the datasource name in jbosscmp-jdbc.xml
>> 
> is even being
> 
>> checked properly?
>> 
>> I gave my config another look and it seems correct. Here
>> 
> are is the console
> 
>> log output:
>> 
>> [11:43:51,571,AutoDeployer] Auto deploy of
>> 
>> 
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqld
> b-default-serv
> 
>> ice.xml
>> [11:43:51,602,Default] Libraries adding URLClassLoader
>> 
> 1240345370 key URL
> 
>> file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
>> [11:43:51,647,ServiceCreator] About to crea

[JBoss-dev] CVS update: newsite/src/docs/developers cvs.jsp

2001-11-20 Thread Jason Dillon

  User: user57  
  Date: 01/11/20 13:34:48

  Modified:src/docs/developers cvs.jsp
  Log:
   o removed jboss-website (and website alias) from the public module list
   o changed [zip] & [tgz] button style back to previous form, since they
 were easier on the eye.
  
  Revision  ChangesPath
  1.12  +6 -12 newsite/src/docs/developers/cvs.jsp
  
  Index: cvs.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/developers/cvs.jsp,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- cvs.jsp   2001/11/20 01:13:08 1.11
  +++ cvs.jsp   2001/11/20 21:34:47 1.12
  @@ -36,14 +36,14 @@
 or select one of the following:
  
 jboss-all
  - [zip]
  - [tgz]
  + [zip]
  + [tgz]
 jboss-mq
  - [zip]
  - [tgz]
  + [zip]
  + [tgz]
 jboss-plugins
  - [zip]
  - [tgz]
  + [zip]
  + [tgz]
  
   
  
  @@ -114,9 +114,6 @@
 jboss-all
 Everything required to build JBoss.
   
  -  jboss-website
  -  The JBoss website.
  -
 jboss-mq
 The JBossMQ standalone server.
   
  @@ -136,9 +133,6 @@
   
  
  
  -  website
  -  jboss-website
  -
 plugins
 jboss-plugins
  
  
  
  

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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Hunter Hillegas

At this point I have no idea what to do next...

> From: Dave Smith <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 16:12:56 -0500
> To: Hunter Hillegas <[EMAIL PROTECTED]>
> Cc: Dain Sundstrom <[EMAIL PROTECTED]>, David Jencks
> <[EMAIL PROTECTED]>, Torsten Schlumm
> <[EMAIL PROTECTED]>, JBoss Dev
> <[EMAIL PROTECTED]>
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> Weird. So this has to point to either the standardjbosscmp-jdbc.xml or
> jbosscmp-jdbc.xml. What's really strange is the default is null. This
> should come from standardjbosscmp-jdbc.xml. What else is strange is that
> it thinks in jboss-cmp-jdbc.xml for each entity you have a datasource
> element. Maybee grabbing the wrong standard config?
> 
> 
> Hunter Hillegas wrote:
> 
>> I'm not so sure. Despite having my jbosscmp-jdbc.xml file included, I get
>> this on the console as it deploys my beans after I made Dave's change:
>> 
>> [13:02:37,433,Default] Entity = ProductAttribute java:/DefaultDS null
>> [13:02:37,437,Default] Entity = Product java:/DefaultDS null
>> [13:02:37,439,Default] Entity = Order java:/DefaultDS null
>> [13:02:37,443,Default] Entity = OrderLineItem java:/DefaultDS null
>> [13:02:37,445,Default] Entity = ProductLineItem java:/DefaultDS null
>> [13:02:37,448,Default] Entity = ProductGroup java:/DefaultDS null
>> 
>> It's apparently trying to use DefaultDS even though I explicitly tell it not
>> to in the jbosscmp-jdbc.xml file...
>> 
>> If your config is working correctly, I'm stumped!
>> 
>> 
>>> From: Dain Sundstrom <[EMAIL PROTECTED]>
>>> Date: Tue, 20 Nov 2001 14:56:24 -0600
>>> To: "'Dave Smith'" <[EMAIL PROTECTED]>, Hunter Hillegas
>>> <[EMAIL PROTECTED]>
>>> Cc: David Jencks <[EMAIL PROTECTED]>, Torsten Schlumm
>>> <[EMAIL PROTECTED]>, JBoss Dev
>>> <[EMAIL PROTECTED]>
>>> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>>> 
>>> Funny.  I just did that but in
>>> org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager line 110 where the
>>> datasource is looked up. And it successfully looks up my new datasource. I
>>> think you have a different problem. I changed the name of the hypersonic
>>> data source. May be the problem is your postgresql driver setup.
>>> 
>>> -dain
>>> 
>>> 
 -Original Message-
 From: Dave Smith [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, November 20, 2001 2:41 PM
 To: Hunter Hillegas
 Cc: David Jencks; Torsten Schlumm; JBoss Dev
 Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
 
 
 Well if you want to get down and dirty in
 jboss/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/
 JDBCEntityMetaData.java
 line 336 is where it sets the datasouce for each entity. On
 line 343 you 
 could add
 System.out.println("Enity = "+entityName+" "+dataSourceNameString+"
 "+defaultValues.getDataSourceName());
 
 
 That should give you the datasource the entity is bound to.
 
 
 
 Hunter Hillegas wrote:
 
 
> Are we sure that the datasource name in jbosscmp-jdbc.xml
> 
 is even being
 
> checked properly?
> 
> I gave my config another look and it seems correct. Here
> 
 are is the console
 
> log output:
> 
> [11:43:51,571,AutoDeployer] Auto deploy of
> 
> 
 file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqld
 b-default-serv
 
> ice.xml
> [11:43:51,602,Default] Libraries adding URLClassLoader
> 
 1240345370 key URL
 
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
> [11:43:51,647,ServiceCreator] About to create the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> [11:43:51,653,ServiceCreator] Created the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> 
> And the file:
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
>  
>  
>  
>  
> 
>   
> 
 name="JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell">
 
> 
> 
 name="ManagedConnectionFactoryProperties">ConnectionURL=jdbc:p
 ostgresql://lo
 
> calhost/groundswell
>  DriverClass=org.postgresql.Driver
>  UserName=postgres
>  Password=""
>Groundswell
> name="TransactionManagerName">java:/TransactionManager
> 
>
>JBOSS-SYSTEM:service=PostgreSQL
> 
> 
> 
 name="ResourceAdapterName">JCA:service=RARDeployment,name=Minerva JDBC
 
> LocalTransaction ResourceAdapter
> 
> 
 name="ConnectionManagerFactoryLoaderName">JCA:service=Connecti
 onManagerFacto
 
> ryLoader,name=MinervaSharedLocalCMFactory
>#
>  #Wed Aug 15 16:17:29 EDT 2001
>  MinSize=0
>  MaxSize=10
>  BlockingTimeoutMillis=5000
>  IdleTimeoutMinutes=30
>  CleanupIntervalMinutes=10
>  MaxIdleTimeoutPer

RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Dain Sundstrom

This section of code is called three times.
1) defaults section of standardjbosscmp-jdbc.xml
2) defaults section of jbosscmp-jdbc.xml
3) entity section for each entity specified in jbosscmp-jdbc.xml

The first time it will be null.

Are you getting a message like in your DEBUG log like this:

[2001-11-20 15:16:06,113,CMP,DEBUG]
jar:file:/home/dain/work/jboss/jboss-all/bui
ld/output/jboss-3.0.0alpha/deploy/Default/relationship.ear/ejb1003.jar!/META
-INF
/jbosscmp-jdbc.xml found. Overriding defaults

If you are not, the jbosscmp-jdbc.xml (NOT jboss-cmp-jdbc.xml) file is in
the wrong place or something like that.

I tested this and it worked fine for me.

-dain

> -Original Message-
> From: Dave Smith [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 3:13 PM
> To: Hunter Hillegas
> Cc: Dain Sundstrom; David Jencks; Torsten Schlumm; JBoss Dev
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> 
> Weird. So this has to point to either the 
> standardjbosscmp-jdbc.xml or 
> jbosscmp-jdbc.xml. What's really strange is the default is null. This 
> should come from standardjbosscmp-jdbc.xml. What else is 
> strange is that 
> it thinks in jboss-cmp-jdbc.xml for each entity you have a datasource 
> element. Maybee grabbing the wrong standard config?
> 
> 
> Hunter Hillegas wrote:
> 
> > I'm not so sure. Despite having my jbosscmp-jdbc.xml file 
> included, I get
> > this on the console as it deploys my beans after I made 
> Dave's change:
> > 
> > [13:02:37,433,Default] Entity = ProductAttribute 
> java:/DefaultDS null
> > [13:02:37,437,Default] Entity = Product java:/DefaultDS null
> > [13:02:37,439,Default] Entity = Order java:/DefaultDS null
> > [13:02:37,443,Default] Entity = OrderLineItem java:/DefaultDS null
> > [13:02:37,445,Default] Entity = ProductLineItem java:/DefaultDS null
> > [13:02:37,448,Default] Entity = ProductGroup java:/DefaultDS null
> > 
> > It's apparently trying to use DefaultDS even though I 
> explicitly tell it not
> > to in the jbosscmp-jdbc.xml file...
> > 
> > If your config is working correctly, I'm stumped!
> > 
> > 
> >>From: Dain Sundstrom <[EMAIL PROTECTED]>
> >>Date: Tue, 20 Nov 2001 14:56:24 -0600
> >>To: "'Dave Smith'" <[EMAIL PROTECTED]>, Hunter Hillegas
> >><[EMAIL PROTECTED]>
> >>Cc: David Jencks <[EMAIL PROTECTED]>, Torsten Schlumm
> >><[EMAIL PROTECTED]>, JBoss Dev
> >><[EMAIL PROTECTED]>
> >>Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> >>
> >>Funny.  I just did that but in
> >>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager line 110 where the
> >>datasource is looked up. And it successfully looks up my 
> new datasource. I
> >>think you have a different problem. I changed the name of 
> the hypersonic
> >>data source. May be the problem is your postgresql driver setup.
> >>
> >>-dain
> >>
> >>
> >>>-Original Message-
> >>>From: Dave Smith [mailto:[EMAIL PROTECTED]]
> >>>Sent: Tuesday, November 20, 2001 2:41 PM
> >>>To: Hunter Hillegas
> >>>Cc: David Jencks; Torsten Schlumm; JBoss Dev
> >>>Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> >>>
> >>>
> >>>Well if you want to get down and dirty in
> >>>jboss/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/
> >>>JDBCEntityMetaData.java
> >>>line 336 is where it sets the datasouce for each entity. On
> >>>line 343 you 
> >>>could add
> >>>System.out.println("Enity = "+entityName+" "+dataSourceNameString+"
> >>>"+defaultValues.getDataSourceName());
> >>>
> >>>
> >>>That should give you the datasource the entity is bound to.
> >>>
> >>>
> >>>
> >>>Hunter Hillegas wrote:
> >>>
> >>>
> Are we sure that the datasource name in jbosscmp-jdbc.xml
> 
> >>>is even being
> >>>
> checked properly?
> 
> I gave my config another look and it seems correct. Here
> 
> >>>are is the console
> >>>
> log output:
> 
> [11:43:51,571,AutoDeployer] Auto deploy of
> 
> 
> >>>file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqld
> >>>b-default-serv
> >>>
> ice.xml
> [11:43:51,602,Default] Libraries adding URLClassLoader
> 
> >>>1240345370 key URL
> >>>
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
> [11:43:51,647,ServiceCreator] About to create the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> [11:43:51,653,ServiceCreator] Created the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> 
> And the file:
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
>   
>   
>   
>   
> 
>     
> 
> >>>name="JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Gro
> undswell">
> >>>
>  
> 
> >>>name="ManagedConnectionFactoryProperties">ConnectionURL=jdbc:p
> >>>ostgresql://lo
> >>>
> calhost/groundswell
>   DriverClass=org.postgresql.Driver
>   UserName=postgres
>   Password=""
> Groundswell
>  name="TransactionManagerName">java:/Transac

Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Dave Smith

Weird. So this has to point to either the standardjbosscmp-jdbc.xml or 
jbosscmp-jdbc.xml. What's really strange is the default is null. This 
should come from standardjbosscmp-jdbc.xml. What else is strange is that 
it thinks in jboss-cmp-jdbc.xml for each entity you have a datasource 
element. Maybee grabbing the wrong standard config?


Hunter Hillegas wrote:

> I'm not so sure. Despite having my jbosscmp-jdbc.xml file included, I get
> this on the console as it deploys my beans after I made Dave's change:
> 
> [13:02:37,433,Default] Entity = ProductAttribute java:/DefaultDS null
> [13:02:37,437,Default] Entity = Product java:/DefaultDS null
> [13:02:37,439,Default] Entity = Order java:/DefaultDS null
> [13:02:37,443,Default] Entity = OrderLineItem java:/DefaultDS null
> [13:02:37,445,Default] Entity = ProductLineItem java:/DefaultDS null
> [13:02:37,448,Default] Entity = ProductGroup java:/DefaultDS null
> 
> It's apparently trying to use DefaultDS even though I explicitly tell it not
> to in the jbosscmp-jdbc.xml file...
> 
> If your config is working correctly, I'm stumped!
> 
> 
>>From: Dain Sundstrom <[EMAIL PROTECTED]>
>>Date: Tue, 20 Nov 2001 14:56:24 -0600
>>To: "'Dave Smith'" <[EMAIL PROTECTED]>, Hunter Hillegas
>><[EMAIL PROTECTED]>
>>Cc: David Jencks <[EMAIL PROTECTED]>, Torsten Schlumm
>><[EMAIL PROTECTED]>, JBoss Dev
>><[EMAIL PROTECTED]>
>>Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>>
>>Funny.  I just did that but in
>>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager line 110 where the
>>datasource is looked up. And it successfully looks up my new datasource. I
>>think you have a different problem. I changed the name of the hypersonic
>>data source. May be the problem is your postgresql driver setup.
>>
>>-dain
>>
>>
>>>-Original Message-
>>>From: Dave Smith [mailto:[EMAIL PROTECTED]]
>>>Sent: Tuesday, November 20, 2001 2:41 PM
>>>To: Hunter Hillegas
>>>Cc: David Jencks; Torsten Schlumm; JBoss Dev
>>>Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>>>
>>>
>>>Well if you want to get down and dirty in
>>>jboss/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/
>>>JDBCEntityMetaData.java
>>>line 336 is where it sets the datasouce for each entity. On
>>>line 343 you 
>>>could add
>>>System.out.println("Enity = "+entityName+" "+dataSourceNameString+"
>>>"+defaultValues.getDataSourceName());
>>>
>>>
>>>That should give you the datasource the entity is bound to.
>>>
>>>
>>>
>>>Hunter Hillegas wrote:
>>>
>>>
Are we sure that the datasource name in jbosscmp-jdbc.xml

>>>is even being
>>>
checked properly?

I gave my config another look and it seems correct. Here

>>>are is the console
>>>
log output:

[11:43:51,571,AutoDeployer] Auto deploy of


>>>file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqld
>>>b-default-serv
>>>
ice.xml
[11:43:51,602,Default] Libraries adding URLClassLoader

>>>1240345370 key URL
>>>
file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
[11:43:51,647,ServiceCreator] About to create the
beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
[11:43:51,653,ServiceCreator] Created the
beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell

And the file:








  

  
  
  
  

  >>> 

>>>name="JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell">
>>>
>>>

>>>name="ManagedConnectionFactoryProperties">ConnectionURL=jdbc:p
>>>ostgresql://lo
>>>
calhost/groundswell
  DriverClass=org.postgresql.Driver
  UserName=postgres
  Password=""
Groundswell
>>>name="TransactionManagerName">java:/TransactionManager


JBOSS-SYSTEM:service=PostgreSQL

>>>

>>>name="ResourceAdapterName">JCA:service=RARDeployment,name=Minerva JDBC
>>>
LocalTransaction ResourceAdapter
>>>

>>>name="ConnectionManagerFactoryLoaderName">JCA:service=Connecti
>>>onManagerFacto
>>>
ryLoader,name=MinervaSharedLocalCMFactory
#
  #Wed Aug 15 16:17:29 EDT 2001
  MinSize=0
  MaxSize=10
  BlockingTimeoutMillis=5000
  IdleTimeoutMinutes=30
  CleanupIntervalMinutes=10
  MaxIdleTimeoutPercent=1.0


  org.jboss.resource.security.ManyToOnePrincipalMapping
   
>>>name="PrincipalMappingProperties">UserName=postgres
  



>From: David Jencks <[EMAIL PROTECTED]>
>Date: Tue, 20 Nov 2001 13:48:05 -0500
>To: Torsten Schlumm <[EMAIL PROTECTED]>
>Cc: Hunter Hillegas <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED]
>Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>
>Have you guys included the latest updates to the
>
>>>ConnectionFactoryLoader
>>>
>configuration format? The hsqldb example has been updated,
>
>>>the manual
>>>
>likewise fo

Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Hunter Hillegas

I'm not so sure. Despite having my jbosscmp-jdbc.xml file included, I get
this on the console as it deploys my beans after I made Dave's change:

[13:02:37,433,Default] Entity = ProductAttribute java:/DefaultDS null
[13:02:37,437,Default] Entity = Product java:/DefaultDS null
[13:02:37,439,Default] Entity = Order java:/DefaultDS null
[13:02:37,443,Default] Entity = OrderLineItem java:/DefaultDS null
[13:02:37,445,Default] Entity = ProductLineItem java:/DefaultDS null
[13:02:37,448,Default] Entity = ProductGroup java:/DefaultDS null

It's apparently trying to use DefaultDS even though I explicitly tell it not
to in the jbosscmp-jdbc.xml file...

If your config is working correctly, I'm stumped!

> From: Dain Sundstrom <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 14:56:24 -0600
> To: "'Dave Smith'" <[EMAIL PROTECTED]>, Hunter Hillegas
> <[EMAIL PROTECTED]>
> Cc: David Jencks <[EMAIL PROTECTED]>, Torsten Schlumm
> <[EMAIL PROTECTED]>, JBoss Dev
> <[EMAIL PROTECTED]>
> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> Funny.  I just did that but in
> org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager line 110 where the
> datasource is looked up. And it successfully looks up my new datasource. I
> think you have a different problem. I changed the name of the hypersonic
> data source. May be the problem is your postgresql driver setup.
> 
> -dain
> 
>> -Original Message-
>> From: Dave Smith [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, November 20, 2001 2:41 PM
>> To: Hunter Hillegas
>> Cc: David Jencks; Torsten Schlumm; JBoss Dev
>> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>> 
>> 
>> Well if you want to get down and dirty in
>> jboss/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/
>> JDBCEntityMetaData.java
>> line 336 is where it sets the datasouce for each entity. On
>> line 343 you 
>> could add
>> System.out.println("Enity = "+entityName+" "+dataSourceNameString+"
>> "+defaultValues.getDataSourceName());
>> 
>> 
>> That should give you the datasource the entity is bound to.
>> 
>> 
>> 
>> Hunter Hillegas wrote:
>> 
>>> Are we sure that the datasource name in jbosscmp-jdbc.xml
>> is even being
>>> checked properly?
>>> 
>>> I gave my config another look and it seems correct. Here
>> are is the console
>>> log output:
>>> 
>>> [11:43:51,571,AutoDeployer] Auto deploy of
>>> 
>> file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqld
>> b-default-serv
>>> ice.xml
>>> [11:43:51,602,Default] Libraries adding URLClassLoader
>> 1240345370 key URL
>>> file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
>>> [11:43:51,647,ServiceCreator] About to create the
>>> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
>>> [11:43:51,653,ServiceCreator] Created the
>>> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
>>> 
>>> And the file:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>   
>>> 
>>>   
>>>   
>>>   
>>>   
>>> 
>>>   >>  
>> name="JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell">
>>> >> 
>> name="ManagedConnectionFactoryProperties">ConnectionURL=jdbc:p
>> ostgresql://lo
>>> calhost/groundswell
>>>   DriverClass=org.postgresql.Driver
>>>   UserName=postgres
>>>   Password=""
>>> Groundswell
>>> >> name="TransactionManagerName">java:/TransactionManager
>>> 
>>> 
>>> JBOSS-SYSTEM:service=PostgreSQL
>>> 
>>> >> 
>> name="ResourceAdapterName">JCA:service=RARDeployment,name=Minerva JDBC
>>> LocalTransaction ResourceAdapter
>>> >> 
>> name="ConnectionManagerFactoryLoaderName">JCA:service=Connecti
>> onManagerFacto
>>> ryLoader,name=MinervaSharedLocalCMFactory
>>> #
>>>   #Wed Aug 15 16:17:29 EDT 2001
>>>   MinSize=0
>>>   MaxSize=10
>>>   BlockingTimeoutMillis=5000
>>>   IdleTimeoutMinutes=30
>>>   CleanupIntervalMinutes=10
>>>   MaxIdleTimeoutPercent=1.0
>>> 
>>> 
>>>   org.jboss.resource.security.ManyToOnePrincipalMapping
>>>
>>> >> name="PrincipalMappingProperties">UserName=postgres
>>>   
>>> 
>>> 
>>> 
 From: David Jencks <[EMAIL PROTECTED]>
 Date: Tue, 20 Nov 2001 13:48:05 -0500
 To: Torsten Schlumm <[EMAIL PROTECTED]>
 Cc: Hunter Hillegas <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
 
 Have you guys included the latest updates to the
>> ConnectionFactoryLoader
 configuration format? The hsqldb example has been updated,
>> the manual
 likewise for mysql and postgres.  If updating is not the
>> problem, could you
 post your cfl config? does DefaultDS get started properly
>> on your system?
 
 Thanks
 david jencks
 
 On 2001.11.20 12:57:30 -0500 Torsten Schlumm wrote:
 
> Hunter,
> 
> I've seen the same thing with mySQL today (it did work with the CVS
> sources
> from about 3 weeks ago).
> 
> After having a closer look at the list of registered MBeans
> (localhost:8082)
> I

RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS? (Postgres and CMP 2)

2001-11-20 Thread marc fleury
Title: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS? (Postgres and CMP 2)



that 
is not true
 
marcf

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of 
  Bunker, DanSent: Tuesday, November 20, 2001 9:59 
  AMTo: JBoss DevSubject: RE: [JBoss-dev] 2.0 jar Really 
  Likes DefaultDS? (Postgres and CMP 2)
  I have been developing with CMP 2 and postgresql for the last 
  2 weeks.  Things seem to be going OK for what I'm using it for.  I 
  have seen some interesting things with the transaction types.  It appears 
  that rabit hole currently only supports "Required" and "RequiresNew" 
  transactions.  All others throw null pointer exceptions.
  Dan 
  -Original Message- From: 
  Hunter Hillegas [mailto:[EMAIL PROTECTED]] 
  Sent: Monday, November 19, 2001 5:06 PM To: Dain Sundstrom; JBoss Dev Subject: Re: 
  [JBoss-dev] 2.0 jar Really Likes DefaultDS? 
  So far nothing from this end. 
  If you get a chance to look at or if anyone else has any 
  ideas, please chime in? 
  Is no one else running Rabbit Hole with PostgreSQL and 2.0 
  EJB? 
  > From: Dain Sundstrom <[EMAIL PROTECTED]> 
  > Date: Mon, 19 Nov 2001 16:14:21 -0600 > To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain 
  Sundstrom > <[EMAIL PROTECTED]>, JBoss Dev 
  <[EMAIL PROTECTED]> > 
  Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS? > The ds jndi name is loaded in the metadata object of entities in 
  the > ...plulgin.cmp.jdbc.metadata package.  
  Then the ds is looked up in the > JDBCStoreManager 
  init method. Finally it is used in the JDBCCommand object. > > -dain > 
  >> -Original Message- >> From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] 
  >> Sent: Monday, November 19, 2001 3:50 PM 
  >> To: Dain Sundstrom; JBoss Dev >> Subject: Re: [JBoss-dev] 2.0 jar Really Likes 
  DefaultDS? >> >> 
  >> I haven't dug around in the source yet. If 
  you can give me a >> pointer where 
  >> to look, I'll check it out... >> >> If I remove DefaultDS (remove 
  the Hypersonic service XML >> file), my 
  beans >> don't deploy at all, complaining that 
  DefaultDS is missing... So it's >> definitely 
  not picking up my request for a different >> 
  datasource to be used. >> >> >> Hunter >> >>> From: Dain Sundstrom 
  <[EMAIL PROTECTED]> >>> Date: Mon, 19 
  Nov 2001 15:40:42 -0600 >>> To: "'Hunter 
  Hillegas'" <[EMAIL PROTECTED]>, JBoss Dev >>> <[EMAIL PROTECTED]> 
  >>> Subject: RE: [JBoss-dev] 2.0 jar Really Likes 
  DefaultDS? >>> >>> Looks right to me.  Did you try tracking this down in 
  the >> source?  I'll look >>> at it later but I'm a little busy right now. 
  >>> >>> 
  -dain >>>  -Original Message-  From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] 
   Sent: Monday, November 19, 2001 1:48 
  PM  To: JBoss Dev  Subject: [JBoss-dev] 2.0 jar Really Likes 
  DefaultDS?    I am 
  deploying a 2.0EJB jar into RH3.  
   Here's my jbosscmp-jdbc.xml 
  file:    
    
    
           
  java:/Groundswell    
  PostgreSQL    
  true    
  true    
  false    
  false    
  300    
  false     >> 
  foreign-key 
       
      No matter 
  what, the jar tries to run against DefaultDS when I  want it to run  against 'Groundswell' as the datasource. 
    
  What am I doing wrong?  
   Hunter   
   
  ___  Jboss-development mailing list  [EMAIL PROTECTED] 
   https://lists.sourceforge.net/lists/listinfo/jboss-development 
   >> 
  >> >> 
  ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development 
  >> 
  ___ 
  Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development 
  


RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Dain Sundstrom

Funny.  I just did that but in
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager line 110 where the
datasource is looked up. And it successfully looks up my new datasource. I
think you have a different problem. I changed the name of the hypersonic
data source. May be the problem is your postgresql driver setup.

-dain

> -Original Message-
> From: Dave Smith [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 2:41 PM
> To: Hunter Hillegas
> Cc: David Jencks; Torsten Schlumm; JBoss Dev
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> 
> Well if you want to get down and dirty in
> jboss/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/
> JDBCEntityMetaData.java
> line 336 is where it sets the datasouce for each entity. On 
> line 343 you 
> could add
> System.out.println("Enity = "+entityName+" "+dataSourceNameString+" 
> "+defaultValues.getDataSourceName());
> 
> 
> That should give you the datasource the entity is bound to.
> 
> 
> 
> Hunter Hillegas wrote:
> 
> > Are we sure that the datasource name in jbosscmp-jdbc.xml 
> is even being
> > checked properly?
> > 
> > I gave my config another look and it seems correct. Here 
> are is the console
> > log output:
> > 
> > [11:43:51,571,AutoDeployer] Auto deploy of
> > 
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqld
> b-default-serv
> > ice.xml
> > [11:43:51,602,Default] Libraries adding URLClassLoader 
> 1240345370 key URL
> > file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
> > [11:43:51,647,ServiceCreator] About to create the
> > beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> > [11:43:51,653,ServiceCreator] Created the
> > beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> > 
> > And the file:
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >   
> > 
> >   
> >   
> >   
> >   
> > 
> >>  
> name="JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell">
> >  > 
> name="ManagedConnectionFactoryProperties">ConnectionURL=jdbc:p
> ostgresql://lo
> > calhost/groundswell
> >   DriverClass=org.postgresql.Driver
> >   UserName=postgres
> >   Password=""
> > Groundswell
> >  > name="TransactionManagerName">java:/TransactionManager
> > 
> > 
> > JBOSS-SYSTEM:service=PostgreSQL
> > 
> >  > 
> name="ResourceAdapterName">JCA:service=RARDeployment,name=Minerva JDBC
> > LocalTransaction ResourceAdapter
> >  > 
> name="ConnectionManagerFactoryLoaderName">JCA:service=Connecti
> onManagerFacto
> > ryLoader,name=MinervaSharedLocalCMFactory
> > #
> >   #Wed Aug 15 16:17:29 EDT 2001
> >   MinSize=0
> >   MaxSize=10
> >   BlockingTimeoutMillis=5000
> >   IdleTimeoutMinutes=30
> >   CleanupIntervalMinutes=10
> >   MaxIdleTimeoutPercent=1.0
> > 
> > 
> >   org.jboss.resource.security.ManyToOnePrincipalMapping
> >
> >  > name="PrincipalMappingProperties">UserName=postgres
> >   
> > 
> > 
> > 
> >>From: David Jencks <[EMAIL PROTECTED]>
> >>Date: Tue, 20 Nov 2001 13:48:05 -0500
> >>To: Torsten Schlumm <[EMAIL PROTECTED]>
> >>Cc: Hunter Hillegas <[EMAIL PROTECTED]>,
> >>[EMAIL PROTECTED]
> >>Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> >>
> >>Have you guys included the latest updates to the 
> ConnectionFactoryLoader
> >>configuration format? The hsqldb example has been updated, 
> the manual
> >>likewise for mysql and postgres.  If updating is not the 
> problem, could you
> >>post your cfl config? does DefaultDS get started properly 
> on your system?
> >>
> >>Thanks
> >>david jencks
> >>
> >>On 2001.11.20 12:57:30 -0500 Torsten Schlumm wrote:
> >>
> >>>Hunter,
> >>>
> >>>I've seen the same thing with mySQL today (it did work with the CVS
> >>>sources
> >>>from about 3 weeks ago).
> >>>
> >>>After having a closer look at the list of registered MBeans
> >>>(localhost:8082)
> >>>I found it (at least something :)
> >>>My mysqlDS was perfectly registered but not started. After 
> starting it by
> >>>hand no problems anymore - deployment works.
> >>>
> >>>If that still doesn't work for you I could also send you 
> the relevant
> >>>files
> >>>from my setup/beans.
> >>>
> >>>I will also try to work out why the bloody thing doesn't 
> get started.
> >>>Anyone any ideas??
> >>>
> >>>Cheers
> >>>Torsten
> >>>
> >>>
> >>>
> >>>
> >>>On Mon, 19 Nov 2001 16:06:25 -0800
> >>>Hunter Hillegas <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> So far nothing from this end.
> 
> If you get a chance to look at or if anyone else has any 
> ideas, please
> 
> >>>chime
> >>>
> in?
> 
> Is no one else running Rabbit Hole with PostgreSQL and 2.0 EJB?
> 
> 
> >From: Dain Sundstrom <[EMAIL PROTECTED]>
> >Date: Mon, 19 Nov 2001 16:14:21 -0600
> >To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain Sundstrom
> ><[EMAIL PROTECTED]>, JBoss Dev
> >
> >><[EMAIL PROTECTED]>
> >>
> >Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> >The ds jn

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

2001-11-20 Thread Andreas Schaefer

  User: schaefera
  Date: 01/11/20 12:46:15

  Modified:src/main/org/jboss/deployment Tag: Branch_2_4
URLWizzard.java
  Log:
  Fixed bug #456467 by not adding a '/' when file in the root directory to
  go along with JAR tool.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.7.6.1   +8 -2  jboss/src/main/org/jboss/deployment/URLWizzard.java
  
  Index: URLWizzard.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/URLWizzard.java,v
  retrieving revision 1.7
  retrieving revision 1.7.6.1
  diff -u -r1.7 -r1.7.6.1
  --- URLWizzard.java   2000/12/07 15:44:07 1.7
  +++ URLWizzard.java   2001/11/20 20:46:15 1.7.6.1
  @@ -33,7 +33,8 @@
   * Very scratchy! Any improvements are welcome!
   *  
   *@author Daniel Schulze <[EMAIL PROTECTED]>
  -*@version $Revision: 1.7 $
  +*@author Andreas Schaefer <[EMAIL PROTECTED]>
  +*@version $Revision: 1.7.6.1 $
   */
   public class URLWizzard
   {
  @@ -121,7 +122,12 @@
}
else
{
  -_jout.putNextEntry (new ZipEntry(_prefix + "/" + content[i].getName 
()));
  +// If no prefix then no '/' necessary
  +_jout.putNextEntry(
  +   new ZipEntry(
  +  ( "".equals( _prefix ) ? "" : _prefix + "/" ) + 
content[i].getName()
  +   )
  +);
   FileInputStream in = new FileInputStream (content[i]);
   write (in, _jout);
   in.close ();
  
  
  

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



[JBoss-dev] [ jboss-Bugs-456467 ] Add in URLWizzard fails for top files

2001-11-20 Thread noreply

Bugs item #456467, was opened at 2001-08-29 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=456467&group_id=22866

Category: JBossServer
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Peter Antman (pra)
Assigned to: Andreas Schaefer (schaefera)
Summary: Add in URLWizzard fails for top files

Initial Comment:
The add() method in URLWizzard, used to download and
pack directorys into a jar file fails with files in the
top directory. 

For example the directory structure

META-INF/jboss.xml
MyClass.class

Will in the resulting jar-file look:

META_INF/jboss.xml
/MyClass.class

An extra "/" is appended for all files in the top dir.

The following line does the jobb:

_jout.putNextEntry (new ZipEntry(_prefix +
"/" + content[i].getName ()));

But for files in the top dir _prefix will be blank, and
the extra "/" will destroy the possibility of looking
it up in the classpath.

One possible solution is:

String sep = (_prefix.equals("") ? "" : "/");
jout.putNextEntry (new ZipEntry(_prefix + sep +
content[i].getName ()))

But someone wich knows the ins and outs of the deployer
stuff should probably fix it.

//Peter

--

>Comment By: Andreas Schaefer (schaefera)
Date: 2001-11-20 12:51

Message:
Logged In: YES 
user_id=70434

Fixed on the current CVS Head as well as on Branch 2.4.4.

Andy

--

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

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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Dave Smith

Well if you want to get down and dirty in
jboss/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCEntityMetaData.java
line 336 is where it sets the datasouce for each entity. On line 343 you 
could add
System.out.println("Enity = "+entityName+" "+dataSourceNameString+" 
"+defaultValues.getDataSourceName());


That should give you the datasource the entity is bound to.



Hunter Hillegas wrote:

> Are we sure that the datasource name in jbosscmp-jdbc.xml is even being
> checked properly?
> 
> I gave my config another look and it seems correct. Here are is the console
> log output:
> 
> [11:43:51,571,AutoDeployer] Auto deploy of
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqldb-default-serv
> ice.xml
> [11:43:51,602,Default] Libraries adding URLClassLoader 1240345370 key URL
> file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
> [11:43:51,647,ServiceCreator] About to create the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> [11:43:51,653,ServiceCreator] Created the
> beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
> 
> And the file:
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
>   
>   
>   
>   
> 
> name="JBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell">
>  name="ManagedConnectionFactoryProperties">ConnectionURL=jdbc:postgresql://lo
> calhost/groundswell
>   DriverClass=org.postgresql.Driver
>   UserName=postgres
>   Password=""
> Groundswell
>  name="TransactionManagerName">java:/TransactionManager
> 
> 
> JBOSS-SYSTEM:service=PostgreSQL
> 
>  name="ResourceAdapterName">JCA:service=RARDeployment,name=Minerva JDBC
> LocalTransaction ResourceAdapter
>  name="ConnectionManagerFactoryLoaderName">JCA:service=ConnectionManagerFacto
> ryLoader,name=MinervaSharedLocalCMFactory
> #
>   #Wed Aug 15 16:17:29 EDT 2001
>   MinSize=0
>   MaxSize=10
>   BlockingTimeoutMillis=5000
>   IdleTimeoutMinutes=30
>   CleanupIntervalMinutes=10
>   MaxIdleTimeoutPercent=1.0
> 
> 
>   org.jboss.resource.security.ManyToOnePrincipalMapping
>
>  name="PrincipalMappingProperties">UserName=postgres
>   
> 
> 
> 
>>From: David Jencks <[EMAIL PROTECTED]>
>>Date: Tue, 20 Nov 2001 13:48:05 -0500
>>To: Torsten Schlumm <[EMAIL PROTECTED]>
>>Cc: Hunter Hillegas <[EMAIL PROTECTED]>,
>>[EMAIL PROTECTED]
>>Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>>
>>Have you guys included the latest updates to the ConnectionFactoryLoader
>>configuration format? The hsqldb example has been updated, the manual
>>likewise for mysql and postgres.  If updating is not the problem, could you
>>post your cfl config? does DefaultDS get started properly on your system?
>>
>>Thanks
>>david jencks
>>
>>On 2001.11.20 12:57:30 -0500 Torsten Schlumm wrote:
>>
>>>Hunter,
>>>
>>>I've seen the same thing with mySQL today (it did work with the CVS
>>>sources
>>>from about 3 weeks ago).
>>>
>>>After having a closer look at the list of registered MBeans
>>>(localhost:8082)
>>>I found it (at least something :)
>>>My mysqlDS was perfectly registered but not started. After starting it by
>>>hand no problems anymore - deployment works.
>>>
>>>If that still doesn't work for you I could also send you the relevant
>>>files
>>>from my setup/beans.
>>>
>>>I will also try to work out why the bloody thing doesn't get started.
>>>Anyone any ideas??
>>>
>>>Cheers
>>>Torsten
>>>
>>>
>>>
>>>
>>>On Mon, 19 Nov 2001 16:06:25 -0800
>>>Hunter Hillegas <[EMAIL PROTECTED]> wrote:
>>>
>>>
So far nothing from this end.

If you get a chance to look at or if anyone else has any ideas, please

>>>chime
>>>
in?

Is no one else running Rabbit Hole with PostgreSQL and 2.0 EJB?


>From: Dain Sundstrom <[EMAIL PROTECTED]>
>Date: Mon, 19 Nov 2001 16:14:21 -0600
>To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain Sundstrom
><[EMAIL PROTECTED]>, JBoss Dev
>
>><[EMAIL PROTECTED]>
>>
>Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>The ds jndi name is loaded in the metadata object of entities in the
>...plulgin.cmp.jdbc.metadata package.  Then the ds is looked up in
>
>>>the
>>>
>JDBCStoreManager init method. Finally it is used in the JDBCCommand
>
>>>object.
>>>
>-dain
>
>
>>-Original Message-
>>From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, November 19, 2001 3:50 PM
>>To: Dain Sundstrom; JBoss Dev
>>Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>>
>>
>>I haven't dug around in the source yet. If you can give me a
>>pointer where
>>to look, I'll check it out...
>>
>>If I remove DefaultDS (remove the Hypersonic service XML
>>file), my beans
>>don't deploy at all, complaining that DefaultDS is missing... So
>>
>>>it's
>>>
>>definitely not picking up my request for a different
>>datasource to be used.
>>
>>
>>Hunter
>>>

[JBoss-dev] ObjectPool - Invalidate On Error

2001-11-20 Thread Ferguson, Doug

We have just noticed that whenever our code throws a SQLException, 
the connection pool continues to grow.  Apparently the connections 
that get "invalidated" aren't ever cleaned up. These grow until Oracle
bails. I am looking at ObjectPool right now to see if I can figure it out.

If anybody already knows about this, please let me know.

Thanks,
d.

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



[JBoss-dev] redesigning J2EE packaging

2001-11-20 Thread Anatoly Akkerman


Hi,

I've been observing some of the recent threads on the list and reflected
on my current project. Mark has mentioned something of the sort that j2ee
packaging sucks. I certainly agree.

Here is what seems to be a better design that is consistent with JBoss
philosophy. Please, don't flame, these are just ideas for discussion.

Deploying anything is just giving 1 xml file to a deployer. No more
multiple files (Richard mentioned that a few days ago, just use XML
namespaces and whatever else is needed to glue the pieces together). This
single XML file has all the necessary information about the item being
deployed:

For services this would be whatever is now in jboss-service.xml 
For j2ee modules/applications the file would contain sections with
standard j2ee metadata, jboss-specific metadata, jaws, whatever.

And, I think the crucial part for all of the above , is the
packaging/scoping information which specifies;
1) CL scoping for this deployable entity
2) any module-specific class library URLs 
3) file archive URLs 

Here is my look at it. CL Scoping is just a service that JBoss provides
which ought to be configurable. No more 'implied' derivations of module
dependencies from awkward MANIFEST.MF Class-Path: entries (though this can
still be supported). It ought to be configured through standard XML
descriptors, like any other service. 

Scope:
keeps scope-wise global class library repository
libraries can be added to the scope/removed/updated

Modules:
deployed in a scope
specify libraries it depends on (from the Scope)
additional libraries/ file archives

I want to be able to just give all the jar library URLs to my personal
Scope and then deploy only the XML descriptors of j2ee modules. 

So, to accomplish this, in this new architecture, one might prepare
('deploy') a new Scope with whatever libraries he may want to use. (Say,
by creating an xml files with the scope description and library URLs that
need to be made available in this scope)

Then deploy modules in that scope by just giving xml files describing
these modules. It may also be important to include additional library /
file archive URLs at module deploy time in that same xml file. For example
when deploying a WAR, one would necessarily have to provide the WAR file
archive with jsps, taglibs, whatever else which is not obtained through
standard classloading mechanisms, so a URL of this archive can be placed
into the xml.

Nice things about this:
- no hard coded xml descriptor names (like META-INF/ejb-jar.xml,
  WEB-INF/web.xml) 
- unified configuration of underlying services in one file
- package libraries/classes whichever way you want just make them 
  available to the underlying CL through scope definition or
  module description
- no more messing with MANIFEST.MF, jarring/unjarring just
  to modify descriptors, yak...

My current project would benefit tremendously in trimming down
packaging/unpackaging complexity if this architecture was in place. Do
others think this may be useful?

-
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719  Tel: 212 998-3493
New York, NY 10003  Fax: 212 995-4123
-



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



[JBoss-dev] [ jboss-Bugs-456467 ] Add in URLWizzard fails for top files

2001-11-20 Thread noreply

Bugs item #456467, was opened at 2001-08-29 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=456467&group_id=22866

Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Peter Antman (pra)
>Assigned to: Andreas Schaefer (schaefera)
Summary: Add in URLWizzard fails for top files

Initial Comment:
The add() method in URLWizzard, used to download and
pack directorys into a jar file fails with files in the
top directory. 

For example the directory structure

META-INF/jboss.xml
MyClass.class

Will in the resulting jar-file look:

META_INF/jboss.xml
/MyClass.class

An extra "/" is appended for all files in the top dir.

The following line does the jobb:

_jout.putNextEntry (new ZipEntry(_prefix +
"/" + content[i].getName ()));

But for files in the top dir _prefix will be blank, and
the extra "/" will destroy the possibility of looking
it up in the classpath.

One possible solution is:

String sep = (_prefix.equals("") ? "" : "/");
jout.putNextEntry (new ZipEntry(_prefix + sep +
content[i].getName ()))

But someone wich knows the ins and outs of the deployer
stuff should probably fix it.

//Peter

--

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

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



[JBoss-dev] [ jboss-Bugs-435463 ] Distributed transactions

2001-11-20 Thread noreply

Bugs item #435463, was opened at 2001-06-22 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=435463&group_id=22866

Category: JBossTX
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Andreas Schaefer (schaefera)
Summary: Distributed transactions 

Initial Comment:
Hello,

I am using jboss-tomcat (jboss v2.2.2) on Windows 2000 
with MS SQL Server using Inets Opta 2000 driver.

I have been working with Volker Berlin at inetsoftware 
to get the opta2000 XDataSource to work with jboss 
2.2. Whenever, I tried to 
use the inet's XDataSource vs. minerva's XADataSource 
I would get the following error:

[UserEntityBean] XAException: tx=XidImpl 
[FormatId=257, GlobalId=KMELDORM//1, BranchQual=] 
errorCode=XAER_NOTA
[UserEntityBean] javax.transaction.xa.XAException: The 
XID is not valid.
[UserEntityBean]at com.inet.tds.k.if(Unknown 
Source)
[UserEntityBean]at com.inet.tds.k.for(Unknown 
Source)
[UserEntityBean]at com.inet.tds.k.end(Unknown 
Source)
[UserEntityBean]at 
org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1147)
[UserEntityBean]at 
org.jboss.tm.TxCapsule.delistResource
(TxCapsule.java:541)
[UserEntityBean]at 
org.jboss.tm.TransactionImpl.delistResource
(TransactionImpl.java:99)
[UserEntityBean]at 
org.opentools.minerva.jdbc.xa.XAConnectionFactory$2.c
loseConnection(XAConnectionFactory.java:97)
[UserEntityBean]at 
org.opentools.minerva.jdbc.xa.XAConnectionFactory$2.con
nectionClosed(XAConnectionFactory.java:82)
[UserEntityBean]at com.inet.pool.c.a(Unknown 
Source)
[UserEntityBean]at com.inet.tds.k.a(Unknown 
Source)
[UserEntityBean]at com.inet.pool.a.close
(Unknown Source)
[UserEntityBean]at 
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute
(JDBCCommand.java:180)
[UserEntityBean]at 
org.jboss.ejb.plugins.jaws.jdbc.JDBCFinderCommand.execu
te(JDBCFinderCommand.java:60)
[UserEntityBean]at 
org.jboss.ejb.plugins.jaws.jdbc.JDBCFindEntitiesCommand
.execute(JDBCFindEntitiesCommand.java:145)
[UserEntityBean]at 
org.jboss.ejb.plugins.jaws.jdbc.JDBCFindEntityCommand
.execute(JDBCFindEntityCommand.java:64)
[UserEntityBean]at 
org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.findE
ntity(JAWSPersistenceManager.java:130)
[UserEntityBean]at 
org.jboss.ejb.plugins.CMPPersistenceManager.findEntity
(CMPPersistenceManager.java:270)
[UserEntityBean]at 
org.jboss.ejb.EntityContainer.find
(EntityContainer.java:419)
[UserEntityBean]at 
java.lang.reflect.Method.invoke(Native Method)
[UserEntityBean]at 
org.jboss.ejb.EntityContainer$ContainerInterceptor.invo
keHome(EntityContainer.java:639)
[UserEntityBean]at 
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.
invokeHome(EntitySynchronizationInterceptor.java:160)
[UserEntityBean]at 
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeH
ome(EntityInstanceInterceptor.java:87)
[UserEntityBean]at 
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext
(TxInterceptorCMT.java:135)
[UserEntityBean]at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:263)
[UserEntityBean]at 
org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome
(TxInterceptorCMT.java:86)
[UserEntityBean]at 
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(
SecurityInterceptor.java:164)
[UserEntityBean]at 
org.jboss.ejb.plugins.LogInterceptor.invokeHome
(LogInterceptor.java:106)
[UserEntityBean]at 
org.jboss.ejb.EntityContainer.invokeHome
(EntityContainer.java:316)
[UserEntityBean]at 
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.
invokeHome(JRMPContainerInvoker.java:436)
[UserEntityBean]at 
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke
(HomeProxy.java:212)
[UserEntityBean]at $Proxy17.findByLogin
(Unknown Source)
[UserEntityBean]at 
com.wtp.nbk.security.UserSessionBean.findByLogin
(UserSessionBean.java:297)
[UserEntityBean]at 
com.wtp.nbk.security.UserSessionBean.returnPassword
(UserSessionBean.java:254)
[UserEntityBean]at 
com.wtp.nbk.security.UserSessionBean.validateUser
(UserSessionBean.java:155)
[UserEntityBean]at 
java.lang.reflect.Method.invoke(Native Method)
[UserEntityBean]at 
org.jboss.ejb.StatelessSessionContainer$ContainerInterc
eptor.invoke(StatelessSessionContainer.java:472)
[UserEntityBean]at 
org.jboss.ejb.plugins.StatelessSessionInstanceIntercept
or.invoke(StatelessSessionInstanceInterceptor.java:87)
[UserEntityBean]at 
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext
(TxInterceptorCMT.java:133)
[UserEntityBean]at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:263)
[UserEntityBean]at 
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:99)
[UserEntityBean]

Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Hunter Hillegas

Are we sure that the datasource name in jbosscmp-jdbc.xml is even being
checked properly?

I gave my config another look and it seems correct. Here are is the console
log output:

[11:43:51,571,AutoDeployer] Auto deploy of
file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/postgresqldb-default-serv
ice.xml
[11:43:51,602,Default] Libraries adding URLClassLoader 1240345370 key URL
file:/Users/hunter/Desktop/jboss-3.0.0alpha/lib/ext/postgresql.jar
[11:43:51,647,ServiceCreator] About to create the
beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell
[11:43:51,653,ServiceCreator] Created the
beanJBOSS-SYSTEM:service=ConnectionFactoryLoader,name=Groundswell

And the file:








  

  
  
  
  

  
ConnectionURL=jdbc:postgresql://lo
calhost/groundswell
  DriverClass=org.postgresql.Driver
  UserName=postgres
  Password=""
Groundswell
java:/TransactionManager


JBOSS-SYSTEM:service=PostgreSQL

JCA:service=RARDeployment,name=Minerva JDBC
LocalTransaction ResourceAdapter
JCA:service=ConnectionManagerFacto
ryLoader,name=MinervaSharedLocalCMFactory
#
  #Wed Aug 15 16:17:29 EDT 2001
  MinSize=0
  MaxSize=10
  BlockingTimeoutMillis=5000
  IdleTimeoutMinutes=30
  CleanupIntervalMinutes=10
  MaxIdleTimeoutPercent=1.0


  org.jboss.resource.security.ManyToOnePrincipalMapping
   
UserName=postgres
  



> From: David Jencks <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 13:48:05 -0500
> To: Torsten Schlumm <[EMAIL PROTECTED]>
> Cc: Hunter Hillegas <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> Have you guys included the latest updates to the ConnectionFactoryLoader
> configuration format? The hsqldb example has been updated, the manual
> likewise for mysql and postgres.  If updating is not the problem, could you
> post your cfl config? does DefaultDS get started properly on your system?
> 
> Thanks
> david jencks
> 
> On 2001.11.20 12:57:30 -0500 Torsten Schlumm wrote:
>> Hunter,
>> 
>> I've seen the same thing with mySQL today (it did work with the CVS
>> sources
>> from about 3 weeks ago).
>> 
>> After having a closer look at the list of registered MBeans
>> (localhost:8082)
>> I found it (at least something :)
>> My mysqlDS was perfectly registered but not started. After starting it by
>> hand no problems anymore - deployment works.
>> 
>> If that still doesn't work for you I could also send you the relevant
>> files
>> from my setup/beans.
>> 
>> I will also try to work out why the bloody thing doesn't get started.
>> Anyone any ideas??
>> 
>> Cheers
>> Torsten
>> 
>> 
>> 
>> 
>> On Mon, 19 Nov 2001 16:06:25 -0800
>> Hunter Hillegas <[EMAIL PROTECTED]> wrote:
>> 
>>> So far nothing from this end.
>>> 
>>> If you get a chance to look at or if anyone else has any ideas, please
>> chime
>>> in?
>>> 
>>> Is no one else running Rabbit Hole with PostgreSQL and 2.0 EJB?
>>> 
 From: Dain Sundstrom <[EMAIL PROTECTED]>
 Date: Mon, 19 Nov 2001 16:14:21 -0600
 To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain Sundstrom
 <[EMAIL PROTECTED]>, JBoss Dev
> <[EMAIL PROTECTED]>
 Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
 The ds jndi name is loaded in the metadata object of entities in the
 ...plulgin.cmp.jdbc.metadata package.  Then the ds is looked up in
>> the
 JDBCStoreManager init method. Finally it is used in the JDBCCommand
>> object.
 
 -dain
 
> -Original Message-
> From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 19, 2001 3:50 PM
> To: Dain Sundstrom; JBoss Dev
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> 
> I haven't dug around in the source yet. If you can give me a
> pointer where
> to look, I'll check it out...
> 
> If I remove DefaultDS (remove the Hypersonic service XML
> file), my beans
> don't deploy at all, complaining that DefaultDS is missing... So
>> it's
> definitely not picking up my request for a different
> datasource to be used.
> 
> 
> Hunter
> 
>> From: Dain Sundstrom <[EMAIL PROTECTED]>
>> Date: Mon, 19 Nov 2001 15:40:42 -0600
>> To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, JBoss Dev
>> <[EMAIL PROTECTED]>
>> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>> 
>> Looks right to me.  Did you try tracking this down in the
> source?  I'll look
>> at it later but I'm a little busy right now.
>> 
>> -dain
>> 
>>> -Original Message-
>>> From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
>>> Sent: Monday, November 19, 2001 1:48 PM
>>> To: JBoss Dev
>>> Subject: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>>> 
>>> 
>>> I am deploying a 2.0EJB jar into RH3.
>>> 
>>> Here's my jbosscmp-jdbc.xml file:
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>>   java:/Groundswel

Re: [JBoss-dev] Application/Deployment Units

2001-11-20 Thread VASQUEZ_JASON

thx -- i'll keep an eye out for it...

-jason





Andreas Schaefer <[EMAIL PROTECTED]>
11/20/2001 12:46 PM

 
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
cc: 
Subject:Re: [JBoss-dev] Application/Deployment Units



Hi

Right now there is no more management information
available. But soon the implementation of JSR-77 should
provide you with the necessary informations.

Have fun - Andy

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 20, 2001 8:10 AM
Subject: [JBoss-dev] Application/Deployment Units


> Hi all --
>
> Sorry for such a newbie question, but
>
> Is there any place with jboss (working with rh) which stores data  about
> *all* pieces of an application deployment at runtime?  For instance, I 
can
> get the "DeployedApplications" attribute from the ContainerFactory 
MBean,
> which gives me an Iterator of org.jboss.ejb.Application objects, with
> which I can in turn retrieve the associated containers for each EJB. 
But,
> I haven't seen how to find any associated web applications in the same
> deployment unit.  (I can get the DeployedApplication from the Jetty 
MBean,
> but there is no association with each webapp to the rest of its
> application)
>
> Could someone give me a little nudge in the right direction?
>
> thanks,
> jason
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>





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



RE: [JBoss-dev] 1 to Many Relations

2001-11-20 Thread Dain Sundstrom

> Uncle. It seems that JBOSS is designed assuming that it has 
> full control of creating tables. 

This isn't really true.  JBossCMP makes the assumption that if the table
structure is not specified the Application Deployer does not care what the
structure is, as long as it runs.

I strongly recommend that before any application goes into production that
the database structure should be locked down (full specified), as the
defaults may change from version to version.

> Well in my case I already have a database already 
> set up so my view of things is how do I stuff this database 
> into JBOSS. 
> I don't think it is worth the discussion which approach is right or 
> wrong but, we should document the view jboss takes and then write 
> appropriate documention for the other approach. Dain if you 
> could get at 
> DTD for jbosscmp-jdbc.xml I'll tidy up xdoclet and write some 
> documentation for "I've got these tables now how do I do relations in 
> JBOSS". This should eliminate this thread occurring over and 
> over on the 
>   user mailing lists.
> 
> Dave
> 

I agree, I have already started on an appendix to the JBossCMP docs that
specifies the default names.

-dain

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



[JBoss-dev] CVS update: manual/src/xdocs jbossdocs.xml resource.xml jdbc-database.xml

2001-11-20 Thread David Jencks

  User: d_jencks
  Date: 01/11/20 10:35:30

  Modified:src/xdocs jbossdocs.xml resource.xml
  Removed: src/xdocs jdbc-database.xml
  Log:
  Added Sybase ConnectionFactoryLoader example and removed 2.4-specific db 
documentation.
  
  Revision  ChangesPath
  3.1   +2 -26 manual/src/xdocs/jbossdocs.xml
  
  Index: jbossdocs.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/xdocs/jbossdocs.xml,v
  retrieving revision 3.0
  retrieving revision 3.1
  diff -u -r3.0 -r3.1
  --- jbossdocs.xml 2001/11/18 20:10:57 3.0
  +++ jbossdocs.xml 2001/11/20 18:35:29 3.1
  @@ -1,12 +1,11 @@
   
  -
  +
   
  
  
  
  
  -   
  
  
  
  @@ -14,7 +13,6 @@
  
  
  
  -   
  
  
  
  @@ -23,7 +21,6 @@
  
  
  
  -   
  
  
  
  @@ -48,7 +45,7 @@
   
   
  
  -  JBoss 2.2+ Documentation
  +  JBoss 3.0 Documentation
 
2000
 2001
  @@ -61,26 +58,6 @@
  &jbossintro.xml;
  &basicconfiguration.xml;
  &resource.xml;
  -
  -   
  -  JDBC
  -   
  - 
  - Aaron
  - Mulder
  - 
  -  [EMAIL PROTECTED]
  - 
  - Fernando
  - Garcia-Loygorri
  - 
  -  [EMAIL PROTECTED]
  -  
  -
  -  &jdbc-database.xml;
  -  &howtomssql.xml;
  -   
  -
  &cmp.xml;
  &customizingjaws.xml;
  &advconfig.xml;
  @@ -117,7 +94,6 @@
 &howtojaas.xml;
 &howtojavamail.xml;
 &howtoejx.xml;
  -  &howtojca.xml;
 &howtojndiexternal.xml;
 &howtosocketfactories.xml;
 &howtojaxp.xml;
  
  
  
  3.1   +59 -3 manual/src/xdocs/resource.xml
  
  Index: resource.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/xdocs/resource.xml,v
  retrieving revision 3.0
  retrieving revision 3.1
  diff -u -r3.0 -r3.1
  --- resource.xml  2001/11/18 20:10:57 3.0
  +++ resource.xml  2001/11/20 18:35:29 3.1
  @@ -14,7 +14,7 @@
 
   Access to Resource Managers
   This chapter is primarily relevant to jboss 3.0 (rabbithole)
  -In order for your ejbs to do much useful work, they will need to 
communicate with a transactional resource manager such as a relational database, 
transactional message queue, or other enterprise information system.  Jboss now 
supports all such communication using Resource Adapters following the jca 1.0 
specification (NEED LINK).  This technology provides a uniform way to combine the 
application server's transaction management and connection pooling functionalities 
with a resource adapter's ability to connect to and do work with a resource 
manager.
  +In order for your ejbs to do much useful work, they will need to 
communicate with a transactional resource manager such as a relational database, 
transactional message queue, or other enterprise information system.  Jboss now 
supports all such communication using Resource Adapters following the  http://java.sun.com/j2ee/connector/";>jca 1.0 
specification.  This technology provides a uniform way to combine 
the application server's transaction management and connection pooling functionalities 
with a resource adapter's ability to connect to and do work with a resource 
manager.
   Jboss provides the ability to deploy any compliant resource adapter, 
and connections from any adapter may be pooled by jboss, obtained from connection 
factories bound in jndi, and used by client code.  At the moment, however, only 
connection factories implementing javax.sql.DataSource and connections implementing 
java.sql.Connection may be used with CMP beans and JAWS to automate database 
access.
   Since few database vendors have supplied resource adapters for their 
database products, the usual strategy for accessing relational databases consists of 
using a generic resource adapter that wraps a jdbc driver into a jca resource adapter. 
 Jboss comes with two such adapters, one for jdbc 1 drivers without xa transaction 
support, and one for jdbc 2 drivers implementing xa support with XADataSource and 
XAConnection.
   As well as providing a systematic, well thought out framework for 
pooling and transaction control that can be used for relational databases, jca also 
provides another specification ("cci") for connection factories and connections 
unrelated to jdbc. An adaptor could use these to provide predefined access to stored 
procedures in a relational database, or these could be used to access a message que, 
or enterprise information system such as CICS or SAP.  Although there are no 
particular conceptual difficulties in using such resource adapters to automatically 
manage persistence of CMP beans, support for this is not yet integrated into jboss. 

  @@ -248,7 +248,7 @@
   
   
   
  -
  +
   
   
   
  @@ 

Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread David Jencks

Have you guys included the latest updates to the ConnectionFactoryLoader
configuration format? The hsqldb example has been updated, the manual
likewise for mysql and postgres.  If updating is not the problem, could you
post your cfl config? does DefaultDS get started properly on your system?

Thanks
david jencks

On 2001.11.20 12:57:30 -0500 Torsten Schlumm wrote:
> Hunter,
> 
> I've seen the same thing with mySQL today (it did work with the CVS
> sources
> from about 3 weeks ago).
> 
> After having a closer look at the list of registered MBeans
> (localhost:8082)
> I found it (at least something :)
> My mysqlDS was perfectly registered but not started. After starting it by
> hand no problems anymore - deployment works.
> 
> If that still doesn't work for you I could also send you the relevant
> files
> from my setup/beans.
> 
> I will also try to work out why the bloody thing doesn't get started.
> Anyone any ideas??
> 
> Cheers
> Torsten
> 
> 
> 
> 
> On Mon, 19 Nov 2001 16:06:25 -0800
> Hunter Hillegas <[EMAIL PROTECTED]> wrote:
> 
> > So far nothing from this end.
> > 
> > If you get a chance to look at or if anyone else has any ideas, please
> chime
> > in?
> > 
> > Is no one else running Rabbit Hole with PostgreSQL and 2.0 EJB?
> > 
> > > From: Dain Sundstrom <[EMAIL PROTECTED]>
> > > Date: Mon, 19 Nov 2001 16:14:21 -0600
> > > To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain Sundstrom
> > > <[EMAIL PROTECTED]>, JBoss Dev
<[EMAIL PROTECTED]>
> > > Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> > > The ds jndi name is loaded in the metadata object of entities in the
> > > ...plulgin.cmp.jdbc.metadata package.  Then the ds is looked up in
> the
> > > JDBCStoreManager init method. Finally it is used in the JDBCCommand
> object.
> > > 
> > > -dain
> > > 
> > >> -Original Message-
> > >> From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
> > >> Sent: Monday, November 19, 2001 3:50 PM
> > >> To: Dain Sundstrom; JBoss Dev
> > >> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> > >> 
> > >> 
> > >> I haven't dug around in the source yet. If you can give me a
> > >> pointer where
> > >> to look, I'll check it out...
> > >> 
> > >> If I remove DefaultDS (remove the Hypersonic service XML
> > >> file), my beans
> > >> don't deploy at all, complaining that DefaultDS is missing... So
> it's
> > >> definitely not picking up my request for a different
> > >> datasource to be used.
> > >> 
> > >> 
> > >> Hunter
> > >> 
> > >>> From: Dain Sundstrom <[EMAIL PROTECTED]>
> > >>> Date: Mon, 19 Nov 2001 15:40:42 -0600
> > >>> To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, JBoss Dev
> > >>> <[EMAIL PROTECTED]>
> > >>> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> > >>> 
> > >>> Looks right to me.  Did you try tracking this down in the
> > >> source?  I'll look
> > >>> at it later but I'm a little busy right now.
> > >>> 
> > >>> -dain
> > >>> 
> >  -Original Message-
> >  From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
> >  Sent: Monday, November 19, 2001 1:48 PM
> >  To: JBoss Dev
> >  Subject: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> >  
> >  
> >  I am deploying a 2.0EJB jar into RH3.
> >  
> >  Here's my jbosscmp-jdbc.xml file:
> >  
> >  
> >  
> >  
> >  
> > 
> >    java:/Groundswell
> >    PostgreSQL
> >    true
> >    true
> >    false
> >    false
> >    300
> >    false
> >    
> >  
> > >> foreign-key
> > 
> >  
> >  
> >  No matter what, the jar tries to run against DefaultDS when I
> >  want it to run
> >  against 'Groundswell' as the datasource.
> >  
> >  What am I doing wrong?
> >  
> >  Hunter
> >  
> >  
> >  ___
> >  Jboss-development mailing list
> >  [EMAIL PROTECTED]
> >  https://lists.sourceforge.net/lists/listinfo/jboss-development
> >  
> > >> 
> > >> 
> > >> ___
> > >> Jboss-development mailing list
> > >> [EMAIL PROTECTED]
> > >> https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >> 
> > 
> > 
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 

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



[JBoss-dev] CVS update: manual/src/xdocs/howto howtojetty.xml howtopetstore.xml howtojca.xml howtomssql.xml

2001-11-20 Thread David Jencks

  User: d_jencks
  Date: 01/11/20 10:35:31

  Modified:src/xdocs/howto howtojetty.xml howtopetstore.xml
  Removed: src/xdocs/howto howtojca.xml howtomssql.xml
  Log:
  Added Sybase ConnectionFactoryLoader example and removed 2.4-specific db 
documentation.
  
  Revision  ChangesPath
  3.1   +1 -1  manual/src/xdocs/howto/howtojetty.xml
  
  Index: howtojetty.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtojetty.xml,v
  retrieving revision 3.0
  retrieving revision 3.1
  diff -u -r3.0 -r3.1
  --- howtojetty.xml2001/11/18 20:10:58 3.0
  +++ howtojetty.xml2001/11/20 18:35:31 3.1
  @@ -238,7 +238,7 @@



  -  
for basic information on configuring JBoss-Jetty to use 
  +  for basic information on configuring JBoss-Jetty to use 
a database server.


  
  
  
  3.1   +2 -2  manual/src/xdocs/howto/howtopetstore.xml
  
  Index: howtopetstore.xml
  ===
  RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtopetstore.xml,v
  retrieving revision 3.0
  retrieving revision 3.1
  diff -u -r3.0 -r3.1
  --- howtopetstore.xml 2001/11/18 20:10:58 3.0
  +++ howtopetstore.xml 2001/11/20 18:35:31 3.1
  @@ -1,5 +1,5 @@
   
  -
  +
   
   
Deploying the Pet Store 1.1.2 Demo in JBoss
  @@ -91,7 +91,7 @@
Add DB Pools to JBoss
The JBoss Pet Store patch file includes the file 
jboss.jcml. This file defines Pet Store DB Pools for JBoss 2.4 using Cloudscape on 
port 1098.
Cloudscape uses port 1099 by default. JBoss uses 
port 1099 for JNDI.
  - If you will be using a different database, you 
will need to define the appropriate DB pools for your database. See  for details
  + If you will be using a different database, you 
will need to define the appropriate DB pools for your database. See  for details


Prepare the Database
  
  
  

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



Re: [JBoss-dev] IBM AS/400 (tm), it seems to be running right. kick webshmere ass

2001-11-20 Thread Andrew Scherpbier

Ernst,
Before you attempt to do what you suggest, I would suggest you first do 
some analysis of your environment.  There are some things that you need 
to be aware of.
The first thing you need to do is determine if there is a performance 
problem.  What are your performance goals?  What makes you think that 
JBoss is the problem?  How did you test this?  Can any performance 
problems be solved by throwing more hardware at the problem?  Are there 
alternative J2EE app servers that will meet your performance goals?

Also, keep in mind that the speed of JBoss is determined more by I/O 
(disk, network, database, etc.) and context switching speed of the 
underlying OS than by the JVM (Java Virtual Machine).

Since you claim to be a Java newby, I have to point out some things 
about Java you probably didn't know:
I assume that the JVM on the AS400 has a JIT (Just In Time compiler). 
 Knowing IBM, this JIT will be of excellent quality.  My (pretty 
extensive) experience with long running systems like JBoss is that 
running the java program with a JIT will be close to the speed or 
sometimes *faster* than running a native version (java compiled into 
native code).  (At least Sun's Hotspot JIT in server mode outperforms 
anything I've tried, including optimized C++ code, when it comes to 
memory allocation/deallocation.)
In short, don't underestimate the power of java and the JVM.  :-)

So, my advise is: don't even think about doing a project like this 
unless you know absolutely need to.  Evalutate the cost of your effort 
compared to the performance gain that you may or may not get.

Ernst Bekker wrote:

>I unzipped 2.4.1 on our as400 v5r1 at work. The server runs without any
>complaints. 
>Unfortunately I am a java newby. (don't stop reading now).
>The as400 can compile java classes into native as400 byte code that runs
>like lightning. What I would like to contribute is as/400 CL and RPG code to
>make JBOSS the obvious choice for as400. So please help me out here.
>I can compile a .class and .jar files with a command (CRTJVAPGM), and then
>run them with (RUNJVAPGM).
>If you can give me an idea of how all the files fit together I am sure I can
>write some software to automate an optimal as400 server.
>
>
>TIA
>Ernst Bekker
>
-- 
Andrew Scherpbier, CTO ([EMAIL PROTECTED])
BlackBall Music (http://www.blackballmusic.com/)




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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Torsten Schlumm

Hunter,

I've seen the same thing with mySQL today (it did work with the CVS sources
from about 3 weeks ago).

After having a closer look at the list of registered MBeans (localhost:8082)
I found it (at least something :)
My mysqlDS was perfectly registered but not started. After starting it by
hand no problems anymore - deployment works.

If that still doesn't work for you I could also send you the relevant files
from my setup/beans.

I will also try to work out why the bloody thing doesn't get started.
Anyone any ideas??

Cheers
Torsten




On Mon, 19 Nov 2001 16:06:25 -0800
Hunter Hillegas <[EMAIL PROTECTED]> wrote:

> So far nothing from this end.
> 
> If you get a chance to look at or if anyone else has any ideas, please chime
> in?
> 
> Is no one else running Rabbit Hole with PostgreSQL and 2.0 EJB?
> 
> > From: Dain Sundstrom <[EMAIL PROTECTED]>
> > Date: Mon, 19 Nov 2001 16:14:21 -0600
> > To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain Sundstrom
> > <[EMAIL PROTECTED]>, JBoss Dev <[EMAIL PROTECTED]>
> > Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> > The ds jndi name is loaded in the metadata object of entities in the
> > ...plulgin.cmp.jdbc.metadata package.  Then the ds is looked up in the
> > JDBCStoreManager init method. Finally it is used in the JDBCCommand object.
> > 
> > -dain
> > 
> >> -Original Message-
> >> From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
> >> Sent: Monday, November 19, 2001 3:50 PM
> >> To: Dain Sundstrom; JBoss Dev
> >> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> >> 
> >> 
> >> I haven't dug around in the source yet. If you can give me a
> >> pointer where
> >> to look, I'll check it out...
> >> 
> >> If I remove DefaultDS (remove the Hypersonic service XML
> >> file), my beans
> >> don't deploy at all, complaining that DefaultDS is missing... So it's
> >> definitely not picking up my request for a different
> >> datasource to be used.
> >> 
> >> 
> >> Hunter
> >> 
> >>> From: Dain Sundstrom <[EMAIL PROTECTED]>
> >>> Date: Mon, 19 Nov 2001 15:40:42 -0600
> >>> To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, JBoss Dev
> >>> <[EMAIL PROTECTED]>
> >>> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> >>> 
> >>> Looks right to me.  Did you try tracking this down in the
> >> source?  I'll look
> >>> at it later but I'm a little busy right now.
> >>> 
> >>> -dain
> >>> 
>  -Original Message-
>  From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
>  Sent: Monday, November 19, 2001 1:48 PM
>  To: JBoss Dev
>  Subject: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>  
>  
>  I am deploying a 2.0EJB jar into RH3.
>  
>  Here's my jbosscmp-jdbc.xml file:
>  
>  
>  
>  
>  
> 
>    java:/Groundswell
>    PostgreSQL
>    true
>    true
>    false
>    false
>    300
>    false
>    
>  
> >> foreign-key
> 
>  
>  
>  No matter what, the jar tries to run against DefaultDS when I
>  want it to run
>  against 'Groundswell' as the datasource.
>  
>  What am I doing wrong?
>  
>  Hunter
>  
>  
>  ___
>  Jboss-development mailing list
>  [EMAIL PROTECTED]
>  https://lists.sourceforge.net/lists/listinfo/jboss-development
>  
> >> 
> >> 
> >> ___
> >> Jboss-development mailing list
> >> [EMAIL PROTECTED]
> >> https://lists.sourceforge.net/lists/listinfo/jboss-development
> >> 
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development

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


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



Re: [JBoss-dev] Bug #482875: Out of Memory

2001-11-20 Thread David Budworth

Yep, you fixed it.  Thank you.

-David

On Sunday 18 November 2001 11:14pm, David Jencks wrote:
> OK, I think I fixed the "can't undeploy broken mbean" problem, with a
> testcase too. (in jmx/test/DeployServiceUnitTestCase).
>
> Could you check and make sure I fixed the problem you were seeing?
>
> Thanks
> david jencks
>
> On 2001.11.17 23:32:09 -0500 David Budworth wrote:
> > Well, while someone is looking at the hot deploy code, please fix the
> > MBean
> > problem.
> >
> > When you deploy a SAR that has a bad mbean, ie: jboss-service.xml
> > specifies
> > an attribute for a MBean that doesn't really exist, you have to restart
> > jboss
> > to get the mbean to go away.
> >
> > Removing the SAR only removes MBeans that successfully deployed, and not
> > anything that threw deployment exceptions when being deployed.
> >
> >
> > I'm gonna try to fix this myself before I file it as a bug.  But if
> > someone
> > is looking at the deploy code, and happens to fix it, please say so.
> >
> > -David
> >
> > On Saturday 17 November 2001 03:57pm, Jason Dillon wrote:
> > > jboss.org is afflicted with this bug (i think).  in an ideal world a
> >
> > jboss
> >
> > > server should not need to be restarted expect to update core componets
> >
> > or
> >
> > > the vm in which it runs.
> > >
> > > I would say that it is a bug.  Does the same thing happen when large
> > > deployables are used on 3.0?
> > >
> > > --jason
> > >
> > > On Sat, 17 Nov 2001, Andreas Schaefer wrote:
> > > > Hi Geeks
> > > >
> > > > Recently this bug was reported on JBoss 2.4 stating that
> > > > JBoss server runs out of memory when to many hot-
> > > > deployment with big archives.
> > > >
> > > > IMO this is not a bug because when people start to deploy
> > > > big archives then they have to deal with it.
> > > > - In Production this should not become a problem and when
> > > >   then a restart of JBoss is necessary
> > > > - In Development this should not be a big problem to bounce
> > > >the server.
> > > >
> > > > What do you think ?
> > > >
> > > > 
> > > >
> > > > Bugs item #482875, was opened at 2001-11-17 12:12
> > > > You can respond by visiting:
> > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=482875&gr
> > > >oup_ id= 22866
> > > >
> > > > Category: JBossServer
> > > > Group: v2.4 (stable)
> > > > Status: Open
> > > > Resolution: None
> > > > Priority: 7
> > > > Submitted By: Joel Boehland (jolby)
> > > > Assigned to: Nobody/Anonymous (nobody)
> > > > Summary: OutOfMemory after many Deploy cycles
> > > >
> > > > Initial Comment:
> > > > I have been seeing OutOfMemoryErrors in my server after
> > > > doing several deploy/redeploy cycles of my application
> > > > .ear file (which is around 3 megs in size)
> > > >
> > > > Basic info:
> > > > *Hardware: AMD-K2-400MHz, 196MB RAM
> > > > *OS: linux 2.2.14
> > > > *jdk: Blackdown-1.3.0-FCS, mixed mode
> > > > *Server: JBoss-2.4.3_Jetty-3.1.3-1
> > > > *ServerTrace: I don't have one now, but I can provide
> > > > one later if needed.
> > > > *Steps to reproduce: Deploy/Redeploy .ear file many
> > > > times. My .ear is around 3 megs, so it may be necessary
> > > > to use a large one to trigger this effect.
> > > >
> > > > Other info
> > > > *I have had this happen using native threads mode, and
> > > > green threads mode.
> > > > *"Jozsa Kristof" <[EMAIL PROTECTED]> has also reported
> > > > this error on the jboss-user list. He was using IBM jdk
> > > > 1.3.0 on linux, so this doesn't appear to be tied to
> > > > any particular version of the jdk.
> > > >
> > > > --Joel
> > > >
> > > > ---
> > > >
> > > > x
> > > > Andreas Schaefer
> > > > Senior Consultant
> > > > JBoss Group, LLC
> > > > x
> > > >
> > > >
> > > > ___
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development

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



Re: [JBoss-dev] Application/Deployment Units

2001-11-20 Thread Andreas Schaefer

Hi

Right now there is no more management information
available. But soon the implementation of JSR-77 should
provide you with the necessary informations.

Have fun - Andy

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 20, 2001 8:10 AM
Subject: [JBoss-dev] Application/Deployment Units


> Hi all --
>
> Sorry for such a newbie question, but
>
> Is there any place with jboss (working with rh) which stores data  about
> *all* pieces of an application deployment at runtime?  For instance, I can
> get the "DeployedApplications" attribute from the ContainerFactory MBean,
> which gives me an Iterator of org.jboss.ejb.Application objects, with
> which I can in turn retrieve the associated containers for each EJB.  But,
> I haven't seen how to find any associated web applications in the same
> deployment unit.  (I can get the DeployedApplication from the Jetty MBean,
> but there is no association with each webapp to the rest of its
> application)
>
> Could someone give me a little nudge in the right direction?
>
> thanks,
> jason
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>


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



Re: [JBoss-dev] IBM AS/400 (tm), it seems to be running right. kick webshmereass

2001-11-20 Thread Adrian Brock

Ernst,

I'm not sure what your asking here.

You should be able to run the distribution from QSH.

DISCLAIMER: I haven't done this myself! I don't own a AS/400.

I think you've done some of this, but I'll list it for completeness.

1) Build the distribution on your PC or Un*x machine
ant probably won't work on the 400 :-(

2) Copy jboss/dist to something like /usr/bin/jboss (use FTP or map a 
network drive)

3) Set the environment variable to allow multi-threading
===> ADDENVAR ENVVAR('QIBM_MULTI_THREAD') VALUE('Y')

4) Start the shell
===> QSH

5) Change to the binary directory
===> cd /usr/bin/jboss/bin

6) start the server
===> ./run.sh

4a) Alternate method, use JAVA or RUNJVA on class org.jboss.Main setting the 
classpath manually.

7) deploy your beans into /usr/bin/jboss/deploy and away you go!

NOTES:
1) To get maximum performance you'll want to run CRTJVAPGM over any .jar or 
.zip in the distribution. Unfortunately they live all over
the place in **/lib directories, there's some in the bin directory as well.

2) You probably want to look in /usr/bin/jboss/conf/default/jboss.jcml
In there you can configure the JdbcProvider to be
com.ibm.as400.access.JDBCDriver

Not sure if that's all you have to change?

You'll have to add this to the classpath
Look in the docs for its location it seems to move from release to release.

3) If you have problems with java.lang.ClassNotFoundException use
LICOPT(*NOPRESOLVEEXTREF) when using CRTJVAPGM.

4) Writing a CL program and/or shell script to automate most of this would 
be nice.

I'll be interested to hear your results.

Regards,
Adrian


>From: Ernst Bekker <[EMAIL PROTECTED]>
>To: "'[EMAIL PROTECTED]'"  
><[EMAIL PROTECTED]>
>Subject: [JBoss-dev] IBM AS/400 (tm), it seems to be running right. kick 
>webshmere ass
>Date: Tue, 20 Nov 2001 18:06:52 +0200
>
>I unzipped 2.4.1 on our as400 v5r1 at work. The server runs without any
>complaints.
>Unfortunately I am a java newby. (don't stop reading now).
>The as400 can compile java classes into native as400 byte code that runs
>like lightning. What I would like to contribute is as/400 CL and RPG code 
>to
>make JBOSS the obvious choice for as400. So please help me out here.
>I can compile a .class and .jar files with a command (CRTJVAPGM), and then
>run them with (RUNJVAPGM).
>If you can give me an idea of how all the files fit together I am sure I 
>can
>write some software to automate an optimal as400 server.
>
>
>TIA
>Ernst Bekker
>
>Confidentiality Caution and Disclaimer
>
>This message and/or any attachment thereto ("the message")
>contains privileged and confidential information intended
>only for the recipient named above.
>If you are not the intended recipient of this message,
>please erase it permanently once you have notified the
>sender, per return e-mail, that you have received the
>message in error.
>Unless the sender is duly authorised by either the Telesure
>Group, or any of its subsidiary companies or I.S Services
>("the Group") to send this message and unless the content
>of this message is also duly authorised by the Group, any
>views expressed in this message are those of the individual
>sender and the Group will not accept liability therefore,
>nor for any consequential damage arising therefrom.
>Any recipient of an unacceptable communication, a chain
>letter or offensive material of any nature is requested
>to report it to [EMAIL PROTECTED]
>
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development


_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


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



RE: [JBoss-dev] RE: Test cases

2001-11-20 Thread Dain Sundstrom

This jar (junitejb.jar) is an ejb-jar file. JUnitEJB uses a session bean to
run the test cases on the serverside.  There are about a billion ways to
package this.  The three styles I have used follow:

* An ejb-jar with a class-path ref to junit.jar in the MANIFEST-MF.
* An ejb-jar with junit.jar classes included.
* A jar without ejb-jar.xml or MANIFEST-MF. (assume user will handle
packaging)

I use the third option for my code. I create an ear with an ejb-jar that has
all my beans, the test runner bean, and all test cases. The ejb-jar has a
class-path ref to the junit.jar which is bundled into the ear.  All of these
involve coordination with the build system, because of the classpath
references, or in the case of the second option, the inclusion of the junit
classes could create classpath issues.

Does anyone have any preferences in my release style?  I'm not sure the best
way to integrate this into the build process.  This is why I waited so long
to add my tests.

-dain

> -Original Message-
> From: Jason Dillon [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 20, 2001 12:04 AM
> To: David Jencks
> Cc: Dain Sundstrom; jboss-dev
> Subject: Re: [JBoss-dev] RE: Test cases
> 
> 
> > Dain has en external project (on sourceforge) in sort of an 
> alpha state
> > that he is using to test cmp 2 stuff.  What is the best way 
> to get these
> > tests + external stuff in?
> > 
> > I suggest
> > -tag other project
> > -build jar, including some kind of info about the checkout tag.
> > -put copy of jar in jboss 
> thirdparty/junitejb/junitejb/lib/junitejb.jar
> 
> A public release would be best, which would indicate that the 
> source module 
> should be tagged, though that is up to the cvs admin policy for that 
> project.
> 
> Otherwise sounds good.  Is the group owner called 'junitejb'? 
>  If not then 
> that name should be used as the vendor.
> 
> > Is this ok?
> 
> Sure.
> 
> > What is the best way to indicate what version (tag in this case) the
> > external project is at?  What are we doing for the other 
> external files?
> 
> Tag the imported files with a label which indicates the version.  For 
> example the junit.jar file has a junit_3_7 tag (amoung 
> others) which shows 
> what version that it is:
> 
> 
> jason(2)reason:...thirdparty/junit/junit/lib>cvs status -v 
> junit.jar  
> ===
> File: junit.jar Status: Up-to-date
> 
>Working revision:1.1.1.1
>Repository revision: 1.1.1.1 
> /cvsroot/jboss/thirdparty/junit/junit/lib/junit.jar,v
>Sticky Tag:  (none)
>Sticky Date: (none)
>Sticky Options:  -kb
> 
>Existing Tags:
> Rel_2_4_4_15(revision: 1.1.1.1)
> Rel_3_0_0_1 (revision: 1.1.1.1)
> RelMQ_1_0_0_2   (revision: 1.1.1.1)
> RelMQ_1_0_0_1   (revision: 1.1.1.1)
> RelMQ_1_0_0_0_0 (revision: 1.1.1.1)
> Rel_2_5_0_4 (revision: 1.1.1.1)
> jboss_buildmagic(branch: 1.1.1.1.4)
> junit_3_7   (revision: 1.1.1.1)
> junit   (branch: 1.1.1)
> 
> 
> I would suggest setting up the proper directory structre then 
> entering the 
> base dir (containing the lib dir and such) and doing:
> 
>cvs import thirdparty/junitejb/junitejb junitejb junitejb_M_m_r
> 
> Where M_m_r is the Major.minor.release or whatever the vendor (dain) 
> descides to use as a convetion for release numbers.
> 
> This will setup the correct tags.
> 
> Be sure to inclde a LICENSE file as a peer to lib/ to indicate its 
> distribution licensing too.
> 
>  * * *
> 
> Tagging is the only way I have found with CVS to tack this version 
> information.  If someone else has an idea on how todo it 
> better please let 
> me know.
> 
> --jason
> 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 

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



Re: [JBoss-dev] 1 to Many Relations

2001-11-20 Thread Dave Smith

Uncle. It seems that JBOSS is designed assuming that it has full control 
of creating tables. Well in my case I already have a database allready 
set up so my view of things is how do I stuff this database into JBOSS. 
I don't think it is worth the discussion which approach is right or 
wrong but, we should document the view jboss takes and then write 
appropriate documention for the other approach. Dain if you could get at 
DTD for jbosscmp-jdbc.xml I'll tidy up xdoclet and write some 
documentation for "I've got these tables now how do I do relations in 
JBOSS". This should eliminate this thread occurring over and over on the 
  user mailing lists.

Dave


Dain Sundstrom wrote:

If I use the jbosscmp-jdbc.xml file I can get it to work.


>>>Do you have to use the jbosscmp-jdbc.xml file?  If you 
>>>
>>don't, what happens?
>>
>>>Does the system generate two columns with the same name?
>>> 
>>>
>>The database table already exsists. Basically I have to use 
>>foreign-key-fields and set field-name and column-name 
>>attributes the same.
>>
> 
> Ok, now we are getting somewhere.  If you want to use an existing database
> structure you must tell JBossCMP about it.  JAWS had the same requirement.
> If your database happens to work by default, well you were lucky.  We make
> no gaurentees that JBossCMP will map by default the way you want.  We may
> decide that a default name was stupid and change it.  Let make this very
> very very very clear.
>  
> All column names are either generated, or specified in the jbosscmp-jdbc.xml
> file.
>  
> 
>>>All column names are either generated, or specified in the 
>>>
>>jbosscmp-jdbc.xml
>>
>>>file.  Your opinion is that when jboss generates the column 
>>>
>>name for a
>>
>>>relationship fk it should first attempt to the name of the cmr-field
>>>abstract accessors.  Problems occur when the entity does not have an
>>>accessor for the relationship, and when the primary key 
>>>
>>related entity maps
>>
>>>to more then one db column.  What is your complete proposal 
>>>
>>for fk column
>>
>>>generation and relation-table column generation? Be specific.
>>>
>>>
>>Not quite I suggest you use the name of the cmr-field-name in the 
>>ejb-relationship. therefore when creating the column the field always 
>>has to be there.
>>
> 
> What about many-to-one unidirectiona relationships that wish to use a fk?
> 
> 
>>Now after great thought how do you keep the columns straight 
>>in a multi 
>>column pk? So if table1 has a primary key of a,b,c and the 
>>foregin key 
>>in the table2 is e,f,g and then to find the key a=g,b=f and 
>>c=e how do 
>>you specify this now?  There is no guarantee on the order the 
>>fields are 
>>pulled out of the primary key. Is the order we specify them in the 
>> have to be the same on both sides of 
>>the relation?
>>
>>Once you answer this I can pull the rest of the proposal together.
>>
>  
> Order has nothing to do with this.  Each pk field is mapped by name in the
> foreign-key-fields element or the table-fields element.
> 
> 
>
>   a 
>   e 
>
>
>   b 
>   f 
>
>
>   c 
>   g 
>
> 
> 
> All of this information is mainatined in the field objects (see the bridge
> package).
>  
> -dain
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 



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



[JBoss-dev] [ jboss-Bugs-483847 ] Change to Datasource Not Picked Up

2001-11-20 Thread noreply

Bugs item #483847, was opened at 2001-11-20 08:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=483847&group_id=22866

Category: JBossCMP
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Hunter Hillegas (hunterhillegas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Change to Datasource Not Picked Up

Initial Comment:
If you specify a different datasource name in jbosscmp-
jdbc.xml (other than DefaultDS), that doesn't get 
picked up, it still tries to use DefaultDS.

--

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

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



Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?

2001-11-20 Thread Hunter Hillegas

Good idea, but my DOCTYPE is correct, exactly as is below... I assume it is
using 2.0 persistence since it doesn't choke on the relationships or the new
entity bean structures...

> From: Peter Levart <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 10:28:54 +0100
> To: Hunter Hillegas <[EMAIL PROTECTED]>, JBoss Dev
> <[EMAIL PROTECTED]>
> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> 
> This should work and it works for me (using Sybase, but nevertheless). Have
> you checked the DOCTYPE of the ejb-jar.xml file? It should read:
> 
>  2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd";>
> 
> If not, then you end up using JAWS instead...
> 
> 
> On Monday 19 November 2001 20:47, Hunter Hillegas wrote:
>> I am deploying a 2.0EJB jar into RH3.
>> 
>> Here's my jbosscmp-jdbc.xml file:
>> 
>> 
>> 
>> 
>> 
>>
>>   java:/Groundswell
>>   PostgreSQL
>>   true
>>   true
>>   false
>>   false
>>   300
>>   false
>>   foreign-key
>>
>> 
>> 
>> No matter what, the jar tries to run against DefaultDS when I want it to
>> run against 'Groundswell' as the datasource.
>> 
>> What am I doing wrong?
>> 
>> Hunter
>> 
>> 
>> ___
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/jboss-development


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



[JBoss-dev] Application/Deployment Units

2001-11-20 Thread VASQUEZ_JASON

Hi all --

Sorry for such a newbie question, but

Is there any place with jboss (working with rh) which stores data  about 
*all* pieces of an application deployment at runtime?  For instance, I can 
get the "DeployedApplications" attribute from the ContainerFactory MBean, 
which gives me an Iterator of org.jboss.ejb.Application objects, with 
which I can in turn retrieve the associated containers for each EJB.  But, 
I haven't seen how to find any associated web applications in the same 
deployment unit.  (I can get the DeployedApplication from the Jetty MBean, 
but there is no association with each webapp to the rest of its 
application)

Could someone give me a little nudge in the right direction?

thanks,
jason

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



[JBoss-dev] IBM AS/400 (tm), it seems to be running right. kick webshmere ass

2001-11-20 Thread Ernst Bekker

I unzipped 2.4.1 on our as400 v5r1 at work. The server runs without any
complaints. 
Unfortunately I am a java newby. (don't stop reading now).
The as400 can compile java classes into native as400 byte code that runs
like lightning. What I would like to contribute is as/400 CL and RPG code to
make JBOSS the obvious choice for as400. So please help me out here.
I can compile a .class and .jar files with a command (CRTJVAPGM), and then
run them with (RUNJVAPGM).
If you can give me an idea of how all the files fit together I am sure I can
write some software to automate an optimal as400 server.


TIA
Ernst Bekker

Confidentiality Caution and Disclaimer

This message and/or any attachment thereto ("the message") 
contains privileged and confidential information intended 
only for the recipient named above.  
If you are not the intended recipient of this message, 
please erase it permanently once you have notified the 
sender, per return e-mail, that you have received the 
message in error.
Unless the sender is duly authorised by either the Telesure 
Group, or any of its subsidiary companies or I.S Services 
("the Group") to send this message and unless the content 
of this message is also duly authorised by the Group, any 
views expressed in this message are those of the individual 
sender and the Group will not accept liability therefore, 
nor for any consequential damage arising therefrom.
Any recipient of an unacceptable communication, a chain 
letter or offensive material of any nature is requested 
to report it to [EMAIL PROTECTED]

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



Re: [JBoss-dev] Ignorance

2001-11-20 Thread Rickard Öberg

Sacha Labourey wrote:

> In RMI's Bible, hum, I mean Rickard's book, 


Hehe, I was just reading the bible, I mean.. uhm, anyway.. to be sure. 
It's always a good idea to do this, especially in such a controlled 
environment as we have, with little need for allowing upgrades in the 
system over time.

/Rickard

-- 
Rickard Öberg


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



Re: [JBoss-dev] Ignorance

2001-11-20 Thread Rickard Öberg

marc fleury wrote:

> |The automatic serversion generation of RMI uses heavy reflection
> |also on the
> |method signatures
> |and leads to CNFE´s in these cases.
> 
> So it is faster to include the serversion or not? I am thinking a lot about
> ways to make these fast.


It is most definitely faster to compute it yourself.

/Rickard

-- 
Rickard Öberg


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



RE: [JBoss-dev] Ignorance

2001-11-20 Thread Sacha Labourey

Hello,

In RMI's Bible, hum, I mean Rickard's book, if I well remember, it is
written that if the serialversion is not explicitely set in the class, it
must be dynamically computed when loading the class => takes much more time
when loading the class if this is not explicitely set.


Sacha


> -Message d'origine-
> |The automatic serversion generation of RMI uses heavy reflection
> |also on the
> |method signatures
> |and leads to CNFE´s in these cases.
>
> So it is faster to include the serversion or not? I am thinking a
> lot about
> ways to make these fast.
>


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



AW: [JBoss-dev] Ignorance

2001-11-20 Thread Jung , Dr. Christoph

I guess, serversion is only computed once per VM & class (ObjectStreamClass
is cached) ... 

CGJ

-Ursprüngliche Nachricht-
Von: marc fleury [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 20. November 2001 16:24
An: Jung , Dr. Christoph; Jboss-Development (E-Mail)
Betreff: RE: [JBoss-dev] Ignorance


|The automatic serversion generation of RMI uses heavy reflection
|also on the
|method signatures
|and leads to CNFE´s in these cases.

So it is faster to include the serversion or not? I am thinking a lot about
ways to make these fast.

marcf
|


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

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



RE: [JBoss-dev] Ignorance

2001-11-20 Thread marc fleury

|The automatic serversion generation of RMI uses heavy reflection
|also on the
|method signatures
|and leads to CNFE´s in these cases.

So it is faster to include the serversion or not? I am thinking a lot about
ways to make these fast.

marcf
|


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


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



RE: [JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/catalina EmbeddedCatalinaServiceSX.java EmbeddedCatalinaServiceSXMBean.java Log4jLogger.java

2001-11-20 Thread marc fleury

dude,

I went to bed at 2 am with invoker madness in my head, but you are even
worse :)

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Tuesday, November 20, 2001 4:54 AM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update:
|contrib/catalina/src/main/org/jboss/web/catalina
|EmbeddedCatalinaServiceSX.java EmbeddedCatalinaServiceSXMBean.java
|Log4jLogger.java
|
|
|  User: starksm
|  Date: 01/11/20 01:54:19
|
|  Modified:catalina/src/main/org/jboss/web/catalina Tag: Branch_2_4
|EmbeddedCatalinaServiceSX.java
|EmbeddedCatalinaServiceSXMBean.java
|Log4jLogger.java
|  Log:
|  Change to the unified log4j based org.jboss.logging.Logger class.
|
|  Revision  ChangesPath
|  No   revision
|
|
|  No   revision
|
|
|  1.2.2.3   +17 -17
|contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaSe
|rviceSX.java
|
|  Index: EmbeddedCatalinaServiceSX.java
|  ===
|  RCS file:
|/cvsroot/jboss/contrib/catalina/src/main/org/jboss/web/catalina/Emb
|eddedCatalinaServiceSX.java,v
|  retrieving revision 1.2.2.2
|  retrieving revision 1.2.2.3
|  diff -u -r1.2.2.2 -r1.2.2.3
|  --- EmbeddedCatalinaServiceSX.java   2001/11/12 19:21:18 1.2.2.2
|  +++ EmbeddedCatalinaServiceSX.java   2001/11/20 09:54:18 1.2.2.3
|  @@ -28,7 +28,7 @@
|   import org.xml.sax.EntityResolver;
|   import org.xml.sax.InputSource;
|
|  -import org.jboss.ejb.DeploymentException;
|  +import org.jboss.deployment.DeploymentException;
|   import org.jboss.security.SecurityDomain;
|   import org.jboss.web.AbstractWebContainer;
|   import org.jboss.web.AbstractWebContainer.WebDescriptorParser;
|  @@ -65,7 +65,7 @@
|@see org.apache.catalina.startup.Embedded
|
|@author [EMAIL PROTECTED]
|  - @version $Revision: 1.2.2.2 $
|  + @version $Revision: 1.2.2.3 $
|*/
|   public class EmbeddedCatalinaServiceSX extends
|AbstractWebContainer implements EmbeddedCatalinaServiceSXMBean
|   {
|  @@ -204,25 +204,25 @@
|
|  public void startService() throws Exception
|  {
|  -  category.info("Starting " + NAME + "");
|  +  log.info("Starting " + NAME + "");
|
| // Start create the embeded catalina container but don't
|let it overwrite the thread class loader
| URLClassLoader cl = (URLClassLoader)
|Thread.currentThread().getContextClassLoader();
| URLClassLoader parent = cl;
| while( parent != null )
| {
|  - category.trace(parent);
|  + log.trace(parent);
|URL[] urls = parent.getURLs();
|for(int u = 0; u < urls.length; u ++)
|  -category.trace("  "+urls[u]);
|  +log.trace("  "+urls[u]);
|parent = (URLClassLoader) parent.getParent();
| }
|
| // Determine the catalina debug level from the enabled priority
| debugLevel = 0;
|  -  if( category.isTraceEnabled() )
|  +  if( log.isTraceEnabled() )
|debugLevel = 2;
|  -  category.debug("Setting catalina debug level to: "+debugLevel);
|  +  log.debug("Setting catalina debug level to: "+debugLevel);
|
| try
| {
|  @@ -232,7 +232,7 @@
|String homePath = catalinaHome.getFile();
|File homeDir = new File(homePath, "../../..");
|homePath = homeDir.getCanonicalPath();
|  - category.debug("Setting catalina.home to: " + homePath);
|  + log.debug("Setting catalina.home to: " + homePath);
|System.setProperty("catalina.home", homePath);
|System.setProperty("catalina.base", homePath);
|initCatalina(cl);
|  @@ -242,7 +242,7 @@
| {
|Thread.currentThread().setContextClassLoader(cl);
| }
|  -  category.info("OK");
|  +  log.info("OK");
|  }
|
|  public void stopService()
|  @@ -266,15 +266,15 @@
|  {
| if( ctxPath.equals("/") )
| {
|  -  category.info("Changing root context path from '/' to ''");
|  +  log.info("Changing root context path from '/' to ''");
| ctxPath = "";
| }
|  -  category.info("deploy, ctxPath="+ctxPath+", warUrl="+warUrl);
|  +  log.info("deploy, ctxPath="+ctxPath+", warUrl="+warUrl);
| ClassLoader ctxClassLoader =
|Thread.currentThread().getContextClassLoader();
|
| URL url = new URL(warUrl);
| WebApplication appInfo = createWebContext(ctxPath, url,
|webAppParser);
|  -  category.debug("Initialized: "+appInfo);
|  +  log.debug("Initialized: "+appInfo);
| return appInfo;
|  }
|
|  @@ -302,7 +302,7 @@
|   */
|  private void initCatalina(ClassLoader parent) throws Exception
|  {
|  -  Logger jbossLog = new Log4jLogger(this.category);
|  +  Logger jbossLog = new Log4jLogger(this.log);
| Realm jbossRealm = new JBo

RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS? (Postgres and CMP 2)

2001-11-20 Thread Bunker, Dan
Title: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS? (Postgres and CMP 2)






I have been developing with CMP 2 and postgresql for the last 2 weeks.  Things seem to be going OK for what I'm using it for.  I have seen some interesting things with the transaction types.  It appears that rabit hole currently only supports "Required" and "RequiresNew" transactions.  All others throw null pointer exceptions.

Dan


-Original Message-
From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 19, 2001 5:06 PM
To: Dain Sundstrom; JBoss Dev
Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?



So far nothing from this end.


If you get a chance to look at or if anyone else has any ideas, please chime
in?


Is no one else running Rabbit Hole with PostgreSQL and 2.0 EJB?


> From: Dain Sundstrom <[EMAIL PROTECTED]>
> Date: Mon, 19 Nov 2001 16:14:21 -0600
> To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, Dain Sundstrom
> <[EMAIL PROTECTED]>, JBoss Dev <[EMAIL PROTECTED]>
> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
> The ds jndi name is loaded in the metadata object of entities in the
> ...plulgin.cmp.jdbc.metadata package.  Then the ds is looked up in the
> JDBCStoreManager init method. Finally it is used in the JDBCCommand object.
> 
> -dain
> 
>> -Original Message-
>> From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, November 19, 2001 3:50 PM
>> To: Dain Sundstrom; JBoss Dev
>> Subject: Re: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>> 
>> 
>> I haven't dug around in the source yet. If you can give me a
>> pointer where
>> to look, I'll check it out...
>> 
>> If I remove DefaultDS (remove the Hypersonic service XML
>> file), my beans
>> don't deploy at all, complaining that DefaultDS is missing... So it's
>> definitely not picking up my request for a different
>> datasource to be used.
>> 
>> 
>> Hunter
>> 
>>> From: Dain Sundstrom <[EMAIL PROTECTED]>
>>> Date: Mon, 19 Nov 2001 15:40:42 -0600
>>> To: "'Hunter Hillegas'" <[EMAIL PROTECTED]>, JBoss Dev
>>> <[EMAIL PROTECTED]>
>>> Subject: RE: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
>>> 
>>> Looks right to me.  Did you try tracking this down in the
>> source?  I'll look
>>> at it later but I'm a little busy right now.
>>> 
>>> -dain
>>> 
 -Original Message-
 From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
 Sent: Monday, November 19, 2001 1:48 PM
 To: JBoss Dev
 Subject: [JBoss-dev] 2.0 jar Really Likes DefaultDS?
 
 
 I am deploying a 2.0EJB jar into RH3.
 
 Here's my jbosscmp-jdbc.xml file:
 
 
 
 
 
    
   java:/Groundswell
   PostgreSQL
   true
   true
   false
   false
   300
   false
   
 
>> foreign-key
    
 
 
 No matter what, the jar tries to run against DefaultDS when I
 want it to run
 against 'Groundswell' as the datasource.
 
 What am I doing wrong?
 
 Hunter
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 
>> 
>> 
>> ___
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/jboss-development
>> 



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





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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 02:52:18

  Added:   src/main/org/jboss/logging Tag: Branch_2_4
TracePriority.java
  Log:
  Move the TracePriority to the logging package
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +1 -1  jboss/src/main/org/jboss/logging/TracePriority.java
  
  Index: TracePriority.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/TracePriority.java,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  --- TracePriority.java2001/09/11 18:35:02 1.1
  +++ TracePriority.java2001/11/20 10:52:18 1.1.2.1
  @@ -17,7 +17,7 @@
@see org.apache.log4j.Priority

@author [EMAIL PROTECTED]
  - @version $Revision: 1.1 $
  + @version $Revision: 1.1.2.1 $
*/
   public class TracePriority extends Priority
   {
  
  
  

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



Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty Security...

2001-11-20 Thread Julian Gosnell

Thanks, Scott,

I'll do the necessary.


Jules

 --- Scott M Stark <[EMAIL PROTECTED]>
wrote: > JBoss security managers are not scoped. Every
> application referring to
> the java:/jaas/domainX security manager is using the
> same instance and
> executing the same JAAS login configuration. For the
> particular case of
> two webapps referring to the same security domain
> via the jboss-web.xml
> security-domain element, they are using the same
> security manager
> instance.
> 
> 
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> 
> - Original Message -
> From: "Julian Gosnell" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, November 20, 2001 2:13 AM
> Subject: [JBoss-dev] JBoss3/Jetty Security...
> 
> 
> >
> > Another small question for Scott...
> >
> > Are JBoss Realms scoped within a Server namespace,
> or
> > an Application ?
> >
> > i.e. If 2 webapps see a Realm with the same name -
> is
> > it the same Realm instance ?
> >
> > Currently I am working under the assumption that
> the
> > answer is "no" - but I'm open to suggestion.
> >
> > Thanks,
> >
> >
> > Jules
> >
> >
> > __
> > Do You Yahoo!?
> > Everything you'll ever need on one web page from
> News and Sport to Email
> and Music Charts
> > http://uk.my.yahoo.com
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
>
https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> 
> 
>  Yahoo! Groups Sponsor
> -~-->
> Universal Inkjet Refill Kit $29.95
> Refill any ink cartridge for less!
> Includes black and color ink.
>
http://us.click.yahoo.com/ltH6zA/MkNDAA/ySSFAA/CefplB/TM
>
-~->
> 
> For the latest information about Jetty, please see
> http://jetty.mortbay. 
> 
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/ 
> 
>  

__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music 
Charts
http://uk.my.yahoo.com

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



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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 02:41:18

  Removed: src/main/org/jboss/logging Tag: Branch_2_4 LoggerMBean.java
  Log:
  The Logger is not an MBean anymore

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



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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 02:40:54

  Removed: src/main/org/jboss/util Tag: Branch_2_4
CounterInterceptor.java
  Log:
  Move to the ejb/plugins package to limit cross package imports

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



Re: [JBoss-dev] JBoss3/Jetty Security...

2001-11-20 Thread Scott M Stark

JBoss security managers are not scoped. Every application referring to
the java:/jaas/domainX security manager is using the same instance and
executing the same JAAS login configuration. For the particular case of
two webapps referring to the same security domain via the jboss-web.xml
security-domain element, they are using the same security manager
instance.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: "Julian Gosnell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, November 20, 2001 2:13 AM
Subject: [JBoss-dev] JBoss3/Jetty Security...


>
> Another small question for Scott...
>
> Are JBoss Realms scoped within a Server namespace, or
> an Application ?
>
> i.e. If 2 webapps see a Realm with the same name - is
> it the same Realm instance ?
>
> Currently I am working under the assumption that the
> answer is "no" - but I'm open to suggestion.
>
> Thanks,
>
>
> Jules
>
>
> __
> Do You Yahoo!?
> Everything you'll ever need on one web page from News and Sport to Email
and Music Charts
> http://uk.my.yahoo.com
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>


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



[JBoss-dev] JBoss3/Jetty Security...

2001-11-20 Thread Julian Gosnell


Another small question for Scott...

Are JBoss Realms scoped within a Server namespace, or
an Application ?

i.e. If 2 webapps see a Realm with the same name - is
it the same Realm instance ?

Currently I am working under the assumption that the
answer is "no" - but I'm open to suggestion.

Thanks,


Jules


__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music 
Charts
http://uk.my.yahoo.com

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



[JBoss-dev] CVS update: contrib/tomcat/src/main/org/jboss/tomcat EmbeddedTomcatService.java EmbeddedTomcatServiceMBean.java EmbeddedTomcatServiceSX.java EmbeddedTomcatServiceSXMBean.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:49:01

  Modified:tomcat/src/main/org/jboss/tomcat Tag: Branch_2_4
EmbeddedTomcatService.java
EmbeddedTomcatServiceMBean.java
EmbeddedTomcatServiceSX.java
EmbeddedTomcatServiceSXMBean.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.11.4.1  +9 -16 
contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatService.java
  
  Index: EmbeddedTomcatService.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatService.java,v
  retrieving revision 1.11
  retrieving revision 1.11.4.1
  diff -u -r1.11 -r1.11.4.1
  --- EmbeddedTomcatService.java2001/02/20 15:29:20 1.11
  +++ EmbeddedTomcatService.java2001/11/20 09:49:00 1.11.4.1
  @@ -24,9 +24,8 @@
   import javax.servlet.ServletContext;
   
   import org.jboss.logging.Logger;
  -import org.jboss.logging.Log;
   import org.jboss.util.ServiceMBeanSupport;
  -import org.jboss.ejb.DeploymentException;
  +import org.jboss.deployment.DeploymentException;
   
   /**
*   
  @@ -34,12 +33,12 @@
*   @see 
*   @author Rickard Öberg ([EMAIL PROTECTED])
*   @author Dewayne McNair ([EMAIL PROTECTED])
  - *   @version $Revision: 1.11 $
  + *   @deprecated, use the org.jboss.tomcat.EmbeddedTomcatServiceSX class
  + *   @version $Revision: 1.11.4.1 $
*/
  -
   public class EmbeddedTomcatService
  -extends ServiceMBeanSupport
  -implements EmbeddedTomcatServiceMBean, MBeanRegistration
  +   extends ServiceMBeanSupport
  +   implements EmbeddedTomcatServiceMBean, MBeanRegistration
   {
   // Constants -
   public static final String NAME = "EmbeddedTomcat";
  @@ -61,13 +60,11 @@
   }
   
   public void startService()
  -throws Exception
  +  throws Exception
   {
  -final Log log = this.log;
  -
  -log.log ("Starting " + NAME + "");
  +log.info("Starting " + NAME + "");
   tomcat = new TomcatEntry();
  -log.log ("OK");
  +log.info ("OK");
   }
   
   public void stopService()
  @@ -89,10 +86,8 @@
  // but the JMX RI's html adaptor can't
  // show inputs for URLs in HTML forms.
  public void deploy(String ctxPath, String warUrl)
  -   throws DeploymentException
  +  throws DeploymentException
  {
  -final Log log = this.log;
  -
 ClassLoader oldCcl = Thread.currentThread().getContextClassLoader();
 try
 {
  @@ -121,8 +116,6 @@
   
  public void undeploy(String warUrl) throws DeploymentException
  {
  -final Log log = this.log;
  -
 try
 {
// find the javax.servlet.ServletContext in the repository
  
  
  
  1.5.4.1   +18 -18
contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceMBean.java
  
  Index: EmbeddedTomcatServiceMBean.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceMBean.java,v
  retrieving revision 1.5
  retrieving revision 1.5.4.1
  diff -u -r1.5 -r1.5.4.1
  --- EmbeddedTomcatServiceMBean.java   2001/02/10 06:00:17 1.5
  +++ EmbeddedTomcatServiceMBean.java   2001/11/20 09:49:00 1.5.4.1
  @@ -4,31 +4,31 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
  - 
  +
   package org.jboss.tomcat;
   
  -import org.jboss.ejb.DeploymentException;
  +import org.jboss.deployment.DeploymentException;
   
   /**
*   Management interface for the Embedded Tomcat service
  - *  
  + *
*   @see 
*   @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
  - *   @version $Revision: 1.5 $
  + *   @version $Revision: 1.5.4.1 $
*/
  -public interface EmbeddedTomcatServiceMBean 
  -   extends org.jboss.util.ServiceMBean 
  +public interface EmbeddedTomcatServiceMBean
  +   extends org.jboss.util.ServiceMBean
   {
  - 
  - // Constants -
  - public static final String OBJECT_NAME = ":service=EmbeddedTomcat";
  - 
  - public void deploy(String ctxPath, String warUrl) 
  -  throws DeploymentException;
  - 
  - public void undeploy(String warUrl) 
  -  throws DeploymentException;
  - 
  - public boolean isDeployed(String warUrl);
  -
  +   
  +   // Constants -
  +   public static final String OBJECT_NAME = ":service=EmbeddedTomcat";
  +   
  +   public void deploy(String ctxPath, String warUrl)
  +   throws DeploymentException;
  +   
  +   public void undeploy(String warUrl)
  +   throws DeploymentExceptio

[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/catalina EmbeddedCatalinaServiceSX.java EmbeddedCatalinaServiceSXMBean.java Log4jLogger.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:54:19

  Modified:catalina/src/main/org/jboss/web/catalina Tag: Branch_2_4
EmbeddedCatalinaServiceSX.java
EmbeddedCatalinaServiceSXMBean.java
Log4jLogger.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.2.3   +17 -17
contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java
  
  Index: EmbeddedCatalinaServiceSX.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java,v
  retrieving revision 1.2.2.2
  retrieving revision 1.2.2.3
  diff -u -r1.2.2.2 -r1.2.2.3
  --- EmbeddedCatalinaServiceSX.java2001/11/12 19:21:18 1.2.2.2
  +++ EmbeddedCatalinaServiceSX.java2001/11/20 09:54:18 1.2.2.3
  @@ -28,7 +28,7 @@
   import org.xml.sax.EntityResolver;
   import org.xml.sax.InputSource;
   
  -import org.jboss.ejb.DeploymentException;
  +import org.jboss.deployment.DeploymentException;
   import org.jboss.security.SecurityDomain;
   import org.jboss.web.AbstractWebContainer;
   import org.jboss.web.AbstractWebContainer.WebDescriptorParser;
  @@ -65,7 +65,7 @@
@see org.apache.catalina.startup.Embedded

@author [EMAIL PROTECTED]
  - @version $Revision: 1.2.2.2 $
  + @version $Revision: 1.2.2.3 $
*/
   public class EmbeddedCatalinaServiceSX extends AbstractWebContainer implements 
EmbeddedCatalinaServiceSXMBean
   {
  @@ -204,25 +204,25 @@
   
  public void startService() throws Exception
  {
  -  category.info("Starting " + NAME + "");
  +  log.info("Starting " + NAME + "");
   
 // Start create the embeded catalina container but don't let it overwrite the 
thread class loader
 URLClassLoader cl = (URLClassLoader) 
Thread.currentThread().getContextClassLoader();
 URLClassLoader parent = cl;
 while( parent != null )
 {
  - category.trace(parent);
  + log.trace(parent);
URL[] urls = parent.getURLs();
for(int u = 0; u < urls.length; u ++)
  -category.trace("  "+urls[u]);
  +log.trace("  "+urls[u]);
parent = (URLClassLoader) parent.getParent();
 }
   
 // Determine the catalina debug level from the enabled priority
 debugLevel = 0;
  -  if( category.isTraceEnabled() )
  +  if( log.isTraceEnabled() )
debugLevel = 2;
  -  category.debug("Setting catalina debug level to: "+debugLevel);
  +  log.debug("Setting catalina debug level to: "+debugLevel);
   
 try
 {
  @@ -232,7 +232,7 @@
String homePath = catalinaHome.getFile();
File homeDir = new File(homePath, "../../..");
homePath = homeDir.getCanonicalPath();
  - category.debug("Setting catalina.home to: " + homePath);
  + log.debug("Setting catalina.home to: " + homePath);
System.setProperty("catalina.home", homePath);
System.setProperty("catalina.base", homePath);
initCatalina(cl);
  @@ -242,7 +242,7 @@
 {
Thread.currentThread().setContextClassLoader(cl);
 }
  -  category.info("OK");
  +  log.info("OK");
  }
   
  public void stopService()
  @@ -266,15 +266,15 @@
  {
 if( ctxPath.equals("/") )
 {
  -   category.info("Changing root context path from '/' to ''");
  +   log.info("Changing root context path from '/' to ''");
  ctxPath = "";
 }
  -  category.info("deploy, ctxPath="+ctxPath+", warUrl="+warUrl);
  +  log.info("deploy, ctxPath="+ctxPath+", warUrl="+warUrl);
 ClassLoader ctxClassLoader = Thread.currentThread().getContextClassLoader();
   
 URL url = new URL(warUrl);
 WebApplication appInfo = createWebContext(ctxPath, url, webAppParser);
  -  category.debug("Initialized: "+appInfo);
  +  log.debug("Initialized: "+appInfo);
 return appInfo;
  }
   
  @@ -302,7 +302,7 @@
   */
  private void initCatalina(ClassLoader parent) throws Exception
  {
  -  Logger jbossLog = new Log4jLogger(this.category);
  +  Logger jbossLog = new Log4jLogger(this.log);
 Realm jbossRealm = new JBossSecurityMgrRealm();
 catalina = new Embedded(jbossLog, jbossRealm);
 catalina.setDebug(debugLevel);
  @@ -375,7 +375,7 @@
  Object source = event.getSource();
  if( source == context && 
event.getType().equals(Lifecycle.START_EVENT) )
  {
  -  category.debug("Context.lifecycleEvent, event="+event);
  +  log.debug("Context.lifecycleEvent, event="+event);
 contextInit(context, appInfo, webAppParser);

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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:49:00

  Modified:tomcat/src/build Tag: Branch_2_4 build.xml
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.15.2.8  +4 -4  contrib/tomcat/src/build/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.xml,v
  retrieving revision 1.15.2.7
  retrieving revision 1.15.2.8
  diff -u -r1.15.2.7 -r1.15.2.8
  --- build.xml 2001/10/03 07:36:53 1.15.2.7
  +++ build.xml 2001/11/20 09:49:00 1.15.2.8
  @@ -1,5 +1,5 @@
   
  -
  +
   
   

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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:55

  Modified:src/main/org/jboss/metadata Tag: Branch_2_4
BeanMetaData.java MetaData.java XmlFileLoader.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.23.2.4  +31 -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.23.2.3
  retrieving revision 1.23.2.4
  diff -u -r1.23.2.3 -r1.23.2.4
  --- BeanMetaData.java 2001/11/12 19:32:56 1.23.2.3
  +++ BeanMetaData.java 2001/11/20 09:42:54 1.23.2.4
  @@ -29,7 +29,7 @@
* @author mailto:[EMAIL PROTECTED]";>Daniel OConnor
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
  - * @version $Revision: 1.23.2.3 $
  + * @version $Revision: 1.23.2.4 $
*/
   public abstract class BeanMetaData
   extends MetaData
  @@ -442,6 +442,7 @@
refMetaData.importEjbJarXml(resourceRef);
resourceEnvReferences.put(refMetaData.getRefName(), refMetaData);
 }
  +  trim();
  }
   
  public void importJbossXml(Element element) throws DeploymentException
  @@ -510,8 +511,36 @@
}
ejbRefMetaData.importJbossXml(ejbRef);
 }
  +  trim();
  }
  -   
  +
  +   /** Trim all string elements that correspond to class names which
  +cannot tolerate leading and trailing space.
  +*/
  +   public void trim()
  +   {
  +  if( ejbName != null )
  + ejbName = ejbName.trim();
  +  if( homeClass != null )
  + homeClass = homeClass.trim();
  +  if( remoteClass != null )
  + remoteClass = remoteClass.trim();
  +  if( localHomeClass != null )
  + localHomeClass = localHomeClass.trim();
  +  if( localClass != null )
  + localClass = localClass.trim();
  +  if( ejbClass != null )
  + ejbClass = ejbClass.trim();
  +  if( jndiName != null )
  + jndiName = jndiName.trim();
  +  if( localJndiName != null )
  + localJndiName = localJndiName.trim();
  +  if( configurationName != null )
  + configurationName = configurationName.trim();
  +  if( securityProxy != null )
  + securityProxy = securityProxy.trim();
  +   }
  +
  // Package protected -
  
  // Protected -
  
  
  
  1.13.6.2  +158 -136  jboss/src/main/org/jboss/metadata/MetaData.java
  
  Index: MetaData.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/MetaData.java,v
  retrieving revision 1.13.6.1
  retrieving revision 1.13.6.2
  diff -u -r1.13.6.1 -r1.13.6.2
  --- MetaData.java 2001/11/02 08:42:36 1.13.6.1
  +++ MetaData.java 2001/11/20 09:42:54 1.13.6.2
  @@ -18,157 +18,179 @@
   
   
   /**
  - *
  - *  
  + *   
  + *
*   @see 
*   @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
  - *   @version $Revision: 1.13.6.1 $
  + *   @version $Revision: 1.13.6.2 $
*/
  -public abstract class MetaData implements XmlLoadable {
  -// Constants -
  - public static final byte TX_NOT_SUPPORTED  = 0;
  -public static final byte TX_REQUIRED   = 1;
  -public static final byte TX_SUPPORTS   = 2;
  -public static final byte TX_REQUIRES_NEW   = 3;
  -public static final byte TX_MANDATORY  = 4;
  -public static final byte TX_NEVER  = 5;
  -public static final byte TX_UNKNOWN= 6;
  -
  -// Attributes 
  -
  -// Static 
  -public static Iterator getChildrenByTagName(Element element, String tagName) {
  - if (element == null) return null;
  -
  - // getElementsByTagName gives the corresponding elements in the whole 
descendance.
  - // We want only children
  - 
  - NodeList children = element.getChildNodes();
  - ArrayList goodChildren = new ArrayList();
  - for (int i=0; i 0)
 {
String result = "";
for (int i = 0; i < children.getLength(); i++)
{
  -if (children.item(i).getNodeType() == Node.TEXT_NODE || 
  -children.item(i).getNodeType() == Node.CDATA_SECTION_NODE)
  +if (children.item(i).getNodeType() == Node.TEXT_NODE ||
  +children.item(i).getNodeType() == Node.CDATA_SECTION_NODE)
  result += children.item(i).getNodeValue();
   

[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy Proxies.java ProxyProxy.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:56

  Modified:src/main/org/jboss/proxy Tag: Branch_2_4 Proxies.java
ProxyProxy.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.6.1   +580 -467  jboss/src/main/org/jboss/proxy/Proxies.java
  
  Index: Proxies.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/Proxies.java,v
  retrieving revision 1.2
  retrieving revision 1.2.6.1
  diff -u -r1.2 -r1.2.6.1
  --- Proxies.java  2000/08/18 03:21:09 1.2
  +++ Proxies.java  2001/11/20 09:42:55 1.2.6.1
  @@ -5,14 +5,17 @@
   
   import org.jboss.logging.Logger;
   /**
  -* Routines for converting between strongly-typed interfaces and
  -* generic InvocationHandler objects.
  -*/
  -public final class Proxies {
  -private Proxies() {}
  -
  -
  -/**
  + * Routines for converting between strongly-typed interfaces and
  + * generic InvocationHandler objects.
  + */
  +public final class Proxies
  +{
  +   static Logger log = Logger.getLogger(Proxies.class);
  +   
  +   private Proxies()
  +   {}
  +   
  +   /**
   * Create a new target object x which is a proxy for
   * the given InvocationHandler disp.  The new object will be equivalent
   * to disp, except that it will support normal Java method
  @@ -43,33 +46,35 @@
   *   // x1 != x3, but calls to x3 are forwarded via i to x1
   * 
   */
  -public static ProxyTarget newTarget(ClassLoader parent, InvocationHandler 
InvocationHandler, Class targetTypes[]) {
  -return Impl.getImpl(targetTypes).newTarget(InvocationHandler, parent);
  -}
  +   public static ProxyTarget newTarget(ClassLoader parent, InvocationHandler 
InvocationHandler, Class targetTypes[])
  +   {
  +  return Impl.getImpl(targetTypes).newTarget(InvocationHandler, parent);
  +   }
   /*public static ProxyTarget newTarget(InvocationHandler InvocationHandler) {
   return newTarget(InvocationHandler, InvocationHandler.getTargetTypes());
   }*/
  -
  -/**
  +   
  +   /**
   * A common interface shared by all objects created
   * by Proxies.newTarget.
   */
  -
  -public interface ProxyTarget extends Serializable/*extends Object*/ {
  -/**
  -* Recover the original InvocationHandler object around which this
  -* proxy is wrapped.
  -*/
  -InvocationHandler getInvocationHandler();
  -
  -
  -/**
  -* Recover the original target types for which this proxy was wrapped.
  -*/
  -Class[] getTargetTypes();
  -}
  -
  -/**
  +   
  +   public interface ProxyTarget extends Serializable/*extends Object*/
  +   {
  +  /**
  +   * Recover the original InvocationHandler object around which this
  +   * proxy is wrapped.
  +   */
  +  InvocationHandler getInvocationHandler();
  +  
  +  
  +  /**
  +   * Recover the original target types for which this proxy was wrapped.
  +   */
  +  Class[] getTargetTypes();
  +   }
  +   
  +   /**
   * Create a new reflective InvocationHandler object InvocationHandler 
wrapped
   * around the given target object, for the given target type(s).
   * 
  @@ -87,27 +92,29 @@
   * InvocationHandler i = Proxies.newInvocationHandler(x1, MyInterface.class);
   * 
   */
  -public static ProxyInvocationHandler newInvocationHandler(Object target, Class 
targetType) {
  -return Impl.getImpl(targetType).newInvocationHandler(target);
  -}
  -public static ProxyInvocationHandler newInvocationHandler(Object target, Class 
targetTypes[]) {
  -return Impl.getImpl(targetTypes).newInvocationHandler(target);
  -}
  -
  -/**
  +   public static ProxyInvocationHandler newInvocationHandler(Object target, Class 
targetType)
  +   {
  +  return Impl.getImpl(targetType).newInvocationHandler(target);
  +   }
  +   public static ProxyInvocationHandler newInvocationHandler(Object target, Class 
targetTypes[])
  +   {
  +  return Impl.getImpl(targetTypes).newInvocationHandler(target);
  +   }
  +   
  +   /**
   * A common interface shared by all objects created
   * by Proxies.newInvocationHandler.
   */
  -public interface ProxyInvocationHandler extends InvocationHandler, Serializable
  -{
  -/**
  -* Recover the original target object around which this
  -* InvocationHandler proxy is wrapped.
  -*/
  -Object getTarget();
  -}
  -
  -/**
  +   public interface ProxyInvocationHandler extends InvocationHandler, Serializable
  +   {
  +  /**
  +   * Recover the original target object around which this
  +   * InvocationHandler proxy is wrapped.
  +   */
  +   

[JBoss-dev] CVS update: jboss/src/main/org/jboss/naming ExternalContext.java JNDIView.java NamingService.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:55

  Modified:src/main/org/jboss/naming Tag: Branch_2_4
ExternalContext.java JNDIView.java
NamingService.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.4.1   +2 -5  jboss/src/main/org/jboss/naming/ExternalContext.java
  
  Index: ExternalContext.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/ExternalContext.java,v
  retrieving revision 1.5
  retrieving revision 1.5.4.1
  diff -u -r1.5 -r1.5.4.1
  --- ExternalContext.java  2001/04/21 05:59:05 1.5
  +++ ExternalContext.java  2001/11/20 09:42:55 1.5.4.1
  @@ -33,9 +33,6 @@
   import javax.naming.ldap.Control;
   import javax.naming.spi.ObjectFactory;
   
  -import org.jnp.server.Main;
  -
  -import org.jboss.logging.Log;
   import org.jboss.util.ServiceMBeanSupport;
   
   /** A MBean that binds an arbitrary InitialContext into the JBoss default
  @@ -47,7 +44,7 @@
   @see org.jboss.naming.NonSerializableFactory
   
   @author [EMAIL PROTECTED]
  -@version $Revision: 1.5 $
  +@version $Revision: 1.5.4.1 $
   */
   public class ExternalContext extends ServiceMBeanSupport implements 
ExternalContextMBean
   {
  @@ -259,7 +256,7 @@
   }
   catch(NamingException e)
   {
  -log.exception(e);
  +log.error("unbind failed", e);
   }
   }
   
  
  
  
  1.4.2.1   +7 -8  jboss/src/main/org/jboss/naming/JNDIView.java
  
  Index: JNDIView.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/JNDIView.java,v
  retrieving revision 1.4
  retrieving revision 1.4.2.1
  diff -u -r1.4 -r1.4.2.1
  --- JNDIView.java 2001/06/16 05:53:38 1.4
  +++ JNDIView.java 2001/11/20 09:42:55 1.4.2.1
  @@ -25,7 +25,6 @@
   import org.jboss.ejb.Application;
   import org.jboss.ejb.Container;
   import org.jboss.ejb.ContainerFactoryMBean;
  -import org.jboss.logging.Log;
   import org.jboss.util.ServiceMBeanSupport;
   
   /** A simple utlity mbean that allows one to recursively list the default
  @@ -37,7 +36,7 @@
   
   @author [EMAIL PROTECTED]
   @author Vladimir Blagojevic <[EMAIL PROTECTED]>
  -@version $Revision: 1.4 $
  +@version $Revision: 1.4.2.1 $
   */
   public class JNDIView extends ServiceMBeanSupport implements JNDIViewMBean
   {
  @@ -78,7 +77,7 @@
   }
   catch(Exception e)
   {
  -log.exception(e);
  +log.warn("Failed to getDeployedApplications", e);
   buffer.append("Failed to getDeployedApplications\n");
   formatException(buffer, e);
   buffer.insert(0, "");
  @@ -133,7 +132,7 @@
   }
   catch(NamingException e)
   {
  -log.exception(e);
  +log.warn("Failed to InitialContext", e);
   buffer.append("Failed to get InitialContext, "+e.toString(true));
   formatException(buffer, e);
   }
  @@ -149,7 +148,7 @@
   }
   catch(NamingException e)
   {
  -log.exception(e);
  +log.warn("Failed to InitialContext", e);
   buffer.append("Failed to get InitialContext, "+e.toString(true));
   formatException(buffer, e);
   }
  @@ -182,7 +181,7 @@
   }
   catch(Exception e)
   {
  -log.exception(e);
  +log.warn("Failed to getDeployedApplications", e);
   buffer.append( "" );
   buffer.append( "" );
   buffer.append( '\n' );
  @@ -260,7 +259,7 @@
   }
   catch(NamingException e)
   {
  -log.exception(e);
  +log.warn("Failed to get getDeployedApplications", e);
   buffer.append( "" );
   buffer.append( '\n' );
   buffer.append( "" + "Failed to get InitialContext, " + 
e.toString( true ) + "" );
  @@ -283,7 +282,7 @@
   }
   catch(NamingException e)
   {
  -log.exception(e);
  +log.warn("Failed to get InitialContext", e);
   buffer.append( "" );
   buffer.append( '\n' );
   buffer.append( "" + "Failed to get InitialContext, " + 
e.toString( true ) + "" );
  
  
  
  1.11.4.4  +9 -10 jboss/src/main/org/jboss/naming/NamingService.java
  
  Index: NamingService.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/NamingService.java,v
  retrieving revision 1.11.4.3
  retrieving revision 1.11.4.4
  diff -u -r1.11.4.3 -r1.11.4.4
  --- NamingService.java2001/09/07 01:31:34 1.11.4.3
  +++ NamingService.java2001/11/

[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging/log4j CategoryWriter.java TracePriority.java JBossCategory.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:54

  Modified:src/main/org/jboss/logging/log4j Tag: Branch_2_4
CategoryWriter.java TracePriority.java
  Removed: src/main/org/jboss/logging/log4j Tag: Branch_2_4
JBossCategory.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.4.2   +32 -20jboss/src/main/org/jboss/logging/log4j/CategoryWriter.java
  
  Index: CategoryWriter.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/log4j/CategoryWriter.java,v
  retrieving revision 1.1.4.1
  retrieving revision 1.1.4.2
  diff -u -r1.1.4.1 -r1.1.4.2
  --- CategoryWriter.java   2001/09/30 23:12:21 1.1.4.1
  +++ CategoryWriter.java   2001/11/20 09:42:54 1.1.4.2
  @@ -26,18 +26,20 @@
* @version$$
*/
   public class CategoryWriter
  -   extends PrintWriter {
  +   extends PrintWriter
  +{
  private Category category;
  private Priority priority;
  private boolean  inWrite;
  private boolean  issuedWarning;
  -
  +   
  /**
   *  Redirect logging to the indicated category using Priority.INFO
   *
   * @param  category  Description of Parameter
   */
  -   public CategoryWriter( final Category category ) {
  +   public CategoryWriter( final Category category )
  +   {
 this( category, Priority.INFO );
  }
   
  @@ -49,51 +51,61 @@
   * @param  priority  Description of Parameter
   */
  public CategoryWriter( final Category category,
  - final Priority priority ) {
  +  final Priority priority )
  +   {
 super( new InternalCategoryWriter( category, priority ), true );
  }
  -
  +   
  /**
   * @createdAugust 19, 2001
   */
  -   static class InternalCategoryWriter extends Writer {
  +   static class InternalCategoryWriter extends Writer
  +   {
 private Category category;
 private Priority priority;
 private boolean closed;
  -
  -  public InternalCategoryWriter( final Category category, final Priority 
priority ) {
  +  
  +  public InternalCategoryWriter( final Category category, final Priority 
priority )
  +  {
lock = category;
//synchronize on this category
this.category = category;
this.priority = priority;
 }
  -
  +  
 public void write( char[] cbuf, int off, int len )
  - throws IOException {
  - if ( closed ) {
  + throws IOException
  +  {
  + if ( closed )
  + {
   throw new IOException( "Called write on closed Writer" );
}
// Remove the end of line chars
  - while ( len > 0 && ( cbuf[len - 1] == '\n' || cbuf[len - 1] == '\r' ) ) {
  + while ( len > 0 && ( cbuf[len - 1] == '\n' || cbuf[len - 1] == '\r' ) )
  + {
   len--;
}
  - if ( len > 0 ) {
  + if ( len > 0 )
  + {
   category.log( priority, String.copyValueOf( cbuf, off, len ) );
}
 }
  -
  -
  +  
  +  
 public void flush()
  - throws IOException {
  - if ( closed ) {
  + throws IOException
  +  {
  + if ( closed )
  + {
   throw new IOException( "Called flush on closed Writer" );
}
 }
  -
  -  public void close() {
  +  
  +  public void close()
  +  {
closed = true;
 }
  }
  -
  +   
   }
   
  
  
  
  1.2.2.2   +2 -1  jboss/src/main/org/jboss/logging/log4j/Attic/TracePriority.java
  
  Index: TracePriority.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/logging/log4j/Attic/TracePriority.java,v
  retrieving revision 1.2.2.1
  retrieving revision 1.2.2.2
  diff -u -r1.2.2.1 -r1.2.2.2
  --- TracePriority.java2001/08/20 22:14:16 1.2.2.1
  +++ TracePriority.java2001/11/20 09:42:54 1.2.2.2
  @@ -17,7 +17,8 @@
@see org.apache.log4j.Priority

@author [EMAIL PROTECTED]
  - @version $Revision: 1.2.2.1 $
  + @version $Revision: 1.2.2.2 $
  + @deprecated, use the org.jboss.logging.TracePriority class.
*/
   public class TracePriority extends Priority
   {
  
  
  

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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata CMPFieldMetaData.java JawsApplicationMetaData.java JawsXmlFileLoader.java MappingMetaData.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:51

  Modified:src/main/org/jboss/ejb/plugins/jaws/metadata Tag: Branch_2_4
CMPFieldMetaData.java JawsApplicationMetaData.java
JawsXmlFileLoader.java MappingMetaData.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.6.4.2   +450 -374  
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java
  
  Index: CMPFieldMetaData.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java,v
  retrieving revision 1.6.4.1
  retrieving revision 1.6.4.2
  diff -u -r1.6.4.1 -r1.6.4.2
  --- CMPFieldMetaData.java 2001/11/02 08:42:34 1.6.4.1
  +++ CMPFieldMetaData.java 2001/11/20 09:42:51 1.6.4.2
  @@ -19,7 +19,6 @@
   import org.jboss.metadata.MetaData;
   import org.jboss.metadata.EjbRefMetaData;
   
  -import org.jboss.logging.Log;
   import org.jboss.logging.Logger;
   
   /**
  @@ -30,411 +29,488 @@
*   @author Sebastien Alborini
*  @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
*  @author mailto:[EMAIL PROTECTED]";>Vincent Harcq
  - *   @version $Revision: 1.6.4.1 $
  + *   @version $Revision: 1.6.4.2 $
*/
  -public class CMPFieldMetaData extends MetaData implements XmlLoadable {
  - // Constants -
  -
  - // Attributes 
  -
  - // the entity this field belongs to
  - private JawsEntityMetaData jawsEntity;
  -
  - // name of the field
  -private String name;
  -
  - // the actual Field in the bean implementation
  - private Field field;
  -
  - // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
  - private int jdbcType;
  - // true if jdbcType has been initialized
  - private boolean validJdbcType;
  -
  - // the sql type, used for table creation.
  - private String sqlType;
  -
  - // the column name in the table
  - private String columnName;
  -
  - private boolean isAPrimaryKeyField;
  -
  -
  - /**
  -  * We need this for nested field retrieval.
  -  */
  - private String ejbClassName;
  -
  - /**
  -  * We need this for nested fields. We could compute it from ejbClassName on 
the fly,
  -  * but it's faster to set it once and cache it.
  -  */
  - private Class ejbClass;
  -
  - /**
  -  * Is true for fields like "data.categoryPK".
  -  */
  - private boolean isNested;
  -
  - // Static 
  -
  - // Constructors --
  - public CMPFieldMetaData(String name, JawsEntityMetaData jawsEntity) throws 
DeploymentException {
  - this.name = name;
  - this.jawsEntity = jawsEntity;
  -
  - // save the class name for nested fields
  - ejbClassName = jawsEntity.getEntity().getEjbClass();
  - ejbClassName = jawsEntity.getEntity().getEjbClass();
  -
  - try {
  - // save the class for nested fields
  - ejbClass = 
jawsEntity.getJawsApplication().getClassLoader().loadClass(ejbClassName);
  - field = ejbClass.getField(name);
  - } catch (ClassNotFoundException e) {
  - throw new DeploymentException("ejb class not found: " + 
ejbClassName);
  - } catch (NoSuchFieldException e) {
  - // we can't throw an Exception here, because we could have a 
nested field
  - checkField();
  - }
  -
  - // default, may be overridden by importXml
  - columnName = getLastComponent(name);
  -
  - // cannot set defaults for jdbctype/sqltype, type mappings are not 
loaded yet.
  - }
  -
  -
  - // Public 
  - public String getName() { return name; }
  -
  - public Field getField() { return field; }
  -
  - public int getJDBCType() {
  - if (! validJdbcType) {
  - // set the default
  -if (field!=null)
  - jdbcType = 
jawsEntity.getJawsApplication().getTypeMapping().getJdbcTypeForJavaType(field.getType());
  -else{
  -try{
  -   jdbcType = 
jawsEntity.getJawsApplication().getTypeMapping().getJdbcTypeForJavaType(ValueObjectHelper.getNestedFieldType(ejbClass,name));
  -} catch(NoSuchMethodException e){
  -Log.getLog().warning("ERROR : Nested Field does not have a get 
method");
  -}
  -}
  -

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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:49:01

  Modified:tomcat/src/main/org/jboss/tomcat/security Tag: Branch_2_4
JBossSecurityMgrRealm.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.2.9   +27 -27
contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java
  
  Index: JBossSecurityMgrRealm.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java,v
  retrieving revision 1.4.2.8
  retrieving revision 1.4.2.9
  diff -u -r1.4.2.8 -r1.4.2.9
  --- JBossSecurityMgrRealm.java2001/09/14 17:55:08 1.4.2.8
  +++ JBossSecurityMgrRealm.java2001/11/20 09:49:01 1.4.2.9
  @@ -17,8 +17,8 @@
   import org.apache.tomcat.core.Response;
   import org.apache.tomcat.util.SecurityTools;
   
  -import org.jboss.logging.log4j.JBossCategory;
  -import org.jboss.security.EJBSecurityManager;
  +import org.jboss.logging.Logger;
  +import org.jboss.security.AuthenticationManager;
   import org.jboss.security.RealmMapping;
   import org.jboss.security.SimplePrincipal;
   import org.jboss.security.SecurityAssociation;
  @@ -31,24 +31,24 @@
for authorization and authenticaton.

@see org.jboss.web.AbstractWebContainer
  - @see org.jboss.security.EJBSecurityManager
  + @see org.jboss.security.AuthenticationManager
@see org.jboss.security.RealmMapping
@see org.jboss.security.SimplePrincipal
@see org.jboss.security.SecurityAssociation
@see org.jboss.security.SubjectSecurityManager

@author [EMAIL PROTECTED]
  - @version $Revision: 1.4.2.8 $
  + @version $Revision: 1.4.2.9 $
*/
   public class JBossSecurityMgrRealm extends BaseInterceptor
   {
  -   private static JBossCategory category = (JBossCategory) 
JBossCategory.getInstance(JBossSecurityMgrRealm.class);
  +   private static Logger log = Logger.getLogger(JBossSecurityMgrRealm.class);
  private static ThreadLocal authInfo = new ThreadLocal();
  private String subjectAttributeName = "j_subject";
  private boolean useJAAS = false;
  
  /** A flag to indicate if the security manager implements the 
SubjectSecurityManager
  -rather than EJBSecurityManager. When true, the authenticated Subject is obtained
  +rather than AuthenticationManager. When true, the authenticated Subject is 
obtained
   from the SubjectSecurityManager and placed into the request under the
   subjectAttributeName attribute.
   */
  @@ -99,12 +99,12 @@
*/
 ClassLoader cl = Thread.currentThread().getContextClassLoader();
 ClassLoader scl = request.getContext().getServletLoader().getClassLoader();
  -  boolean trace = category.isTraceEnabled();
  +  boolean trace = log.isTraceEnabled();
 if( trace )
 {
  - category.trace("Authenticating access, username: " + username + " " 
+request);
  - category.trace("ClassLoader: "+cl.toString()+':'+cl.hashCode());
  - category.trace("Servlet ClassLoader: "+scl.toString()+':'+scl.hashCode());
  + log.trace("Authenticating access, username: " + username + " " +request);
  + log.trace("ClassLoader: "+cl.toString()+':'+cl.hashCode());
  + log.trace("Servlet ClassLoader: "+scl.toString()+':'+scl.hashCode());
 }
 
 // If we don't have a security context security is not required
  @@ -114,14 +114,14 @@
 if( securityCtx == null )
 {
if( trace )
  -category.trace("No SecurityContext, returning 0");
  +log.trace("No SecurityContext, returning 0");
return 0;
 }
   
 try
 {
// Get the JBoss security manager from the ENC context
  - EJBSecurityManager securityMgr = (EJBSecurityManager) 
securityCtx.lookup("securityMgr");
  + AuthenticationManager securityMgr = (AuthenticationManager) 
securityCtx.lookup("securityMgr");
SimplePrincipal principal = new SimplePrincipal(username);
char[] passwordChars = null;
if( password != null )
  @@ -134,7 +134,7 @@
   if (ctx != null)
  request.setAuthType(ctx.getAuthMethod());
   if( trace )
  -   category.trace("Username: "+username+" is authenticated");
  +   log.trace("Username: "+username+" is authenticated");
   SecurityAssociation.setPrincipal(principal);
   SecurityAssociation.setCredential(passwordChars);
   authInfo.set(new AuthInfo(principal, passwordChars));
  @@ -148,12 +148,12 @@
else
{
   if( trace )
  -   category.trace("User: "+username+" is NOT authenticated");
  +   log.trace("User: "+username+" is NOT au

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

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:54

  Modified:src/main/org/jboss/mail Tag: Branch_2_4 MailService.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.6.1   +128 -116  jboss/src/main/org/jboss/mail/MailService.java
  
  Index: MailService.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/mail/MailService.java,v
  retrieving revision 1.2
  retrieving revision 1.2.6.1
  diff -u -r1.2 -r1.2.6.1
  --- MailService.java  2001/01/21 00:24:41 1.2
  +++ MailService.java  2001/11/20 09:42:54 1.2.6.1
  @@ -28,123 +28,135 @@
* in JNDI under java:/ namespace with the name provided with method {@link 
#setJNDIName}.
*
* @author Simone Bordet ([EMAIL PROTECTED])
  - * @version $Revision: 1.2 $
  + * @version $Revision: 1.2.6.1 $
*/
   public class MailService
  - extends ServiceMBeanSupport
  - implements MailServiceMBean
  +extends ServiceMBeanSupport
  +implements MailServiceMBean
   {
  - // Constants -
  -
  - // Attributes 
  - private String m_user;
  - private String m_password;
  - private String m_properties;
  - private String m_jndiName;
  - private String m_bindName;
  -
  - // Static 
  -
  - // Constructors --
  -
  - // Public 
  - public String getName()
  - {
  - return "Mail Service";
  - }
  - public void setUser(String user) {m_user = user;}
  - protected String getUser() {return m_user;}
  - public void setPassword(String password) {m_password = password;}
  - protected String getPassword() {return m_password;}
  - public void setConfigurationFile(String file) {m_properties = file;}
  - protected String getConfigurationFile() {return m_properties;}
  - public void setJNDIName(String name) {m_jndiName = name;}
  - protected String getJNDIName() {return m_jndiName;}
  -
  - public void startService()
  - throws Exception
  - {
  - // Setup password authentication
  - final PasswordAuthentication pa = new 
PasswordAuthentication(getUser(), getPassword());
  - Authenticator a = new Authenticator()
  - {
  - protected PasswordAuthentication getPasswordAuthentication()
  - {
  - return pa;
  - }
  - };
  -
  - // Read mail properties from configuration directory
  - String properties = getConfigurationFile();
  - // If MBean does not provide configuration file, default to 
mail.properties
  - if (properties == null) {properties = "mail.properties";}
  - InputStream is = 
Thread.currentThread().getContextClassLoader().getResourceAsStream(properties);
  - if (is == null) {throw new java.io.FileNotFoundException("Cannot find 
file '" + properties + "'");}
  - Properties p = new Properties();
  - p.load(is);
  -
  - // Finally create a mail session
  - Session session = Session.getInstance(p, a);
  - bind(session);
  - }
  -
  - public void stopService()
  - {
  - // Unbind from JNDI
  - try
  - {
  - unbind();
  - }
  - catch (NamingException x)
  - {
  - log.exception(x);
  - }
  - }
  -
  -
  - // Private -
  - private void bind(Session session) throws NamingException
  - {
  - Context ctx = new InitialContext();
  - String name = getJNDIName();
  - if (name == null) {name = "java:/Mail";}
  - else if (!name.startsWith("java:/")) {name = "java:/" + name;}
  - m_bindName = name;
  -
  - // Ah ! Session isn't serializable, so we use a helper class
  - NonSerializableFactory.bind(m_bindName, session);
  -
  - Name n = ctx.getNameParser("").parse(m_bindName);
  - while (n.size() > 1)
  - {
  - String ctxName = n.get(0);
  - try
  - {
  - ctx = (Context)ctx.lookup(ctxName);
  - }
  - catch (NameNotFoundException e)
  - {
  - ctx = ctx.createSubcontext(ctxName);
  - }
  - n = n.

[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm TransactionManagerService.java TxCapsule.java TxManager.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:56

  Modified:src/main/org/jboss/tm Tag: Branch_2_4
TransactionManagerService.java TxCapsule.java
TxManager.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.11.4.1  +3 -5  jboss/src/main/org/jboss/tm/TransactionManagerService.java
  
  Index: TransactionManagerService.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/tm/TransactionManagerService.java,v
  retrieving revision 1.11
  retrieving revision 1.11.4.1
  diff -u -r1.11 -r1.11.4.1
  --- TransactionManagerService.java2001/05/08 07:22:06 1.11
  +++ TransactionManagerService.java2001/11/20 09:42:56 1.11.4.1
  @@ -24,10 +24,8 @@
   
   import javax.management.MBeanServer;
   import javax.management.ObjectName;
  -
   import javax.transaction.TransactionManager;
   
  -import org.jboss.logging.Log;
   import org.jboss.util.ServiceMBeanSupport;
   
   /**
  @@ -38,7 +36,7 @@
*  @author Rickard Öberg ([EMAIL PROTECTED])
*  @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
*  @author Toby Allsopp ([EMAIL PROTECTED])
  - *  @version $Revision: 1.11 $
  + *  @version $Revision: 1.11.4.1 $
*/
   public class TransactionManagerService
  extends ServiceMBeanSupport
  @@ -79,7 +77,7 @@
  {
 // Initialize the Xid constructor.
 if (xidClassName != null) {
  - log.log("Using Xid class '" + xidClassName + "'");
  + log.info("Using Xid class '" + xidClassName + "'");
Class cls = Class.forName(xidClassName);
   
TxCapsule.xidConstructor = cls.getConstructor(
  @@ -111,7 +109,7 @@
ctx.unbind(JNDI_IMPORTER);
ctx.unbind(JNDI_EXPORTER);
 } catch (Exception e) {
  - log.exception(e);
  + log.error("stopService error", e);
 }
  }
   
  
  
  
  1.27.4.1  +60 -59jboss/src/main/org/jboss/tm/TxCapsule.java
  
  Index: TxCapsule.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/tm/TxCapsule.java,v
  retrieving revision 1.27
  retrieving revision 1.27.4.1
  diff -u -r1.27 -r1.27.4.1
  --- TxCapsule.java2001/05/08 07:22:06 1.27
  +++ TxCapsule.java2001/11/20 09:42:56 1.27.4.1
  @@ -49,10 +49,11 @@
*  @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
*  @author Toby Allsopp ([EMAIL PROTECTED])
*
  - *  @version $Revision: 1.27 $
  + *  @version $Revision: 1.27.4.1 $
*/
   class TxCapsule implements TimeoutTarget
   {
  +   private static Logger log = Logger.getLogger(TxCapsule.class);
  // Constants -
   
  // Trace enabled flag
  @@ -140,7 +141,7 @@
 this.timeout = TimeoutFactory.createTimeout(start+timeout, this);
   
 if (trace)
  - Logger.debug("TxCapsule: Created new instance for tx=" + toString());
  + log.debug("TxCapsule: Created new instance for tx=" + toString());
  }
   
  /**
  @@ -166,7 +167,7 @@
 this.timeout = TimeoutFactory.createTimeout(start+timeout, this);
   
 if (trace)
  - Logger.debug("TxCapsule: Reused instance for tx=" + toString());
  + log.debug("TxCapsule: Reused instance for tx=" + toString());
  }
   
  // Public 
  @@ -179,7 +180,7 @@
 try {
lock();
   
  - Logger.warning("Transaction " + toString() + " timed out." +
  + log.warn("Transaction " + toString() + " timed out." +
   " status=" + getStringStatus(status));
   
if (this.timeout == null)
  @@ -221,7 +222,7 @@
   return; // commit will fail
   
default:
  -Logger.warning("TxCapsule: Unknown status at timeout, tx=" +
  +log.warn("TxCapsule: Unknown status at timeout, tx=" +
  toString());
   return;
}
  @@ -262,7 +263,7 @@
lock();
   
if (trace)
  -Logger.debug("TxCapsule.commit(): Entered, tx=" + toString() +
  +log.debug("TxCapsule.commit(): Entered, tx=" + toString() +
" status=" + getStringStatus(status));
   
switch (status) {
  @@ -304,7 +305,7 @@
doBeforeCompletion();
   
if (trace)
  -Logger.debug("TxCapsule.commit(): Before completion done, " +
  +log.debug("TxCapsule.commit(): Before completion done, " +
"tx=" + toString() +
" status=" + getStringStatus(status));
   
  @@ -314,17 +315,17 @@
   if (resourceCount == 0) {
  // Zero phase 

[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm/usertx/server ClientUserTransactionService.java UserTransactionSessionImpl.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:56

  Modified:src/main/org/jboss/tm/usertx/server Tag: Branch_2_4
ClientUserTransactionService.java
UserTransactionSessionImpl.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.4.1   +3 -3  
jboss/src/main/org/jboss/tm/usertx/server/ClientUserTransactionService.java
  
  Index: ClientUserTransactionService.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/tm/usertx/server/ClientUserTransactionService.java,v
  retrieving revision 1.1
  retrieving revision 1.1.4.1
  diff -u -r1.1 -r1.1.4.1
  --- ClientUserTransactionService.java 2001/04/29 08:12:52 1.1
  +++ ClientUserTransactionService.java 2001/11/20 09:42:56 1.1.4.1
  @@ -29,7 +29,7 @@
*  usage for standalone clients.
*  
*  @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
  - *  @version $Revision: 1.1 $
  + *  @version $Revision: 1.1.4.1 $
*/
   public class ClientUserTransactionService
  extends ServiceMBeanSupport
  @@ -85,11 +85,11 @@
try {
   UnicastRemoteObject.unexportObject(factory, true);
} catch (Exception ex) {
  -log.exception(ex);
  +log.error("unexportObject failure", ex);
}
factory = null;
 } catch (Exception e) {
  - log.exception(e);
  + log.error("stopService failure", e);
 }
  }
   
  
  
  
  1.2.4.1   +7 -8  
jboss/src/main/org/jboss/tm/usertx/server/UserTransactionSessionImpl.java
  
  Index: UserTransactionSessionImpl.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/tm/usertx/server/UserTransactionSessionImpl.java,v
  retrieving revision 1.2
  retrieving revision 1.2.4.1
  diff -u -r1.2 -r1.2.4.1
  --- UserTransactionSessionImpl.java   2001/04/30 06:38:21 1.2
  +++ UserTransactionSessionImpl.java   2001/11/20 09:42:56 1.2.4.1
  @@ -30,10 +30,8 @@
   import javax.transaction.HeuristicMixedException;
   import javax.transaction.HeuristicRollbackException;
   
  -import org.jboss.tm.TransactionPropagationContextFactory;
  -
   import org.jboss.logging.Logger;
  -
  +import org.jboss.tm.TransactionPropagationContextFactory;
   import org.jboss.tm.usertx.interfaces.UserTransactionSession;
   
   
  @@ -47,6 +45,7 @@
   {
  /** Cache a reference to the TM. */
  private static TransactionManager tm = null;
  +   private static Logger log = Logger.getLogger(UserTransactionSessionImpl.class);
   
  /**
   *  Get a reference to the transaction manager.
  @@ -58,7 +57,7 @@
   Context ctx = new InitialContext();
   tm = (TransactionManager)ctx.lookup("java:/TransactionManager");
} catch (NamingException ex) {
  -Logger.exception(ex);
  +log.error("TransactionManager lookup failure", ex);
}
 }
 return tm;
  @@ -77,7 +76,7 @@
   Context ctx = new InitialContext();
   tpcFactory = 
(TransactionPropagationContextFactory)ctx.lookup("java:/TransactionPropagationContextExporter");
} catch (NamingException ex) {
  -Logger.exception(ex);
  +log.error("TransactionPropagationContextExporter lookup failure", ex);
}
 }
 return tpcFactory;
  @@ -238,10 +237,10 @@
   */
  public void unreferenced()
  {
  -  Logger.debug("Lost connection to UserTransaction client.");
  +  log.debug("Lost connection to UserTransaction client.");
   
 if (!activeTx.isEmpty()) {
  - Logger.error("Lost connection to UserTransaction clients: " +
  +log.error("Lost connection to UserTransaction clients: " +
 "Rolling back " + activeTx.size() +
 " active transaction(s).");
Collection txs = activeTx.values();
  @@ -251,7 +250,7 @@
   try {
 tx.rollback();
   } catch (Exception ex) {
  -   Logger.exception(ex);
  +   log.error("rollback failure", ex);
   }
}
 }
  
  
  

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



[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging Log4jService.java Logger.java ConsoleLogging.java ConsoleLoggingMBean.java DefaultLog.java FileLogging.java FileLoggingMBean.java Log.java LogStream.java LogToCategory.java LogWriter.java ViewerLogging.java ViewerLoggingMBean.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:54

  Modified:src/main/org/jboss/logging Tag: Branch_2_4 Log4jService.java
Logger.java
  Removed: src/main/org/jboss/logging Tag: Branch_2_4
ConsoleLogging.java ConsoleLoggingMBean.java
DefaultLog.java FileLogging.java
FileLoggingMBean.java Log.java LogStream.java
LogToCategory.java LogWriter.java
ViewerLogging.java ViewerLoggingMBean.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.7.2.1   +3 -57 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.7
  retrieving revision 1.7.2.1
  diff -u -r1.7 -r1.7.2.1
  --- Log4jService.java 2001/06/15 18:00:17 1.7
  +++ Log4jService.java 2001/11/20 09:42:53 1.7.2.1
  @@ -14,8 +14,6 @@
   import javax.management.MalformedObjectNameException;
   import javax.management.MBeanRegistration;
   import javax.management.MBeanServer;
  -import javax.management.Notification;
  -import javax.management.NotificationListener;
   import javax.management.ObjectName;
   
   import org.apache.log4j.Category;
  @@ -27,22 +25,13 @@
   1., It initalizes the log4j framework from the log4j properties format file
   specified by the ConfigurationPath attribute to that the log4j may be
   used by JBoss components.
  -2., It collects JMX notification events fired by the "service=Log" mbean
  -and logs the msgs to log4j. This allows the Log4jService
  -to replace all other JBoss logging services like ConsoleLogging and
  -FileLogging.
  -
  -3,  It uses the log name as the category to log under, allowing you to turn 
  -individual components on and off using the log4j configuration file
  -(automatically reloaded frequently).
   
   @author mailto:[EMAIL PROTECTED]";>Fulco Muriglio
  -@author [EMAIL PROTECTED]
  +@author [EMAIL PROTECTED]
   @author mailto:[EMAIL PROTECTED]";>David Jencks
  -@version $Revision: 1.7 $
  +@version $Revision: 1.7.2.1 $
   */
  -public class Log4jService implements Log4jServiceMBean, NotificationListener,
  -MBeanRegistration
  +public class Log4jService implements Log4jServiceMBean, MBeanRegistration
   {
   
   // Attributes 
  @@ -141,55 +130,12 @@
   category.info("Stopped Log4jService");
   }
   
  -// Public 
  -/** This method recevies JMX notification events posted via a Logger
  -instances fireNotification method and logs the msg through the
  -log4j root Category.
  -
  -@param n, the log event. This provides the log source as n.getUserData(),
  -the log msg as n.getMessage(), and the type of message from n.getType().
  -@see org.jboss.logging.Logger#fireNotification(String, Object, String)
  -*/
  -public void handleNotification(Notification n, Object handback)
  -{
  -if( category == null )
  -return;
  -
  -String msg = n.getMessage();
  -char type = n.getType().charAt(0);
  -String source = (String) n.getUserData();
  -if( source == null || source.length() == 0 )
  -source = "Default";
  -//get a category based on the source name, so we can turn on and off pieces 
of logging.
  -Category localCategory = category.getInstance(source);
  -switch( type )
  -{
  -case 'W':
  -localCategory.warn(msg);
  -break;
  -case 'D':
  -localCategory.debug(msg);
  -break;
  -case 'E':
  -localCategory.error(msg);
  -break;
  -default:
  -localCategory.info(msg);
  -break;
  -}
  -}
   
   // --- Begin MBeanRegistration interface methods
  -/** Initializes the MBean by registering as a addNotificationListener of the
  -Log service and then invokes start() to configure the log4j framework.
  -@return the name of this mbean.
  -*/
   public ObjectName preRegister(MBeanServer server, ObjectName name) throws 
Exception
   {
   start();
  -// Receive notification events sent by the Logger mbean
   ObjectName logger = new 
ObjectName(server.getDefaultDomain(),"service","Log");
  -server.addNotificationListener(logger,this,null,null);
   return name == null ? new ObjectName(OBJECT_NAME) : name;
   }
   public void postRegister(Boolean b)
  
  
  
  1.8.4.1   +188 -133  jboss/src/main/org/jbos

[JBoss-dev] CVS update: jboss/src/main/org/jboss/management ContainerManagement.java ServerDataCollector.java

2001-11-20 Thread Scott M Stark

  User: starksm 
  Date: 01/11/20 01:42:54

  Modified:src/main/org/jboss/management Tag: Branch_2_4
ContainerManagement.java ServerDataCollector.java
  Log:
  Change to the unified log4j based org.jboss.logging.Logger class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +6 -16 jboss/src/main/org/jboss/management/ContainerManagement.java
  
  Index: ContainerManagement.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/management/ContainerManagement.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- ContainerManagement.java  2001/11/02 08:42:36 1.1.2.1
  +++ ContainerManagement.java  2001/11/20 09:42:54 1.1.2.2
  @@ -40,19 +40,7 @@
   import javax.management.ObjectName;
   
   import org.jboss.ejb.Container;
  -
  -import org.jboss.logging.Log;
  -import org.jboss.logging.ConsoleLogging;
  -import org.jboss.logging.ConsoleLoggingMBean;
  -
  -import org.jboss.metadata.ApplicationMetaData;
   import org.jboss.metadata.BeanMetaData;
  -import org.jboss.metadata.SessionMetaData;
  -import org.jboss.metadata.EntityMetaData;
  -import org.jboss.metadata.MessageDrivenMetaData;
  -import org.jboss.metadata.ConfigurationMetaData;
  -import org.jboss.metadata.XmlLoadable;
  -import org.jboss.metadata.XmlFileLoader;
   import org.jboss.logging.Logger;
   
   /**
  @@ -61,7 +49,7 @@
   *   @see Container
   *   @author Andreas Schaefer ([EMAIL PROTECTED])
   *
  -*   @version $Revision: 1.1.2.1 $
  +*   @version $Revision: 1.1.2.2 $
   */
   public class ContainerManagement
 extends org.jboss.util.ServiceMBeanSupport
  @@ -70,14 +58,16 @@
  // Attributes 
  // Container this is the management proxy for
  Container mContainer = null;
  -   // The logger of this service
  -   Log mLog = Log.createLog( getName() );
  ObjectName mName = null;
   
  // Constructor ---
   
  -   public ContainerManagement( Container pContainer ) {
  +   public ContainerManagement( Container pContainer )
  +   {
 setContainer( pContainer );
  +  BeanMetaData bmd = pContainer.getBeanMetaData();
  +  String name = getClass().getName() + '.' + bmd.getEjbName();
  +  log = Logger.getLogger(name);
  }
  
  // Public 
  
  
  
  1.1.2.1   +164 -124  
jboss/src/main/org/jboss/management/Attic/ServerDataCollector.java
  
  Index: ServerDataCollector.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/management/Attic/ServerDataCollector.java,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  --- ServerDataCollector.java  2001/06/16 05:48:44 1.1
  +++ ServerDataCollector.java  2001/11/20 09:42:54 1.1.2.1
  @@ -23,7 +23,7 @@
   import javax.naming.Reference;
   import javax.naming.StringRefAddr;
   
  -import org.jboss.logging.Log;
  +import org.jboss.logging.Logger;
   import org.jboss.naming.NonSerializableFactory;
   import org.jboss.util.ServiceMBeanSupport;
   
  @@ -35,35 +35,35 @@
* @author Marc Fleury
**/
   public class ServerDataCollector
  -   extends ServiceMBeanSupport
  -   implements ServerDataCollectorMBean
  +extends ServiceMBeanSupport
  +implements ServerDataCollectorMBean
   {
  -
  +   
  // -
  // Constants
  -   // -  
  -
  +   // -
  +   
  public static String JNDI_NAME = "servercollector:domain";
  public static String JMX_NAME = "servercollector";
  -
  +   
  // -
  // Members
  -   // -  
  -
  +   // -
  +   
  private MBeanServer mServer;
  private String mName;
  private Boolean mRefresh = new Boolean( true );
  private RefreshWorker mWorker;
  private int mRefreshSleep = 2000;
  -
  +   
  private Map mApplications = new Hashtable();
  private Collection mResources = new ArrayList();
  private Collection mNodes = new ArrayList();
  -
  +   
  // -
  // Constructors
  -   // -  
  -
  +   // -
  +   
  /**
   * Default (no-args) Constructor

  1   2   >