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
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:
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 Changes
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
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
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:59:13
Modified:src/main/org/jboss/deployment/scanner
URLDeploymentScanner.java
Log:
o don't be so loud
Revision ChangesPath
1.4 +4 -2
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:
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
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 installing,
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
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
Bugs item #523305, was opened at 2002-02-27 09:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=523305group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Assigned
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:
|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
|
|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
Bugs item #523305, was opened at 2002-02-27 09:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=523305group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Assigned
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,
|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]
|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
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
|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
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
Bugs item #523305, was opened at 2002-02-27 09:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=523305group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
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
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:
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
|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
|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
Patches item #524923, was opened at 2002-03-02 21:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=524923group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabor Liptak (gliptak)
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=524925group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to:
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 the
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
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
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=524925group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to:
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=detailatid=376685aid=524925group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to: Adrian
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 keep
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:
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
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=66thread=10060
___
Jboss-development
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 it using
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
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
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
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
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:
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
Bugs item #524925, was opened at 2002-03-02 21:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=524925group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt (mpetteys)
Assigned to: Adrian
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
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 day
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:
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,
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
I asked Andreas the part about the lt;parent-j2eeTypegt; 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
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
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
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 6:36 GMT]
[java.version:
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
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
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
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
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
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
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
67 matches
Mail list logo
