JBoss daily test results
SUMMARY
Number of tests run: 21
Successful tests: 15
Errors:6
Failures: 0
[time of test: 22 September 2001 7:46 GMT]
[java.version:
Bugs item #463790, was opened at 2001-09-22 05:33
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463790group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to:
Why not place each virtual host in a differnt deploy directory
where an config file in that dir contains the directives for the virtual
host
for example
JBOSS_HOME/deploy/anhost
host.xml
this my beplaced in another config file like core-service.xml or
User: pra
Date: 01/09/22 07:00:42
Modified:src/main/org/jboss/jms/ra JmsManagedConnection.java
Log:
Fixed connection bug. Connection was never started and therefore sync receive did
not work. Hereby fixed.
Revision ChangesPath
1.7 +2 -2
User: pra
Date: 01/09/22 07:05:21
Added: src/main/org/jboss/test/jmsra/bean QueueRec.java
QueueRecBean.java QueueRecHome.java
Log:
Adding test for sync receive
Revision ChangesPath
1.1
User: pra
Date: 01/09/22 07:06:15
Modified:src/resources/jmsra/META-INF ejb-jar.xml jboss.xml
Log:
Adding test for sync receive
Revision ChangesPath
1.2 +21 -0 jbosstest/src/resources/jmsra/META-INF/ejb-jar.xml
Index: ejb-jar.xml
User: pra
Date: 01/09/22 07:05:22
Added: src/main/org/jboss/test/jmsra/test
RaSyncRecUnitTestCase.java
Log:
Adding test for sync receive
Revision ChangesPath
1.1
Hello,
Do you know why jetty is so long to stop when stopping JBoss (current MAIN
CVS snapshot)? Is it only my config or do you also have long waiting time
(compared to all other services)?
Cheers,
Sacha
___
User: pra
Date: 01/09/22 08:51:39
Modified:src/main/org/jboss/jms/ra Tag: Branch_2_4
JmsManagedConnection.java
Log:
Backported connection start bug to 2.4 branch, now sync receive work
Revision ChangesPath
No revision
Hi,
I'd like to change the sar format to be more in line with other compressed
non jar package formats:
a sar file will contain a META-INF/jboss-service.xml file (in its current
format) and any number of other compressed package files (jar, rar, ear
etc) in an arbitrary directory structure.
Also, a question about j2ee deployment. (sorry I've only been looking at
j2ee pfd 3) There are a lot of classpath descriptions in section 8.3.1/2
etc. referring to using manifest classpath entries to figure out what to
include in the application classpath. However, it seems to me that if
Hi David
I am not quite happy with this because of:
- Whereas JAR, RAR, WAR and EAR files are vendor
neutral archives is the SAR/JSR not vendor neutral
(it also has nothing to do with J2EE but with JMX).
- SAR/JSR components (resources) servers more than
just one application therefore
Be more precise about what security can be enforced at the packaging level.
All I can see is the file permission on expanded directories but that is
all.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Nick
|Betteridge
|Sent: Saturday,
|a sar file will contain a META-INF/jboss-service.xml file (in its current
ok
|format) and any number of other compressed package files (jar, rar, ear
|etc) in an arbitrary directory structure. When deploying a sar file, all
I don't understand the package files in arbitrary directory
|I am not quite happy with this because of:
|
|- Whereas JAR, RAR, WAR and EAR files are vendor
| neutral archives is the SAR/JSR not vendor neutral
| (it also has nothing to do with J2EE but with JMX).
See my previous mail, sars are not encompassing units in my mind, or at
least David has
On 2001.09.22 12:54:16 -0400 Nick Betteridge wrote:
Also, a question about j2ee deployment. (sorry I've only been looking
at
j2ee pfd 3) There are a lot of classpath descriptions in section
8.3.1/2
etc. referring to using manifest classpath entries to figure out what
to
include in
On 2001.09.22 13:31:47 -0400 Andreas Schaefer wrote:
Hi David
I am not quite happy with this because of:
- Whereas JAR, RAR, WAR and EAR files are vendor
neutral archives is the SAR/JSR not vendor neutral
(it also has nothing to do with J2EE but with JMX).
- SAR/JSR components
Not talking filesystems here. If one has a number of different domains
(eg security, personnel, marketing, customer service etc) and they all
have their own environment for developing applications and they are all
using the same server to deploy. They all defer to the same mechanism
for building
|--including non jar packages in the classpaths of a *service.xml sar
|configuration file. This is free, and very useful for for instance making
|sure a resource adapter is deployed before your ConnectionFactoryLoader
|mbean that uses it and your xxx mbean that on startup needs the
|Not talking filesystems here. If one has a number of different domains
|(eg security, personnel, marketing, customer service etc) and they all
|have their own environment for developing applications and they are all
|using the same server to deploy. They all defer to the same mechanism
|for
On 2001.09.22 14:16:25 -0400 marc fleury wrote:
|a sar file will contain a META-INF/jboss-service.xml file (in its
current
ok
|format) and any number of other compressed package files (jar, rar, ear
|etc) in an arbitrary directory structure. When deploying a sar file,
all
I don't
This mailing system is driving me crazy - I write something and I'm
already an hour out of sync.
I think that this is an issue and as it addresses security, I think that
spending just a little time on getting it right at the beginning will
make for a sweet, long lasting recipe.
An example that
|Well I would hope people would keep it simple and use
|jar1
|jar1
|rar1
|jar3
|META-INF/jboss-service.xml
where do you put the simple classes for the SAR (WHAT THIS IS SUPPOSED TO DO
IN THE FIRST PLACE). The current stuff is
dir1/dir2/class1
META-INF/jboss-service.xml
which is what the jar
On 2001.09.22 14:57:36 -0400 marc fleury wrote:
|--including non jar packages in the classpaths of a *service.xml sar
|configuration file. This is free, and very useful for for instance
making
|sure a resource adapter is deployed before your ConnectionFactoryLoader
|mbean that uses it and
Hi David
My view is that services (in JSR-77 notion: resources) are made available
by the J2EE administartor to the entire server. It is the responsibility
of
the deployer to ensure that all needed resources are available but it is
not his job to create them because it is the job of the
|--including *service.xml files in ears, or sars in ears. One of these
is
|convenient for making an ear application that contains mbeans, is
|deployable as it stands on jboss (the mbean codebase and configuration
|being in the included sar), yet can be deployed (as an ear) on other
|Well the ConnectionFactoryLoader mbean is but needing a RAR to be deployed
|is not -- there is no mbean for a rar.
That's a point.
| that's great but we don't have a single real life scenario that warrants
| this, do we?
|
|Don't lots of people have app-specific mbeans? Don't they want to
|If you are using app-specific MBeans w/o looking them up through JNDI
|you are not J2EE compliant.
he is not talking about that he is talking about the packaging.
Relax
|But then the lookup is again not J2EE compliant. And also how does then
|the administator administer all these private
|My view is that services (in JSR-77 notion: resources) are made available
|by the J2EE administartor to the entire server. It is the responsibility
|of
|the deployer to ensure that all needed resources are available but it is
|not his job to create them because it is the job of the
|I don't know about datasources. MBeans that are application dependent (as
|David is saying) are normal and quite common. Those MBeans can now be
|packaged as a SAR and be managed as part of the application deployment,
|clear, clean.
In other words, that part is actually a valid implementation
Well marc, my goal here is to get a good system that works as well as
possible and is as simple as practical, not to piss you off. I apologize
for this inadvertent side effect. This is not the simplest thing I have
ever worked on, and I'm kind of thinking out loud.
One thing I feel really
JBoss daily test results
SUMMARY
Number of tests run: 111
Successful tests: 89
Errors:19
Failures: 3
[time of test: 23 September 2001 3:27 GMT]
[java.version:
JBoss daily test results
SUMMARY
Number of tests run: 128
Successful tests: 118
Errors:8
Failures: 2
[time of test: 23 September 2001 4:17 GMT]
[java.version:
JBoss daily test results
SUMMARY
Number of tests run: 111
Successful tests: 90
Errors:18
Failures: 3
[time of test: 23 September 2001 5:27 GMT]
[java.version:
JBoss daily test results
SUMMARY
Number of tests run: 128
Successful tests: 118
Errors:8
Failures: 2
[time of test: 23 September 2001 6:26 GMT]
[java.version:
35 matches
Mail list logo
