JBoss daily test results
SUMMARY
Number of tests run: 129
Successful tests: 129
Errors:0
Failures: 0
[time of test: 15 December 2001 7:47 GMT]
[java.version: 1.
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
Hello,
The org.jboss.Shutdown class does
User: starksm
Date: 01/12/14 22:54:07
Modified:src/docs/jbossgroup partners.jsp
Added: src/docs/jbossgroup mvcsoft.jsp
Log:
Update the MVCSoft Persistence Manager section and read more file
Revision ChangesPath
1.5 +10 -10newsite/src/docs/jbossgroup/pa
> > That's fine. This should be done using the java.security.MessageDigest
class
> > so that additional one-way hash algorigthms may be introduced using
> > java.security.MessageDigestSpi subclasses.
> >
>
> But isn't that part of the JCA* stuff - you should only have to specify
> an algorithm na
Just noticed.
It looks like I completely contradicted by first post.
>Personally, I think this policy decision should be passed to each deployer
>The deployers should be dumb
My first sentence is about allowing each deployer
to implement redeploy() in an optimized/seamless way.
Its probably cl
David,
I agree to an extent.
The deployers should be dumb. Deploy this please,
remove this please, can you deploy this?
But something has to hold the state of what's deployed and it isn't currently the
AutoDeployer?
e.g. If I manually deploy something from file:/some/where/else
I want to be
Scott M Stark wrote:
>>
>>I'll have a go at modifying UsernamePasswordLoginModule accordingly...
>>
> That's fine. This should be done using the java.security.MessageDigest class
> so that additional one-way hash algorigthms may be introduced using
> java.security.MessageDigestSpi subclasses.
>
>
> Ah yes, of course. I only meant storing digests of the passwords,
> nothing to do with HTTP authentication protocols. I don't know why I
> said digest authentication, because that's obviously something competely
> different.
>
> I'll have a go at modifying UsernamePasswordLoginModule according
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
Hello,
The org.jboss.Shutdown class does
JBoss daily test results
SUMMARY
Number of tests run: 129
Successful tests: 127
Errors:2
Failures: 0
[time of test: 15 December 2001 5:3 GMT]
[java.version: 1.3
Scott M Stark wrote:
> It would be good to add a hash of the password, but this is not
> digest authentication as in HTTP digest authentication.
Ah yes, of course. I only meant storing digests of the passwords,
nothing to do with HTTP authentication protocols. I don't know why I
said digest
User: ejort
Date: 01/12/14 20:48:04
Modified:src/main/javax/management AttributeChangeNotification.java
Log:
Implement AttributeChangeNotification
Revision ChangesPath
1.2 +139 -17 jmx/src/main/javax/management/AttributeChangeNotification.java
Index: Attr
I would like deployers to only do as they are told and autodeployer to
undeploy and redeploy when it notices a timestamp change. I don't like
deployers second guessing my intentions.
If you are going to change the behavior (I think it should change) please
change autodeployer rather than deploye
I'm not sure of the exact status of j2ee deployer right now, but it is
possible that if you put a sar inside an ear with a classpath reference to
your jars they would get deployed. Also you can simply deploy a
myapp-service.xml file with a reference to the jars. BOth
of these will load the clas
User: ejort
Date: 01/12/14 20:00:24
Modified:src/main/javax/management Attribute.java
Log:
JMX Javadoc
Revision ChangesPath
1.2 +76 -7 jmx/src/main/javax/management/Attribute.java
Index: Attribute.java
=
User: ejort
Date: 01/12/14 19:23:24
Modified:.build.xml
Log:
Added javax.management.* packages to the API output
It appears in OtherPackages group in Javadoc (correct?)
Revision ChangesPath
1.3 +2 -2 jmx/build.xml
Index: build.xml
=
Hi,
Method DeployerMBeanSupport.deploy(URL)
stops any derived deployers redeploying changed urls spotted by the AutoDeployer.
Personally, I think this policy decision should be passed to each deployer.
But the proposed change is always do an undeploy then a deploy, just like J2eeDeployer.
Does
User: user57
Date: 01/12/14 18:19:58
Modified:.build.xml
Log:
o only load the source files which have xdoclet tags. assume that files
ending with Bean and not MBean will have these tags.
Revision ChangesPath
1.47 +5 -3 jboss/build.xml
Inde
Looks like my environment was hosed... please ignore. =|
__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66&thread=5720
___
Jboss-developmen
User: ejort
Date: 01/12/14 17:12:38
Modified:src/main/org/jboss/mx/server MBeanInvoker.java
Log:
Javadoc for DynamicMBean and other javadoc tidy-up
Revision ChangesPath
1.2 +1 -2 jmx/src/main/org/jboss/mx/server/MBeanInvoker.java
Index: MBeanInvoker.ja
User: ejort
Date: 01/12/14 17:12:37
Modified:src/main/javax/management
AttributeChangeNotificationFilter.java
DynamicMBean.java
Log:
Javadoc for DynamicMBean and other javadoc tidy-up
Revision ChangesPath
1.2 +2 -2
User: ejort
Date: 01/12/14 17:12:38
Modified:src/main/org/jboss/mx/server/registry
BasicMBeanRegistry.java
Log:
Javadoc for DynamicMBean and other javadoc tidy-up
Revision ChangesPath
1.5 +2 -2
jmx/src/main/org/jboss/mx/server/regis
User: ejort
Date: 01/12/14 17:12:38
Modified:src/main/javax/management/modelmbean ModelMBean.java
ModelMBeanConstructorInfo.java
ModelMBeanOperationInfo.java
Log:
Javadoc for DynamicMBean and other javadoc tidy-up
Revision Cha
User: ejort
Date: 01/12/14 17:12:38
Modified:src/main/org/jboss/mx/interceptor LogInterceptor.java
ModelMBeanInterceptor.java
Log:
Javadoc for DynamicMBean and other javadoc tidy-up
Revision ChangesPath
1.2 +2 -2 jmx/src/main/org/jbo
I am getting this after an update:
compile-classes:
[javac] Compiling 17 source files to
/nfs/home/jason/ws/jboss/jboss-all/serv
er/output/classes
/nfs/home/jason/ws/jboss/jboss-all/server/src/main/org/jboss/management/j2ee/Con
nectorModule.java:30: getResourceAdapters() in
org.jboss.manage
Bugs item #493519, was opened at 2001-12-14 16:30
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=493519&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Cook (oravecz)
Assigned to: N
Where does one specify the dependency libs for an ejb deployment now? Used
to drop them into lib/ext and restart... now looks like I might need to modify
jboss-service.xml, but that seems like it is a bad idea.
Perhaps jboss.xml needs (or has) some facility to do the samething that
does in j
It would be good to add a hash of the password, but this is not
digest authentication as in HTTP digest authentication. For that,
a server side component must supply a challenge. This is a weak
challenge, much weaker than the SRP login protocol. An HTTP
digest login proceedure would have to be a n
This occurs for what? The tests of deployed ears work fine.
- Original Message -
From: "Bill Burke" <[EMAIL PROTECTED]>
To: "Jboss-Development@Lists. Sourceforge. Net"
<[EMAIL PROTECTED]>
Sent: Friday, December 14, 2001 9:06 AM
Subject: [JBoss-dev] Need help fixing 2.4.4beta and Tomcat 4
User: schaefera
Date: 01/12/14 13:01:12
Added: src/resources/util test-default-scheduler-service.xml
Log:
Added a test suite to check the Scheduler (only one test added but
there will come more).
Revision ChangesPath
1.1 jbosstest/src/resources/util/
User: schaefera
Date: 01/12/14 13:01:12
Modified:sun/jsr77/lib jsr77.jar
Log:
Added a test suite to check the Scheduler (only one test added but
there will come more).
Revision ChangesPath
1.11 +61 -66thirdparty/sun/jsr77/lib/jsr77.jar
<>
___
User: schaefera
Date: 01/12/14 13:01:11
Modified:.build.xml
Log:
Added a test suite to check the Scheduler (only one test added but
there will come more).
Revision ChangesPath
1.48 +52 -1 jbosstest/build.xml
Index: build.xml
User: schaefera
Date: 01/12/14 13:01:11
Added: src/main/org/jboss/test/util/test SchedulerUnitTestCase.java
Log:
Added a test suite to check the Scheduler (only one test added but
there will come more).
Revision ChangesPath
1.1
jbosstest/src/main/or
Bugs item #490156, was opened at 2001-12-07 00:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=490156&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Rune Hamnvik (runeh)
>Assigned t
User: schaefera
Date: 01/12/14 12:57:59
jbosstest/src/main/org/jboss/test/util/test - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 01/12/14 12:56:39
jbosstest/src/resources/util - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
but from the reading that I make in the container of the use of "beanMapping" I find
it silly.
Correct me if I am wrong but since the use of bean mapping in EJB standard is to cover
interface->bean mapping (remember the bean doesn't implement the interface) then it is
useless in the case of
Hi all,
I just got a mail from a guy asking about digest authentication and if
it would be possible to include an extra login module which provides this.
It would be useful to have this available without having to supply a
different login module, so can anyone think of any reasons for not
mo
Hello,
I see a current behaviour with the last 3.0 snapshot and the 3.0 alpha. The
home stub of a bean is not bound to the jndi name that is specified in
jboss.xml. Example below uses testbean2.jar from the testsuite.
After a compilation from a clean snapshot, I deployed testbean2.jar and
checke
Nothing gets configured for the root context w/ jboss-catalina.
Usually, their is a tomcat-test.ear to test the embedded catalina. Otherwise, throw an
ear out there with a context root and it works just fine.
--javabettin
__
V
I need a hint on what this could be so that I can fix itI can run
catalina standalone and everything works.
Thanks in advance,
Bill
[12:02:37,769,EmbeddedCatalinaServiceSX] StandardHost[localhost]: MAPPING
configuration error for request URI
[12:02:37,789,EmbeddedCatalinaServiceSX] HttpProc
Touching the deployment descriptor will reload everything, but the
libs may not be correctly updated due to an existing ZipFile bug:
http://developer.java.sun.com/developer/bugParade/bugs/4388666.html
- Original Message -
From: "Dave" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thur
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
Hello,
The org.jboss.Shutdown class does
JBoss daily test results
SUMMARY
Number of tests run: 127
Successful tests: 127
Errors:0
Failures: 0
[time of test: 14 December 2001 11:58 GMT]
[java.version: 1
On Thu, 13 Dec 2001, Jason Dillon wrote:
> > Because I was still seeing javadoc tasks running. Looking closer these
> > are all xdoclet taks.
>
> Sure are... too bad javadoc won't run in the same vm, cause it slows things
> down quite a bit.
Inside the XDoclet project there is a subproject to
Title: KOSFA INDUSTRIAL CO
RANGE: 1.
AUTOMOTIVE REPLACEMENT PARTS FOR
TOYOTA, NISSAN,
JBoss daily test results
SUMMARY
Number of tests run: 201
Successful tests: 201
Errors:0
Failures: 0
[time of test: 14 December 2001 9:12 GMT]
[java.version: 1.
47 matches
Mail list logo
