-Ursprüngliche Nachricht-
Von: David Jencks [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 26. September 2001 20:41
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local
directories. (rh/3.0)
Hmm, I guess I should experiment and see if a url like
Hi David,
[This thread was actually started in the messaging forum
(http://www.jboss.org/forums/thread.jsp?forum=48thread=2169).
David Jencks wrote:
Aha! you have to set minsize 0 in the pool unless you
can supply default credentials to the adapter. In
this case, the adapter does not
Hi,
now it has happened two days in a row. When i try to work with the CVS
HEAD when I wake up here in Europe it is broken.
You americans, please, please try to check that your last late night
check ins at least compile!
//Peter
--
Jobba hos oss: http://www.tim.se/weblab
on 1-09-26 22.33, Jason Dillon at [EMAIL PROTECTED] wrote:
Anyways, the class loader stuff is nice, as it makes it easy to pull in
files, but it sucks when you really need to work with a set of files. We
can build a system to make accessing such a set network transparent
(based on http,
On 27 Sep, Till: [EMAIL PROTECTED] wrote:
Hi, a quick look into the spec shows that the JMS ra is probably not
spec compliant since it will not work with a ConnectionInfoRequest set
to null. I am working on this now, but I can not test it today since the
CVS tree is broken (again). I will come
Hi,
I can't get the new Deployer to work.
If I only include deploy.jar in path I get a classdef not found:
[java] Exception in thread main java.lang.NoClassDefFoundError:
org.jboss.jmx.connector.notification.JMSNotificationListener
[java] at
Hi,
I had to play a little with the sar deployer when testing the new jmsra
stuff, and I have a question: was it not meant that it should be
possible to reconfigure your resources hot, for instance to be able to
change the attributes of a resource in runtime without having to stop
the server.
I am at work - so can't do anything about this until
this evening - GMT.
If the Jetty build is broken, then I would be
surprised if I broke it - I haven't checked anything
back in for a while, and was very careful to make sure
that everything built last time I did so.
If it does turn out to be
I just tried this:
bash-2.02$ diff -r JBoss-2.4.1
JBoss-2.4.1_Tomcat-3.2.3/jboss | grep -v Binary | grep
-v Common
Only in JBoss-2.4.1: docs
Only in JBoss-2.4.1: external
Only in JBoss-2.4.1: src
Only in JBoss-2.4.1_Tomcat-3.2.3/jboss/bin:
run_with_tomcat.bat
Only in
Anybody have any ideas concerning synchronising hsqldb'd in a cluster ? ...
CUTE
hsqldb could be a convenient resource/properties lookup in a distributed
environment ? ...
/CUTE
/peter_f
___
Jboss-development mailing list
[EMAIL PROTECTED]
Well one thing that would be nice would be to get the tests to where they
need to be so we can make sure that commiters have something to check
against.
that being said that Head that doesn't *compile* isn't good. Is that what
you are talking about? You don't need tests for that...
marcf
I was thinking last night g
David came back with the original proposal I did when designing it and I
kind of like it.
It goes like this, we can
1- keep the current sar format with xml and classes inside. This kind of
packaging is heavy and today is prone to class duplication in the different
On 2001.09.27 03:19:30 -0400 Jung , Dr. Christoph wrote:
-Ursprüngliche Nachricht-
Von: David Jencks [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 26. September 2001 20:41
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local
directories. (rh/3.0)
On 27 Sep, marc fleury wrote:
Well one thing that would be nice would be to get the tests to where they
need to be so we can make sure that commiters have something to check
against.
that being said that Head that doesn't *compile* isn't good. Is that what
you are talking about? You
I got jetty to build by copying the jboss/conf/dadada/jetty-service.xml into
jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml
or so, maybe that little helps.
CGJ
-Ursprüngliche Nachricht-
Von: Peter Antman [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 27. September 2001
User: pra
Date: 01/09/27 06:25:22
Modified:src/main/org/jboss/jms/ra JmsConnectionRequestInfo.java
JmsManagedConnectionFactory.java
Added: src/main/org/jboss/jms/ra JmsMCFProperties.java
StringUtil.java
Log:
Fixed problem
Yes, the nested jar: trick was just so (if the opening jar prevents you
from moving/changing it problem got fixed
I´m not sure, do you think that the java.util.zip.ZipStreams are flexible
enough to change
nested directories on the fly?
CGJ
___
User: pra
Date: 01/09/27 06:26:22
Modified:src/resources/org/jboss/jms/ra/META-INF ra.xml
Log:
Added new MCF properties UserName, Password and SessionDefaultType.
Revision ChangesPath
1.5 +18 -1 jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml
Hi Peter,
1. Right now you have to specifically undeploy a package and then redeploy
it. Very shortly I should have it so that the autodeployer does this for
you if a timestamp changes.
2.a. Well, the j2ee deployer is configured to need Jetty, so I think the
current deployment is consistent.
User: pra
Date: 01/09/27 06:32:05
Modified:src/etc/conf/default jms-service.xml
Log:
Added ConnectionManagerProperties, mostly to show how the properties UserName,
Password and SessionDefaultType are now possible to use.
Revision ChangesPath
1.3 +5 -0
|Yes, the nested jar: trick was just so (if the opening jar prevents you
|from moving/changing it problem got fixed we wouldn't have to copy and
|completely unpack highly nested packages (jar in rar in ear is the deepest
|nesting I know of required by sun). This is pretty much the limitation in
Hi.
I have the following problem: i'm calling a Session Stateless Bean from a
bean.
The Session Bean just execute some insert or update statements into a
PostgreSQL DB (first it tries to insert a record in the DB,
if an exception occurres, it execute an update statement; if another
exception
Hi, on the whole I think it works verry nice. Great work. But...
On 27 Sep, David Jencks wrote:
Hi Peter,
1. Right now you have to specifically undeploy a package and then redeploy
it. Very shortly I should have it so that the autodeployer does this for
you if a timestamp changes.
I tested
All,
I'm using jBoss 2.2.2 with Java 1.3.1 and have a question concerning the
behavior of the DriverManager.
Essentially I've provided a simple implementation of the java.sql.Driver
interface. At the moment one of the things it does is try to obtain a list
of other registered drivers by
?? I don't understand. What needs changing on the fly? If you redeploy a
nested package (ear contains rar contains jar), you're going to be changing
the timestamp on the ear, so the entire ear will be undeployed, throwing
away all its URLClassloaders, and redeployed, getting entirely new ones.
I still find this pretty confusing.. Yesterday the deployments from the
testsuite were working for me (basically from JBossTestServices, and the
build.xml sets the classpath). Are you doing something similar?
david jencks
On 2001.09.27 06:35:46 -0400 Peter Antman wrote:
Hi,
I can't get the
-Ursprüngliche Nachricht-
Von: David Jencks [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 27. September 2001 16:16
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local
directori es. (rh/3.0)
?? I don't understand. What needs changing on the fly?
I
27 matches
Mail list logo
