Re: [JBoss-dev] AutoNumber in Jboss 3.0.0

[Marius Kotsbak]

On Wed, 2002-04-03 at 19:52, Dain Sundstrom wrote:
> I wasn't aware of this.  Are you sure it was removed?  If you are having 
> problems, post again, and I'll ask around.
I just note that since the autonumber was moved to varia (from
jboss.util?), I get AutoNumber not foud while deploying. I solved this
by packing the compiled files (by the buildscript) for autonumber into a
jar and deploy that one, then it works again.

If it is not deprecated (I saw a post for some time ago, when someone
asked (in a checking) if anyone still used it), I think it should be
placed in the lib or deploy dir in a normal build of jboss.

> 
> -dain
> 
> Marius Kotsbak wrote:
> 
> > On ons, 2002-03-27 at 23:13, jessica hekman wrote:
> > 
> >>I am trying to upgrade from 2.4 to 3.0 in order to use CMP 2.0. However, in moving 
>my application over to 3.0 I'm having trouble using the AutoNumber class. In 2.4 it 
>was in org.jboss.util; in 3.0 it is in org.jboss.varia.autonumber (so far, so good). 
>In 2.4 it was available in ext/jboss.jar; in 3.0 it does not seem to be built into 
>any jar files. Is this intentional? Am I missing it?
> >>
> >>I have been using AutoNumber to generate unique primary keys, which I understand 
>isn't yet handled in any better way in JBoss (but will be soon; I just need a 
>solution in the meantime).
> >>
> >>Thanks!
> > 
> > I see that this module is removed from the normal builds. What are we
> > supposed to use for this purpose? the counter service? How does it work?
> > 
> > Marius
> > SW dev. Boostcom.no
> > 
> 
> 
> 
> ___
> 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] Todo: multiple instances detection

[Dain Sundstrom]

Marc,

I was talking about this last week.  The problem with this suggestion is 
it does not address other ports such as http, http-jmx management.  My 
ideas was to have a port config file that listed each named port for a 
server, and then each mbean that used a port would look in this file (or 
an mbean that represents the file).  Scott said that this idea was lame, 
and we need naming conventions for the port attributes or xmbeans with 
additional meta data.  I don't think there was a resolution.

-dain

marc fleury wrote:

> there should be a service that is part of the first services coming up and
> that detects if other JBoss systems are running on the same physical
> machines, this is to avoid port conflict as some services are holding on to
> some ports (e.g. naming on 1099, detached RMI, clustered RMI).
> 
> We would then not start the naming as a duplicate nor the detached RMI but
> we would use the clustered RMI by increasing the connection port.
> 
> This will enable people to run multiple instances of JBoss without having to
> manually change the stuff all the time.  At least on the services we provide
> we should show how these behave.
> 
> marcf
> 
> 
> ___
> 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] Connection Pool Configuration

[Dain Sundstrom]

Can this be set in the initial connection properties?  I don't know much 
about pool set-up, but David does (and I CCed him on this email).  Does 
the current pool code support setting of properties in the config file?

-dain

Giorgio42 wrote:

> Is JBoss CMP currently making any use
> of proprietary JDBC Driver implementation
> features?
> 
> Specifically, is the method 
> setDefaultRowPrefetch(int rows) provided
> by the Oracle thin client driver used?
> 
> My experience is, that this setting can have
> a huge impact on the performance of data-oriented
> applications, especially if they read large datasets.
> 
> Using reflection, the code need not directly depend on
> on the Oracle driver being in the classpath and still
> get compiled, like this:
> 
> java.lang.reflect.Method method = conn.getClass().getMethod("setDefaultRowPrefetch", 
>new Class[]{ int.class });
> method.invoke(conn, new Object[]{ new Integer(rowPrefetch) });
> 
> This could be added to (standardjboss)cmp-jdbc.xml
> configuration parameters.
> 
> JDBC3.0 defines a (small) set of standard properties for
> pooled connection sources (in section 11.7), so 
> this is a first step in standardizing this process.
> 
> Just a suggestion...
> 
> And a happy easter to the JBoss team!
> 
> Georg
> 
> _
> View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=11768
> 
> ___
> 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: 2-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   563



Successful tests:  534

Errors:19

Failures:  10





[time of test: 2 April 2002 6:55 GMT]
[java.version: 1.3.1_02]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.3.1_02-b02]
[java.vm.name: Java HotSpot(TM) Server VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

[JBoss-dev] AIX 5L port for J2SE 1.3.1_02

[Chandan S Pansare]

Hi,

This is real urgent. I am looking for J2SE 1.3.1_02 for AIX 5L. Is this available? 
where can I download this if it is availbale? 
_
View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=12117

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

Re: [JBoss-dev] Added DeploymentCache & friends

[Jason Dillon]

SF mailing lists seem to be behind... really behind.

--jason


On Wed, 3 Apr 2002, Jason Dillon wrote:

> I just commited an initial impl of a deployment cache, which sits 
> between a DeploymentScanner and MainDeployer.
> 
> The actual storage of deployments is handled by a pluggable 
> DeploymentStore component.  I added a simple local file version which is 
> probably good enough for most cases.  Please before you start bitching 
> about the abstraction, go look at the code and see how the seperation 
> makes both components simpliler (marc =P).
> 
> Currently a cached deployment url will only become invalid if the 
> orinigal url changes.  I imagine that we should add a pluggable 
> policy/period based clean up of undeployed cached urls as well as expose 
> mgmt over the store.  I didn't spend too much time testing this for 
> thread safty and whatever, so it could use some more pounding.
> 
> I updated the default jboss-service.xml to have commeted instructions on 
> how to enable the cache and I will update the NetBoot demo files to use 
> this by default in the days to come... to tired to do it now.
> 
> Finally, I did run the testsuite and even though the failure/error count 
> is higher than my usual limit... I am thinking that I didn't break 
> anything major.  We really need to fix this so it always runs clean 
> unless something is broken.  Anyways, please forgive me if I did break 
> something... I can't really tell.
> 
> Enjoy,
> 
> --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

[JBoss-dev] Automated JBoss Testsuite Results: 4-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   536



Successful tests:  208

Errors:319

Failures:  9





[time of test: 4 April 2002 7:12 GMT]
[java.version: 1.4.0]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.4.0-b92]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

[JBoss-dev] RE: Bug in EntitySynchronizationInterceptor.java?

[Bill Burke]

Henri,

Good catch.  I finally actually read your bug report :)

BTW, this would only happen if your entity bean is re-entrant, right?

The fix for this I believe is in EntitySynchronizationInterceptor.  I think
it is ok to register() before invoke() since register() will always happen
anyways.  Anybody see anything wrong about that?

Henri,  when I commit to 2.4.5 (Branch_2_4) and 3.0, do you have a test for
this?

Thanks,

Bill

> -Original Message-
> From: Henri Chen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 02, 2002 11:30 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: FW:Bug in EntitySynchronizationInterceptor.java?
>
>
> I found I post my former mail to
> [EMAIL PROTECTED] and that is not
> correct. So I forward the mail to the correct list again. Sorry
> for the inconvenience.
> --
> Dear Bill,
>
> The transaction did propagate correctly and without problem
> because it is not a different transaction issue.
>
> The question is that the new activated instance (when calling
> m1()) is not put into the HashMap IMMEDIATELY. It does it in the
> "finally block" and that is after the invoke chain. So if the
> implementation of m1() calling m2() thru the entitie's component
> interface (i.e. calling thru container), the m2() would go thru
> the EntityMultiInstanceInterceptor again. The interceptor would
> try to looks that HashMap for the instance. Oops! It  would still
> activate a new instance of the same PK because the instance
> activated during calling in m1() is not put into the HashMap YET
> (because the invoke chain is not completed yet.)
>
> This is what I think it might be a bug.
>
> Henri
>
> P.S. It did cause trouble in my code. I saw two instances  were
> consecutiously activated and I read the source code of jboss
> release 2.4.4.
>
> -Original Message-
> From: Bill Burke [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2002 10:10 PM
> To: Henri Chen; [EMAIL PROTECTED]
> Subject: RE: Bug in EntitySynchronizationInterceptor.java?
>
>
> I don't think soLet me go through your comments again just to
> make sure.
>
> I keep a transaction->entity map.  Before an instance is created anew, the
> EntityMultiInstanceInterceptor looks in a HashMap to see if the
> instance has
> already been created for this transaction.  The transaction should be
> propagated when you call _ctx.getEJBOejct()->stubx1->m2().
> Unless there is
> some bug someplace and the transaction is not getting propagated.  Are you
> seeing bad behaviour?  Or is this just your observation just
> looking at the
> code?
>
> Bill
>
> > -Original Message-
> > From: Henri Chen [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 22, 2002 1:33 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Bug in EntitySynchronizationInterceptor.java?
> >
> >
> > Dear Bill,
> >
> > It might be too late to associate the entity bean with the
> > transaction until after the invoke chain.
> >
> > The following is a senario that might cause trouble:
> >
> > * An entity bean XBean with component interface method m1() and m2().
> > * Some session bean Y calls XHome.findByPrimaryKey() to get the
> > component interface stub x1.
> > * Y calls x1.m1(), the EntityMutltiInstanceInterceptor
> > automatically activate and load an instance of the XBean.
> > * The implementation of method m1() in XBean use
> > _ctx.getEJBObject() to get the stub x1, and calling m2() thru the
> > container again.
> > * The EntityMutltiInstanceInterceptor, AGAIN, automatically
> > activate and load ANOTHER NEW INSTANCE of  x1; and then invoke
> > m2() on this new instance and return.
> > * The EntitySynchronizationInterceptor associate 2nd instance
> > into txEntityMap.
> > * The m1() on the first instance return.
> > * The EntitySynchronizationInterceptor associate 1st instance
> > into txEntityMap WITH the same primary key and transaction.(So
> > basically, the 2nd instance is overwritten and gone)
> >
> > The result is that two methods m1() and m2 are called on two
> > DIFFERENT instances. Therefore, the state of the bean would be
> > unpredictable because all that have done inside m2() is lost.
> >
> > Am I right?
> >
> > Henri Chen
> >
> > PS. This is based on the jboss 2.4.4 source code, and use commit
> > Option B.


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

Re: [JBoss-dev] How to configure JBoss for multiple developers

[Mitchell Kim]

Run multiple instances of JBoss... on different ports.

Mitch
- Original Message -
From: "Leung Kam Lung" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 03, 2002 2:15 PM
Subject: [JBoss-dev] How to configure JBoss for multiple developers


> Hello,
>
> I am new to JBoss. I have some question about setting JBoss for multiple
developers. Example, I have an application name someApplication.ear which
was developed by 4 developers. All four of them need to deploy the same
someApllication.ear to the "deploy" directory for testing. How do I solve
this kind of development issue?
> The only thing that I can come up is to have multiple machine which
contains a instance of JBoss. But this required lots of money and time to
setup. I am sure there are many ways to solve this issue. Anything will
help.
> Thank you in advance,
>
> Kam Lung Leung
>
> _
> View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=12058
>
> ___
> 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] recent break in service redeployment....

[Jules Gosnell]

within the last 24hrs - redeploying the Jetty service now throws an
exception :

06:53:40,346 INFO  [MainDeployer] Undeploying
file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar

06:53:40,347 INFO  [JettyService] Stopping
06:53:40,350 INFO  [Jetty] Stopping Acceptor
ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8080]
06:53:40,671 INFO  [Jetty] Stopped SocketListener on 0.0.0.0:8080
06:53:40,672 INFO  [Jetty] Stopped org.mortbay.http.NCSARequestLog@84174

06:53:40,673 INFO  [Jetty] Stopped org.jboss.jetty.Jetty@309e87
06:53:40,673 INFO  [JettyService] Stopped
06:53:40,674 INFO  [JettyService] Destroying
06:53:40,675 INFO  [Jetty] Deregister jboss.web:Jetty=0,SocketListener=0

06:53:40,676 INFO  [Jetty] Deregister jboss.web:Jetty=0,NCSARequestLog=0

06:53:40,677 INFO  [Jetty] Deregister jboss.web:Jetty=0
06:53:40,678 INFO  [Jetty] Deregister jboss.web:Jetty=Debug
06:53:40,679 INFO  [Jetty] Deregister jboss.web:Jetty=Log
06:53:40,681 INFO  [Jetty] Deregister jboss.web:JBossLogSink=0
06:53:40,681 INFO  [JettyService] Destroyed
06:53:40,682 INFO  [MainDeployer] not deleting localUrl, it is null or
not a copy:
njar:file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/tmp/deploy/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar/54.jetty-plugin.sar^/org.mortbay.jetty.jmx.jar

06:53:40,683 INFO  [MainDeployer] Undeployed
njar:file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/tmp/deploy/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar/54.jetty-plugin.sar^/org.mortbay.jetty.jmx.jar

06:53:40,683 INFO  [MainDeployer] not deleting localUrl, it is null or
not a copy:
njar:file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/tmp/deploy/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar/54.jetty-plugin.sar^/org.mortbay.jetty.jar

06:53:40,690 INFO  [MainDeployer] Undeployed
njar:file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/tmp/deploy/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar/54.jetty-plugin.sar^/org.mortbay.jetty.jar

06:53:40,705 INFO  [MainDeployer] Cleaned Deployment
file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar

06:53:40,712 INFO  [ServiceController] Exception removing mbean:
jboss.web:service=Jetty
javax.management.InstanceNotFoundException: jboss.web:service=Jetty is
not registered.
 at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:413)

 at
org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:452)

 at
org.jboss.system.ServiceConfigurator.internalGetConfiguration(ServiceConfigurator.java:587)

 at
org.jboss.system.ServiceConfigurator.getConfiguration(ServiceConfigurator.java:578)

 at
org.jboss.system.ServiceController.unregisterClassName(ServiceController.java:658)

 at
org.jboss.system.ServiceController.handleNotification(ServiceController.java:645)

 at org.jboss.system.ServiceLibraries.notify(ServiceLibraries.java:612)
 at
org.jboss.system.ServiceLibraries.removeClassLoader(ServiceLibraries.java:304)

 at org.jboss.deployment.DeploymentInfo.cleanup(DeploymentInfo.java:241)

 at org.jboss.deployment.MainDeployer.destroy(MainDeployer.java:432)
 at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:342)
 at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:308)
 at java.lang.reflect.Method.invoke(Native Method)
 at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)

 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:441)

 at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
 at $Proxy5.undeploy(Unknown Source)
 at
org.jboss.deployment.scanner.URLDeploymentScanner.undeploy(URLDeploymentScanner.java:351)

 at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:432)

 at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:204)

 at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:193)

06:53:40,713 INFO  [MainDeployer] Undeployed
file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar

06:53:45,724 INFO  [MainDeployer] Starting deployment of package:
file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0beta2/server/default/deploy/jetty-plugin.sar

