Patches item #612023, was opened at 2002-09-20 08:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=612023group_id=22866
Category: JBossMQ
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Conner (kevinconner)
Assigned to:
Patches item #612033, was opened at 2002-09-20 09:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=612033group_id=22866
Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marian Kelc (mkelc)
Assigned to:
There have been a number of changes to the proxy compiler code in the past
7 days by Hiram. Were these changes tested against the full testsuite? Also,
the formatting of these changes is screwed up. Please test and fix both the
problem and the formatting.
Scott Stark
I fixed the immeadiate problem which was causing the NPE, but these recent changes
still need to be validated against the full testsuite.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Scott M Stark
Hi all,
The AuthenticationManager.isValid(principal,credential) isn't a good fit for
certificates AFAICS, because you don't know the principal name before you've
authenticated the credential.
I am extending the jetty and tomcat bindings to support certificate
authentication to a JAAS
You'll have to describe the usecase better. Why can't the principal name
be taken from the cert subject distinguished name? Why not incorporate
the cert into the credential rather than the principal?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Bugs item #612087, was opened at 2002-09-20 05:03
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=612087group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to:
The jetty ClientCertAuthenticator has the following code
java.security.cert.X509Certificate[] certs =
(java.security.cert.X509Certificate[])
request.getAttribute(javax.servlet.request.X509Certificate);
if (certs==null || certs.length==0 || certs[0]==null)
Jason,
Since you asked...
I'd like to see a documentation task so that one can generate just the
documentation for any module. I like to use the Javadocs when looking at
the code, but don't want to wait for the lengthy build all process just to
see them.
- Matt
-Original
I'll look into it right away.
Regards,
Hiram
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
Sent: Friday, September 20, 2002 7:10 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Proxy generator broken
I fixed the immeadiate
Hi Greg, Hi Scott,
Thanks for your replies.
Unfortunately, unlike Jetty, JbossSX does require that the principal be the
same for each subsequent call into the security layer after the initial
auth, since JaasSecurityManager caches the subject information based on
principal. This means AFAIK I
Dawes, Phil wrote:
Unfortunately, unlike Jetty, JbossSX does require that the principal be the
same for each subsequent call into the security layer after the initial
auth, since JaasSecurityManager caches the subject information based on
principal. This means AFAIK I can't switch the
CGJ JBoss.Net Developers,
First, let me say Thank you. I now have MBeans in the server exposed as
web services. Although it took a bit of research to figure out how to do
this, the minimal amount of (xml) code required to expose MBeans as
webservices (should I call this JMX.Net?) speaks for
Thanks Scott.
I think the proxy code needs a good rewrite. It seems to use a lot
complicated code and array tricks because the writer decided not to use
the collections APIs.
If we can simplify this code, I think we should change our usage of
java.util.Proxy over to our generator, as ours
I think it would be cool (which means it is not a formal request) to be
able to have some tasks that can build the javadocs and push them to our
webserver (of course you would have to authenticate by hand). It would
be nice if this were simple, so we can have (trusted) others post
results to
I agree. Having them posted might encourage people to make them more
accurate and comprehensive.
The xdoclet-generated todo list would be good also. This is now generated
by the all build.
Along with the javadocs I'd like to suggest we work a little more on the
jmx-api docs I started on that
Hi Scott,
Yeh, we could do this, but see later.
There is no real reason why this shouldn't be a valid ObjectName
jboss.j2ee:service=Ejb,jndi-name=java:/blah
other than the spec of course.
Only the first : has any relevence for parsing.
The other reserved characters =*, are similar although ,
It sounds like to me you simply want to be able to get a principal with
a meaningful name in application code through HttpServletRequest.getUserPrincipal.
This is already supported through the CallerPrincipal mapping. The login
module simply creates a java.security.acl.Group named CallerPrincipal
The one item I have run into now and then are not being able to see the
default property settings that drive the build because they are stuck in
a buildmagic jar someplace. All the properties and their defaults should
be readily available as a file included into the build so that problems are
Patches item #612217, was opened at 2002-09-20 19:50
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=612217group_id=22866
Category: JBossSX
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Levart (plevart)
Assigned to:
Bugs item #612242, was opened at 2002-09-20 13:38
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=612242group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Dain Sundstrom (dsundstrom)
Less mysteriousness, as in:
!--
| Initialize the build system. Must depend on '_buildmagic:init'.
| Other targets should depend on 'init' or things will mysteriously fail.
--
target name=init unless=init.disable depends=_buildmagic:init
/target
I would like standard Ant +
`build.sh docs`
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED]] On Behalf Of Matt Munz
Sent: Friday, September 20, 2002 5:51 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Give me your build system complaints or
desires...
Jason,
Can you find any more info about using xslt or velocity as a
preprocessor to the build files? I think this might be a good idea, but
just as you say I can not find any examples of it to study.
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED]] On
So all of the examples you list which depend on other modules to
function are integration tests. You could imagine that for Naming you
might have a simple test which only tests the basic protocol
handshaking, versioning or whatever. For transactions you might have a
simple test to make sure
Yes, once there is a decent include mechanism, either scripted or
whatever, we can have all of the default includes and whatnot in plain
view, probably under tools/* somewhere.
Buildmagic was put together to get around some issues with Ant 1.2.
Since then things have changed. It should be
Jason,
Did you just add this feature to cvs? I tried this on my machine (current
as of yesterday) with the following results.
D:\programs\jboss-versions\jboss-all-HEAD\jboss-all\buildbuild
docs -Dmodules=jmx
Calling ..\tools\bin\ant.bat docs -Dmodules jmx
Buildfile: build.xml
Trying to
Not sure what you may want to do with XSL, but we use it for our
product's build system and I use it for a personal project as well. Its
quite powerful, since you have define a modules.xml that has all the
dependencies and let XSL generate the right build targets. It would
offer primary targets
Please explain this to me... I don't get why this is needed.
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing
Hrm... I can't really say why this does not work. The build system has
changed since I last was actively maintaining it. Try:
jmx/build.sh docs
and look in jmx/output/api for the javadocs.
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED]] On
Its not clear to me. What is the module closest to testing the progation of the
security context from a war to an EJB over SSL with authentication done using
client certificates? I don't buy the organizational concept as most of the work
is setting up the components, not the basic functionality
Jason,
jmx/build.sh docs
yep. That does it. Thanks.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
Dillon
Sent: Friday, September 20, 2002 3:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Give me your build system complaints
Juha didn't want all of thirdparty downloaded to build the jmx project
(outside of jboss). I wrote something with 2 chunks, roughly jmx-only and
all. Dain generalized this to only include libraries that actually are
available.
I don't completely understand why this is needed either, but
This is exactly my point. This is the same thing that I am saying.
most of the work is setting up the components, not the basic
functionality
testing. If there are truly module isolated functional tests, put
these in
the module, but cross module testing belongs in a teststuite module
with
I've seen similar explanations on the ant list sometimes, but they all go
way over my head. Is there any chance of showing us one of these projects
build system to look at in detail?
thanks
david jencks
On 2002.09.20 15:49:51 -0400 James Higginbotham wrote:
Not sure what you may want to do
I can't release the scripts from the company I work at, but I can point
you to a project I work on that is simply a website put together using
XSL + XML. It uses the same principles in its design and should give you
an overview. Using anon CVS to fetch:
cvs -d:pserver:[EMAIL
The only bits that are not lazy are the glob specs... like *.jar, so
simply listing the jars explicitly will resolve this without needing to
check for the availability of them.
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED]] On Behalf Of David
For a variety of 'business reasons', we're running tomcat instead of jetty,
and would very much benefit from being on the 4.1.10 release. I've been
working on getting jboss 3.2 integrate with tomcat 4.10, and for the most
part, it's an easy upgrade.
On 9/16, I checked out Branch_3_2, and
When you deploy a web application utilizing Tomcat/Catalina with JBoss 3.0
and Tomcat 4.0.3, how does JBoss work with the application.xml in the
[JBOSS_HOME]/server/default/deploy/web-application.ear, if at all?
Micael
P.S. The application.xml is in the web-applicationWEB-INF/application.xml
Then don't use 10 paragraphs to say it.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, September 20, 2002 1:20 PM
Subject: RE:
I did not know that.
Do we care about all the library available tasks? The take no time, but
print a lot of stuff during build.
If we do care, do you want to make the change Jason? Otherwise, I can.
-dain
Jason Dillon wrote:
The only bits that are not lazy are the glob specs... like
Number of tests run: 929
Successful tests: 901
Errors:20
Failures: 8
[time of test: 21 September 2002 1:49 GMT]
[java.version: 1.3.1_03]
[java.vendor: Sun
Number of tests run: 933
Successful tests: 915
Errors:11
Failures: 7
[time of test: 20 September 2002 19:23 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer,
43 matches
Mail list logo
