User: starksm
Date: 02/03/02 23:41:28
Modified:src/resources/security-spec/META-INF ejb-jar.xml jboss.xml
Log:
Add test of a stateless session bean accessing getCallerPrincipal
in ejbCreate
Revision ChangesPath
1.3 +16 -0 jbosstest/src/resources/security-spe
User: starksm
Date: 02/03/02 23:40:50
Modified:src/main/org/jboss/test/security/test
EJBSpecUnitTestCase.java
Log:
Add test of a stateless session bean accessing getCallerPrincipal
in ejbCreate
Revision ChangesPath
1.10 +65 -47
jbosste
User: starksm
Date: 02/03/02 23:40:50
Added: src/main/org/jboss/test/security/ejb
StatelessSessionBean4.java
Log:
Add test of a stateless session bean accessing getCallerPrincipal
in ejbCreate
Revision ChangesPath
1.2 +83 -0
jbosst
User: starksm
Date: 02/03/02 23:00:59
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Change version to 2.4.5
Revision ChangesPath
No revision
No revision
1.77.2.13 +1 -1 jboss/src/build/Attic/build.xml
Ind
User: starksm
Date: 02/03/02 22:58:31
Modified:src/lib Tag: Branch_2_4 jboss-jaas.jar jbosssx.jar
Log:
Don't log password info
Revision ChangesPath
No revision
No revision
1.11.2.22 +199 -170 jboss/src/lib/Attic/jbos
User: starksm
Date: 02/03/02 22:51:07
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstancePool.java EntityInstanceCache.java
EntityInstanceInterceptor.java
EntityInstancePool.java
User: starksm
Date: 02/03/02 22:51:07
Modified:src/main/org/jboss/ejb Tag: Branch_2_4
EnterpriseContext.java EntityEnterpriseContext.java
InstancePool.java
MessageDrivenEnterpriseContext.java
User: starksm
Date: 02/03/02 22:43:45
Modified:src/main/org/jboss/test/security/test Tag: Branch_2_4
TestEJBSpec.java
Log:
Add test of getCallerPrincipal in ejbCreate of a stateless session
Revision ChangesPath
No revision
User: starksm
Date: 02/03/02 22:43:44
Added: src/main/org/jboss/test/security/ejb Tag: Branch_2_4
StatelessSessionBean4.java
Log:
Add test of getCallerPrincipal in ejbCreate of a stateless session
Revision ChangesPath
No revis
User: starksm
Date: 02/03/02 22:41:51
Modified:src/resources/security/META-INF Tag: Branch_2_4 ejb-jar.xml
jboss-spec.xml jboss.xml
Log:
Add test of getCallerPrincipal in ejbCreate of a stateless session
Revision ChangesPath
No
JBoss daily test results
SUMMARY
Number of tests run: 503
Successful tests: 495
Errors:4
Failures: 4
[time of test: 3 March 2002 6:36 GMT]
[java.version: 1.3.1_
User: starksm
Date: 02/03/02 22:23:13
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Enable debug by default
Revision ChangesPath
No revision
No revision
1.2.2.7 +2 -2 jbosspool/src/build/Attic/build.xml
JBoss daily test results
SUMMARY
Number of tests run: 503
Successful tests: 495
Errors:4
Failures: 4
[time of test: 3 March 2002 5:50 GMT]
[java.version: 1.3.1]
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524925&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matt (mpetteys)
>Assigned to
User: d_jencks
Date: 02/03/02 21:24:22
Modified:.build.xml
Log:
fix for bug 524925. cleaned up handling of no-parent for jsr-77 ejbModule mbeans and
added a testcase. Testcase will need changing if no-parent handling changes
Revision ChangesPath
1.83 +22 -1
User: d_jencks
Date: 02/03/02 21:24:21
Modified:src/main/org/jboss/ejb EjbModule.java
Log:
fix for bug 524925. cleaned up handling of no-parent for jsr-77 ejbModule mbeans and
added a testcase. Testcase will need changing if no-parent handling changes
Revision ChangesPath
User: d_jencks
Date: 02/03/02 21:24:21
Modified:src/main/org/jboss/management/j2ee EjbModule.java
Log:
fix for bug 524925. cleaned up handling of no-parent for jsr-77 ejbModule mbeans and
added a testcase. Testcase will need changing if no-parent handling changes
Revision Cha
User: d_jencks
Date: 02/03/02 21:24:21
Added: src/main/org/jboss/test/jmx/test
JarInSarJSR77UnitTestCase.java
Log:
fix for bug 524925. cleaned up handling of no-parent for jsr-77 ejbModule mbeans and
added a testcase. Testcase will need changing if no-pare
I asked Andreas the part about the and he did not have a
chance to respond before he had to leave for the weekend. the current version of the
JSR77 interfaces and most of the implementation in jboss is based on the public draft
from last year.
yes, vendor specific types ar
JBoss daily test results
SUMMARY
Number of tests run: 503
Successful tests: 495
Errors:4
Failures: 4
[time of test: 3 March 2002 4:54 GMT]
[java.version: 1.3.1]
Ok,
I've done a quick scan of the proposed final draft.
The J2EEManagedObject is a standardized
management interface. It can be used to expose everything
from the server right down to an individual servlet.
Section 3.1.1.3 is the important section for the
problem we have.
The spec says we are
I am working with Andreas to implement the JSR77 stuff
and there are plans to convert the current JSR77 MBeans into XMBeans when they are
ready. we are planning to look
at the XMBeans sometime next week.
As for the problems you guys are running into, the JSR77 spec was not designed to
handle
Thanks David,
I'll download the JSR77 spec, to see what it all about.
The other problem is, that JSR77 has the same
ObjectName problems as we found with EjbModule.
Try deploying
My=App.ear and you get a MalformedObjectName exception :-)
Regards,
Adrian
> On 2002.03.02 22:00:15 -0500 Adrian Br
I think this starting to get too cute as there can be different
semantics as to whether bind or rebind is allowed to overwrite
existing entries, whether missing subcontexts should be created
or represent an error, whether a live reference or a serializable
object should be bound, etc. to me, manag
JBoss daily test results
SUMMARY
Number of tests run: 503
Successful tests: 495
Errors:4
Failures: 4
[time of test: 3 March 2002 3:36 GMT]
[java.version: 1.3.1]
On 2002.03.02 22:00:15 -0500 Adrian Brock wrote:
> You are correct, I didn't read the bug report very well.
>
> When I fixed the windows locking problem for ears,
> I saw the same exception. I thought it was the same
> problem.
>
> I've been making too many errors this week.
> I think I *need* a
There's been some discussion of finding things in jndi and in jmx via
obejct name queries, and we currently have quite a few mbeans that end up
binding themselves or an object they control into jndi.
I think we can provide a generic way of dealing with this situation using
the interceptor stack b
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524925&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to: Adr
JBoss daily test results
SUMMARY
Number of tests run: 503
Successful tests: 494
Errors:4
Failures: 5
[time of test: 3 March 2002 2:58 GMT]
[java.version: 1.3.0]
You are correct, I didn't read the bug report very well.
When I fixed the windows locking problem for ears,
I saw the same exception. I thought it was the same
problem.
I've been making too many errors this week.
I think I *need* a day off. :-)
Regards,
Adrian
> Hi Adrian,
>
> I'm not very f
If a web app context has a WEB-INF/classes or non-empty WEB-INF/lib,
then we create a mortbay class loader as the thread context class
loader. Otherwise, we use the parent class loader as the thread
context class loader, which in the case of JBoss will be an
MBeanClassLoader.
Jan
Jason Dillon
Hi Adrian,
I'm not very familiar with jsr-77 either, and despite repeated explanations
from Andreas I keep having difficulty understanding what problem it is
solving ;-)
I've started wondering if there is some way of eliminating the current
jsr-77 mbeans and providing the entire implementation a
Hi David,
I've only just started looking at the new Deployer and
I'm not familiar with JSR77.
But, like you say, the problem is that JSR77
tries to do everything in one step.
Creating the MBeans in create and linking them in start
is a general solution to the problem.
The current code doesn't
IMO we either need to create every jsr-77 mbean in the init phase of the
appropriate deployer or deployment activity, or create the jsr-77 mbeans in
create and set their parents in start. We also need to deal with jsr-77
mbeans for non-j2ee packages such as sars, and non-j2ee nesting such as ear
On 2002.03.02 18:47:40 -0500 Jason Dillon wrote:
> >
> >
> >In general, that won't help. It happens in this case that jbosscx.sar
> >defines an mbean that DefaultDS needs, so deployment would wait, but if
> put
> >the ConnectionFactoryLoader class somewhere else there'd be no way to
> look
> >for
Je suis d accord avec toi Marc, mais il y a qd meme quelques francais derriere toi.
Bye.
_
View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10060
___
Jboss-development mailin
The 'BCEL' directory has been replaced by 'bcel' and is no longer in the
repository. Due to windows being especially lame in this area, you may
still get garbage like this:
cvs server: cannot open directory /cvsroot/jboss/thirdparty/apache/BCEL:
No such file or directory
cvs server: skipping
User: user57
Date: 02/03/02 15:59:57
Modified:apache/bcel VERSION
Log:
o Update version info
Revision ChangesPath
1.2 +2 -1 thirdparty/apache/bcel/VERSION
Index: VERSION
===
RCS file:
>
>
>In general, that won't help. It happens in this case that jbosscx.sar
>defines an mbean that DefaultDS needs, so deployment would wait, but if put
>the ConnectionFactoryLoader class somewhere else there'd be no way to look
>for it using depends. Marc wanted to use the MBeanClassLoader to ke
For some reason sourceforge is not showing me this bug...
How can it be due to something about an ear file? there is none. I think
the problem is that the ejb module di has a parent, but that no jsr-77
mbean is created for it, since it isn't an official jsr-77 deployment unit.
I think I'll "fix
Patches item #524958, was opened at 2002-03-03 00:36
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=524958&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Jain (ejain)
Assi
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524925&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to: A
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524925&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
>Assigned to: Adr
User: ejort
Date: 02/03/02 15:22:10
Modified:src/main/org/jboss/deployment EARDeployer.java
Log:
Create the JSR77 appliction in init. Sub-module creation comes before application
creation. The sub-modules JSR77 mbeans need the application mbean to exist
Revision Changes
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524925&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to: Nobo
User: starksm
Date: 02/03/02 14:07:49
Modified:src/main/org/jboss/security/auth/spi Tag: Branch_2_4
UsernamePasswordLoginModule.java
Log:
Don't log any password info.
Revision ChangesPath
No revision
No
User: ejort
Date: 02/03/02 13:52:40
Modified:src/main/test/compliance/relation
RelationServiceTestCase.java
Log:
Don't use assert it is reserved in 1.4
Revision ChangesPath
1.2 +5 -5
jmx/src/main/test/compliance/relation/RelationSer
On 2002.03.02 14:51:08 -0500 marc fleury wrote:
> |for it using depends. Marc wanted to use the MBeanClassLoader to keep
> |track of class dependencies and wait if a class was not found when you
> |tried to "install" it. I'm not sure how far he got with this.
>
> Yes that was its purpose before
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524925&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to: Nobo
Patches item #524923, was opened at 2002-03-02 21:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=524923&group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabor Liptak (gliptak)
|Do you want all instances of javax.transaction.Transaction
|floating around the server to be instances of a JBoss-specific
|extension of this interface that knows how to serialize itself?
yes
marcf
___
Jboss-development mailing list
[EMAIL PROTECTE
|Do you want all instances of javax.transaction.Transaction
|floating around the server to be instances of a JBoss-specific
|extension of this interface that knows how to serialize itself?
yes
marcf
___
Jboss-development mailing list
[EMAIL PROTECTE
Hi,
I am not sure if I understand you.
Do you want all instances of javax.transaction.Transaction
floating around the server to be instances of a JBoss-specific
extension of this interface that knows how to serialize itself?
marc fleury wrote:
> |Not that i really like this design. When i came
So if a deployment is located under jboss.home, strip jboss.home
from the path created under tmp/deploy. Any path outside of jboss.home
is included in full.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "
DCJ,
I got jb.net to deploy. There was a small error in
Constants.java, I prepended META-INF to the
"axis-config.xml" constant ->
static final String
AXIS_CONFIGURATION_FILE="META-INF/axis-config.xml";
Also, the axis-config.xml isn't getting included in
the resources directory for the .jar pro
|IMHO this is another design flaw in JTA: The methods
|in TPCImporter and TCPFactory should belong in the
|TransactionManager. Without them, the transport needs
|to have special knowledge about the transaction server
|to be able to move transaction contexts across the wire.
Yes that is a weakness
|for it using depends. Marc wanted to use the MBeanClassLoader to keep
|track of class dependencies and wait if a class was not found when you
|tried to "install" it. I'm not sure how far he got with this.
Yes that was its purpose before the advent of the Unified ClassLoader
everywhere.
That w
Bugs item #523305, was opened at 2002-02-27 09:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=523305&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Assi
User: ejort
Date: 02/03/02 08:34:25
Modified:src/main/org/jboss/deployment EARDeployer.java
Log:
Use the tmp copy to load deployment descriptors to avoid locking on windows
Revision ChangesPath
1.9 +2 -2 jboss/src/main/org/jboss/deployment/EARDeployer.java
|I don't know what web context is being started here as there really
|is not one. Its probably some default setup that is irrelevant but
|the Jetty guys will have to determine if that is the case. If need be
|an empty URLClassLoader can be created for the startService
|context.
OK I see, a Unifie
Unified is a URLCl,
however I don't understand
1- the problem
2- the analysis
so I am not going to make guess work on this
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
|JBossMX remembers the
|context classloader from the MBean's registration and
|uses it again during MBean invocation. It has to be
|something to do with that.
it should be using UnifiedCL...
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED
|But (I think) with JBossMX jasper gets the apps
|UnifiedClassLoader instead of JettyService's MBeanClassLoader.
that would be the best actually, wrong guess work
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.
Guys,
here is the breakdown for the training coming up
UK: 35%
Scadinavians: 26%
Germany: 21%
Switzerland: 8%
Italy: 5%
Belgium : 5%
FRANCE: FUCKING %
Putain c'est quoi votre probleme? Vous etes vraiment trop cons. Je veux
bien que "personne n'est prophete dans son pays" mais quand meme,
|JMX speed is NOT important for ejb. If you do intensive
I figured as much
|JMX processing we are much better than the RI, but who does that?
we will
This is great news, we will try and ship it with RC1/2
marcf
___
Jboss-development mailing list
[
|Anyways, I am seeing consistent ClassCastExceptions for
|MBeanClassLoader... which is not a URLClassLoader. My guess is that
|MBeanClassLoader could be a URLClassLoader, but that seems a bit
|artificial.
MBeanCL might be going away
marcf
|
|Anybody know what is up with this?
|
|--jason
|
|
Bugs item #523305, was opened at 2002-02-27 09:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=523305&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Assigne
User: ejort
Date: 02/03/02 07:59:25
Modified:src/main/org/jboss/ejb EjbModule.java
Log:
Load the deployment descriptor from the tmp copy to avoid locks on windows
Revision ChangesPath
1.6 +2 -2 jboss/src/main/org/jboss/ejb/EjbModule.java
Index: EjbModu
Bugs item #523305, was opened at 2002-02-27 09:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=523305&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
>Assign
User: mnf999
Date: 02/03/02 06:29:37
Modified:src/docs/jbossgroup training.jsp
Log:
Update: fixed grammar error in JavaOne announcement, added new quotes
to the training page.
Revision ChangesPath
1.18 +25 -0 newsite/src/docs/jbossgroup/training.jsp
Ind
User: mnf999
Date: 02/03/02 06:29:36
Modified:src/docs index.jsp
Log:
Update: fixed grammar error in JavaOne announcement, added new quotes
to the training page.
Revision ChangesPath
1.44 +1 -1 newsite/src/docs/index.jsp
Index: index.jsp
On 2002.03.02 04:41:37 -0500 Jason Dillon wrote:
> Why do we attempt to install an MBean before its dependencies have been
> met? Looks like install hapens before create, and create is where
> depends logic begins. It seems like a better choice would be to check
> for depends before installin
Hi,
Sorry for my late answer, I am a bit busy these days.
marc fleury wrote:
> I never realized this until I was working on the client interceptors
> yesterday late at night. Our transaction object requires an external person
> to serialize itself. Namely the extraction of the transaction prop
I don't think this is one of our exceptions...
* * *
org.jboss.deployment.DeploymentException: exception in init of
file:/C:/home/jason/workspace/jboss/clean-jboss-all/build/output/jboss-3.0.0beta2/server/default/deploy/jbossmq-testsuite-service.xml;
- nested throwable is: org.jboss.deploymen
User: user57
Date: 02/03/02 01:59:13
Modified:src/main/org/jboss/deployment/scanner
URLDeploymentScanner.java
Log:
o don't be so loud
Revision ChangesPath
1.4 +4 -2
jboss-system/src/main/org/jboss/deployment/scanner/URLDeploymentSca
Why do we attempt to install an MBean before its dependencies have been
met? Looks like install hapens before create, and create is where
depends logic begins. It seems like a better choice would be to check
for depends before installing, or rather before attempting to
instantiate the mbean
User: user57
Date: 02/03/02 01:14:27
Modified:src/main/org/jboss/util MuLong.java
Log:
o forgot this one.
Revision ChangesPath
1.2 +10 -0 jboss-common/src/main/org/jboss/util/MuLong.java
Index: MuLong.java
=
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
[jar] Building jar:
/disk/orig/home
User: user57
Date: 02/03/02 00:41:09
Modified:src/main/org/jboss/deployment MainDeployerMBean.java
Log:
o Added deploy(URL) and undeploy(URL) to MainDeployerMBean interface
o Using above for deployment/undeployment
Revision ChangesPath
1.4 +6 -4
jboss-s
User: user57
Date: 02/03/02 00:40:36
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
o Changed deployments to deploymentMap for clarity, deploymentsList to
deploymentList for consistency.
o Using Counter helper object instead of handrolled
o Using Streams
User: user57
Date: 02/03/02 00:41:09
Modified:src/main/org/jboss/deployment/scanner
URLDeploymentScanner.java
Log:
o Added deploy(URL) and undeploy(URL) to MainDeployerMBean interface
o Using above for deployment/undeployment
Revision ChangesP
User: user57
Date: 02/03/02 00:37:43
Modified:src/main/org/jboss/deployment DeploymentSorter.java
Log:
o Don't need sortFiles() anymore
Revision ChangesPath
1.2 +1 -33 jboss-system/src/main/org/jboss/deployment/DeploymentSorter.java
Index: DeploymentSor
User: user57
Date: 02/03/02 00:22:20
Modified:src/etc/conf/default jboss-service.xml
Log:
o URLDeploymentScanner is the default
Revision ChangesPath
1.33 +11 -6 jboss/src/etc/conf/default/jboss-service.xml
Index: jboss-service.xml
=
User: user57
Date: 02/03/02 00:22:57
Removed: src/main/org/jboss/deployment/scanner
DirectoryDeploymentScanner.java
DirectoryDeploymentScannerMBean.java
Log:
o buh-bye... UDS is vastly better than you are... so take a hike
84 matches
Mail list logo