06:53:49,791 INFO  [Jetty] Registered jboss.web:Jetty=0
06:53:50,407 INFO  [Jetty] Registered jboss.web:Jetty=Debug
06:53:50,546 INFO  [Jetty] Registered jboss.web:Jetty=Log
06:53:50,565 INFO  [Je

Re: [JBoss-dev] Todo: multiple instances detection

[Hiram Chirino]

Keep in mind that,

Most admins like to have thier ports fixed so that they know what holes they 
have to punch in the firewalls.

Regards,
Hiram

>From: Jason Dillon <[EMAIL PROTECTED]>
>To: Bill Burke <[EMAIL PROTECTED]>
>CC: marc fleury <[EMAIL PROTECTED]>,   "Jboss-Development@Lists. 
>Sourceforge. Net" <[EMAIL PROTECTED]>
>Subject: Re: [JBoss-dev] Todo: multiple instances detection
>Date: Wed, 03 Apr 2002 20:22:06 -0800
>
>Couldn't the refs reattache to the invoker via JNDI, leaving them free
>to use random ports... only JNDI would need a static port number then...
>or am I missing something?
>
>--jason
>
>
>Bill Burke wrote:
>
>>Maybe the invokers should run on a hard-coded port.  With a hard-coded 
>>port,
>>I think references can live beyond the life of the server.  Or maybe I 
>>don't
>>know what I'm talking about :)
>>
>>>-Original Message-
>>>From: [EMAIL PROTECTED]
>>>[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
>>>Dillon
>>>Sent: Wednesday, April 03, 2002 4:49 PM
>>>To: marc fleury
>>>Cc: Jboss-Development@Lists. Sourceforge. Net
>>>Subject: Re: [JBoss-dev] Todo: multiple instances detection
>>>
>>>
>>>Not sure that an external component is the best choice for this... but I
>>>have not really thought it through.
>>>
>>>On a related note, I sent mail a while ago asking about the web service
>>>for class loading wtr having it use an anonymous port.  If we set the
>>>default RMI port to anonymous too, then we only have naming,
>>>jmx-html-adapter and web ports to deal with.  Once the jmx-html-adapter
>>>is a .war, then we only have naming and web.
>>>
>>>Does anyone know if it is possible to setup on public port, which then
>>>attaches to other anonymous/random ports, switching based on the
>>>content.  This would make it look to clients like there was only one
>>>port, but really there could be many, but the actual numer would
>>>not matter.
>>>
>>>Something like this could (assuming it is possible) would make it easy
>>>to integrate thirdparty plugins into the single port scheme which simply
>>>need a port, with out them having to know about a special component or
>>>conform to a specific api to select a random port or whatever...
>>>
>>>--jason
>>>
>>>
>>>marc fleury wrote:
>>>
there should be a service that is part of the first services

>>>coming up and
>>>
that detects if other JBoss systems are running on the same physical
machines, this is to avoid port conflict as some services are

>>>holding on to
>>>
some ports (e.g. naming on 1099, detached RMI, clustered RMI).

We would then not start the naming as a duplicate nor the

>>>detached RMI but
>>>
we would use the clustered RMI by increasing the connection port.

This will enable people to run multiple instances of JBoss

>>>without having to
>>>
manually change the stuff all the time.  At least on the

>>>services we provide
>>>
we should show how these behave.

marcf


___
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



_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


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

[JBoss-dev] Automated JBoss Testsuite Results: 4-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   567



Successful tests:  540

Errors:19

Failures:  8





[time of test: 4 April 2002 6:7 GMT]
[java.version: 1.3.1_02]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.3.1_02-b02]
[java.vm.name: Java HotSpot(TM) Server VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

[JBoss-dev] [ jboss-Bugs-539096 ] Lack of Reasonable Error on Deployment

[noreply]

Bugs item #539096, was opened at 2002-04-03 22:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=539096&group_id=22866

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Luttrell (objec)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lack of Reasonable Error on Deployment

Initial Comment:
I am using jboss3.0+tomcat the build from 02.22.2002.

I just attempted to deploy an entity bean, where in the
deployment descriptor, i specified the incorrect
classname to one that did not exist.

The messages on the console were just: [Bean Deployer]
Deploying: file:/bla...

In cases where something is as blatently wrong as a
class name that does not exist in the jar file, normal
users will expect somesort of error message. Maybe a
ClassNotFoundException.

--

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

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

RE: [JBoss-dev] RE: Bug in EntitySynchronizationInterceptor.java?

[Bill Burke]

Nope, no leak.  A synchronization object is registered with the transaction.
It will release the instance.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf
> Of Henri Chen
> Sent: Wednesday, April 03, 2002 8:34 PM
> To: Bill Burke; [EMAIL PROTECTED]
> Subject: [JBoss-dev] RE: Bug in EntitySynchronizationInterceptor.java?
>
>
> Bill,
>
> Yes, it would only happen for re-entrant beans.
>
> I did not see through the whole source codes. But if any
> Exception happened during the invoke(), wouldn't there a memory
> leak in that HashMap?(Of course, this argument applys to the old
> "finally block" implementation, too)
>
> If there is no memory leak issue, I think register() before
> invoke() is ok because the old implementation  would always
> register it in "finally block".
>
> Henri
>
> -Original Message-
> From: Bill Burke [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 04, 2002 7:26 AM
> To: Henri Chen; [EMAIL PROTECTED]
> Subject: RE: Bug in EntitySynchronizationInterceptor.java?
>
>
> Henri,
>
> Good catch.  I finally actually read your bug report :)
>
> BTW, this would only happen if your entity bean is re-entrant, right?
>
> The fix for this I believe is in
> EntitySynchronizationInterceptor.  I think
> it is ok to register() before invoke() since register() will always happen
> anyways.  Anybody see anything wrong about that?
>
> Henri,  when I commit to 2.4.5 (Branch_2_4) and 3.0, do you have
> a test for
> this?
>
> Thanks,
>
> Bill
>
> > -Original Message-
> > From: Henri Chen [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 02, 2002 11:30 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: FW:Bug in EntitySynchronizationInterceptor.java?
> >
> >
> > I found I post my former mail to
> > [EMAIL PROTECTED] and that is not
> > correct. So I forward the mail to the correct list again. Sorry
> > for the inconvenience.
> > --
> > Dear Bill,
> >
> > The transaction did propagate correctly and without problem
> > because it is not a different transaction issue.
> >
> > The question is that the new activated instance (when calling
> > m1()) is not put into the HashMap IMMEDIATELY. It does it in the
> > "finally block" and that is after the invoke chain. So if the
> > implementation of m1() calling m2() thru the entitie's component
> > interface (i.e. calling thru container), the m2() would go thru
> > the EntityMultiInstanceInterceptor again. The interceptor would
> > try to looks that HashMap for the instance. Oops! It  would still
> > activate a new instance of the same PK because the instance
> > activated during calling in m1() is not put into the HashMap YET
> > (because the invoke chain is not completed yet.)
> >
> > This is what I think it might be a bug.
> >
> > Henri
> >
> > P.S. It did cause trouble in my code. I saw two instances  were
> > consecutiously activated and I read the source code of jboss
> > release 2.4.4.
> >
> > -Original Message-
> > From: Bill Burke [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 22, 2002 10:10 PM
> > To: Henri Chen; [EMAIL PROTECTED]
> > Subject: RE: Bug in EntitySynchronizationInterceptor.java?
> >
> >
> > I don't think soLet me go through your comments again just to
> > make sure.
> >
> > I keep a transaction->entity map.  Before an instance is
> created anew, the
> > EntityMultiInstanceInterceptor looks in a HashMap to see if the
> > instance has
> > already been created for this transaction.  The transaction should be
> > propagated when you call _ctx.getEJBOejct()->stubx1->m2().
> > Unless there is
> > some bug someplace and the transaction is not getting
> propagated.  Are you
> > seeing bad behaviour?  Or is this just your observation just
> > looking at the
> > code?
> >
> > Bill
> >
> > > -Original Message-
> > > From: Henri Chen [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, March 22, 2002 1:33 AM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Bug in EntitySynchronizationInterceptor.java?
> > >
> > >
> > > Dear Bill,
> > >
> > > It might be too late to associate the entity bean with the
> > > transaction until after the invoke chain.
> > >
> > > The following is a senario that might cause trouble:
> > >
> > > * An entity bean XBean with component interface method m1() and m2().
> > > * Some session bean Y calls XHome.findByPrimaryKey() to get the
> > > component interface stub x1.
> > > * Y calls x1.m1(), the EntityMutltiInstanceInterceptor
> > > automatically activate and load an instance of the XBean.
> > > * The implementation of method m1() in XBean use
> > > _ctx.getEJBObject() to get the stub x1, and calling m2() thru the
> > > container again.
> > > * The EntityMutltiInstanceInterceptor, AGAIN, automatically
> > > activate and load ANOTHER NEW INSTANCE of  x1; and then invoke
> > > m2() on this new instance and return.
> > > * The EntitySynchronizationInterceptor associate 2nd instance
> > > 

RE: [JBoss-dev] Todo: multiple instances detection

[Bill Burke]

Only home interfaces are registered into JNDI.

> -Original Message-
> From: Jason Dillon [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 03, 2002 11:22 PM
> To: Bill Burke
> Cc: marc fleury; Jboss-Development@Lists. Sourceforge. Net
> Subject: Re: [JBoss-dev] Todo: multiple instances detection
>
>
> Couldn't the refs reattache to the invoker via JNDI, leaving them free
> to use random ports... only JNDI would need a static port number then...
> or am I missing something?
>
> --jason
>
>
> Bill Burke wrote:
>
> >Maybe the invokers should run on a hard-coded port.  With a
> hard-coded port,
> >I think references can live beyond the life of the server.  Or
> maybe I don't
> >know what I'm talking about :)
> >
> >>-Original Message-
> >>From: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> >>Dillon
> >>Sent: Wednesday, April 03, 2002 4:49 PM
> >>To: marc fleury
> >>Cc: Jboss-Development@Lists. Sourceforge. Net
> >>Subject: Re: [JBoss-dev] Todo: multiple instances detection
> >>
> >>
> >>Not sure that an external component is the best choice for this... but I
> >>have not really thought it through.
> >>
> >>On a related note, I sent mail a while ago asking about the web service
> >>for class loading wtr having it use an anonymous port.  If we set the
> >>default RMI port to anonymous too, then we only have naming,
> >>jmx-html-adapter and web ports to deal with.  Once the jmx-html-adapter
> >>is a .war, then we only have naming and web.
> >>
> >>Does anyone know if it is possible to setup on public port, which then
> >>attaches to other anonymous/random ports, switching based on the
> >>content.  This would make it look to clients like there was only one
> >>port, but really there could be many, but the actual numer would
> >>not matter.
> >>
> >>Something like this could (assuming it is possible) would make it easy
> >>to integrate thirdparty plugins into the single port scheme which simply
> >>need a port, with out them having to know about a special component or
> >>conform to a specific api to select a random port or whatever...
> >>
> >>--jason
> >>
> >>
> >>marc fleury wrote:
> >>
> >>>there should be a service that is part of the first services
> >>>
> >>coming up and
> >>
> >>>that detects if other JBoss systems are running on the same physical
> >>>machines, this is to avoid port conflict as some services are
> >>>
> >>holding on to
> >>
> >>>some ports (e.g. naming on 1099, detached RMI, clustered RMI).
> >>>
> >>>We would then not start the naming as a duplicate nor the
> >>>
> >>detached RMI but
> >>
> >>>we would use the clustered RMI by increasing the connection port.
> >>>
> >>>This will enable people to run multiple instances of JBoss
> >>>
> >>without having to
> >>
> >>>manually change the stuff all the time.  At least on the
> >>>
> >>services we provide
> >>
> >>>we should show how these behave.
> >>>
> >>>marcf
> >>>
> >>>
> >>>___
> >>>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: jbossmq/src/main/org/jboss/mq/pm/rollinglogged PersistenceManager.java PersistenceManagerMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:35:07

  Modified:src/main/org/jboss/mq/pm/rollinglogged
PersistenceManager.java
  Removed: src/main/org/jboss/mq/pm/rollinglogged
PersistenceManagerMBean.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
   o Using XDoclet to generate some *MBean interfaces
  
  Revision  ChangesPath
  1.22  +34 -16
jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java
  
  Index: PersistenceManager.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- PersistenceManager.java   9 Mar 2002 15:32:34 -   1.21
  +++ PersistenceManager.java   4 Apr 2002 04:35:07 -   1.22
  @@ -32,14 +32,17 @@
   import org.jboss.system.ServiceMBeanSupport;
   import org.jboss.mq.server.MessageReference;
   import org.jboss.mq.server.MessageCache;
  -import org.jboss.system.server.ServerConfigImplMBean;
  +
  +import org.jboss.system.server.ServerConfigLocator;
   
   /**
  - *  This class manages all persistence related services.
  + * This class manages all persistence related services.
  + *
  + * @jmx:mbean extends="org.jboss.system.ServiceMBean, 
org.jboss.mq.pm.PersistenceManagerMBean"
*
  - * @author David Maplesden ([EMAIL PROTECTED])
  + * @author David Maplesden ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>David Jencks
  - * @version$Revision: 1.21 $
  + * @version $Revision: 1.22 $
*/
   public class PersistenceManager
  extends ServiceMBeanSupport
  @@ -103,25 +106,26 @@
 return messageCache;
  }
   
  -
  /**
  -*  Insert the method's description here. Creation date: (6/27/2001 12:53:12
  -*  AM)
  +* Sets the DataDirectory attribute of the PersistenceManagerMBean object
  +*
  +* @jmx:managed-attribute
   *
  -* @param  newDataDirectory  java.lang.String
  +* @param  newDataDirectory  The new DataDirectory value
   */
  -   public void setDataDirectory(java.lang.String newDataDirectory)
  +   public void setDataDirectory(String newDataDirectory)
  {
 dataDirectory = newDataDirectory;
  }
   
  /**
  -*  Insert the method's description here. Creation date: (6/27/2001 12:53:12
  -*  AM)
  +* Gets the DataDirectory attribute of the PersistenceManagerMBean object
   *
  -* @returnjava.lang.String
  +* @jmx:managed-attribute
  +*
  +* @returnThe DataDirectory value
   */
  -   public java.lang.String getDataDirectory()
  +   public String getDataDirectory()
  {
 return dataDirectory;
  }
  @@ -131,11 +135,26 @@
 this.rollOverSize = rollOverSize;
  }
   
  +   /**
  +* Gets maximum number of messages until log rolls over
  +*
  +* @jmx:managed-attribute
  +*
  +* @return number of messages before log rolls over
  +*/
  public int getRollOverSize()
  {
 return rollOverSize;
  }
   
  +   /**
  +* Sets the maxmimum number of messages before log rolls over
  +*
  +* @jmx:managed-attribute
  +*
  +* @param   rollOverSize   The maxmimum number of messages before
  +* rollover occurs
  +*/
  public Object getInstance()
  {
 return this;
  @@ -233,9 +252,8 @@
  {
 log.debug("Using new rolling logged persistence manager.");
   
  -  // Get the system home directory (may want to use dataDir)
  -  File systemHomeDir = (File)
  - server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "ServerHomeDir");
  +  // Get the system home directory
  +  File systemHomeDir = ServerConfigLocator.locate().getServerHomeDir();
 
 dataDir = new File(systemHomeDir, dataDirectory);
 if (log.isDebugEnabled()) {
  
  
  

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

[JBoss-dev] CVS update: contrib/jboss.net/src/main/org/jboss/net/axis/server AxisService.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:34:41

  Modified:jboss.net/src/main/org/jboss/net/axis/server
AxisService.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
  
  Revision  ChangesPath
  1.16  +4 -5  
contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java
  
  Index: AxisService.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- AxisService.java  3 Apr 2002 08:44:52 -   1.15
  +++ AxisService.java  4 Apr 2002 04:34:41 -   1.16
  @@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
   
  -// $Id: AxisService.java,v 1.15 2002/04/03 08:44:52 user57 Exp $
  +// $Id: AxisService.java,v 1.16 2002/04/04 04:34:41 user57 Exp $
   
   package org.jboss.net.axis.server;
   
  @@ -34,7 +34,7 @@
   
   import org.jboss.naming.Util;
   import org.jboss.metadata.MetaData;
  -import org.jboss.system.server.ServerConfigImplMBean;
  +import org.jboss.system.server.ServerConfigLocator;
   
   import org.w3c.dom.Document;
   import org.w3c.dom.Element;
  @@ -84,7 +84,7 @@
* 
* @created 27. September 2001
* @author mailto:[EMAIL PROTECTED]";>Christoph G. Jung
  - * @version $Revision: 1.15 $
  + * @version $Revision: 1.16 $
*/
   
   public class AxisService
  @@ -145,8 +145,7 @@
   
  /** returns the jboss deploy dir */
  protected String getDeployDir() throws Exception {
  -  File systemTempDir =
  - (File) server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "TempDir");
  +  File systemTempDir = ServerConfigLocator.locate().getServerTempDir();
   
 return new File(new File(systemTempDir, "deploy"), Constants.AXIS_DEPLOY_DIR)
.getCanonicalPath();
  
  
  

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

[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/jdbc2 PersistenceManager.java PersistenceManagerMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:35:07

  Modified:src/main/org/jboss/mq/pm/jdbc2 PersistenceManager.java
  Removed: src/main/org/jboss/mq/pm/jdbc2 PersistenceManagerMBean.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
   o Using XDoclet to generate some *MBean interfaces
  
  Revision  ChangesPath
  1.2   +20 -14jbossmq/src/main/org/jboss/mq/pm/jdbc2/PersistenceManager.java
  
  Index: PersistenceManager.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/jdbc2/PersistenceManager.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- PersistenceManager.java   28 Mar 2002 03:08:04 -  1.1
  +++ PersistenceManager.java   4 Apr 2002 04:35:07 -   1.2
  @@ -40,13 +40,15 @@
   import org.jboss.tm.TransactionManagerService;
   
   /**
  - *  This class manages all persistence related services for JDBC based
  - *  persistence.
  + * This class manages all persistence related services for JDBC based
  + * persistence.
*
  - * @author: Jayesh Parayali ([EMAIL PROTECTED])
  - * @author: Hiram Chirino ([EMAIL PROTECTED])
  + * @jmx:mbean extends="org.jboss.system.ServiceMBean, 
org.jboss.mq.pm.PersistenceManagerMBean, org.jboss.mq.pm.CacheStoreMBean"
*
  - *  @version $Revision: 1.1 $
  + * @author Jayesh Parayali ([EMAIL PROTECTED])
  + * @author Hiram Chirino ([EMAIL PROTECTED])
  + *
  + *  @version $Revision: 1.2 $
*/
   public class PersistenceManager
  extends ServiceMBeanSupport
  @@ -1015,8 +1017,6 @@
   
  public void startService() throws Exception
  {
  -  log.debug("Starting");
  -
 SELECT_ALL_UNCOMMITED_TXS = 
sqlProperties.getProperty("SELECT_ALL_UNCOMMITED_TXS", SELECT_ALL_UNCOMMITED_TXS);
 DELETE_ALL_MESSAGE_WITH_TX = 
sqlProperties.getProperty("DELETE_ALL_MESSAGE_WITH_TX", DELETE_ALL_MESSAGE_WITH_TX);
 DELETE_TX = sqlProperties.getProperty("DELETE_TX", DELETE_TX);
  @@ -1060,7 +1060,6 @@
   
 log.debug("Resolving uncommited TXS");
 resolveAllUncommitedTXs();
  -  log.debug("Started");
  }
   
  public Object getInstance()
  @@ -1078,21 +1077,22 @@
 this.messageCacheName = messageCache;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public ObjectName getDataSource()
  {
 return dataSourceName;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public void setDataSource(ObjectName dataSourceName)
  {
 this.dataSourceName = dataSourceName;
  }
   
  -   public String getName()
  -   {
  -  return "JBossMQ-jdbc-PersistenceManager";
  -   }
  -
  public MessageCache getMessageCacheInstance()
  {
 return messageCache;
  @@ -1100,6 +1100,9 @@
   
  /**
   * Gets the sqlProperties.
  +*
  +* @jmx:managed-attribute
  +*
   * @return Returns a Properties
   */
  public String getSqlProperties()
  @@ -1118,6 +1121,9 @@
   
  /**
   * Sets the sqlProperties.
  +*
  +* @jmx:managed-attribute
  +*
   * @param sqlProperties The sqlProperties to set
   */
  public void setSqlProperties(String value)
  @@ -1135,4 +1141,4 @@
 }
  }
   
  -}
  \ No newline at end of file
  +}
  
  
  

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

[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/sm/file DynamicStateManager.java OldStateManager.java DynamicStateManagerMBean.java OldStateManagerMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:35:07

  Modified:src/main/org/jboss/mq/sm/file DynamicStateManager.java
OldStateManager.java
  Removed: src/main/org/jboss/mq/sm/file DynamicStateManagerMBean.java
OldStateManagerMBean.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
   o Using XDoclet to generate some *MBean interfaces
  
  Revision  ChangesPath
  1.2   +58 -20jbossmq/src/main/org/jboss/mq/sm/file/DynamicStateManager.java
  
  Index: DynamicStateManager.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/sm/file/DynamicStateManager.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DynamicStateManager.java  6 Mar 2002 17:27:51 -   1.1
  +++ DynamicStateManager.java  4 Apr 2002 04:35:07 -   1.2
  @@ -21,7 +21,7 @@
   import javax.jms.JMSException;
   import javax.jms.JMSSecurityException;
   
  -import org.jboss.system.server.ServerConfigImplMBean;
  +import org.jboss.system.server.ServerConfigLocator;
   import org.jboss.mq.DurableSubscriptionID;
   import org.jboss.mq.SpyTopic;
   import org.jboss.mq.SpyJMSException;
  @@ -31,21 +31,15 @@
   import org.jboss.mq.sm.StateManager;
   import org.jboss.mq.sm.AbstractStateManager;
   
  -
   /**
* A state manager that allowed durable subscriptions to be dynamically
* created if configured to support it. Otherwise backward compatible with
* the old StateManager.
*
  - * Backed by an XML file.
  + * Backed by an XML file.
*
  - * @author Norbert Lataille
  - * @author Hiram Chirino
  - * @author Peter Antman
  - * @version $Revision: 1.1 $
  - */
  -/*
  -Example of fileformat
  + * Example file format:
  + * 
   

  
  @@ -71,11 +65,19 @@
   

   
  + * 
  + *
  + * @jmx:mbean extends="org.jboss.mq.sm.AbstractStateManagerMBean"
  + *
  + * @author Norbert Lataille
  + * @author Hiram Chirino
  + * @author Peter Antman
  + * @version $Revision: 1.2 $
*/
  -public class DynamicStateManager  extends AbstractStateManager
  -  implements DynamicStateManagerMBean
  +public class DynamicStateManager 
  +   extends AbstractStateManager
  +   implements DynamicStateManagerMBean
   {
  -   
  class DynamicDurableSubscription extends DurableSubscription {
 XElement element;
 public  DynamicDurableSubscription(XElement element) throws XElementException{
  @@ -104,7 +106,9 @@
  boolean hasSecurityManager = true; 
  
  XElement stateConfig = new XElement("StateManager");//So sync allways work
  -   private String stateFile = "conf/default/jbossmq-state.xml";
  +
  +   /** State file is relateive to systemConfigURL. */
  +   private String stateFile = "jbossmq-state.xml";
  private URL systemConfigURL;
  
  
  @@ -118,20 +122,18 @@
  {
 return this;
  }
  -   
   
  -   protected void createService() throws Exception {
  +   protected void createService() throws Exception 
  +   {
 // Get the system configuration URL
  -  systemConfigURL = (URL)
  - server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "ServerConfigURL");
  +  systemConfigURL = ServerConfigLocator.locate().getServerConfigURL();
  }
  
  public void startService() throws Exception
  {
  -
 loadConfig();
  -
  }
  +
  /**
   * Show the current configuration.
   */
  @@ -139,9 +141,12 @@
  {
 return stateConfig.toString();
  }
  +
  /**
   * Set the name of the statefile.
   *
  +* @jmx:managed-attribute
  +*
   * @param  newStateFile  java.lang.String
   */
  public void setStateFile(String newStateFile)
  @@ -152,6 +157,8 @@
  /**
   * Get name of file.
   *
  +* @jmx:managed-attribute
  +*
   * @returnjava.lang.String
   */
  public String getStateFile()
  @@ -159,14 +166,23 @@
 return stateFile;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public boolean hasSecurityManager() {
 return hasSecurityManager;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public void setHasSecurityManager(boolean hasSecurityManager) {
 this.hasSecurityManager = hasSecurityManager;
  }
   
  +   /**
  +* @jmx:managed-operation
  +*/
  public void loadConfig() throws IOException, XElementException
  {
 URL configURL = new URL(systemConfigURL, stateFile);
  @@ -185,6 +201,9 @@
 }
  }
   
  +   /**
  +* @jmx:managed-operation
  +*/
  public void saveConfig() throws IOException
  {
 URL configURL = new URL(systemConfigURL, stateFile);
  @@ -432,6 +451,10 @@
  //
  // The methods that allow dynamic edititing of state manager.
  //
  +
  +   /**
  +* @jmx:

[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/sm AbstractStateManager.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:35:07

  Modified:src/main/org/jboss/mq/sm AbstractStateManager.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
   o Using XDoclet to generate some *MBean interfaces
  
  Revision  ChangesPath
  1.2   +4 -4  jbossmq/src/main/org/jboss/mq/sm/AbstractStateManager.java
  
  Index: AbstractStateManager.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/sm/AbstractStateManager.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- AbstractStateManager.java 6 Mar 2002 17:27:51 -   1.1
  +++ AbstractStateManager.java 4 Apr 2002 04:35:07 -   1.2
  @@ -23,20 +23,20 @@
* An abstract baseclass to make it a little bit easier to implement
* new StateManagers.
*
  + * 
* Apart from one methods in StateManager subclasses implement
* the protected abstract callback methods to do its work.
*
  - *
* @author Peter Antman
* @author Norbert Lataille
* @author Hiram Chirino
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
*/
   
   public abstract class AbstractStateManager 
  extends ServiceMBeanSupport
  -   implements StateManager, AbstractStateManagerMBean {
  -
  +   implements StateManager, AbstractStateManagerMBean 
  +{
  /**
   * Abstracts the data between a subclass and this class.
   * 
  
  
  

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

[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/jdbc PersistenceManager.java PersistenceManagerMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:35:06

  Modified:src/main/org/jboss/mq/pm/jdbc PersistenceManager.java
  Removed: src/main/org/jboss/mq/pm/jdbc PersistenceManagerMBean.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
   o Using XDoclet to generate some *MBean interfaces
  
  Revision  ChangesPath
  1.17  +27 -13jbossmq/src/main/org/jboss/mq/pm/jdbc/PersistenceManager.java
  
  Index: PersistenceManager.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/jdbc/PersistenceManager.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- PersistenceManager.java   9 Mar 2002 15:32:34 -   1.16
  +++ PersistenceManager.java   4 Apr 2002 04:35:06 -   1.17
  @@ -31,15 +31,18 @@
   import java.util.Map;
   
   /**
  - *  This class manages all persistence related services for JDBC based
  - *  persistence.
  + * This class manages all persistence related services for JDBC based
  + * persistence.
*
  - * @author: Jayesh Parayali ([EMAIL PROTECTED])
  + * @jmx:mbean extends="org.jboss.system.ServiceMBean, 
org.jboss.mq.pm.PersistenceManagerMBean"
*
  - *  @version $Revision: 1.16 $
  + * @author Jayesh Parayali ([EMAIL PROTECTED])
  + * @version $Revision: 1.17 $
*/
  -public class PersistenceManager extends ServiceMBeanSupport implements 
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager {
  -
  +public class PersistenceManager 
  +   extends ServiceMBeanSupport 
  +   implements PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager 
  +{
  private ObjectName messageCacheName;
  private MessageCache messageCache;
   
  @@ -92,40 +95,54 @@
  }
   
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public ObjectName getDataSource()
  {
 return dataSourceName;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public void setDataSource(ObjectName dataSourceName)
  {
 this.dataSourceName = dataSourceName;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public String getMessageTableName()
  {
 return messageTableName;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public void setMessageTableName(String tableName)
  {
 messageTableName = tableName;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public String getTransactionTableName()
  {
 return transactionTableName;
  }
   
  +   /**
  +* @jmx:managed-attribute
  +*/
  public void setTransactionTableName(String tableName)
  {
 transactionTableName = tableName;
  }
   
  -   public String getName() {
  -  return "JBossMQ-jdbc-PersistenceManager";
  -   }
  -
  public void startService() throws Exception
  {
 //Find the ConnectionFactoryLoader MBean so we can find the datasource
  @@ -397,6 +414,3 @@
  }
   
   }
  -
  -
  -
  
  
  

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

[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java PersistenceManager.java CacheStoreMBean.java PersistenceManagerMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:35:06

  Modified:src/main/org/jboss/mq/pm/file CacheStore.java
PersistenceManager.java
  Removed: src/main/org/jboss/mq/pm/file CacheStoreMBean.java
PersistenceManagerMBean.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
   o Using XDoclet to generate some *MBean interfaces
  
  Revision  ChangesPath
  1.7   +22 -8 jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
  
  Index: CacheStore.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CacheStore.java   27 Feb 2002 09:24:25 -  1.6
  +++ CacheStore.java   4 Apr 2002 04:35:06 -   1.7
  @@ -20,13 +20,16 @@
   import org.jboss.mq.SpyMessage;
   import org.jboss.mq.server.MessageReference;
   import org.jboss.system.ServiceMBeanSupport;
  -import org.jboss.system.server.ServerConfigImplMBean;
  +
  +import org.jboss.system.server.ServerConfigLocator;
   
   /**
* This class manages the persistence needs of the MessageCache
*
  + * @jmx:mbean extends="org.jboss.system.ServiceMBean, 
org.jboss.mq.pm.CacheStoreMBean"
  + *
* @author Hiram Chirino 
  - * @version$Revision: 1.6 $
  + * @version$Revision: 1.7 $
*/
   public class CacheStore
  extends ServiceMBeanSupport
  @@ -75,14 +78,26 @@
  }
   
  /**
  -* @see CacheStoreMBean#getDataDirectory()
  +* Gets the DataDirectory attribute of the CacheStoreMBean object
  +*
  +* @returnThe DataDirectory value
  +*
  +* @see CacheStoreMBean#getDataDirectory
  +*
  +* @jmx:managed-attribute
   */
  public String getDataDirectory() {
  -  return null;
  +  return dataDirectory;
  }
   
  /**
  -* @see CacheStoreMBean#setDataDirectory(String)
  +* Sets the DataDirectory attribute of the CacheStoreMBean object
  +*
  +* @param  newDataDirectory  The new DataDirectory value
  +*
  +* @see CacheStoreMBean#setDataDirectory
  +*
  +* @jmx:managed-attribute
   */
  public void setDataDirectory(String newDataDirectory) {
 dataDirectory = newDataDirectory;
  @@ -94,9 +109,8 @@
  protected void startService() throws Exception {
 boolean debug = log.isDebugEnabled();
   
  -  // Get the system home directory (may want to use dataDir or tempDir)
  -  File systemHomeDir = (File)
  - server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "ServerHomeDir");
  +  // Get the system home directory
  +  File systemHomeDir = ServerConfigLocator.locate().getServerHomeDir();
   
 dataDir = new File(systemHomeDir, dataDirectory);
 if (debug)
  
  
  
  1.22  +12 -5 jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java
  
  Index: PersistenceManager.java
  ===
  RCS file: 
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- PersistenceManager.java   9 Mar 2002 15:32:34 -   1.21
  +++ PersistenceManager.java   4 Apr 2002 04:35:06 -   1.22
  @@ -33,15 +33,19 @@
   import org.jboss.mq.server.PersistentQueue;
   import org.jboss.mq.server.MessageReference;
   import org.jboss.mq.server.MessageCache;
  +
   import org.jboss.system.ServiceMBeanSupport;
  -import org.jboss.system.server.ServerConfigImplMBean;
  +
  +import org.jboss.system.server.ServerConfigLocator;
   
   /**
* This class manages all persistence related services for file based
* persistence.
*
  + * @jmx:mbean extends="org.jboss.system.ServiceMBean, 
org.jboss.mq.pm.PersistenceManagerMBean"
  + *
* @author Paul Kendall ([EMAIL PROTECTED])
  - * @version$Revision: 1.21 $
  + * @version$Revision: 1.22 $
*/
   public class PersistenceManager
  extends ServiceMBeanSupport
  @@ -109,6 +113,8 @@
   *  Sets the DataDirectory attribute of the PersistenceManager object
   *
   * @param  newDataDirectory  The new DataDirectory value
  +*
  +* @jmx:managed-attribute
   */
  public void setDataDirectory(String newDataDirectory)
  {
  @@ -119,6 +125,8 @@
   *  Gets the DataDirectory attribute of the PersistenceManager object
   *
   * @returnThe DataDirectory value
  +*
  +* @jmx:managed-attribute
   */
  public String getDataDirectory()
  {
  @@ -141,9 +149,8 @@
   */
  public void startService() throws Exception
  {
  -  // Get the system home directory (may want to use dataDir)
  -  File systemHomeDir = (File)
  - server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "ServerHomeDir");
  +  // Get the system home directory
  +

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment/cache DeploymentCache.java FileDeploymentStore.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:33:58

  Modified:src/main/org/jboss/deployment/cache DeploymentCache.java
FileDeploymentStore.java
  Log:
   o Using @jmx:managed-attribute where appropriate
  
  Revision  ChangesPath
  1.2   +5 -5  
jboss-system/src/main/org/jboss/deployment/cache/DeploymentCache.java
  
  Index: DeploymentCache.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/cache/DeploymentCache.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DeploymentCache.java  3 Apr 2002 08:29:23 -   1.1
  +++ DeploymentCache.java  4 Apr 2002 04:33:58 -   1.2
  @@ -36,7 +36,7 @@
*
* @todo clean up stale cache members
*
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public class DeploymentCache
  @@ -58,7 +58,7 @@
  /
   
  /**
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public void setDeployer(final ObjectName deployerName)
  {
  @@ -70,7 +70,7 @@
  }
   
  /**
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public ObjectName getDeployer()
  {
  @@ -78,7 +78,7 @@
  }
   
  /**
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public void setStore(final ObjectName storeName)
  {
  @@ -90,7 +90,7 @@
  }
   
  /**
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public ObjectName getStore()
  {
  
  
  
  1.2   +5 -5  
jboss-system/src/main/org/jboss/deployment/cache/FileDeploymentStore.java
  
  Index: FileDeploymentStore.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/cache/FileDeploymentStore.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- FileDeploymentStore.java  3 Apr 2002 08:29:24 -   1.1
  +++ FileDeploymentStore.java  4 Apr 2002 04:33:58 -   1.2
  @@ -45,7 +45,7 @@
*
* @todo Validate the urlMap
*
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public class FileDeploymentStore
  @@ -68,7 +68,7 @@
   *
   * @throws IOExceptionFile not found, not a directory, can't write...
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public void setDirectory(File dir) throws IOException
  {
  @@ -113,7 +113,7 @@
   *
   * @return The local directory where cache data is stored.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public File getDirectory() {
 return this.dir;
  @@ -128,7 +128,7 @@
   *
   * @throws IOExceptionFile not found, not a directory, can't write...
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public void setDirectoryName(String dirname) throws IOException
  {
  @@ -143,7 +143,7 @@
   *
   * @return The name of the local directory where cache data is stored.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public String getDirectoryName() {
 return dir.getAbsolutePath();
  
  
  

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerConfig.java ServerConfigImpl.java ServerImpl.java ServerInfo.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:33:59

  Modified:src/main/org/jboss/system/server ServerConfig.java
ServerConfigImpl.java ServerImpl.java
ServerInfo.java
  Log:
   o Using @jmx:managed-attribute where appropriate
  
  Revision  ChangesPath
  1.7   +4 -1  jboss-system/src/main/org/jboss/system/server/ServerConfig.java
  
  Index: ServerConfig.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/server/ServerConfig.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ServerConfig.java 27 Feb 2002 09:24:26 -  1.6
  +++ ServerConfig.java 4 Apr 2002 04:33:59 -   1.7
  @@ -16,7 +16,10 @@
   /**
* The interface of the basic typed JBoss server configuration.
*
  - * @version $Revision: 1.6 $
  + * Clients should use {@link ServerConfigLocator} to get an instance of 
  + *{@link ServerConfig} and then use it to get the server's configuration bits.
  + *
  + * @version $Revision: 1.7 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public interface ServerConfig
  
  
  
  1.5   +20 -62
jboss-system/src/main/org/jboss/system/server/ServerConfigImpl.java
  
  Index: ServerConfigImpl.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/server/ServerConfigImpl.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ServerConfigImpl.java 4 Apr 2002 02:53:14 -   1.4
  +++ ServerConfigImpl.java 4 Apr 2002 04:33:59 -   1.5
  @@ -31,10 +31,14 @@
* Most values are determined durring first call to getter.  All values
*when determined will have equivilent system properties set.
*
  + * Clients are not meant to use this class directly.  Instead use
  + *{@link ServerConfigLocator} to get an instance of {@link ServerConfig}
  + *and then use it to get the server's configuration bits.
  + *
* @jmx:mbean name="jboss.system:type=ServerConfig"
*
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @version $Revision: 1.4 $
  + * @version $Revision: 1.5 $
*/
   public class ServerConfigImpl
  implements ServerConfig, ServerConfigImplMBean
  @@ -127,7 +131,7 @@
  /**
   * Get the local home directory which the server is running from.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public File getHomeDir() 
  {
  @@ -137,7 +141,7 @@
  /**
   * Get the home URL which the server is running from.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL getHomeURL()
  {
  @@ -147,7 +151,7 @@
  /**
   * Get the home URL which the server is running from.
   * 
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL getLibraryURL() 
  {
  @@ -169,7 +173,7 @@
  /**
   * Get the patch URL for the server.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL getPatchURL() 
  {
  @@ -197,7 +201,7 @@
  /**
   * Get the name of the server.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public String getServerName()
  {
  @@ -211,7 +215,7 @@
  /**
   * Get the base directory for calculating server home directories.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public File getServerBaseDir()
  {
  @@ -228,7 +232,7 @@
  /**
   * Get the server home directory.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public File getServerHomeDir() {
 if (serverHomeDir == null) {
  @@ -244,7 +248,7 @@
  /**
   * Get the directory where temporary files will be stored.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public File getServerTempDir()
  {
  @@ -261,7 +265,7 @@
  /**
   * Get the directory where local data will be stored.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public File getServerDataDir()
  {
  @@ -278,7 +282,7 @@
  /**
   * Get the base directory for calculating server home URLs.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL getServerBaseURL()
  {
  @@ -300,7 +304,7 @@
  /**
   * Get the server home URL.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL getServerHomeURL()
  {
  @@ -322,7 +326,7 @@
  /**
   * Get the server library URL.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL getServerLibraryURL()
  {
  @@ -344,7 +348,7 @@
  /**
 

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:34:26

  Modified:src/main/org/jboss/web AbstractWebContainer.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
  
  Revision  ChangesPath
  1.39  +5 -15 jboss/src/main/org/jboss/web/AbstractWebContainer.java
  
  Index: AbstractWebContainer.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- AbstractWebContainer.java 3 Apr 2002 08:25:18 -   1.38
  +++ AbstractWebContainer.java 4 Apr 2002 04:34:26 -   1.39
  @@ -59,7 +59,8 @@
   import org.jboss.naming.Util;
   import org.jboss.security.plugins.NullSecurityManager;
   import org.jboss.system.ServiceMBeanSupport;
  -import org.jboss.system.server.ServerConfigImplMBean;
  +
  +import org.jboss.system.server.ServerConfigLocator;
   
   /** A template pattern class for web container integration into JBoss. This class
   should be subclasses by web container providers wishing to integrate their
  @@ -151,7 +152,7 @@
   @see org.jboss.security.SecurityAssociation;
   
   @author  [EMAIL PROTECTED]
  -@version $Revision: 1.38 $
  +@version $Revision: 1.39 $
   */
   public abstract class AbstractWebContainer 
  extends SubDeployerSupport
  @@ -256,19 +257,8 @@
   
  public void parseWEBINFClasses(DeploymentInfo di) throws DeploymentException
  {
  -  File tmpDeployDir = null;
  -
  -  try
  -  {
  - File systemTmpDir = (File)
  -server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "TempDir");
  - tmpDeployDir = new File(systemTmpDir, "deploy");
  -  }
  -  catch (Exception e)
  -  {
  - // should never happen
  - throw new Error("Failed to get system temporary directory: " + e);
  -  }
  +  File systemTmpDir = ServerConfigLocator.locate().getServerTempDir();
  +  File tmpDeployDir = new File(systemTmpDir, "deploy");
 
 JarFile jarFile = null;
 // Do we have a jar file jar:!/..
  
  
  

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

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:33:59

  Modified:src/main/org/jboss/logging Log4jService.java
  Log:
   o Using @jmx:managed-attribute where appropriate
  
  Revision  ChangesPath
  1.6   +4 -4  jboss-system/src/main/org/jboss/logging/Log4jService.java
  
  Index: Log4jService.java
  ===
  RCS file: /cvsroot/jboss/jboss-system/src/main/org/jboss/logging/Log4jService.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Log4jService.java 4 Apr 2002 02:53:14 -   1.5
  +++ Log4jService.java 4 Apr 2002 04:33:59 -   1.6
  @@ -45,7 +45,7 @@
*
* @jmx:mbean name="jboss.system:type=Log4jService,service=Logging"
*
  - * @version $Revision: 1.5 $
  + * @version $Revision: 1.6 $
* @author mailto:[EMAIL PROTECTED]";>Fulco Muriglio
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>David Jencks
  @@ -130,7 +130,7 @@
  /**
   * Get the refresh period.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public int getRefreshPeriod()
  {
  @@ -140,7 +140,7 @@
  /**
   * Get the path to the Log4j configuration file.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public String getConfigurationPath()
  {
  @@ -150,7 +150,7 @@
  /**
   * Set the path to the Log4j configuration file.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public void setConfigurationPath(String path)
  {
  
  
  

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

[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/mbean TestDeployer.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:33:30

  Modified:src/main/org/jboss/test/jmx/mbean TestDeployer.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
  
  Revision  ChangesPath
  1.6   +3 -4  jbosstest/src/main/org/jboss/test/jmx/mbean/TestDeployer.java
  
  Index: TestDeployer.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/mbean/TestDeployer.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- TestDeployer.java 27 Feb 2002 09:24:27 -  1.5
  +++ TestDeployer.java 4 Apr 2002 04:33:29 -   1.6
  @@ -21,13 +21,13 @@
   import org.jboss.system.Service;
   import org.jboss.system.ServiceMBeanSupport;
   
  -import org.jboss.system.server.ServerConfigImplMBean;
  +import org.jboss.system.server.ServerConfigLocator;
   
   /**
* This is a do-nothing mbean to test service archive deployment.
*
* @author mailto:[EMAIL PROTECTED]";>David Jencks
  - * @version $Revision: 1.5 $
  + * @version $Revision: 1.6 $
*
* 20010901 david jencks
* 
  @@ -40,8 +40,7 @@
   {
  public String getBaseDir() throws Exception
  {
  -  File file = (File)
  - server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "ServerHomeDir");
  +  File file = ServerConfigLocator.locate().getServerHomeDir();
   
 return file.getCanonicalPath();
  }
  
  
  

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

[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/jdbc HypersonicDatabase.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:33:08

  Modified:varia/src/main/org/jboss/jdbc HypersonicDatabase.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
  
  Revision  ChangesPath
  1.15  +5 -5  contrib/varia/src/main/org/jboss/jdbc/HypersonicDatabase.java
  
  Index: HypersonicDatabase.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/varia/src/main/org/jboss/jdbc/HypersonicDatabase.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- HypersonicDatabase.java   24 Feb 2002 10:24:35 -  1.14
  +++ HypersonicDatabase.java   4 Apr 2002 04:33:08 -   1.15
  @@ -18,7 +18,8 @@
   import javax.management.*;
   
   import org.jboss.system.ServiceMBeanSupport;
  -import org.jboss.system.server.ServerConfigImplMBean;
  +import org.jboss.system.server.ServerConfigLocator;
  +
   import org.jboss.logging.Logger;
   
   // our patched HSQLDB Server class
  @@ -36,7 +37,7 @@
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
* @author mailto:[EMAIL PROTECTED]";>Peter Fagerlund
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @version $Revision: 1.14 $
  + * @version $Revision: 1.15 $
*/
   public class HypersonicDatabase 
  extends ServiceMBeanSupport 
  @@ -126,9 +127,8 @@
   
  protected void startService() throws Exception {
 // Get the server data directory
  -  File dataDir = (File)
  - server.getAttribute(ServerConfigImplMBean.OBJECT_NAME, "DataDir");
  -  
  +  File dataDir = ServerConfigLocator.locate().getServerDataDir();
  +
 // Get DB directory
 dbPath = new File(dataDir, "hypersonic");
 if (!dbPath.exists()) {
  
  
  

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

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:32:35

  Modified:.build.xml
  Log:
   o testsuite needs ServerConfig & friends
  
  Revision  ChangesPath
  1.13  +4 -1  jboss-system/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jboss-system/build.xml,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- build.xml 3 Apr 2002 08:21:08 -   1.12
  +++ build.xml 4 Apr 2002 04:32:35 -   1.13
  @@ -12,7 +12,7 @@
   
   
   
  -
  +
   
   
   
  @@ -406,6 +406,9 @@



  + 
  + 
  + 
 
   
   
  
  
  

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment/scanner AbstractDeploymentScanner.java DeploymentScanner.java URLDeploymentScanner.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:33:59

  Modified:src/main/org/jboss/deployment/scanner
AbstractDeploymentScanner.java
DeploymentScanner.java URLDeploymentScanner.java
  Log:
   o Using @jmx:managed-attribute where appropriate
  
  Revision  ChangesPath
  1.5   +1 -3  
jboss-system/src/main/org/jboss/deployment/scanner/AbstractDeploymentScanner.java
  
  Index: AbstractDeploymentScanner.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/scanner/AbstractDeploymentScanner.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- AbstractDeploymentScanner.java3 Apr 2002 08:22:51 -   1.4
  +++ AbstractDeploymentScanner.java4 Apr 2002 04:33:59 -   1.5
  @@ -32,8 +32,6 @@
   import org.jboss.deployment.DeploymentException;
   import org.jboss.deployment.Deployer;
   
  -import org.jboss.system.server.ServerConfigImplMBean;
  -
   import org.jboss.logging.Logger;
   
   import org.jboss.util.NullArgumentException;
  @@ -50,7 +48,7 @@
*
* Sub-classes only need to implement {@link DeploymentScanner#scan}.
*
  - * @version $Revision: 1.4 $
  + * @version $Revision: 1.5 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public abstract class AbstractDeploymentScanner
  
  
  
  1.4   +6 -6  
jboss-system/src/main/org/jboss/deployment/scanner/DeploymentScanner.java
  
  Index: DeploymentScanner.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/scanner/DeploymentScanner.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DeploymentScanner.java3 Apr 2002 08:22:51 -   1.3
  +++ DeploymentScanner.java4 Apr 2002 04:33:59 -   1.4
  @@ -21,7 +21,7 @@
*
* @jmx:mbean extends="org.jboss.system.ServiceMBean"
*
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public interface DeploymentScanner
  @@ -32,7 +32,7 @@
   *
   * @param deployerNameThe object name of the deployer to use.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  void setDeployer(ObjectName deployerName);
   
  @@ -41,7 +41,7 @@
   *
   * @returnThe object name of the deployer we are using.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  ObjectName getDeployer();
   
  @@ -52,7 +52,7 @@
   *
   * @throws IllegalArgumentExceptionPeriod value out of range.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  void setScanPeriod(long period);
   
  @@ -72,7 +72,7 @@
   * @param flagTrue to enable or false to disable period
   *based scanning.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  void setScanEnabled(boolean flag);
   
  @@ -81,7 +81,7 @@
   *
   * @returnTrue if enabled, false if disabled.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  boolean isScanEnabled();
   
  
  
  
  1.8   +4 -4  
jboss-system/src/main/org/jboss/deployment/scanner/URLDeploymentScanner.java
  
  Index: URLDeploymentScanner.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/scanner/URLDeploymentScanner.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- URLDeploymentScanner.java 2 Apr 2002 05:10:05 -   1.7
  +++ URLDeploymentScanner.java 4 Apr 2002 04:33:59 -   1.8
  @@ -40,7 +40,7 @@
*
* @jmx:mbean extends="org.jboss.deployment.scanner.DeploymentScannerMBean"
*
  - * @version $Revision: 1.7 $
  + * @version $Revision: 1.8 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public class URLDeploymentScanner
  @@ -60,7 +60,7 @@
  protected DeploymentSorter sorter = new DeploymentSorter();
   
  /**
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public void setURLList(final List list)
  {
  @@ -87,7 +87,7 @@
  }
   
  /**
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public List getURLList()
  {
  @@ -140,7 +140,7 @@
  /
   
  /**
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public void setURLs(final String listspec) throws MalformedURLException
  {
  
  
  

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

[JBoss-dev] CVS update: jbossmq build.xml

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:35:06

  Modified:.build.xml
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
   o Using XDoclet to generate some *MBean interfaces
  
  Revision  ChangesPath
  1.28  +34 -2 jbossmq/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jbossmq/build.xml,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- build.xml 23 Mar 2002 21:11:01 -  1.27
  +++ build.xml 4 Apr 2002 04:35:06 -   1.28
  @@ -12,7 +12,7 @@
   
   
   
  -
  +
   
   
   
  @@ -221,6 +221,7 @@
   
   
   
  +
   
   
   
  @@ -262,6 +263,19 @@

   
   
  +
  +
  +
  +  
  +  
  +  
  +
  +
  +
  +
 
   
   
  @@ -277,9 +291,26 @@
|  documentation compiles.
   -->
 
   
  +  
  +  
  +
  +
  +
  +
  +  
  +
  +
  +  
  +  
  +
  +  
  +
 
 
   
  @@ -343,6 +374,7 @@
   includeJavaRuntime="${javac.include.java.runtime}"
   failonerror="${javac.fail.onerror}">
  
  +   
  
  
  
  
  
  

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

Re: [JBoss-dev] Todo: multiple instances detection

[Jason Dillon]

Couldn't the refs reattache to the invoker via JNDI, leaving them free 
to use random ports... only JNDI would need a static port number then... 
or am I missing something?

--jason


Bill Burke wrote:

>Maybe the invokers should run on a hard-coded port.  With a hard-coded port,
>I think references can live beyond the life of the server.  Or maybe I don't
>know what I'm talking about :)
>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
>>Dillon
>>Sent: Wednesday, April 03, 2002 4:49 PM
>>To: marc fleury
>>Cc: Jboss-Development@Lists. Sourceforge. Net
>>Subject: Re: [JBoss-dev] Todo: multiple instances detection
>>
>>
>>Not sure that an external component is the best choice for this... but I
>>have not really thought it through.
>>
>>On a related note, I sent mail a while ago asking about the web service
>>for class loading wtr having it use an anonymous port.  If we set the
>>default RMI port to anonymous too, then we only have naming,
>>jmx-html-adapter and web ports to deal with.  Once the jmx-html-adapter
>>is a .war, then we only have naming and web.
>>
>>Does anyone know if it is possible to setup on public port, which then
>>attaches to other anonymous/random ports, switching based on the
>>content.  This would make it look to clients like there was only one
>>port, but really there could be many, but the actual numer would
>>not matter.
>>
>>Something like this could (assuming it is possible) would make it easy
>>to integrate thirdparty plugins into the single port scheme which simply
>>need a port, with out them having to know about a special component or
>>conform to a specific api to select a random port or whatever...
>>
>>--jason
>>
>>
>>marc fleury wrote:
>>
>>>there should be a service that is part of the first services
>>>
>>coming up and
>>
>>>that detects if other JBoss systems are running on the same physical
>>>machines, this is to avoid port conflict as some services are
>>>
>>holding on to
>>
>>>some ports (e.g. naming on 1099, detached RMI, clustered RMI).
>>>
>>>We would then not start the naming as a duplicate nor the
>>>
>>detached RMI but
>>
>>>we would use the clustered RMI by increasing the connection port.
>>>
>>>This will enable people to run multiple instances of JBoss
>>>
>>without having to
>>
>>>manually change the stuff all the time.  At least on the
>>>
>>services we provide
>>
>>>we should show how these behave.
>>>
>>>marcf
>>>
>>>
>>>___
>>>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/ejb/plugins StatefulSessionFilePersistenceManager.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:34:25

  Modified:src/main/org/jboss/ejb/plugins
StatefulSessionFilePersistenceManager.java
  Log:
   o Using ServerConfigLocator instead of ServerConfigImplMBean
  
  Revision  ChangesPath
  1.35  +5 -4  
jboss/src/main/org/jboss/ejb/plugins/StatefulSessionFilePersistenceManager.java
  
  Index: StatefulSessionFilePersistenceManager.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/StatefulSessionFilePersistenceManager.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- StatefulSessionFilePersistenceManager.java5 Mar 2002 18:41:48 -  
 1.34
  +++ StatefulSessionFilePersistenceManager.java4 Apr 2002 04:34:25 -  
 1.35
  @@ -36,7 +36,9 @@
   import org.jboss.ejb.StatefulSessionPersistenceManager;
   import org.jboss.ejb.StatefulSessionEnterpriseContext;
   import org.jboss.logging.Logger;
  -import org.jboss.system.server.ServerConfigImplMBean;
  +
  +import org.jboss.system.server.ServerConfigLocator;
  +
   import org.jboss.util.jmx.MBeanServerLocator;
   
   /**
  @@ -47,7 +49,7 @@
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
  - * @version $Revision: 1.34 $
  + * @version $Revision: 1.35 $
*/
   public class StatefulSessionFilePersistenceManager
  implements StatefulSessionPersistenceManager
  @@ -89,8 +91,7 @@
 String ejbName = con.getBeanMetaData().getEjbName();
   
 // Get the system data directory
  -  File systemDataDir = (File)
  - 
MBeanServerLocator.locate().getAttribute(ServerConfigImplMBean.OBJECT_NAME, "DataDir");
  +  File systemDataDir = ServerConfigLocator.locate().getServerDataDir();
   
 // Gte a handle on the sysdata/sessions/ejbname directory
 dataDir = new File(new File(systemDataDir, "sessions"), ejbName);
  
  
  

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system ServiceController.java ServiceLibraries.java UnifiedClassLoader.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 20:33:59

  Modified:src/main/org/jboss/system ServiceController.java
ServiceLibraries.java UnifiedClassLoader.java
  Log:
   o Using @jmx:managed-attribute where appropriate
  
  Revision  ChangesPath
  1.7   +1 -6  jboss-system/src/main/org/jboss/system/ServiceController.java
  
  Index: ServiceController.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/ServiceController.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ServiceController.java4 Apr 2002 02:17:22 -   1.6
  +++ ServiceController.java4 Apr 2002 04:33:59 -   1.7
  @@ -9,11 +9,6 @@
   
   package org.jboss.system;
   
  -
  -
  -
  -
  -
   import java.lang.reflect.InvocationHandler;
   import java.lang.reflect.Method;
   import java.lang.reflect.Proxy;
  @@ -53,7 +48,7 @@
* 
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>David Jencks
  - * @version $Revision: 1.6 $ 
  + * @version $Revision: 1.7 $ 
*
* Revisions: 
*
  
  
  
  1.5   +2 -5  jboss-system/src/main/org/jboss/system/ServiceLibraries.java
  
  Index: ServiceLibraries.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/ServiceLibraries.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ServiceLibraries.java 4 Apr 2002 02:53:14 -   1.4
  +++ ServiceLibraries.java 4 Apr 2002 04:33:59 -   1.5
  @@ -9,9 +9,6 @@
   
   package org.jboss.system;
   
  -
  -
  -
   import java.net.URL;
   import java.util.Collection;
   import java.util.HashMap;
  @@ -38,7 +35,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
  - * @version $Revision: 1.4 $
  + * @version $Revision: 1.5 $
*
* 20010830 marc fleury:
* 
  @@ -491,7 +488,7 @@
   * Obtain a listing of the URL for all UnifiedClassLoaders associated with
   * the ServiceLibraries
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL[] getURLs()
  {
  
  
  
  1.4   +2 -2  jboss-system/src/main/org/jboss/system/UnifiedClassLoader.java
  
  Index: UnifiedClassLoader.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/UnifiedClassLoader.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- UnifiedClassLoader.java   4 Apr 2002 02:53:14 -   1.3
  +++ UnifiedClassLoader.java   4 Apr 2002 04:33:59 -   1.4
  @@ -26,7 +26,7 @@
* @author Marc Fleury
* @author Christoph G. Jung
* @author Scott Stark/a>
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
*
* 20010830 marc fleury:
* 
  @@ -129,7 +129,7 @@
  /**
   * Returns the single URL for this UCL.
   *
  -* @jmx:managed-operation
  +* @jmx:managed-attribute
   */
  public URL getURL() {
 return url;
  
  
  

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

[JBoss-dev] Automated JBoss Testsuite Results: 4-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   567



Successful tests:  540

Errors:19

Failures:  8





[time of test: 4 April 2002 5:7 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-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

Re: [JBoss-dev] AutoNumber in Jboss 3.0.0

[Jason Dillon]

This is back in the build again.

--jason


Jessica Perry Hekman wrote:

>On Wed, 3 Apr 2002, Dain Sundstrom wrote:
>
>>I wasn't aware of this.  Are you sure it was removed?  If you are having
>>problems, post again, and I'll ask around.
>>
>
>I looked in the build.xml file; it is definitely not there (in varia or
>otherwise).
>
>j
>
>---
>  "Users complain that they receive too much spam, while spammers protest
>messages are legal." -InfoWorld
>  "You do not have to do everything disagreeable that you have a right to
>do." -Judith Martin (Miss Manners)
>
>
>
>
>___
>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] Never mind

[Jason Dillon]

Ahh... I am loosing my mind sorry for the noise.

--jason


Jason Dillon wrote:

> found it
>
> --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] XDoclet... I love you

[Andreas Schaefer]

Later on we maybe can change the JavaDoc therefore it transfor
these two tags in the layout Marc initially wanted.

Andy

- Original Message -
From: "David Jencks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 03, 2002 7:13 PM
Subject: Re: [JBoss-dev] XDoclet... I love you


> We could certainly use this format for changelog crap, and since noone
uses
> it for anything we don't need an xdoclet task to process it.  I definitely
> agree it looks better than the incorrect html.
>
> david jencks
>
> On 2002.04.03 21:42:30 -0500 Jason Dillon wrote:
> > >
> > >
> > >I don't understand what you want to have generated, nor why.  Could you
> > be
> > >more specific?  xdoclet can't modify the contents of a java file, it
can
> > >only generate new files.
> > >
> >
> > I know it can't modify the file... basically I think that it would be
> > easier and more consistent to code these changelog-like things as:
> >
> > @change   20010830 marc fleury
> > @change-infoInitial import
> >
> > >Personally I think these "I messed with it in this way" historical
> > comments
> > >are a _really_ bad idea, and duplicate badly something cvs does well.
I
> > >prefer the comments to explain clearly only the current functionality
of
> > >the class.
> > >
> >
> > I agree completely.  Unfortunatly some people (well ok one person)
> > thinks differently.  Perhaps we can convince them otherwise.
> >
> > I would much rather these go away, but if the don't go away, a
> > consistent manner for writting them seem appropriate.  I have already
> > had to correct many of the imporper html usage... so I was thinking if
> > we didn't use html to give it structure it would be easier to keep
> > consistent.
> >
> > --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
>
>



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

[JBoss-dev] Never mind

[Jason Dillon]

found it

--jason


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

RE: [JBoss-dev] JBoss.net/IIOP and JBossMX integration

[Francisco Reverbel]

Hi Claudio,

Thanks for running the tests on NT!

On Wed, 3 Apr 2002, Vesco Claudio wrote:

> I have checked the iiop implementation with sun jdk 1.4 (windows NT)...
> 
> If I start jboss with:
> 
> JAVA_OPTS="-Dpolicy.expandProperties=false
> -Xbootclasspath/p:$JBOSS_HOME/lib/jacorb.jar"
> 
> I don't have problems in deploy.

Good.

> If I don't prepend jacorb.jar to the bootclasspath, I have this exception in
> deploy:
> ... (stacktrace omitted)

Yes, I also see this. The JacORB library must be prepended to the
bootclasspath. 

> When I run the testsuite I have this exceptions with helloiiop (client
> side):
> 
> java.lang.ClassCastException
>   at
> com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemo
> teObject.java:293)
>   at
> javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134) 
>   at
> org.jboss.test.helloiiop.test.HelloTimingStressTestCase.testData(HelloTiming
> StressTestCase.java:74) 

On Linux I don't get this exception... I wonder if there is something special
in my environment...

> PS:
> 
> policy.expandProperties=false is needed because I have an exception when I
> try to run jboss (jboss does not start). This problem is explained some days
> before in mailing list

Yes.

> prepending jacorb.jar in classpath permit to deploy a ejb module with an
> iiop invoker.

Yes.

> PS2: I'll try the iiop at home with linux and sun jdk 1.4...

Please do it! I am starting to feel uneasy about my test environment.
It would be good to know if iiop works (or not) elsewhere.

Cheers,

Francisco



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

Re: [JBoss-dev] XDoclet... I love you

[David Jencks]

We could certainly use this format for changelog crap, and since noone uses
it for anything we don't need an xdoclet task to process it.  I definitely
agree it looks better than the incorrect html.

david jencks

On 2002.04.03 21:42:30 -0500 Jason Dillon wrote:
> >
> >
> >I don't understand what you want to have generated, nor why.  Could you
> be
> >more specific?  xdoclet can't modify the contents of a java file, it can
> >only generate new files.
> >
> 
> I know it can't modify the file... basically I think that it would be 
> easier and more consistent to code these changelog-like things as:
> 
> @change   20010830 marc fleury
> @change-infoInitial import
> 
> >Personally I think these "I messed with it in this way" historical
> comments
> >are a _really_ bad idea, and duplicate badly something cvs does well.  I
> >prefer the comments to explain clearly only the current functionality of
> >the class.
> >
> 
> I agree completely.  Unfortunatly some people (well ok one person) 
> thinks differently.  Perhaps we can convince them otherwise.
> 
> I would much rather these go away, but if the don't go away, a 
> consistent manner for writting them seem appropriate.  I have already 
> had to correct many of the imporper html usage... so I was thinking if 
> we didn't use html to give it structure it would be easier to keep 
> consistent.
> 
> --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] Cannot start Tomcat with JBoss option

[Prasad Bijur]

I had JVM 1.2.2. It works now after setting it to
1.3.1.

Thanks a ton,
Prasad


--- Jeff Tulley <[EMAIL PROTECTED]> wrote:
> This is a user question, not a development question.
>  I'll answer it in
> a user forum for you.
> How about the "Installation and Configuration"
> forum, 
> http://main.jboss.org/forum.jsp?forum=61
> 
> Actually, the forums are not working for me for some
> reason.  (Keeps
> insisting that I do not have rights to post a
> message, and making me log
> in again, never gets past that, even though my
> username and password are
> valid)...
> 
> I guess I'll answer here. 
> 
> You probably are running on an older JVM, one that
> does not have the
> Runtime.addShutdownHook method.  Make sure that the
> JVM that you are
> using is 1.3 or higher.  Even if you have both JVM's
> installed, maybe
> for some reason the default one is not set to 1.3. 
> Check that.
> 
> 
> Anybody know why the forums are broken???
> 
> Jeff Tulley  ([EMAIL PROTECTED])
> (801)861-5322
> Novell, Inc., the leading provider of Net business
> solutions
> http://www.novell.com
> 
> >>> Prasad Bijur <[EMAIL PROTECTED]> 4/3/02
> 6:55:35 AM >>>
> Hi,
> 
> I am new to JBoss and am trying it out for the first
> time. I downloaded the
> 'JBoss-2.4.4_Tomcat-4.0.1.zip'
> installation file and extracted it to a local
> folder.
> I go to the 'JBoss/bin' folder and issue the command
> 'run_with_catalina'. I get the following errors:
> 
> java.lang.NoSuchMethorError: addShutdownHook
> and
> java.lang.NoClassDefFoundError:
> java.lang.reflect.InvocationHandler
> 
> I have not done any setting after extracting the zip
> file. I just gave this command. This was suggested
> in
> JBoss site. Is there any setting I need to do before
> starting. Same errors with run.bat. I am working on
> Windows NT.
> 
> Any help is highly appreciated.
> 
> Regards,
> Prasad
> 
> __
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/ 
> 
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED] 
>
https://lists.sourceforge.net/lists/listinfo/jboss-development


__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerConfigImpl.java ServerImpl.java ServerInfo.java ServerConfigImplMBean.java ServerImplMBean.java ServerInfoMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 18:53:14

  Modified:src/main/org/jboss/system/server ServerConfigImpl.java
ServerImpl.java ServerInfo.java
  Removed: src/main/org/jboss/system/server ServerConfigImplMBean.java
ServerImplMBean.java ServerInfoMBean.java
  Log:
   o Using XDoclet to generate *MBean interfaces
  
  Revision  ChangesPath
  1.4   +92 -1 
jboss-system/src/main/org/jboss/system/server/ServerConfigImpl.java
  
  Index: ServerConfigImpl.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/server/ServerConfigImpl.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ServerConfigImpl.java 27 Feb 2002 09:24:26 -  1.3
  +++ ServerConfigImpl.java 4 Apr 2002 02:53:14 -   1.4
  @@ -31,8 +31,10 @@
* Most values are determined durring first call to getter.  All values
*when determined will have equivilent system properties set.
*
  + * @jmx:mbean name="jboss.system:type=ServerConfig"
  + *
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
*/
   public class ServerConfigImpl
  implements ServerConfig, ServerConfigImplMBean
  @@ -122,16 +124,31 @@
  // Typed Access//
  /
   
  +   /**
  +* Get the local home directory which the server is running from.
  +*
  +* @jmx:managed-operation
  +*/
  public File getHomeDir() 
  {
 return homeDir;
  }
   
  +   /**
  +* Get the home URL which the server is running from.
  +*
  +* @jmx:managed-operation
  +*/
  public URL getHomeURL()
  {
 return homeURL;
  }
   
  +   /**
  +* Get the home URL which the server is running from.
  +* 
  +* @jmx:managed-operation
  +*/
  public URL getLibraryURL() 
  {
 if (libraryURL == null) {
  @@ -149,6 +166,11 @@
 return libraryURL;
  }
   
  +   /**
  +* Get the patch URL for the server.
  +*
  +* @jmx:managed-operation
  +*/
  public URL getPatchURL() 
  {
 if (patchURL == null) {
  @@ -172,6 +194,11 @@
 return (URL)patchURL;
  }
   
  +   /**
  +* Get the name of the server.
  +*
  +* @jmx:managed-operation
  +*/
  public String getServerName()
  {
 if (serverName == null) {
  @@ -181,6 +208,11 @@
 return serverName;
  }
   
  +   /**
  +* Get the base directory for calculating server home directories.
  +*
  +* @jmx:managed-operation
  +*/
  public File getServerBaseDir()
  {
 if (serverBaseDir == null) {
  @@ -193,6 +225,11 @@
 return serverBaseDir;
  }
   
  +   /**
  +* Get the server home directory.
  +*
  +* @jmx:managed-operation
  +*/
  public File getServerHomeDir() {
 if (serverHomeDir == null) {
serverHomeDir = getFile(ServerConfig.SERVER_HOME_DIR);
  @@ -204,6 +241,11 @@
 return serverHomeDir;
  }
   
  +   /**
  +* Get the directory where temporary files will be stored.
  +*
  +* @jmx:managed-operation
  +*/
  public File getServerTempDir()
  {
 if (serverTempDir == null) {
  @@ -216,6 +258,11 @@
 return serverTempDir;
  }
   
  +   /**
  +* Get the directory where local data will be stored.
  +*
  +* @jmx:managed-operation
  +*/
  public File getServerDataDir()
  {
 if (serverDataDir == null) {
  @@ -228,6 +275,11 @@
 return serverDataDir;
  }
   
  +   /**
  +* Get the base directory for calculating server home URLs.
  +*
  +* @jmx:managed-operation
  +*/
  public URL getServerBaseURL()
  {
 if (serverBaseURL == null) {
  @@ -245,6 +297,11 @@
 return serverBaseURL;
  }
   
  +   /**
  +* Get the server home URL.
  +*
  +* @jmx:managed-operation
  +*/
  public URL getServerHomeURL()
  {
 if (serverHomeURL == null) {
  @@ -262,6 +319,11 @@
 return serverHomeURL;
  }
   
  +   /**
  +* Get the server library URL.
  +*
  +* @jmx:managed-operation
  +*/
  public URL getServerLibraryURL()
  {
 if (serverLibraryURL == null) {
  @@ -279,6 +341,11 @@
 return serverLibraryURL;
  }
   
  +   /**
  +* Get the server configuration URL.
  +*
  +* @jmx:managed-operation
  +*/
  public URL getServerConfigURL()
  {
 if (serverConfigURL == null) {
  @@ -296,6 +363,15 @@
 return serverConfigURL;
  }
   
  +   /**
  +* Enable or disable exiting the JVM when {@link Server#shutdown} is called.
  +* If enabled, then shutdown calls {@link Ser

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system MBeanClassLoader.java ServiceLibraries.java UnifiedClassLoader.java MBeanClassLoaderMBean.java ServiceLibrariesMBean.java UnifiedClassLoaderMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 18:53:14

  Modified:src/main/org/jboss/system MBeanClassLoader.java
ServiceLibraries.java UnifiedClassLoader.java
  Removed: src/main/org/jboss/system MBeanClassLoaderMBean.java
ServiceLibrariesMBean.java
UnifiedClassLoaderMBean.java
  Log:
   o Using XDoclet to generate *MBean interfaces
  
  Revision  ChangesPath
  1.2   +3 -1  jboss-system/src/main/org/jboss/system/MBeanClassLoader.java
  
  Index: MBeanClassLoader.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/MBeanClassLoader.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- MBeanClassLoader.java 24 Feb 2002 10:24:34 -  1.1
  +++ MBeanClassLoader.java 4 Apr 2002 02:53:14 -   1.2
  @@ -18,9 +18,11 @@
   
   /**
* The pupose of MBeanCL is to load the classes on behalf of an MBean.
  + *
  + * @jmx:mbean
* 
* @author Marc Fleury
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
*
* 20010830 marc fleury:
* 
  
  
  
  1.4   +18 -21jboss-system/src/main/org/jboss/system/ServiceLibraries.java
  
  Index: ServiceLibraries.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/ServiceLibraries.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ServiceLibraries.java 4 Apr 2002 02:17:22 -   1.3
  +++ ServiceLibraries.java 4 Apr 2002 02:53:14 -   1.4
  @@ -34,10 +34,11 @@
* Service Libraries. The service libraries is a central repository of all
* classes loaded by the ClassLoaders
*
  - * @see 
  + * @jmx:mbean name="jboss.system:service=Libraries"
  + *
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
  - * @version $Revision: 1.3 $ 
  + * @version $Revision: 1.4 $
*
* 20010830 marc fleury:
* 
  @@ -71,14 +72,8 @@
  /** Class logger */
  private static final Logger log = Logger.getLogger(ServiceLibraries.class);
  
  -   // Static 
  -
  private static ServiceLibraries libraries;
  
  -   // Constants -
  -   
  -   // Attributes 
  -   
  private long sequenceId = 0;
   
  /**
  @@ -131,10 +126,6 @@
   
  private MBeanNotificationInfo[] info;
  
  -   // Constructors --
  -   
  -   // Public 
  -   
  /**
   * Gets the Libraries attribute of the ServiceLibraries class
   *
  @@ -458,10 +449,12 @@
 throw new ClassNotFoundException(name);
  }
   
  -   /** Iterates through the current class loaders and tries to find the
  -   given class name.
  -   @return the Class object for name if found, null otherwise.
  -   */
  +   /** 
  +* Iterates through the current class loaders and tries to find the
  +* given class name.
  +*
  +* @return the Class object for name if found, null otherwise.
  +*/
  public Class findClass(String name)
  {
 Class clazz = null;
  @@ -494,8 +487,11 @@
 return clazz;
  }
   
  -   /** Obtain a listing of the URL for all UnifiedClassLoaders associated with
  -*the ServiceLibraries
  +   /** 
  +* Obtain a listing of the URL for all UnifiedClassLoaders associated with
  +* the ServiceLibraries
  +*
  +* @jmx:managed-operation
   */
  public URL[] getURLs()
  {
  @@ -534,10 +530,11 @@
  /** 
   * Pre-register this component.
   * 
  -* @param serverThe server which the component is registering with.
  -* @param name  The configured name of the object.
  +* @param serverThe server which the component is registering with.
  +* @param name  The configured name of the object.
  +* @return  The name to register the object as.
  +*
   * @throws ExceptionPre-registration failed
  -* @return  The name to register the object as.
   */   
  public ObjectName preRegister(MBeanServer server, ObjectName name)
 throws Exception
  
  
  
  1.3   +6 -2  jboss-system/src/main/org/jboss/system/UnifiedClassLoader.java
  
  Index: UnifiedClassLoader.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/UnifiedClassLoader.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- UnifiedClassLoader.java   19 Mar 2002 22:24:30 -  1.2
  +++ UnifiedClassLoader.java   4 Apr 2

[JBoss-dev] Automated JBoss Testsuite Results: 4-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   567



Successful tests:  538

Errors:20

Failures:  9





[time of test: 4 April 2002 3:48 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1-02a-FCS]
[java.vm.name: Classic VM]
[java.vm.info: green threads, nojit]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

Re: [JBoss-dev] XDoclet... I love you

[Jason Dillon]

>
>
>I don't understand what you want to have generated, nor why.  Could you be
>more specific?  xdoclet can't modify the contents of a java file, it can
>only generate new files.
>

I know it can't modify the file... basically I think that it would be 
easier and more consistent to code these changelog-like things as:

@change   20010830 marc fleury
@change-infoInitial import

>Personally I think these "I messed with it in this way" historical comments
>are a _really_ bad idea, and duplicate badly something cvs does well.  I
>prefer the comments to explain clearly only the current functionality of
>the class.
>

I agree completely.  Unfortunatly some people (well ok one person) 
thinks differently.  Perhaps we can convince them otherwise.

I would much rather these go away, but if the don't go away, a 
consistent manner for writting them seem appropriate.  I have already 
had to correct many of the imporper html usage... so I was thinking if 
we didn't use html to give it structure it would be easier to keep 
consistent.

--jason



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

[JBoss-dev] Beta2 ?

[Jason Dillon]

Any thoughts on releasing a beta2 ?

I am thinking that the current code base is fairly near complete, but we 
did change the jmx impl... which is kind of a large change.   How about 
releasing a beta2 now (next few days), then work on minor tweaks, 
performance improvements and docs for a few weeks, then release an RC?

Also... is it timer for a 3.0 branch?  So that we can continue on with 
3.1 development changes.

--jason


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

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 18:53:14

  Modified:src/main/org/jboss/logging Log4jService.java
  Removed: src/main/org/jboss/logging Log4jServiceMBean.java
  Log:
   o Using XDoclet to generate *MBean interfaces
  
  Revision  ChangesPath
  1.5   +21 -3 jboss-system/src/main/org/jboss/logging/Log4jService.java
  
  Index: Log4jService.java
  ===
  RCS file: /cvsroot/jboss/jboss-system/src/main/org/jboss/logging/Log4jService.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Log4jService.java 5 Mar 2002 03:45:46 -   1.4
  +++ Log4jService.java 4 Apr 2002 02:53:14 -   1.5
  @@ -43,7 +43,9 @@
* Installs CategoryStream adapters for System.out and System.err
*to catch and redirect calls to Log4j.
*
  - * @version $Revision: 1.4 $
  + * @jmx:mbean name="jboss.system:type=Log4jService,service=Logging"
  + *
  + * @version $Revision: 1.5 $
* @author mailto:[EMAIL PROTECTED]";>Fulco Muriglio
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>David Jencks
  @@ -125,13 +127,20 @@
 this.refreshPeriod = refreshPeriod;
  }
   
  +   /**
  +* Get the refresh period.
  +*
  +* @jmx:managed-operation
  +*/
  public int getRefreshPeriod()
  {
 return refreshPeriod;
  }
  
  /**
  -* Get the log4j.properties format config file path
  +* Get the path to the Log4j configuration file.
  +*
  +* @jmx:managed-operation
   */
  public String getConfigurationPath()
  {
  @@ -139,7 +148,9 @@
  }
  
  /**
  -* Set the log4j.properties format config file path
  +* Set the path to the Log4j configuration file.
  +*
  +* @jmx:managed-operation
   */
  public void setConfigurationPath(String path)
  {
  @@ -152,6 +163,8 @@
   * throws a FileNotFoundException exception if the current
   * configurationPath cannot be located to avoid interaction problems
   * between the log4j framework and the JBoss ConsoleLogging service.
  +*
  +* @jmx:managed-operation
   */
  public void start() throws Exception
  {
  @@ -225,6 +238,8 @@
   * Stops the log4j framework by calling the Category.shutdown() method.
   * 
   * @see org.apache.log4j.Category#shutdown()
  +*
  +* @jmx:managed-operation
   */
  public void stop()
  {
  @@ -258,14 +273,17 @@
  
  public void postRegister(Boolean b)
  {
  +  // empty
  }
  
  public void preDeregister()
  {
  +  // empty
  }
  
  public void postDeregister()
  {
  +  // empty
  }
  
  // --- End MBeanRegistration interface methods
  
  
  

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

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 18:34:35

  Modified:src/resources/idgen/META-INF ejb-jar.xml
  Log:
   o forgot to change the dd
  
  Revision  ChangesPath
  1.3   +1 -1  jbosstest/src/resources/idgen/META-INF/ejb-jar.xml
  
  Index: ejb-jar.xml
  ===
  RCS file: /cvsroot/jboss/jbosstest/src/resources/idgen/META-INF/ejb-jar.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ejb-jar.xml   7 May 2001 20:44:28 -   1.2
  +++ ejb-jar.xml   4 Apr 2002 02:34:35 -   1.3
  @@ -37,7 +37,7 @@


  Counter value
  -   current
  +   currentValue

 
   size
  
  
  

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

Re: [JBoss-dev] XDoclet... I love you

[David Jencks]

I don't understand what you want to have generated, nor why.  Could you be
more specific?  xdoclet can't modify the contents of a java file, it can
only generate new files.

Personally I think these "I messed with it in this way" historical comments
are a _really_ bad idea, and duplicate badly something cvs does well.  I
prefer the comments to explain clearly only the current functionality of
the class.

david jencks

On 2002.04.03 20:51:43 -0500 Jason Dillon wrote:
> Ok, so I am again too lazy to send this to the xdoclet folks, but this 
> is really for them.  How about some XDoclet magic to replace the in 
> class javadoc version fluff like this:
> 
>  * 20010830 marc fleury:
>  * 
>  *   Initial import
>  * 
> 
> Something similar in flavor to @todo...
> 
> I love XDoclet... this is just great stuff.
> 
> --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

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

[David Jencks]

  User: d_jencks
  Date: 02/04/03 18:21:11

  Removed: src/main/org/jboss/test/jmx/test
MBeanClassLoaderUnitTestCase.java
  Log:
  removed obsolete test case

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

[JBoss-dev] JBoss 2.4.5

[Jeffrey Wescott]

When the JBoss 2.4.5 bundle(s) are released (Scott says 2 weeks from March 
25th), I think we should include Tomcat 4.0.3.  This has a few pretty nice 
bug fixes and is pretty low-risk, in my opinion.  What does everyone think?

++jeff

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

[JBoss-dev] [ jboss-Bugs-539048 ] Manifest not mapped to unpacked EAR

[noreply]

Bugs item #539048, was opened at 2002-04-04 01:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=539048&group_id=22866

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Kelley (yellek)
Assigned to: Nobody/Anonymous (nobody)
Summary: Manifest not mapped to unpacked EAR 

Initial Comment:
We are having some problems deploying an EAR file. We 
have in our EAR file (sample.ear), amongst other 
things, ejb.jar with the EJB's and data.jar with the 
data utility classes. The manifest in ejb.jar includes 
the following line:

Class-Path: data.jar jvi6.0.2-jdk1.2.jar

(The jvi jar which is also in the EAR includes some 
Versant classes)

When we deploy the EAR in JBoss 3.0.0 beta we get the 
following messages:

11:18:34,548 INFO [MainDeployer] Deploying: 
file:/C:/tools/jboss-3.0.0beta/deploy/sample.ear
11:18:34,618 INFO [EARDeployer] Init J2EE application: 
file:/C:/tools/jboss-3.0.0beta/deploy/sample.ear
11:18:35,088 INFO [MainDeployer] Deploying: 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/94.jvi6.0.2-
jdk1.2.jar
11:18:35,158 INFO [MainDeployer] Deploying: 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/92.ejb.jar
11:18:35,168 WARN [MainDeployer] The manifest entry in 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/92.ejb.jar 
references URL file:/C:/tools/jboss-
3.0.0beta/tmp/deploy/data.jar which could not be 
opened, entry ignored
11:18:35,178 WARN [MainDeployer] The manifest entry in 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/92.ejb.jar 
references URL file:/C:/tools/jboss-
3.0.0beta/tmp/deploy/jvi6.0.2-jdk1.2.jar which could 
not be opened, entry ignored
11:18:35,289 INFO [EJBDeployer] Deploying TesterBean
11:18:36,030 ERROR [ServiceController] 
JMRuntimeException thrown during ServiceProxy 
operation create on mbean 
jboss.j2ee:service=EJB,jndiName=test/Testerjava.lang.No
ClassDefFoundError: au/com/moveit/data/Header

It appears as if JBoss is prepending a number and a 
period to the jar file name in the deployment 
directory but then trying to look up the jar files 
without the number and the period when the classpath 
information in the manifest file is used.

JDK1.3.1_02


--

>Comment By: David Jencks (d_jencks)
Date: 2002-04-04 02:24

Message:
Logged In: YES 
user_id=60525

Please test against cvs head and report whether the problem
is already fixed.  In the future, please ALWAYS test against
cvs head before reporting alleged problems.

--

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

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system ServiceConfigurator.java ServiceController.java ServiceCreator.java ServiceLibraries.java

[David Jencks]

  User: d_jencks
  Date: 02/04/03 18:17:22

  Modified:src/main/org/jboss/system ServiceConfigurator.java
ServiceController.java ServiceCreator.java
ServiceLibraries.java
  Log:
  implemented automatic dependency management between mbeans and the classes their 
ObjectInstance indicates they require.  ClassNotFoundException results in the 
deployment waiting until new classes are available. Undeploying classes undeploys 
mbeans known to be using them, saving the current configuration until the classes once 
again become available.
  
  Revision  ChangesPath
  1.6   +122 -138  jboss-system/src/main/org/jboss/system/ServiceConfigurator.java
  
  Index: ServiceConfigurator.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/ServiceConfigurator.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ServiceConfigurator.java  28 Mar 2002 03:13:35 -  1.5
  +++ ServiceConfigurator.java  4 Apr 2002 02:17:22 -   1.6
  @@ -54,13 +54,14 @@
   import org.w3c.dom.Node;
   import org.w3c.dom.NodeList;
   import org.w3c.dom.Text;
  +import java.util.Iterator;
   
   /**
* Service configuration helper.
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
  - * @version $Revision: 1.5 $
  + * @version $Revision: 1.6 $
*
* 20010830 marc fleury:
* 
  @@ -127,21 +128,44 @@
 List mbeans = new ArrayList();
 try 
 {
  - NodeList nl = config.getChildNodes();
  -  
  - for (int i = 0; i < nl.getLength(); i++)
  - {
  -if (nl.item(i).getNodeType() == Node.ELEMENT_NODE)
  -{
  +  if (config.getTagName().equals("mbean"))
  +  {
  + try
  + {
  +internalInstall(config, mbeans);
  + }
  + catch (ClassNotFoundException cnfe)
  + {
  +//ignore
  + }
   
  -   Element element = (Element)nl.item(i);
  -   if (element.getTagName().equals("mbean"))
  +  }
  +  else
  +  {
  + NodeList nl = config.getChildNodes();
  + 
  + for (int i = 0; i < nl.getLength(); i++)
  + {
  +if (nl.item(i).getNodeType() == Node.ELEMENT_NODE)
  {
  -  Element mbean = (Element)nl.item(i);
  -  internalInstall(mbean, mbeans);
  -   } // end of if ()
  -} // end of if ()
  - }
  +
  +   Element element = (Element)nl.item(i);
  +   if (element.getTagName().equals("mbean"))
  +  {
  +  Element mbean = (Element)nl.item(i);
  +  try
  +  {
  + internalInstall(mbean, mbeans);
  +  }
  +  catch (ClassNotFoundException cnfe)
  + {
  + //ignore
  +  }
  +
  +   } // end of if ()
  +} // end of if ()
  + }//end of for
  + } //end of else
return mbeans;  
 }
 catch (DeploymentException de)
  @@ -164,24 +188,31 @@
 } // end of try-catch
  }
   
  -   private ObjectName internalInstall(Element mbean, List mbeans) throws 
DeploymentException
  +   private ObjectName internalInstall(Element mbeanElement, List mbeans) throws 
DeploymentException, ClassNotFoundException
  {
  -  ObjectName mbeanName = null;
  +  ObjectInstance instance = null;
 try 
 {
  - mbeanName = serviceCreator.install(mbean).getObjectName();
  + instance = serviceCreator.install(mbeanElement);
  +  }
  +  catch (ClassNotFoundException cnfe)
  +  {
  +  serviceController.registerWaitingForClass(mbeanElement);
  +  throw cnfe;
 }
 catch (Exception e)
 {
throw new DeploymentException("could not create mbean", e);
 } // end of catch
  +  serviceController.registerMBeanClassName(instance);
  +  ObjectName mbeanName = instance.getObjectName();
 
 mbeans.add(mbeanName);
 if (mbeanName != null) 
 {
try 
{
  -configure(mbeanName, mbean, mbeans);
  +configure(mbeanName, mbeanElement, mbeans);
   serviceController.getServiceContext(mbeanName).state = 
ServiceContext.CONFIGURED;
}
catch (DeploymentException de)
  @@ -431,7 +462,14 @@
   Element child = (Element)childNode;
   if (child.getTagName().equals("mbean"))
   {
  -   dependsObjectName = internalInstall(child, mbeans);
  +try
  +{
  +   dependsObjectName = internalInstall(child, mbeans);
  +  

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

[David Jencks]

  User: d_jencks
  Date: 02/04/03 18:17:22

  Modified:src/main/org/jboss/deployment MainDeployer.java
  Log:
  implemented automatic dependency management between mbeans and the classes their 
ObjectInstance indicates they require.  ClassNotFoundException results in the 
deployment waiting until new classes are available. Undeploying classes undeploys 
mbeans known to be using them, saving the current configuration until the classes once 
again become available.
  
  Revision  ChangesPath
  1.22  +34 -2 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
  
  Index: MainDeployer.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- MainDeployer.java 3 Apr 2002 08:18:59 -   1.21
  +++ MainDeployer.java 4 Apr 2002 02:17:22 -   1.22
  @@ -40,6 +40,7 @@
   import javax.management.MalformedObjectNameException;
   import javax.management.Notification;
   import javax.management.ObjectName;
  +import org.jboss.system.ServiceControllerMBean;
   import org.jboss.system.ServiceMBeanSupport;
   import org.jboss.system.server.ServerConfig;
   import org.jboss.system.server.ServerConfigLocator;
  @@ -56,7 +57,7 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>David Jencks
  - * @version $Revision: 1.21 $
  + * @version $Revision: 1.22 $
*
* @jmx:mbean name="jboss.system:service=MainDeployer"
*extends="org.jboss.system.ServiceMBean, 
org.jboss.deployment.DeployerMBean"
  @@ -180,7 +181,7 @@
  
  /**
   * The removeDeployer method unregisters a deployer with the 
MainDeployer.
  -* Currently deployed packages deployed with this deployer are not undeployed.
  +* Deployed packages deployed with this deployer are undeployed.
   *
   * @param deployer a SubDeployer value
   * @jmx:managed-operation
  @@ -194,6 +195,24 @@
 {
deployers.remove(deployer); 
 }
  +  List copy = null;
  +  synchronized(deploymentList)
  +  {
  +  copy = new ArrayList(deploymentList);
  +  }
  +  for (Iterator i = copy.iterator(); i.hasNext(); )
  +  {
  +  DeploymentInfo di = (DeploymentInfo)i.next();
  +  if (di.deployer == deployer)
  +  {
  + undeploy(di);
  + di.deployer = null;
  + synchronized (waitingDeployments)
  + {
  +waitingDeployments.add(di);
  + }
  +  }
  +  }
  }
   
  /**
  @@ -525,6 +544,19 @@
   makeLocalCopy(deployment);
   // initialize the unified classloaders for this deployment
   deployment.createClassLoaders();
  + //See if this lets us deploy any waiting configurations.
  + try
  + {
  +getServer().invoke(ServiceControllerMBean.OBJECT_NAME, 
  +   "newClassLoaderNotification",
  +   new Object[] {},
  +   new String[] {});
  + }
  + catch (Exception e)
  +{
  +log.info("Exception notifying class removed", e);
  + }
  + //serviceController.newClassLoaderNotification();
} // end of if ()


  
  
  

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

[JBoss-dev] XDoclet... I love you

[Jason Dillon]

Ok, so I am again too lazy to send this to the xdoclet folks, but this 
is really for them.  How about some XDoclet magic to replace the in 
class javadoc version fluff like this:

 * 20010830 marc fleury:
 * 
 *   Initial import
 * 

Something similar in flavor to @todo...

I love XDoclet... this is just great stuff.

--jason


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

Re: [JBoss-dev] Added Deployer & SubDeployer interfaces

[David Jencks]

very nice, jason, thank you.

david jencks

On 2002.04.02 00:08:45 -0500 Jason Dillon wrote:
> I just commited the changes to add a Deployer and SubDeployer interface. 
>  SubDeployer implementors still need to be hooked up... but at the 
> moment that is not needed for this to work.  I added that interface to 
> be explicit with respect to the differences between Deployer and 
> SubDeployer.
> 
> Anyways, Deployer is now configurable via jboss-service.xml for 
> DeploymentScanners.  This means that we can implement interceptors 
> between the DS and MainDeployer... like a deployment cache for NetBoot.
> 
> I will whip up a simple deployment cache for the 3.0 release in the next 
> few days.
> 
> Enjoy,
> 
> --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

[JBoss-dev] [ jboss-Bugs-539048 ] Manifest not mapped to unpacked EAR

[noreply]

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Kelley (yellek)
Assigned to: Nobody/Anonymous (nobody)
Summary: Manifest not mapped to unpacked EAR 

Initial Comment:
We are having some problems deploying an EAR file. We 
have in our EAR file (sample.ear), amongst other 
things, ejb.jar with the EJB's and data.jar with the 
data utility classes. The manifest in ejb.jar includes 
the following line:

Class-Path: data.jar jvi6.0.2-jdk1.2.jar

(The jvi jar which is also in the EAR includes some 
Versant classes)

When we deploy the EAR in JBoss 3.0.0 beta we get the 
following messages:

11:18:34,548 INFO [MainDeployer] Deploying: 
file:/C:/tools/jboss-3.0.0beta/deploy/sample.ear
11:18:34,618 INFO [EARDeployer] Init J2EE application: 
file:/C:/tools/jboss-3.0.0beta/deploy/sample.ear
11:18:35,088 INFO [MainDeployer] Deploying: 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/94.jvi6.0.2-
jdk1.2.jar
11:18:35,158 INFO [MainDeployer] Deploying: 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/92.ejb.jar
11:18:35,168 WARN [MainDeployer] The manifest entry in 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/92.ejb.jar 
references URL file:/C:/tools/jboss-
3.0.0beta/tmp/deploy/data.jar which could not be 
opened, entry ignored
11:18:35,178 WARN [MainDeployer] The manifest entry in 
file:/C:/tools/jboss-3.0.0beta/tmp/deploy/92.ejb.jar 
references URL file:/C:/tools/jboss-
3.0.0beta/tmp/deploy/jvi6.0.2-jdk1.2.jar which could 
not be opened, entry ignored
11:18:35,289 INFO [EJBDeployer] Deploying TesterBean
11:18:36,030 ERROR [ServiceController] 
JMRuntimeException thrown during ServiceProxy 
operation create on mbean 
jboss.j2ee:service=EJB,jndiName=test/Testerjava.lang.No
ClassDefFoundError: au/com/moveit/data/Header

It appears as if JBoss is prepending a number and a 
period to the jar file name in the deployment 
directory but then trying to look up the jar files 
without the number and the period when the classpath 
information in the manifest file is used.

JDK1.3.1_02


--

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

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

[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/idgen/interfaces IdCounter.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 17:39:44

  Modified:src/main/org/jboss/test/idgen/interfaces IdCounter.java
  Log:
   o Changed next & current to nextValue & currentValue to avoid problems
 with SQL reserved words.
  
  Revision  ChangesPath
  1.2   +3 -3  
jbosstest/src/main/org/jboss/test/idgen/interfaces/IdCounter.java
  
  Index: IdCounter.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/idgen/interfaces/IdCounter.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- IdCounter.java25 Aug 2000 13:43:40 -  1.1
  +++ IdCounter.java4 Apr 2002 01:39:44 -   1.2
  @@ -10,8 +10,8 @@
   /**
*  
*   @see 
  - *   @author $Author: oberg $
  - *   @version $Revision: 1.1 $
  + *   @author $Author: user57 $
  + *   @version $Revision: 1.2 $
*/
   public interface IdCounter
  extends EJBObject
  @@ -25,7 +25,7 @@
  // Constructors --
  
  // Public 
  -   public long getNext()
  +   public long getNextValue()
 throws RemoteException;

  public String getName()
  
  
  

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

[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/idgen/ejb IdCounterBean.java IdCounterBeanCMP.java IdGeneratorBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 17:39:44

  Modified:src/main/org/jboss/test/idgen/ejb IdCounterBean.java
IdCounterBeanCMP.java IdGeneratorBean.java
  Log:
   o Changed next & current to nextValue & currentValue to avoid problems
 with SQL reserved words.
  
  Revision  ChangesPath
  1.2   +33 -41jbosstest/src/main/org/jboss/test/idgen/ejb/IdCounterBean.java
  
  Index: IdCounterBean.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/idgen/ejb/IdCounterBean.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- IdCounterBean.java25 Aug 2000 13:43:39 -  1.1
  +++ IdCounterBean.java4 Apr 2002 01:39:43 -   1.2
  @@ -13,58 +13,50 @@
   /**
*  
*   @see 
  - *   @author $Author: oberg $
  - *   @version $Revision: 1.1 $
  + *   @author $Author: user57 $
  + *   @version $Revision: 1.2 $
*/
   public abstract class IdCounterBean
  extends EntitySupport
   {
  -   // Constants -
  -
  -   // Attributes 
  - long nextId;
  - long size;
  +   long nextId;
  +   long size;
  
  -   // Static 
  -
  -   // Constructors --
  -   
  -   // Public 
  -   public long getNext()
  +   public long getNextValue()
  {
  - // Is sequence finished?
  - // If so start a new one
  - if (nextId == (getCurrent() + size))
  - {
  - setCurrent(nextId);
  - }
  - 
  - return nextId++;
  +  // Is sequence finished?
  +  // If so start a new one
  +
  +  if (nextId == (getCurrentValue() + size))
  +  {
  + setCurrentValue(nextId);
  +  }
  +  
  +  return nextId++;
  }
  
  -   public abstract long getCurrent();
  -   public abstract void setCurrent(long current);
  +   public abstract long getCurrentValue();
  +   public abstract void setCurrentValue(long current);

  public abstract String getName();
  public abstract void setName(String beanName);

  - public void ejbLoad()
  - throws RemoteException
  - {
  - nextId = getCurrent();
  - }
  +   public void ejbLoad()
  +  throws RemoteException
  +   {
  +  nextId = getCurrentValue();
  +   }

  - public void setEntityContext(EntityContext ctx)
  - throws RemoteException
  - {
  - super.setEntityContext(ctx);
  - 
  - try
  - {
  -size = ((Long)new 
InitialContext().lookup("java:comp/env/size")).longValue();
  - } catch (Exception e)
  - {
  -throw new EJBException(e);
  - }
  - }
  +   public void setEntityContext(EntityContext ctx)
  +  throws RemoteException
  +   {
  +  super.setEntityContext(ctx);
  +  
  +  try {
  + size = ((Long)new 
InitialContext().lookup("java:comp/env/size")).longValue();
  +  } 
  +  catch (Exception e) {
  + throw new EJBException(e);
  +  }
  +   }
   }
  
  
  
  1.2   +8 -17 
jbosstest/src/main/org/jboss/test/idgen/ejb/IdCounterBeanCMP.java
  
  Index: IdCounterBeanCMP.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/idgen/ejb/IdCounterBeanCMP.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- IdCounterBeanCMP.java 25 Aug 2000 13:43:39 -  1.1
  +++ IdCounterBeanCMP.java 4 Apr 2002 01:39:43 -   1.2
  @@ -11,31 +11,23 @@
   /**
*  
*   @see 
  - *   @author $Author: oberg $
  - *   @version $Revision: 1.1 $
  + *   @author $Author: user57 $
  + *   @version $Revision: 1.2 $
*/
   public class IdCounterBeanCMP
  extends IdCounterBean
   {
  -   // Constants -
  -
  -   // Attributes 
  public String name;
  -   public long current;
  +   public long currentValue;
  
  -   // Static 
  -
  -   // Constructors --
  -   
  -   // Public 
  -   public long getCurrent()
  +   public long getCurrentValue()
  {
  - return current;
  +return currentValue;
  }

  -   public void setCurrent(long current)
  +   public void setCurrentValue(long current)
  {
  - this.current = current;
  + thi

[JBoss-dev] RE: Bug in EntitySynchronizationInterceptor.java?

[Henri Chen]

Bill,

Yes, it would only happen for re-entrant beans.

I did not see through the whole source codes. But if any Exception happened during the 
invoke(), wouldn't there a memory leak in that HashMap?(Of course, this argument 
applys to the old "finally block" implementation, too)

If there is no memory leak issue, I think register() before invoke() is ok because the 
old implementation  would always register it in "finally block".

Henri

-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 04, 2002 7:26 AM
To: Henri Chen; [EMAIL PROTECTED]
Subject: RE: Bug in EntitySynchronizationInterceptor.java?


Henri,

Good catch.  I finally actually read your bug report :)

BTW, this would only happen if your entity bean is re-entrant, right?

The fix for this I believe is in EntitySynchronizationInterceptor.  I think
it is ok to register() before invoke() since register() will always happen
anyways.  Anybody see anything wrong about that?

Henri,  when I commit to 2.4.5 (Branch_2_4) and 3.0, do you have a test for
this?

Thanks,

Bill

> -Original Message-
> From: Henri Chen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 02, 2002 11:30 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: FW:Bug in EntitySynchronizationInterceptor.java?
>
>
> I found I post my former mail to
> [EMAIL PROTECTED] and that is not
> correct. So I forward the mail to the correct list again. Sorry
> for the inconvenience.
> --
> Dear Bill,
>
> The transaction did propagate correctly and without problem
> because it is not a different transaction issue.
>
> The question is that the new activated instance (when calling
> m1()) is not put into the HashMap IMMEDIATELY. It does it in the
> "finally block" and that is after the invoke chain. So if the
> implementation of m1() calling m2() thru the entitie's component
> interface (i.e. calling thru container), the m2() would go thru
> the EntityMultiInstanceInterceptor again. The interceptor would
> try to looks that HashMap for the instance. Oops! It  would still
> activate a new instance of the same PK because the instance
> activated during calling in m1() is not put into the HashMap YET
> (because the invoke chain is not completed yet.)
>
> This is what I think it might be a bug.
>
> Henri
>
> P.S. It did cause trouble in my code. I saw two instances  were
> consecutiously activated and I read the source code of jboss
> release 2.4.4.
>
> -Original Message-
> From: Bill Burke [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2002 10:10 PM
> To: Henri Chen; [EMAIL PROTECTED]
> Subject: RE: Bug in EntitySynchronizationInterceptor.java?
>
>
> I don't think soLet me go through your comments again just to
> make sure.
>
> I keep a transaction->entity map.  Before an instance is created anew, the
> EntityMultiInstanceInterceptor looks in a HashMap to see if the
> instance has
> already been created for this transaction.  The transaction should be
> propagated when you call _ctx.getEJBOejct()->stubx1->m2().
> Unless there is
> some bug someplace and the transaction is not getting propagated.  Are you
> seeing bad behaviour?  Or is this just your observation just
> looking at the
> code?
>
> Bill
>
> > -Original Message-
> > From: Henri Chen [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 22, 2002 1:33 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Bug in EntitySynchronizationInterceptor.java?
> >
> >
> > Dear Bill,
> >
> > It might be too late to associate the entity bean with the
> > transaction until after the invoke chain.
> >
> > The following is a senario that might cause trouble:
> >
> > * An entity bean XBean with component interface method m1() and m2().
> > * Some session bean Y calls XHome.findByPrimaryKey() to get the
> > component interface stub x1.
> > * Y calls x1.m1(), the EntityMutltiInstanceInterceptor
> > automatically activate and load an instance of the XBean.
> > * The implementation of method m1() in XBean use
> > _ctx.getEJBObject() to get the stub x1, and calling m2() thru the
> > container again.
> > * The EntityMutltiInstanceInterceptor, AGAIN, automatically
> > activate and load ANOTHER NEW INSTANCE of  x1; and then invoke
> > m2() on this new instance and return.
> > * The EntitySynchronizationInterceptor associate 2nd instance
> > into txEntityMap.
> > * The m1() on the first instance return.
> > * The EntitySynchronizationInterceptor associate 1st instance
> > into txEntityMap WITH the same primary key and transaction.(So
> > basically, the 2nd instance is overwritten and gone)
> >
> > The result is that two methods m1() and m2 are called on two
> > DIFFERENT instances. Therefore, the state of the bean would be
> > unpredictable because all that have done inside m2() is lost.
> >
> > Am I right?
> >
> > H

[JBoss-dev] Automated JBoss Testsuite Results: 4-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   567



Successful tests:  542

Errors:19

Failures:  6





[time of test: 4 April 2002 2:33 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1_02a-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-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

Re: [JBoss-dev] Long deployment file names... again

[Dain Sundstrom]

My $0.02.

I think that _filename would be the easiest to for developers to 
follow.  Even better would be if the UID was always the same length, so 
they would lineup in with ls or dir.

-dain

Jason Dillon wrote:

> For the cache, I initially implement a reproducable long url -> short 
> url using a CRC32 + shortfilename (which it still does), but I later 
> added a serialized hash for faster lookups + to make startup easier. The 
> cache impl is not really the issue here, it just tickles the real problem.
> 
> The main issue that I have is that our deployment system is pushing on 
> the edge of OS compatiblity by using these really long file names... 
> where it does not appear that we need to do so
> 
> I think we should either revert to number incremented (or new 
> UID().toString() prefixed filenames) or some other simple and shorter 
> reproducable mapping system.
> 
> Perhaps providing a mgmnt operation to reverse the maping is ok?  This 
> can simply be an in memory map, since the tmp/deploy stuff does not live 
> beyond the life of the VM.
> 
> If all we are using full url filenames for is for developer convienece, 
> then scew it, we don't need to be convienent at the expense of being 
> compatible.  If there is a real problem concering security policies, 
> then lets look into what our options are to solving that with out using 
> long filesnames.
> 
> Is there any issue short of developer conveience which motivated us to 
> use long filenames?
> 
> --jason
> 
> 
> David Jencks wrote:
> 
>> We had it working for a while with unique file names, namely an 
>> incremented
>> number/short-jar-name.  I don't care, going back to this is fine with 
>> me. Many people liked being able to find the deployed copy.
>>
>> This however is not reproducible, and I would expect that your cache 
>> would
>> need reproducible mappings.  If I am wrong, wonderful.  Otherwise I can't
>> think of much except a mapping file, maybe properties
>> url=number
>> to identify where the copy is.
>>
>>
>> david jencks
>>
>> On 2002.04.03 17:58:02 -0500 Jason Dillon wrote:
>>

 What is this problem? I think any reproducible 1-1 mapping will work,

>>> but I
>>>
 don't know of any other than using the whole URL.
 david jencks

>>> The problem is that on windows (ick) it limits the length of a 
>>> filename unreasonabily.  This problem shows up with the currently 
>>> deployment scheme of taking the entire URL of a deployment and using 
>>> that as the path under the ${jboss.server.home.dir}/tmp/deploy 
>>> directory.  This means that the length of the filename is now 
>>> "${jboss.server.home.dir}/tmp/deploy".length + url.toString.length.  
>>> If this is > then the giving crappy limit on win32 we are hosed.
>>>
>>> It would be *safer* to employ a different method for the url suffix 
>>> bits, as the first part is a sunk cost.  Sure we can tell users to 
>>> run from a different directory, using a shorter name, but we can't 
>>> really control the URLs that come in for deployment.
>>>
>>> I personally have the following setup (which I don not think
>>> unreasonable):
>>>
>>> base project dir: /home/jason/workspace/jboss/jboss-all (prefixed by 
>>> c:\cygwin for winblows)
>>>
>>> This means that the final value for ${jboss.server.home.dir} is:
>>>
>>> 
>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default 
>>>
>>>
>>> Now the deployments live under conf/ and deploy/ relative to this 
>>> path, longest filename currently seems to be:
>>>
>>> new-hsqldb-default-service.xml
>>>
>>> which makes the actual deployment file:
>>>
>>> 
>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
> 
>>>
>>>
>>> Now this full path will be constructed under:
>>>
>>> 
>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy
> 
>>>
>>>
>>> making the full deployed filename:
>>>
>>> 
>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy\C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
> 
>>>
>>>
>>> with translations applied, I am too lazy for this at the moment.
>>>
>>> Now in comes the cache repository.  If I employed the same scheme, 
>>> then the deployment URL which is given to MainDeployer would be about 
>>> as long as the tmp\deploy version... which would then become even 
>>> longer once it was copied to tmp\deploy.
>>>
>>> See what I mean?  If this is all because of security policies, then I 
>>> suggest we need to find another way to implement the policy, perhaps 
>>> even punting easier configuration until 1.4 is the defacto.  If not 
>>> please explain why we need this, cause I just don't understand.
>>>
>>> These insanely long filenames are going to bite us... they have 
>>> already bitten me several times.
>>>
>>> There must be a better solution, which does

[JBoss-dev] Automated JBoss Testsuite Results: 4-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   567



Successful tests:  540

Errors:19

Failures:  8





[time of test: 4 April 2002 1:46 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-20020124 (JIT enabled: jitc)]
[os.name: Linux]
[os.arch: x86]
[os.version: 2.4.9-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/idgen/interfaces IdCounterHome.java IdGeneratorHome.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 16:30:35

  Modified:src/main/org/jboss/test/idgen/interfaces IdCounterHome.java
IdGeneratorHome.java
  Log:
   o Keep EJB Verifier from bitching
  
  Revision  ChangesPath
  1.3   +3 -3  
jbosstest/src/main/org/jboss/test/idgen/interfaces/IdCounterHome.java
  
  Index: IdCounterHome.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/idgen/interfaces/IdCounterHome.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- IdCounterHome.java18 Apr 2001 19:48:28 -  1.2
  +++ IdCounterHome.java4 Apr 2002 00:30:35 -   1.3
  @@ -11,8 +11,8 @@
   /**
*  
*   @see 
  - *   @author $Author: starksm $
  - *   @version $Revision: 1.2 $
  + *   @author $Author: user57 $
  + *   @version $Revision: 1.3 $
*/
   public interface IdCounterHome
  extends EJBHome
  @@ -35,5 +35,5 @@
 throws RemoteException, FinderException;
 
  public Collection findAll()
  -  throws RemoteException;
  +  throws RemoteException, FinderException;
   }
  
  
  
  1.2   +3 -3  
jbosstest/src/main/org/jboss/test/idgen/interfaces/IdGeneratorHome.java
  
  Index: IdGeneratorHome.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/idgen/interfaces/IdGeneratorHome.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- IdGeneratorHome.java  25 Aug 2000 13:43:41 -  1.1
  +++ IdGeneratorHome.java  4 Apr 2002 00:30:35 -   1.2
  @@ -10,8 +10,8 @@
   /**
*  
*   @see 
  - *   @author $Author: oberg $
  - *   @version $Revision: 1.1 $
  + *   @author $Author: user57 $
  + *   @version $Revision: 1.2 $
*/
   public interface IdGeneratorHome
  extends EJBHome
  @@ -28,6 +28,6 @@
  
  // Public 
  public IdGenerator create()
  -  throws RemoteException;
  +  throws CreateException, RemoteException;
  
   }
  
  
  

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

[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors RegExp.java Operator.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 16:20:17

  Modified:src/main/org/jboss/mq/selectors Operator.java
  Added:   src/main/org/jboss/mq/selectors RegExp.java
  Log:
  o Applied patch: [ 531571 ] performance tuning for selector LIKE
  
  Revision  ChangesPath
  1.6   +19 -64jbossmq/src/main/org/jboss/mq/selectors/Operator.java
  
  Index: Operator.java
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/Operator.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Operator.java 14 Feb 2002 02:54:29 -  1.5
  +++ Operator.java 4 Apr 2002 00:20:17 -   1.6
  @@ -15,7 +15,7 @@
* @author [EMAIL PROTECTED]
* @author [EMAIL PROTECTED]
* @createdAugust 16, 2001
  - * @version$Revision: 1.5 $
  + * @version$Revision: 1.6 $
*/
   public class Operator
   {
  @@ -31,6 +31,11 @@
  int  class1;
  int  class2;
  int  class3;
  +   
  +   // info about the regular expression
  +   // if this is a LIKE operator
  +   // (perhaps this should be a subclass)
  +   RegExpre = null;
   
  public final static int EQUAL = 0;
  public final static int NOT = 1;
  @@ -654,73 +659,23 @@
escapeChar = new Character( escapeBuf.charAt( 0 ) );
 }
   
  -  StringBuffer patternBuf = new StringBuffer( ( String )arg2 );
  -  StringBuffer REpattern = new StringBuffer( "^" );
  -
  -  for ( int i = 0; i < patternBuf.length(); i++ ) {
  - boolean escaped = false;
  - char c = patternBuf.charAt( i );
  -
  - if ( use_escape && escapeChar != null && escapeChar.charValue() == c ) {
  -if ( i + 1 < patternBuf.length() ) {
  -   escaped = true;
  -   i++;
  -   c = patternBuf.charAt( i );
  -} else {
  -   throw new Exception( "LIKE ESCAPE: Bad use of escape character" );
  -}
  - }
  -
  - // Match characters, or escape ones special to the underlying
  - // regex engine
  - switch ( c ) {
  -case '_':
  -   if ( escaped ) {
  -  REpattern.append( c );
  -   } else {
  -  REpattern.append( '.' );
  -   }
  -   break;
  -case '%':
  -   if ( escaped ) {
  -  REpattern.append( c );
  -   } else {
  -  REpattern.append( ".*" );
  -   }
  -   break;
  -case '*':
  -case '.':
  -case '\\':
  -case '^':
  -case '$':
  -case '[':
  -case ']':
  -   //  case '(':
  -   //  case ')':
  -   //  case '+':
  -   //  case '?':
  -   //  case '{':
  -   //  case '}':
  -   //  case '|':
  -   REpattern.append( "\\" + c );
  -   break;
  -default:
  -   REpattern.append( c );
  -   break;
  - }
  +  if (re == null) {
  + // the first time through we prepare the regular expression
  + re = new RegExp ( (String) arg2, escapeChar);
 }
  -
  -  REpattern.append( '$' );
  -
  -  // Parse the regex
  -  gnu.regexp.RE re = new gnu.regexp.RE( REpattern, 0, 
gnu.regexp.RESyntax.RE_SYNTAX_POSIX_MINIMAL_BASIC );
  -
  -  boolean result = re.isMatch( arg1 );
  +  
  +  boolean result = re.isMatch (arg1);
 if ( not ) {
result = !result;
 }
  -
  -  return new Boolean( result );
  +  
  +  if (result == true) {
  + return Boolean.TRUE;
  +  }
  +  else {
  + return Boolean.FALSE;
  +  }
  + 
  }
   
  //Operator 22
  
  
  
  1.1  jbossmq/src/main/org/jboss/mq/selectors/RegExp.java
  
  Index: RegExp.java
  ===
  /*
   * JBossMQ, the OpenSource JMS implementation
   *
   * Distributable under LGPL license.
   * See terms of license at gnu.org.
   */
  
  package org.jboss.mq.selectors;
  
  import gnu.regexp.RE;
  
  /**
   * Regular expressions to support the selector LIKE operator.
   *
   * @created Dec. 7, 2001
   * @version $Revision: 1.1 $
   *
   * @author Norbert Lataille ([EMAIL PROTECTED])
   * @author [EMAIL PROTECTED]
   * @author [EMAIL PROTECTED]
   * @author Loren Rosen
   */
  public class RegExp 
  {
 protected RE re;
   
 public RegExp (String pattern, Character escapeChar)
throws Exception 
 {
re = new RE(adjustPattern(pattern, escapeChar)

Re: [JBoss-dev] Todo: multiple instances detection

[Mitchell Kim]

I have a question about this.  How will JBoss behave when one of the
instance gets shut down?  Is it going to be smart enough not to close the
service that other instances are using? such as Naming service?

Mitch

- Original Message -
From: "marc fleury" <[EMAIL PROTECTED]>
To: "Jboss-Development@Lists. Sourceforge. Net"
<[EMAIL PROTECTED]>
Sent: Wednesday, April 03, 2002 11:09 AM
Subject: [JBoss-dev] Todo: multiple instances detection


> there should be a service that is part of the first services coming up and
> that detects if other JBoss systems are running on the same physical
> machines, this is to avoid port conflict as some services are holding on
to
> some ports (e.g. naming on 1099, detached RMI, clustered RMI).
>
> We would then not start the naming as a duplicate nor the detached RMI but
> we would use the clustered RMI by increasing the connection port.
>
> This will enable people to run multiple instances of JBoss without having
to
> manually change the stuff all the time.  At least on the services we
provide
> we should show how these behave.
>
> marcf
>
>
> ___
> 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: 4-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   560



Successful tests:  532

Errors:21

Failures:  7





[time of test: 4 April 2002 0:57 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-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

Re: [JBoss-dev] jboss-all

[Jason Dillon]

It is just CVS... what is the problem?  Please read the quick start:

http://www.jboss.org/developers/guide/quickstart.jsp

--jason


Anthony Burns wrote:

>I dont know how to use jboss-all with cvs
>
>is there a simpler way to get it or can some one please explain how to get it with cvs
>_
>View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=11901
>
>___
>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] Long deployment file names... again

[Jason Dillon]

For the cache, I initially implement a reproducable long url -> short 
url using a CRC32 + shortfilename (which it still does), but I later 
added a serialized hash for faster lookups + to make startup easier. 
 The cache impl is not really the issue here, it just tickles the real 
problem.

The main issue that I have is that our deployment system is pushing on 
the edge of OS compatiblity by using these really long file names... 
where it does not appear that we need to do so

I think we should either revert to number incremented (or new 
UID().toString() prefixed filenames) or some other simple and shorter 
reproducable mapping system.

Perhaps providing a mgmnt operation to reverse the maping is ok?  This 
can simply be an in memory map, since the tmp/deploy stuff does not live 
beyond the life of the VM.

If all we are using full url filenames for is for developer convienece, 
then scew it, we don't need to be convienent at the expense of being 
compatible.  If there is a real problem concering security policies, 
then lets look into what our options are to solving that with out using 
long filesnames.

Is there any issue short of developer conveience which motivated us to 
use long filenames?

--jason


David Jencks wrote:

>We had it working for a while with unique file names, namely an incremented
>number/short-jar-name.  I don't care, going back to this is fine with me. 
>Many people liked being able to find the deployed copy.
>
>This however is not reproducible, and I would expect that your cache would
>need reproducible mappings.  If I am wrong, wonderful.  Otherwise I can't
>think of much except a mapping file, maybe properties
>url=number
>to identify where the copy is.
>
>
>david jencks
>
>On 2002.04.03 17:58:02 -0500 Jason Dillon wrote:
>
>>>
>>>What is this problem? I think any reproducible 1-1 mapping will work,
>>>
>>but I
>>
>>>don't know of any other than using the whole URL.
>>>david jencks
>>>
>>The problem is that on windows (ick) it limits the length of a filename 
>>unreasonabily.  This problem shows up with the currently deployment 
>>scheme of taking the entire URL of a deployment and using that as the 
>>path under the ${jboss.server.home.dir}/tmp/deploy directory.  This 
>>means that the length of the filename is now 
>>"${jboss.server.home.dir}/tmp/deploy".length + url.toString.length.  If 
>>this is > then the giving crappy limit on win32 we are hosed.
>>
>>It would be *safer* to employ a different method for the url suffix 
>>bits, as the first part is a sunk cost.  Sure we can tell users to run 
>>from a different directory, using a shorter name, but we can't really 
>>control the URLs that come in for deployment.
>>
>>I personally have the following setup (which I don not think
>>unreasonable):
>>
>> base project dir: /home/jason/workspace/jboss/jboss-all (prefixed by 
>>c:\cygwin for winblows)
>>
>>This means that the final value for ${jboss.server.home.dir} is:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default
>>
>>Now the deployments live under conf/ and deploy/ relative to this path, 
>>longest filename currently seems to be:
>>
>>new-hsqldb-default-service.xml
>>
>>which makes the actual deployment file:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
>>
>>Now this full path will be constructed under:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy
>>
>>making the full deployed filename:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy\C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
>>
>>with translations applied, I am too lazy for this at the moment.
>>
>>Now in comes the cache repository.  If I employed the same scheme, then 
>>the deployment URL which is given to MainDeployer would be about as long 
>>as the tmp\deploy version... which would then become even longer once it 
>>was copied to tmp\deploy.
>>
>>See what I mean?  If this is all because of security policies, then I 
>>suggest we need to find another way to implement the policy, perhaps 
>>even punting easier configuration until 1.4 is the defacto.  If not 
>>please explain why we need this, cause I just don't understand.
>>
>>These insanely long filenames are going to bite us... they have already 
>>bitten me several times.
>>
>>There must be a better solution, which does not force users to hack up 
>>there environment to work around this OS limitation... perhaps there are 
>>other OS'n out there which have similar limits... who knows.  Lets not 
>>stick our necks out to find out.
>>
>>Can you please explain all of the details why we need these long 
>>filenames.  I don't get it.
>>
>>--jason
>>
>>
>>
>>



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://

Re: [JBoss-dev] Long deployment file names... again

[David Jencks]

We had it working for a while with unique file names, namely an incremented
number/short-jar-name.  I don't care, going back to this is fine with me. 
Many people liked being able to find the deployed copy.

This however is not reproducible, and I would expect that your cache would
need reproducible mappings.  If I am wrong, wonderful.  Otherwise I can't
think of much except a mapping file, maybe properties
url=number
to identify where the copy is.


david jencks

On 2002.04.03 17:58:02 -0500 Jason Dillon wrote:
> >
> >
> >What is this problem? I think any reproducible 1-1 mapping will work,
> but I
> >don't know of any other than using the whole URL.
> >david jencks
> >
> 
> The problem is that on windows (ick) it limits the length of a filename 
> unreasonabily.  This problem shows up with the currently deployment 
> scheme of taking the entire URL of a deployment and using that as the 
> path under the ${jboss.server.home.dir}/tmp/deploy directory.  This 
> means that the length of the filename is now 
> "${jboss.server.home.dir}/tmp/deploy".length + url.toString.length.  If 
> this is > then the giving crappy limit on win32 we are hosed.
> 
> It would be *safer* to employ a different method for the url suffix 
> bits, as the first part is a sunk cost.  Sure we can tell users to run 
> from a different directory, using a shorter name, but we can't really 
> control the URLs that come in for deployment.
> 
> I personally have the following setup (which I don not think
> unreasonable):
> 
>  base project dir: /home/jason/workspace/jboss/jboss-all (prefixed by 
> c:\cygwin for winblows)
> 
> This means that the final value for ${jboss.server.home.dir} is:
> 
> C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default
> 
> Now the deployments live under conf/ and deploy/ relative to this path, 
> longest filename currently seems to be:
> 
> new-hsqldb-default-service.xml
> 
> which makes the actual deployment file:
> 
> 
>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
> 
> Now this full path will be constructed under:
> 
> 
>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy
> 
> making the full deployed filename:
> 
> 
>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy\C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
> 
> with translations applied, I am too lazy for this at the moment.
> 
> Now in comes the cache repository.  If I employed the same scheme, then 
> the deployment URL which is given to MainDeployer would be about as long 
> as the tmp\deploy version... which would then become even longer once it 
> was copied to tmp\deploy.
> 
> See what I mean?  If this is all because of security policies, then I 
> suggest we need to find another way to implement the policy, perhaps 
> even punting easier configuration until 1.4 is the defacto.  If not 
> please explain why we need this, cause I just don't understand.
> 
> These insanely long filenames are going to bite us... they have already 
> bitten me several times.
> 
> There must be a better solution, which does not force users to hack up 
> there environment to work around this OS limitation... perhaps there are 
> other OS'n out there which have similar limits... who knows.  Lets not 
> stick our necks out to find out.
> 
> Can you please explain all of the details why we need these long 
> filenames.  I don't get it.
> 
> --jason
> 
> 
> 
> 

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

Re: [JBoss-dev] I ask for advice on CVS lock

[Oleg Nitz]

On Tuesday 02 April 2002 06:39, you wrote:
> Did this ever get resolved?
Yes, yesterday the lock was removed, thanks to SourceForge guy who did this.
Jetty 4 is fully committed to JBoss CVS.

Oleg


> Oleg Nitz wrote:
> >Hi All,
> >
> >I am trying to update Jetty in JBoss CVS, but there is a lock in
> > /cvsroot/jboss/contrib/jetty/src/main/org/mortbay/http
> >so that I cannot commit changes to this dir.
> >I don't know how to solve this issue.
> >Probably I should contact somebody from SourceForge?
> >Any ideas?
> >
> >Thanks in advance,
> > Oleg
> >
> >___
> >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-system/src/main/org/jboss/deployment Deployer.java

[Jason Dillon]

  User: user57  
  Date: 02/04/01 21:20:40

  Modified:src/main/org/jboss/deployment Deployer.java
  Log:
   o remove evil spaces
  
  Revision  ChangesPath
  1.2   +4 -4  jboss-system/src/main/org/jboss/deployment/Deployer.java
  
  Index: Deployer.java
  ===
  RCS file: /cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/Deployer.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Deployer.java 2 Apr 2002 05:10:04 -   1.1
  +++ Deployer.java 2 Apr 2002 05:20:40 -   1.2
  @@ -17,7 +17,7 @@
*
* Clients should use the MainDeployer to deploy URLs.
*
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public interface Deployer
  @@ -27,21 +27,21 @@
   *
   * @param url an URL value
   */
  -   void undeploy(URL url) ;
  +   void undeploy(URL url);
   
  /**
   * Undeploys a package represented by a DeploymentInfo object.
   *
   * @param di a DeploymentInfo value
   */
  -   void undeploy(DeploymentInfo di) ;
  +   void undeploy(DeploymentInfo di);
   
  /**
   * Deploys a package identified by a URL
   *
   * @param url an URL value
   */
  -   void deploy(URL url) ;
  +   void deploy(URL url);
   
  /**
   * Deploys a package represented by a DeploymentInfo object.
  @@ -58,5 +58,5 @@
   * @param url an URL value
   * @return a boolean value
   */
  -   boolean isDeployed(URL url) ;
  +   boolean isDeployed(URL url);
   }
  
  
  

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

[JBoss-dev] jboss-all

[Anthony Burns]

I dont know how to use jboss-all with cvs

is there a simpler way to get it or can some one please explain how to get it with cvs
_
View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=11901

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment/cache - New directory

[Jason Dillon]

  User: user57  
  Date: 02/04/01 21:10:33

  jboss-system/src/main/org/jboss/deployment/cache - New directory

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment/scanner AbstractDeploymentScanner.java DeploymentScanner.java URLDeploymentScanner.java DeploymentScannerMBean.java URLDeploymentScannerMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/01 21:10:05

  Modified:src/main/org/jboss/deployment/scanner
AbstractDeploymentScanner.java
DeploymentScanner.java URLDeploymentScanner.java
  Removed: src/main/org/jboss/deployment/scanner
DeploymentScannerMBean.java
URLDeploymentScannerMBean.java
  Log:
   o Added Deployer & SubDeployer interfaces
   o Made DS target Deployer configurable
   o Using XDoclet to gen MBean interfaces
  
  Revision  ChangesPath
  1.2   +29 -11
jboss-system/src/main/org/jboss/deployment/scanner/AbstractDeploymentScanner.java
  
  Index: AbstractDeploymentScanner.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/scanner/AbstractDeploymentScanner.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- AbstractDeploymentScanner.java2 Mar 2002 08:05:19 -   1.1
  +++ AbstractDeploymentScanner.java2 Apr 2002 05:10:05 -   1.2
  @@ -31,7 +31,7 @@
   import org.jboss.deployment.MainDeployerMBean;
   import org.jboss.deployment.DeploymentInfo;
   import org.jboss.deployment.DeploymentException;
  -import org.jboss.deployment.DeploymentSorter;
  +import org.jboss.deployment.Deployer;
   
   import org.jboss.system.server.ServerConfigImplMBean;
   
  @@ -45,9 +45,12 @@
   /**
* An abstract support class for implementing a deployment scanner.
*
  - * Sub-class must implement {@link DeploymentScanner#scan}.
  + * Provides the implementation of period-based scanning, as well
  + *as Deployer integration.
*
  - * @version $Revision: 1.1 $
  + * Sub-classes only need to implement {@link DeploymentScanner#scan}.
  + *
  + * @version $Revision: 1.2 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public abstract class AbstractDeploymentScanner
  @@ -60,20 +63,33 @@
  /** True if period based scanning is enabled. */
  protected MuBoolean scanEnabled = new MuBoolean(true);
   
  -   /** A proxy to the main deployer. */
  -   protected MainDeployerMBean deployer;
  +   /** A proxy to the deployer we are using. */
  +   protected Deployer deployer;
  +
  +   /** The ObjectName of the depoyer (for mgmnt only). */
  +   protected ObjectName deployerName;
   
  /** The scanner thread. */
  protected ScannerThread scannerThread;
   
  -   /** A helper for sorting deployments. */
  -   protected DeploymentSorter sorter = new DeploymentSorter();
  -
   
  /
  //   DeploymentScanner //
  /
   
  +   public void setDeployer(final ObjectName deployerName)
  +   {
  +  if (deployerName == null)
  + throw new NullArgumentException("deployerName");
  +
  +  this.deployerName = deployerName;
  +   }
  +
  +   public ObjectName getDeployer()
  +   {
  +  return deployerName;
  +   }
  +
  /**
   * Period must be >= 0.
   */
  @@ -210,11 +226,13 @@
   
  protected void createService() throws Exception
  {
  +  if (deployerName == null)
  + throw new ConfigurationException("Missing attribute 'Deployer'");
  +
 // setup deployer
  -  deployer = (MainDeployerMBean)
  - MBeanProxy.create(MainDeployerMBean.class, 
  -   MainDeployerMBean.OBJECT_NAME,
  -   server);
  +  deployer = (Deployer)MBeanProxy.create(Deployer.class, 
  + deployerName, 
  + server);
   
 // setup + start scanner thread
 scannerThread = new ScannerThread(false);
  
  
  
  1.2   +28 -4 
jboss-system/src/main/org/jboss/deployment/scanner/DeploymentScanner.java
  
  Index: DeploymentScanner.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/scanner/DeploymentScanner.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DeploymentScanner.java1 Mar 2002 08:29:57 -   1.1
  +++ DeploymentScanner.java2 Apr 2002 05:10:05 -   1.2
  @@ -19,22 +19,40 @@
* A deployment scanner scans for new, removed or changed
*deployments.
*
  - * @todo Expose deployer name as depenent MBean when there is
  - *   a common interface for deployment management (not
  - *   deployment lifecycle mgmnt).
  + * @jmx:mbean extends="org.jboss.system.ServiceMBean, 
org.jboss.deployment.scanner.DeploymentScanner"
*
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
   public interface DeploymentScanner
  

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment Deployer.java SubDeployer.java MainDeployer.java SARDeployer.java

[Jason Dillon]

  User: user57  
  Date: 02/04/01 21:10:04

  Modified:src/main/org/jboss/deployment MainDeployer.java
SARDeployer.java
  Added:   src/main/org/jboss/deployment Deployer.java SubDeployer.java
  Log:
   o Added Deployer & SubDeployer interfaces
   o Made DS target Deployer configurable
   o Using XDoclet to gen MBean interfaces
  
  Revision  ChangesPath
  1.20  +4 -7  jboss-system/src/main/org/jboss/deployment/MainDeployer.java
  
  Index: MainDeployer.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- MainDeployer.java 18 Mar 2002 22:34:03 -  1.19
  +++ MainDeployer.java 2 Apr 2002 05:10:04 -   1.20
  @@ -9,10 +9,6 @@
   
   package org.jboss.deployment;
   
  -
  -
  -
  -
   import java.io.BufferedInputStream;
   import java.io.BufferedOutputStream;
   import java.io.File;
  @@ -54,18 +50,19 @@
   
   /**
* The main/primary component for deployment.
  - * MainDeployerMBean is now generated by xdoclet.
  + * 
  + * MainDeployerMBean is generated by xdoclet.
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>David Jencks
  - * @version $Revision: 1.19 $
  + * @version $Revision: 1.20 $
* @jmx:mbean name="jboss.system:service=MainDeployer"
*extends="org.jboss.system.ServiceMBean"
*/
   public class MainDeployer
  extends ServiceMBeanSupport
  -   implements MainDeployerMBean
  +   implements Deployer, MainDeployerMBean
   {
  /** Deployers **/
  private final LinkedList deployers = new LinkedList();
  
  
  
  1.4   +2 -2  jboss-system/src/main/org/jboss/deployment/SARDeployer.java
  
  Index: SARDeployer.java
  ===
  RCS file: 
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/SARDeployer.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SARDeployer.java  24 Mar 2002 05:35:01 -  1.3
  +++ SARDeployer.java  2 Apr 2002 05:10:04 -   1.4
  @@ -69,7 +69,7 @@
* @author mailto:[EMAIL PROTECTED]";>David Maplesden
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
*
* 20010830 marc fleury:
* 
  @@ -112,7 +112,7 @@
*/
   public class SARDeployer
  extends ServiceMBeanSupport
  -   implements SARDeployerMBean
  +   implements SubDeployer, SARDeployerMBean
   {
  /** A proxy to the ServiceController. */
  private ServiceControllerMBean serviceController;
  
  
  
  1.1  jboss-system/src/main/org/jboss/deployment/Deployer.java
  
  Index: Deployer.java
  ===
  /***
   * *
   *  JBoss: The OpenSource J2EE WebOS   *
   * *
   *  Distributable under LGPL license.  *
   *  See terms of license at gnu.org.   *
   * *
   ***/
  
  package org.jboss.deployment;
  
  import java.net.URL;
  import java.net.MalformedURLException;
  
  /**
   * The interface which a deployer must implement.
   *
   * Clients should use the MainDeployer to deploy URLs.
   *
   * @version $Revision: 1.1 $
   * @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
   */
  public interface Deployer
  {
 /**
  * Undeploys a package identified by a URL
  *
  * @param url an URL value
  */
 void undeploy(URL url) ;
  
 /**
  * Undeploys a package represented by a DeploymentInfo object.
  *
  * @param di a DeploymentInfo value
  */
 void undeploy(DeploymentInfo di) ;
  
 /**
  * Deploys a package identified by a URL
  *
  * @param url an URL value
  */
 void deploy(URL url) ;
  
 /**
  * Deploys a package represented by a DeploymentInfo object.
  *
  * @param deployment a DeploymentInfo value
  *
  * @throws DeploymentException if an error occurs
  */
 void deploy(DeploymentInfo deployment) throws DeploymentException;
  
 /**
  * Tells you if a packaged identified by a URL is deployed.
  *
  * @param url an URL value
  * @return a boolean value
  */
 boolean isDeployed(URL url) ;
  }
  
  
  
  1.1  jboss-system/src/main/org/jboss/deployment/SubDeployer.java
  
  Index: SubDeployer.java
  ===
  /***
   * *
   *  JBoss: The OpenSource J2EE WebOS   *
 

Re: [JBoss-dev] [ jboss-Patches-537795 ] [JETTY]ClassNaming/Mapping Issue

[Jules Gosnell]

Stephen,
I'm forwarding your patch to Jetty-Discuss for discussion.
We have a problem here as Jasper is an independent OpenSource project.
We have a copy of the source in JBoss cvs to aid with debugging etc, but
the intention is to try very hard not to delta from the main project, otherwise
management of it becomes much more complicated.
Greg (Jetty maintainer) may have some input, but it may be that you
need to submit your patch direct to the Jasper community. Jetty will then
refresh from their cvs and JBoss from Jetty's, bringing us all back into
sync.
Sorry it can't be simpler.
 
Greg, would you comment, and if necessary, put Stephen in touch with
the relevant guy on Jasper
 
Cheers,
 
 
 
Jules
 
[EMAIL PROTECTED] wrote:
Patches item #537795, was opened at 2002-04-01 11:47
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=537795&group_id=22866
Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Davidson (northgorky)
Assigned to: Nobody/Anonymous (nobody)
Summary: [JETTY]ClassNaming/Mapping Issue
Initial Comment:
When JSPC is run from ant, jsp files in the context
root have a '.' prepended to their name.  This results
in the classloader looking for files like
".siteMain.class", which does not exist.
Fix:
retrieving revision 1.6
diff -u -r1.6 JspC.java
--- src/main/org/apache/jasper/JspC.java   
11 Mar
2002 05:28:56 -  1.6
+++ src/main/org/apache/jasper/JspC.java   
1 Apr
2002 17:43:24 -
@@ -418,7 +418,11 @@
servletout.write("\n\t\n\t\t");

servletout.write(thisServletName);
servletout.write("\n\t\t");
-   
servletout.write(thisServletName);
+   
//HACK: Must trim the leading ".","*",
whatever, from the classname. SPD
+   
if
(Character.isLetter(thisServletName.charAt(0)) ||
(thisServletName.charAt(0) == '/') )
+   
servletout.write(thisServletName);
+   
else
+
servletout.write(thisServletName.substring(1));
servletout.write("\n\t\n");
 
 
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=537795&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

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

[Jason Dillon]

  User: user57  
  Date: 02/04/01 21:10:04

  Modified:.build.xml
  Log:
   o Added Deployer & SubDeployer interfaces
   o Made DS target Deployer configurable
   o Using XDoclet to gen MBean interfaces
  
  Revision  ChangesPath
  1.11  +3 -1  jboss-system/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jboss-system/build.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- build.xml 24 Mar 2002 05:35:01 -  1.10
  +++ build.xml 2 Apr 2002 05:10:03 -   1.11
  @@ -12,7 +12,7 @@
   
   
   
  -
  +
   
   
   
  @@ -239,6 +239,8 @@
   
   
   
  +
  +
   
 
 
  
  
  

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

Re: [JBoss-dev] Long deployment file names... again

[Jason Dillon]

>
>
>What is this problem? I think any reproducible 1-1 mapping will work, but I
>don't know of any other than using the whole URL.
>david jencks
>

The problem is that on windows (ick) it limits the length of a filename 
unreasonabily.  This problem shows up with the currently deployment 
scheme of taking the entire URL of a deployment and using that as the 
path under the ${jboss.server.home.dir}/tmp/deploy directory.  This 
means that the length of the filename is now 
"${jboss.server.home.dir}/tmp/deploy".length + url.toString.length.  If 
this is > then the giving crappy limit on win32 we are hosed.

It would be *safer* to employ a different method for the url suffix 
bits, as the first part is a sunk cost.  Sure we can tell users to run 
from a different directory, using a shorter name, but we can't really 
control the URLs that come in for deployment.

I personally have the following setup (which I don not think unreasonable):

 base project dir: /home/jason/workspace/jboss/jboss-all (prefixed by 
c:\cygwin for winblows)

This means that the final value for ${jboss.server.home.dir} is:

C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default

Now the deployments live under conf/ and deploy/ relative to this path, 
longest filename currently seems to be:

new-hsqldb-default-service.xml

which makes the actual deployment file:

C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml

Now this full path will be constructed under:

C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy

making the full deployed filename:

C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy\C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml

with translations applied, I am too lazy for this at the moment.

Now in comes the cache repository.  If I employed the same scheme, then 
the deployment URL which is given to MainDeployer would be about as long 
as the tmp\deploy version... which would then become even longer once it 
was copied to tmp\deploy.

See what I mean?  If this is all because of security policies, then I 
suggest we need to find another way to implement the policy, perhaps 
even punting easier configuration until 1.4 is the defacto.  If not 
please explain why we need this, cause I just don't understand.

These insanely long filenames are going to bite us... they have already 
bitten me several times.

There must be a better solution, which does not force users to hack up 
there environment to work around this OS limitation... perhaps there are 
other OS'n out there which have similar limits... who knows.  Lets not 
stick our necks out to find out.

Can you please explain all of the details why we need these long 
filenames.  I don't get it.

--jason



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

[JBoss-dev] Added Deployer & SubDeployer interfaces

[Jason Dillon]

I just commited the changes to add a Deployer and SubDeployer interface. 
 SubDeployer implementors still need to be hooked up... but at the 
moment that is not needed for this to work.  I added that interface to 
be explicit with respect to the differences between Deployer and 
SubDeployer.

Anyways, Deployer is now configurable via jboss-service.xml for 
DeploymentScanners.  This means that we can implement interceptors 
between the DS and MainDeployer... like a deployment cache for NetBoot.

I will whip up a simple deployment cache for the 3.0 release in the next 
few days.

Enjoy,

--jason


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

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 14:50:00

  Modified:src/main/org/jboss/test/jbossmq/test
SelectorSyntaxUnitTestCase.java
  Log:
   o Applied patch: #530418 added tests to mq Selector unit tests
  
  Revision  ChangesPath
  1.3   +429 -9
jbosstest/src/main/org/jboss/test/jbossmq/test/SelectorSyntaxUnitTestCase.java
  
  Index: SelectorSyntaxUnitTestCase.java
  ===
  RCS file: 
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/test/SelectorSyntaxUnitTestCase.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SelectorSyntaxUnitTestCase.java   15 Feb 2002 23:52:54 -  1.2
  +++ SelectorSyntaxUnitTestCase.java   3 Apr 2002 22:50:00 -   1.3
  @@ -19,7 +19,7 @@
* Needs a lot of work...
*
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @version $Revision: 1.2 $
  + * @version $Revision: 1.3 $
*/
   public class SelectorSyntaxUnitTestCase
  extends TestCase
  @@ -31,25 +31,25 @@
  {
 super(name);
  }
  -
  +   
  protected void setUp() throws Exception
  {
 super.setUp();
 message = new SpyMessage();
  }
  -
  +   
  public void testBooleanTrue() throws Exception
  {
 selector = new Selector("MyBoolean=true");
 testBoolean("MyBoolean", true);
  }
  -
  +   
  public void testBooleanFalse() throws Exception
  -   {   
  +   {
 selector = new Selector("MyBoolean=false");
 testBoolean("MyBoolean", false);
  }
  -
  +   
  private void testBoolean(String name, boolean flag) throws Exception
  {
 message.setBooleanProperty(name, flag);
  @@ -58,15 +58,435 @@
 message.setBooleanProperty(name, !flag);
 assertTrue(!selector.test(message));
  }
  -
  -   public void testStringEquals() throws Exception 
  +   
  +   public void testStringEquals() throws Exception
  {
  +  // First, simple test of string equality and inequality
 selector = new Selector("MyString='astring'");
  -
  +  
 message.setStringProperty("MyString", "astring");
 assertTrue(selector.test(message));
 
 message.setStringProperty("MyString", "NOTastring");
 assertTrue(!selector.test(message));
  +  
  +  // test empty string
  +  selector = new Selector("MyString=''");
  +  
  +  message.setStringProperty("MyString", "");
  +  assertTrue("test 1", selector.test(message));
  +  
  +  message.setStringProperty("MyString", "NOTastring");
  +  assertTrue("test 2", !selector.test(message));
  +  
  +  // test literal apostrophes (which are escaped using two apostrophes
  +  // in selectors)
  +  selector = new Selector("MyString='test JBoss''s selector'");
  +  
  +  // note: apostrophes are not escaped in string properties
  +  message.setStringProperty("MyString", "test JBoss's selector");
  +  // this test fails -- bug 530120
  +  //assertTrue("test 3", selector.test(message));
  +  
  +  message.setStringProperty("MyString", "NOTastring");
  +  assertTrue("test 4", !selector.test(message));
  +  
  +   }
  +   
  +   public void testStringLike() throws Exception
  +   {
  +  // test LIKE operator with no wildcards
  +  selector = new Selector("MyString LIKE 'astring'");
  +  
  +  // test where LIKE operand matches
  +  message.setStringProperty("MyString", "astring");
  +  assertTrue(selector.test(message));
  +  
  +  // test one character string
  +  selector = new Selector("MyString LIKE 'a'");
  +  message.setStringProperty("MyString","a");
  +  assertTrue(selector.test(message));
  +  
  +  // test empty string
  +  selector = new Selector("MyString LIKE ''");
  +  message.setStringProperty("MyString", "");
  +  assertTrue(selector.test(message));
  +  
  +  // tests where operand does not match
  +  selector = new Selector("MyString LIKE 'astring'");
  +  
  +  // test with extra characters at beginning
  +  message.setStringProperty("MyString", "NOTastring");
  +  assertTrue(!selector.test(message));
  +  
  +  // test with extra characters at end
  +  message.setStringProperty("MyString", "astringNOT");
  +  assertTrue(!selector.test(message));
  +  
  +  // test with extra characters in the middle
  +  message.setStringProperty("MyString", "astNOTring");
  +  assertTrue(!selector.test(message));
  +  
  +  // test where operand is entirely different
  +  message.setStringProperty("MyString", "totally different");
  +  assertTrue(!selector.test(message));
  +  
  +  // test case sensitivity
  +  message.setStringProperty("MyString", "ASTRING");
  +  assertTrue(!selector.test(message));
  +  
  +  // test empty string
  +  

[JBoss-dev] Automated JBoss Testsuite Results: 2-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   563



Successful tests:  534

Errors:19

Failures:  10





[time of test: 2 April 2002 5:56 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-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

[JBoss-dev] CVS update: jbosstest build.xml

[Jason Dillon]

  User: user57  
  Date: 02/04/03 14:50:00

  Modified:.build.xml
  Log:
   o Applied patch: #530418 added tests to mq Selector unit tests
  
  Revision  ChangesPath
  1.100 +11 -3 jbosstest/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jbosstest/build.xml,v
  retrieving revision 1.99
  retrieving revision 1.100
  diff -u -r1.99 -r1.100
  --- build.xml 30 Mar 2002 21:01:20 -  1.99
  +++ build.xml 3 Apr 2002 22:50:00 -   1.100
  @@ -13,7 +13,7 @@
   
   
   
  -
  +
   
   
   
  @@ -142,6 +142,13 @@
 
   
   
  +
  +
  +
  +
  +  
  +
  +
   
   
  @@ -151,8 +158,6 @@
 
   
   
  -
  -
   
   
 
  @@ -165,6 +170,9 @@
 
 
 
  +
  +  
  +  
   
   
   
  
  
  

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

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 14:29:35

  Modified:jbossbuild.xml
  Log:
   o applied patch: [ 523396 ] AutoNumber not being built, plus it's broken...
  
  Revision  ChangesPath
  1.113 +2 -1  build/jboss/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/build/jboss/build.xml,v
  retrieving revision 1.112
  retrieving revision 1.113
  diff -u -r1.112 -r1.113
  --- build.xml 25 Mar 2002 00:36:16 -  1.112
  +++ build.xml 3 Apr 2002 22:29:34 -   1.113
  @@ -12,7 +12,7 @@
   
   
   
  -
  +
   
   
   
  @@ -1087,6 +1087,7 @@



  + 
 
   
   
  
  
  

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

Re: [JBoss-dev] Long deployment file names... again

[David Jencks]

What is this problem? I think any reproducible 1-1 mapping will work, but I
don't know of any other than using the whole URL.
david jencks

On 2002.04.03 03:00:46 -0500 Jason Dillon wrote:
> While implementing a simple deployment cache, I ran into the long 
> deployment filename problem again.  
> 
> I am putting cached deployment files under 
> ${jboss.server.home}/data/deployment-cache.  These files are shorter 
> than the orignial urls, basically, I CRC32 the URL.toString(), then 
> append the short filename of the orgininal URL... but still this is too 
> long.
> 
> Do we really need to have the full URL path under 
> ${jboss.server.home}/tmp/deploy ?
> 
> --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

[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/varia/autonumber AutoNumberEJB2.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 14:29:17

  Modified:varia/src/main/org/jboss/varia/autonumber
AutoNumberEJB2.java
  Log:
   o Applied patch: [ 523396 ] AutoNumber not being built, plus it's broken...
  
  Revision  ChangesPath
  1.2   +13 -2 
contrib/varia/src/main/org/jboss/varia/autonumber/AutoNumberEJB2.java
  
  Index: AutoNumberEJB2.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/varia/src/main/org/jboss/varia/autonumber/AutoNumberEJB2.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- AutoNumberEJB2.java   16 Feb 2002 04:41:32 -  1.1
  +++ AutoNumberEJB2.java   3 Apr 2002 22:29:17 -   1.2
  @@ -11,33 +11,44 @@
   import javax.naming.InitialContext;
   
   /**
  - * The CMP 2 compatible version of AutoNumberEJB
  + * The CMP 2 compatible version of AutoNumberEJB.
  + *
  + * @version $Revision: 1.2 $
* @author mailto:[EMAIL PROTECTED]";>Michel de Groot
* @author mailto:[EMAIL PROTECTED]";>Ignacio Coloma
  - * @version $Revision: 1.1 $
*/
   public abstract class AutoNumberEJB2
  implements EntityBean
   {
  public abstract Integer getValue();
  +
  public abstract void setValue(Integer value);
  
  public abstract String getName();
  +
  public abstract void setName(String name);
  
  public String ejbCreate(String name)
  {
  +  setName(name);
  +
 return null;
  }
  
  public void ejbPostCreate(String name) {}
  
  public void ejbActivate() {}
  +
  public void ejbPassivate() {}
  +
  public void ejbLoad() {}
  +
  public void ejbStore() {}
  +
  public void ejbRemove() {}
  +
  public void setEntityContext(javax.ejb.EntityContext unused) {}
  +
  public void unsetEntityContext() {}
  
   }
  
  
  

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

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 14:29:17

  Modified:variabuild.xml
  Log:
   o Applied patch: [ 523396 ] AutoNumber not being built, plus it's broken...
  
  Revision  ChangesPath
  1.28  +8 -1  contrib/varia/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/contrib/varia/build.xml,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- build.xml 23 Mar 2002 21:11:04 -  1.27
  +++ build.xml 3 Apr 2002 22:29:17 -   1.28
  @@ -12,7 +12,7 @@
   
   
   
  -
  +
   
   
   
  @@ -420,6 +420,13 @@
   
   
   -->
  +
  +
  +
  +  
  +
  +  
  +
   
   
   
  
  
  

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

RE: [JBoss-dev] Todo: multiple instances detection

[Bill Burke]

Maybe the invokers should run on a hard-coded port.  With a hard-coded port,
I think references can live beyond the life of the server.  Or maybe I don't
know what I'm talking about :)

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> Dillon
> Sent: Wednesday, April 03, 2002 4:49 PM
> To: marc fleury
> Cc: Jboss-Development@Lists. Sourceforge. Net
> Subject: Re: [JBoss-dev] Todo: multiple instances detection
>
>
> Not sure that an external component is the best choice for this... but I
> have not really thought it through.
>
> On a related note, I sent mail a while ago asking about the web service
> for class loading wtr having it use an anonymous port.  If we set the
> default RMI port to anonymous too, then we only have naming,
> jmx-html-adapter and web ports to deal with.  Once the jmx-html-adapter
> is a .war, then we only have naming and web.
>
> Does anyone know if it is possible to setup on public port, which then
> attaches to other anonymous/random ports, switching based on the
> content.  This would make it look to clients like there was only one
> port, but really there could be many, but the actual numer would
> not matter.
>
> Something like this could (assuming it is possible) would make it easy
> to integrate thirdparty plugins into the single port scheme which simply
> need a port, with out them having to know about a special component or
> conform to a specific api to select a random port or whatever...
>
> --jason
>
>
> marc fleury wrote:
>
> >there should be a service that is part of the first services
> coming up and
> >that detects if other JBoss systems are running on the same physical
> >machines, this is to avoid port conflict as some services are
> holding on to
> >some ports (e.g. naming on 1099, detached RMI, clustered RMI).
> >
> >We would then not start the naming as a duplicate nor the
> detached RMI but
> >we would use the clustered RMI by increasing the connection port.
> >
> >This will enable people to run multiple instances of JBoss
> without having to
> >manually change the stuff all the time.  At least on the
> services we provide
> >we should show how these behave.
> >
> >marcf
> >
> >
> >___
> >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] AutoNumber in Jboss 3.0.0

[Jason Dillon]

I will apply the patch soon... can someone write a testcase for this.

--jason


Jessica Perry Hekman wrote:

>On Wed, 3 Apr 2002, Dain Sundstrom wrote:
>
>>I wasn't aware of this.  Are you sure it was removed?  If you are having
>>problems, post again, and I'll ask around.
>>
>
>I looked in the build.xml file; it is definitely not there (in varia or
>otherwise).
>
>j
>
>---
>  "Users complain that they receive too much spam, while spammers protest
>messages are legal." -InfoWorld
>  "You do not have to do everything disagreeable that you have a right to
>do." -Judith Martin (Miss Manners)
>
>
>
>
>___
>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] Todo: multiple instances detection

[Jason Dillon]

Not sure that an external component is the best choice for this... but I 
have not really thought it through.

On a related note, I sent mail a while ago asking about the web service 
for class loading wtr having it use an anonymous port.  If we set the 
default RMI port to anonymous too, then we only have naming, 
jmx-html-adapter and web ports to deal with.  Once the jmx-html-adapter 
is a .war, then we only have naming and web.

Does anyone know if it is possible to setup on public port, which then 
attaches to other anonymous/random ports, switching based on the 
content.  This would make it look to clients like there was only one 
port, but really there could be many, but the actual numer would not matter.

Something like this could (assuming it is possible) would make it easy 
to integrate thirdparty plugins into the single port scheme which simply 
need a port, with out them having to know about a special component or 
conform to a specific api to select a random port or whatever...

--jason


marc fleury wrote:

>there should be a service that is part of the first services coming up and
>that detects if other JBoss systems are running on the same physical
>machines, this is to avoid port conflict as some services are holding on to
>some ports (e.g. naming on 1099, detached RMI, clustered RMI).
>
>We would then not start the naming as a duplicate nor the detached RMI but
>we would use the clustered RMI by increasing the connection port.
>
>This will enable people to run multiple instances of JBoss without having to
>manually change the stuff all the time.  At least on the services we provide
>we should show how these behave.
>
>marcf
>
>
>___
>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] AutoNumber in Jboss 3.0.0

[Jessica Perry Hekman]

On Wed, 3 Apr 2002, Dain Sundstrom wrote:

> I wasn't aware of this.  Are you sure it was removed?  If you are having
> problems, post again, and I'll ask around.

I looked in the build.xml file; it is definitely not there (in varia or
otherwise).

j

---
  "Users complain that they receive too much spam, while spammers protest
messages are legal." -InfoWorld
  "You do not have to do everything disagreeable that you have a right to
do." -Judith Martin (Miss Manners)




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

[JBoss-dev] Automated JBoss Testsuite Results: 2-April-2002

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   563



Successful tests:  533

Errors:20

Failures:  10





[time of test: 2 April 2002 4:29 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Team]
[java.vm.version: Blackdown-1.3.1-02a-FCS]
[java.vm.name: Classic VM]
[java.vm.info: green threads, nojit]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.9-31]

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





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 really is easy, just use the ant target 'run-basic-testsuite' from the 
build directory.


To just run the unit tests (they are quite quick):

In the testsuite directory, 
./build.sh tests-unit


You can run a single test case using:
./build.sh -Dtest=[XXXTestCase] one-test

The XXXTestCase is the classname of the junit class to run. So, to run the 
EJBSpecUnitTestCase use:
./build.sh -Dtest=EJBSpecUnitTestCase one-test


To run all tests within a package, use
./build.sh -Dtest=[package] test

The package is name of the directory under the org/jboss/test directory that 
contains the tests to run. So, to run the unit tests in the 
org.jboss.test.security package use:
./build.sh -Dtest=security test



Thanks for all your effort - we really do love you!



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

Re: [JBoss-dev] AutoNumber in Jboss 3.0.0

[Jessica Perry Hekman]

On 3 Apr 2002, Marius Kotsbak wrote:

> I just note that since the autonumber was moved to varia (from
> jboss.util?), I get AutoNumber not foud while deploying. I solved this
> by packing the compiled files (by the buildscript) for autonumber into a
> jar and deploy that one, then it works again.

I tried that too; for me, under JBoss 3.0beta, it didn't work. I had to
modify the EJB classes to get it working again. I don't remember exactly
what I did, but would be happy to look if someone is interested.

j

---
  "Users complain that they receive too much spam, while spammers protest
messages are legal." -InfoWorld
  "You do not have to do everything disagreeable that you have a right to
do." -Judith Martin (Miss Manners)



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

Re: [JBoss-dev] CVS write access problem

[Jason Dillon]

What was the CVSROOT you were using?

--jason


Adrian Brock wrote:

>Hi,
>
>I just applied a fix to Branch_2_4.
>I'm trying to tag with Rel_2_4_5_10.
>It gets part way through, then tells me I haven't got
>write access.
>Is this a file system authority?
>
>bash-2.05$ cvs tag Rel_2_4_5_10
>? jboss_co.log
>? jnp_co.log
>? jbosssx_co.log
>? jbossmq_co.log
>? jbosscx_co.log
>? jbosspool_co.log
>? jbossj2ee_co.log
>? tomcat.log
>? catalina.log
>? jetty.log
>? jboss.log
>? jboss-j2ee.log
>? jnp.log
>? jbosssx.log
>? jbosscx.log
>? jbosspool.log
>? jbossmq.log
>? jboss2.log
>cvs server: Tagging .
>cvs server: Tagging docs
>cvs server: Tagging external
>cvs server: Tagging lib
>cvs server: Tagging src
>cvs server: Tagging src/bin
>cvs server: Tagging src/build
>cvs server: Tagging src/client
>cvs server: Tagging src/client/admin
>cvs server: Tagging src/client/admin/lib
>cvs server: Tagging src/docs
>cvs server: Tagging src/docs/images
>cvs server: Tagging src/etc
>cvs server: Tagging src/etc/beaninfo
>cvs server: Tagging src/etc/beaninfo/jaws
>cvs server: Tagging src/etc/conf
>cvs server: Tagging src/etc/conf/default
>cvs server: Tagging src/etc/deploy
>cvs server: Tagging src/lib
>cvs server: Tagging src/main
>cvs server: Tagging src/main/org
>cvs server: Tagging src/main/org/jboss
>cvs server: Tagging src/main/org/jboss/configuration
>cvs server: Tagging src/main/org/jboss/deployment
>cvs server: Tagging src/main/org/jboss/deployment/scope
>cvs server: Tagging src/main/org/jboss/ejb
>cvs server: Tagging src/main/org/jboss/ejb/plugins
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jaws
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jaws/bmp
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jaws/jdbc
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jaws/metadata
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jms
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp/interfaces
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp/server
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp12
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp12/interfaces
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp12/server
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp13
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp13/interfaces
>cvs server: Tagging src/main/org/jboss/ejb/plugins/jrmp13/server
>cvs server: Tagging src/main/org/jboss/ejb/plugins/local
>cvs server: Tagging src/main/org/jboss/ejb/plugins/lock
>cvs server: Tagging src/main/org/jboss/jdbc
>cvs server: Tagging src/main/org/jboss/jms
>cvs server: Tagging src/main/org/jboss/jms/asf
>cvs server: Tagging src/main/org/jboss/jms/jndi
>cvs server: Tagging src/main/org/jboss/jms/ra
>cvs server: Tagging src/main/org/jboss/jms/ra/client
>cvs server: Tagging src/main/org/jboss/jmx
>cvs server: Tagging src/main/org/jboss/jmx/client
>cvs server: Tagging src/main/org/jboss/jmx/interfaces
>cvs server: Tagging src/main/org/jboss/jmx/server
>cvs server: Tagging src/main/org/jboss/logging
>cvs server: Tagging src/main/org/jboss/logging/log4j
>cvs server: Tagging src/main/org/jboss/mail
>cvs server: Tagging src/main/org/jboss/management
>cvs server: Tagging src/main/org/jboss/metadata
>cvs server: Tagging src/main/org/jboss/monitor
>cvs server: Tagging src/main/org/jboss/monitor/client
>cvs server: Tagging src/main/org/jboss/naming
>cvs server: Tagging src/main/org/jboss/naming/java
>cvs server: Tagging src/main/org/jboss/proxy
>cvs server: Tagging src/main/org/jboss/security
>cvs server: Tagging src/main/org/jboss/security/plugins
>cvs server: Tagging src/main/org/jboss/security/plugins/samples
>cvs server: Tagging src/main/org/jboss/tm
>cvs server: Tagging src/main/org/jboss/tm/plugins
>cvs server: Tagging src/main/org/jboss/tm/plugins/tyrex
>cvs server: Tagging src/main/org/jboss/tm/usertx
>cvs server: Tagging src/main/org/jboss/tm/usertx/client
>cvs server: Tagging src/main/org/jboss/tm/usertx/interfaces
>cvs server: Tagging src/main/org/jboss/tm/usertx/server
>cvs server: Tagging src/main/org/jboss/util
>cvs server: Tagging src/main/org/jboss/util/timeout
>cvs server: Tagging src/main/org/jboss/verifier
>cvs server: Tagging src/main/org/jboss/verifier/event
>cvs server: Tagging src/main/org/jboss/verifier/factory
>cvs server: Tagging src/main/org/jboss/verifier/strategy
>cvs server: Tagging src/main/org/jboss/web
>cvs server: Tagging src/main/test
>cvs server: Tagging src/main/test/jboss
>cvs server: Tagging src/main/test/jboss/deployment
>cvs server: Tagging src/main/test/jboss/jmx
>cvs server: Tagging src/main/test/jboss/jrmp
>cvs server: Tagging src/main/test/jboss/minerva
>cvs server: Tagging src/main/test/jboss/minerva/factories
>cvs server: Tagging src/main/test/jboss/minerva/pools
>cvs server: Tagging src/main/test/jboss/naming
>cvs server: Tagging src/main/test/jboss/testdb
>cvs server: Tagging src/resources
>cvs server: Tagging src/resources/org
>cv

Re: [JBoss-dev] I ask for advice on CVS lock

[Jason Dillon]

Did this ever get resolved?

--jason


Oleg Nitz wrote:

>Hi All,
>
>I am trying to update Jetty in JBoss CVS, but there is a lock in 
> /cvsroot/jboss/contrib/jetty/src/main/org/mortbay/http
>so that I cannot commit changes to this dir.
>I don't know how to solve this issue. 
>Probably I should contact somebody from SourceForge?
>Any ideas?
>
>Thanks in advance,
> Oleg
>
>___
>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] AutoNumber in Jboss 3.0.0

[Jason Dillon]

It might have been reomved from building by default due to lack of
maintenece... there is a bug/patch for this... just haven't had time to look
into it yet.

--jason


On Wed, 3 Apr 2002, Dain Sundstrom wrote:

> I wasn't aware of this.  Are you sure it was removed?  If you are having
> problems, post again, and I'll ask around.
>
> -dain
>
> Marius Kotsbak wrote:
>
> > On ons, 2002-03-27 at 23:13, jessica hekman wrote:
> >
> >>I am trying to upgrade from 2.4 to 3.0 in order to use CMP 2.0. However, in moving 
>my application over to 3.0 I'm having trouble using the AutoNumber class. In 2.4 it 
>was in org.jboss.util; in 3.0 it is in org.jboss.varia.autonumber (so far, so good). 
>In 2.4 it was available in ext/jboss.jar; in 3.0 it does not seem to be built into 
>any jar files. Is this intentional? Am I missing it?
> >>
> >>I have been using AutoNumber to generate unique primary keys, which I understand 
>isn't yet handled in any better way in JBoss (but will be soon; I just need a 
>solution in the meantime).
> >>
> >>Thanks!
> >
> > I see that this module is removed from the normal builds. What are we
> > supposed to use for this purpose? the counter service? How does it work?
> >
> > Marius
> > SW dev. Boostcom.no
> >
>
>
>
> ___
> 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: contrib/jboss.net/src/main/org/jboss/net/axis/server AxisService.java AxisServiceMBean.java

[Jason Dillon]

  User: user57  
  Date: 02/04/03 00:44:53

  Modified:jboss.net/src/main/org/jboss/net/axis/server
AxisService.java AxisServiceMBean.java
  Log:
   o DeployerMBean -> SubDeployer
  
  Revision  ChangesPath
  1.15  +10 -9 
contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java
  
  Index: AxisService.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- AxisService.java  12 Mar 2002 11:04:46 -  1.14
  +++ AxisService.java  3 Apr 2002 08:44:52 -   1.15
  @@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
   
  -// $Id: AxisService.java,v 1.14 2002/03/12 11:04:46 cgjung Exp $
  +// $Id: AxisService.java,v 1.15 2002/04/03 08:44:52 user57 Exp $
   
   package org.jboss.net.axis.server;
   
  @@ -16,9 +16,11 @@
   
   import org.jboss.deployment.DeploymentException;
   import org.jboss.deployment.DeploymentInfo;
  +import org.jboss.deployment.MainDeployerMBean;
  +import org.jboss.deployment.SubDeployer;
  +
   import org.jboss.system.ServiceMBeanSupport;
   import org.jboss.web.WebApplication;
  -import org.jboss.deployment.MainDeployerMBean;
   
   import org.apache.log4j.Category;
   import org.apache.log4j.Priority;
  @@ -33,7 +35,6 @@
   import org.jboss.naming.Util;
   import org.jboss.metadata.MetaData;
   import org.jboss.system.server.ServerConfigImplMBean;
  -import org.jboss.deployment.DeployerMBean;
   
   import org.w3c.dom.Document;
   import org.w3c.dom.Element;
  @@ -83,7 +84,7 @@
* 
* @created 27. September 2001
* @author mailto:[EMAIL PROTECTED]";>Christoph G. Jung
  - * @version $Revision: 1.14 $
  + * @version $Revision: 1.15 $
*/
   
   public class AxisService
  @@ -110,7 +111,7 @@
  protected AxisServer axisServer;
   
  /** the web deployer that hosts our servlet */
  -   protected DeployerMBean webDeployer;
  +   protected SubDeployer webDeployer;
   
  //
  // Constructors
  @@ -266,7 +267,7 @@
   .iterator();
   
 while (allDeployers.hasNext() && webDeployer == null) {
  - DeployerMBean nextBean = (DeployerMBean) allDeployers.next();
  + SubDeployer nextBean = (SubDeployer) allDeployers.next();
if (nextBean.accepts(myDeploymentInfo)) {
   webDeployer = nextBean;
}
  @@ -330,7 +331,7 @@
  MainDeployerMBean.OBJECT_NAME,
  "addDeployer",
  new Object[] { this },
  -   new String[] { "org.jboss.deployment.DeployerMBean" });
  +   new String[] { "org.jboss.deployment.SubDeployer" });
} catch (Exception e) {
   log.error("Could not register with MainDeployer", e);
}
  @@ -368,7 +369,7 @@
   MainDeployerMBean.OBJECT_NAME,
   "removeDeployer",
   new Object[] { this },
  -new String[] { "org.jboss.deployment.DeployerMBean" });
  +new String[] { "org.jboss.deployment.SubDeployer" });
 } catch (Exception e) {
log.error("Could not deregister from MainDeployer", e);
 }
  @@ -689,4 +690,4 @@
 return (AxisServer) axisServerMap.get(context);
  }
   
  -}
  \ No newline at end of file
  +}
  
  
  
  1.4   +5 -6  
contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisServiceMBean.java
  
  Index: AxisServiceMBean.java
  ===
  RCS file: 
/cvsroot/jboss/contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisServiceMBean.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- AxisServiceMBean.java 1 Mar 2002 22:12:57 -   1.3
  +++ AxisServiceMBean.java 3 Apr 2002 08:44:52 -   1.4
  @@ -5,7 +5,7 @@
   * See terms of license at gnu.org.
   */
   
  -// $Id: AxisServiceMBean.java,v 1.3 2002/03/01 22:12:57 cgjung Exp $
  +// $Id: AxisServiceMBean.java,v 1.4 2002/04/03 08:44:52 user57 Exp $

   package org.jboss.net.axis.server;
   
  @@ -13,12 +13,11 @@
* Mbean interface to the AxisService 
* @author mailto:[EMAIL PROTECTED]";>Christoph G. Jung
* @created 27. September 2001
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
*/
  -
  -public interface AxisServiceMBean extends org.jboss.deployment.DeployerMBean {
  -  // P---
  -  
  +public interface AxisServiceMBean 
  +   extends org.jboss.deployment.SubDeployerMBean 
  +{
 public String getRootContext();
 public void setRootContext(String name) throws Exception;
 public String getSecurityDomain();
  
  
  

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

[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment/cache DeploymentCache.java DeploymentStore.java FileDeploymentStore.java package.html

[Jason Dillon]

  User: user57  
  Date: 02/04/03 00:29:24

  Added:   src/main/org/jboss/deployment/cache DeploymentCache.java
DeploymentStore.java FileDeploymentStore.java
package.html
  Log:
   o Adding a simple (yet pluggable) deployment cache component with
 a file based storage implementation.
   * Works, but incomplete
  
  Revision  ChangesPath
  1.1  
jboss-system/src/main/org/jboss/deployment/cache/DeploymentCache.java
  
  Index: DeploymentCache.java
  ===
  /***
   * *
   *  JBoss: The OpenSource J2EE WebOS   *
   * *
   *  Distributable under LGPL license.  *
   *  See terms of license at gnu.org.   *
   * *
   ***/
  
  package org.jboss.deployment.cache;
  
  import java.util.Set;
  import java.util.HashSet;
  
  import java.net.URL;
  
  import javax.management.ObjectName;
  import javax.management.MBeanServer;
  
  import org.jboss.system.ServiceMBeanSupport;
  import org.jboss.system.ConfigurationException;
  
  import org.jboss.deployment.Deployer;
  import org.jboss.deployment.DeploymentException;
  
  import org.jboss.util.NullArgumentException;
  import org.jboss.util.jmx.MBeanProxy;
  import org.jboss.util.jmx.MBeanProxyInstance;
  
  /**
   * A Deployer-like service which intercepts deploy/undeploy calls
   * to MainDeployer and provides local caching of target URLs using 
   * local disk.
   *
   * @jmx:mbean extends="org.jboss.system.ServiceMBean, 
org.jboss.deployment.DeployerMBean"
   *
   * @todo clean up stale cache members
   *
   * @version $Revision: 1.1 $
   * @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
   */
  public class DeploymentCache
 extends ServiceMBeanSupport
 implements Deployer, DeploymentCacheMBean
  {
 /** A proxy to the deployer we are using. */
 protected Deployer deployer;
  
 /** A proxy to the deployment store we are using. */
 protected DeploymentStore store;
  
 /** A set of original deployment URLs which are deployed. */
 protected Set deployedSet = new HashSet();
  
  
 /
 //   Pluggables//
 /
  
 /**
  * @jmx:managed-operation
  */
 public void setDeployer(final ObjectName deployerName)
 {
if (deployerName == null)
   throw new NullArgumentException("deployerName");
  
deployer = (Deployer)
   MBeanProxy.create(Deployer.class, deployerName, server);
 }
  
 /**
  * @jmx:managed-operation
  */
 public ObjectName getDeployer()
 {
return ((MBeanProxyInstance)deployer).getMBeanProxyObjectName();
 }
  
 /**
  * @jmx:managed-operation
  */
 public void setStore(final ObjectName storeName)
 {
if (storeName == null)
   throw new NullArgumentException("storeName");
  
store = (DeploymentStore)
   MBeanProxy.create(DeploymentStore.class, storeName, server);
 }
  
 /**
  * @jmx:managed-operation
  */
 public ObjectName getStore()
 {
return ((MBeanProxyInstance)store).getMBeanProxyObjectName();
 }
  
  
 /
 //   Deployer  //
 /
  
 protected long getLastModified(final URL url)
throws Exception
 {
// stupid file: URLConnection does not return lastModified as one
// would expect, so we have to work around it here for now...
// it would be better to wrap the UC, but that is too much work for
// me right now =|
  
if (url.getProtocol().equals("file")) {
   java.io.File file = new java.io.File(url.getFile());
   return file.lastModified();
}
else {
   return url.openConnection().getLastModified();
}
 }
  
 protected boolean isInvalid(final URL orig, final URL stored)
throws Exception
 {
boolean trace = log.isTraceEnabled();
  
long omod = getLastModified(orig);
long smod = getLastModified(stored);
  
if (trace) {
   log.trace("Modfication times (orig, stored): " + omod + ", " + smod);
}

return omod > smod;
 }
  
 public void deploy(final URL url) throws DeploymentException
 {
boolean debug = log.isDebugEnabled();
  
try {
   URL storedURL = store.get(url);
   if (storedURL != null) {
  // it's in the cac

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

[Jason Dillon]

  User: user57  
  Date: 02/04/03 00:35:31

  Modified:src/etc/conf/default jboss-service.xml
  Log:
   o Added comment instructions on how to enable the deployment cache
 component.
  
  Revision  ChangesPath
  1.41  +19 -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.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- jboss-service.xml 2 Apr 2002 19:36:41 -   1.40
  +++ jboss-service.xml 3 Apr 2002 08:35:31 -   1.41
  @@ -1,6 +1,6 @@
   
   
  -
  +
   
   
   
  @@ -22,9 +22,27 @@
 
 
   
  +  
  +
 
  +
  +
   jboss.system:service=MainDeployer
  +
   5000