Okay, I've had some time to start working on multiple invokers per
container. Here's what the config looks like. I'm too tired to explain,
but you should be able to understand it by the example below.
standardjboss.xml:
*NOTE* is removed from container-configuration
entity-
I am afraid I beg to differ. I think that the SAR is an excellent concept
and approach. First of all it is simple. Simple is good. Sometimes
simple doesn't cover all the bases, but being too complex can make
something unusable. In JBoss 2.4x, I had created an alternate solution,
but it wa
If so, I can clean up some of the dead configuration stuff in
standardjboss.xml and the meta data classes.
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
So, xmbeans are what I'm suggesting? What are xmbeans? Are they talked
about in Juha's book?
Thanks,
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Jencks
> Sent: Sunday, April 21, 2002 2:43 AM
> To: Bill Burke
> Cc: Jboss-Dev
> Su
> 1. Related to these problems is the question of how we should store
> "persistent" mbean attributes and the desired relationship between these
> persistent attributes from storage and those from a possibly modified
> config file. Remember the bad old days of jboss-auto.jcml? That is gone
> but
I think both of these fit well into the xmbean configuration, although they
aren't there now.
Earlier today I thought about putting default mbean dependencies there --
such as on the naming service or tm which you might not want to repeat in
every mbean needing them. similar idea.
david jencks
One of my older xml books says you can have in a dtd
which will allow any content. Don't know if you can do this in xsd.
I think interceptors should come from interceptor factories which are
mbeans -- thus configured via mbean configuration process -- and assembled
into stacks by other mbean
Another thing we could use mbean-templates for is to define default mbean
dependencies for EJBs as well.
> -Original Message-
> From: Bill Burke [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 21, 2002 2:16 AM
> To: Jboss-Dev
> Subject: next-gen mbean config
>
>
> Jason got me thinking,
Jason got me thinking,
We need a standard way of configuring some sort of MBean templates. In the
future, we need to be able to define what an MBean looks like in standard
meta-data that can be used as a factory to create new mbeans. We should and
will be able to define distributed object frame
1. Related to these problems is the question of how we should store
"persistent" mbean attributes and the desired relationship between these
persistent attributes from storage and those from a possibly modified
config file. Remember the bad old days of jboss-auto.jcml? That is gone
but no replac
Yes perhaps... but I think only if we can get a schema to accept any given xml nested
inside of a tag... which I still don't know if that is possible.
Otherwise we would need to wrap that in CDATA & let the interceptor do whatever it
wanted with it (parse it into xml, read it as properties, bla
Maybe pass in XML configuration.
blah blah
Much more flexible. More food for thought.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> Dillon
> Sent: Sunday, April 21, 2002 1:13 AM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] M
Ever since tahoe I have been thinking about MBean interceptor stack configuration...
very cool when we get it up and working.
One thing I was thinking would be nice would be allow passing init arguments to the
interceptor, similar to servlet init params. As well as a name for the interceptor.
Well, perhaps not completly sucky, but as it is now it does suck. When I wrote that
email long ago about those pesky birds, which eventually lead to .sar (and other
things), I did not have this in mind.
The idea was to make it *easier* to configuration components not complicate it. SAR
as it
I am still getting errors like this from a default build:
21:16:01,826 INFO [MainDeployer] Successfully completed deployment of package:
file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/jbossmq-destinations-service.xml
21:16:01,826 INFO [MainDe
I have just finished setting up the forum integration for the new email list:
[EMAIL PROTECTED]
You will need to subscribe to this list to receive cvs change notifications:
https://lists.sourceforge.net/lists/listinfo/jboss-cvs-commits
I also dropped the 'CVS update:' prefix, as the '[jboss-c
User: user57
Date: 02/04/20 20:26:04
Modified:.log_accum.pl loginfo
Log:
change target address for logs
Revision ChangesPath
1.5 +2 -2 CVSROOT/log_accum.pl
Index: log_accum.pl
==
Hi - This is a small list of requirements for JBoss's deployment process. Please
provide as much feedback as you can and help fill in the gaps.
Thanks.
For the purpose of this document, the following Definitions will apply:
·user The user (usually a person) attempting to deploy an applicatio
User: reverbel
Date: 02/04/20 12:31:05
Modified:.build.xml
Log:
- IIOP tests excluded from tests-standard-stress.
- Created target tests-iiop-stress.
- Targets tests and tests-stress now depend on tests-iiop-stress.
Revision ChangesPath
1.110 +56
User: squirest
Date: 02/04/20 10:13:31
Modified:src/main/org/jboss/mx/logging LoggerManager.java
Log:
test driving new intellij inspection feature - found this typo
Revision ChangesPath
1.2 +1 -1 jmx/src/main/org/jboss/mx/logging/LoggerManager.java
Index:
Change Notes item #546528, was opened at 2002-04-20 16:36
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=546528&group_id=22866
Category: JBossMX
Group: None
Status: Open
Priority: 5
Submitted By: Adrian Brock (ejort)
Assigned to: Nobody/Anonymous (nobody
User: ejort
Date: 02/04/20 09:31:00
Modified:src/main/org/jboss/mx/server/registry
BasicMBeanRegistry.java MBeanEntry.java
MBeanRegistry.java ManagedMBeanRegistry.java
Log:
Allow generic data to be stored with an MBeans registration
User: ejort
Date: 02/04/20 09:31:00
Added: src/main/test/implementation/registry RegistrySUITE.java
ValuesTestCase.java
Log:
Allow generic data to be stored with an MBeans registration. Fixed the double
creation of the MBeanRegistry. Synchronized the lo
User: ejort
Date: 02/04/20 09:30:59
Modified:src/main/org/jboss/mx/server MBeanServerImpl.java
ServerConstants.java
Log:
Allow generic data to be stored with an MBeans registration. Fixed the double
creation of the MBeanRegistry. Synchronized the long seq
User: ejort
Date: 02/04/20 09:31:00
Modified:src/main/test/implementation ImplementationSUITE.java
Log:
Allow generic data to be stored with an MBeans registration. Fixed the double
creation of the MBeanRegistry. Synchronized the long sequence numbers in the MBean
Registry
User: ejort
Date: 02/04/20 09:31:01
Added: src/main/test/implementation/registry/support Trivial.java
TrivialMBean.java
Log:
Allow generic data to be stored with an MBeans registration. Fixed the double
creation of the MBeanRegistry. Synchronized the lo
User: ejort
Date: 02/04/20 09:18:23
jmx/src/main/test/implementation/registry/support - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: ejort
Date: 02/04/20 09:17:38
jmx/src/main/test/implementation/registry - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: ejort
Date: 02/04/20 04:37:49
Modified:src/main/javax/management/monitor Monitor.java
Log:
Improved Timer and Monitor Services
Revision ChangesPath
1.6 +18 -176 jmx/src/main/javax/management/monitor/Monitor.java
Index: Monitor.java
===
User: ejort
Date: 02/04/20 04:37:49
Modified:src/main/javax/management/timer Timer.java
Log:
Improved Timer and Monitor Services
Revision ChangesPath
1.9 +35 -173 jmx/src/main/javax/management/timer/Timer.java
Index: Timer.java
=
User: ejort
Date: 02/04/20 04:37:50
Added: src/main/org/jboss/mx/util RunnableScheduler.java
SchedulableRunnable.java
Log:
Improved Timer and Monitor Services
Revision ChangesPath
1.1 jmx/src/main/org/jboss/mx/util/RunnableSc
User: ejort
Date: 02/04/20 04:37:50
Modified:src/main/test/performance/timer TimerTortureTestCase.java
Log:
Improved Timer and Monitor Services
Revision ChangesPath
1.2 +0 -1 jmx/src/main/test/performance/timer/TimerTortureTestCase.java
Index: TimerTor
User: ejort
Date: 02/04/20 04:37:49
Modified:.build.xml
Log:
Improved Timer and Monitor Services
Revision ChangesPath
1.36 +55 -1 jmx/build.xml
Index: build.xml
===
RCS file: /cv
User: ejort
Date: 02/04/20 04:37:50
Added: src/main/test/stress/timer TimerSUITE.java
TimerTestCase.java
Log:
Improved Timer and Monitor Services
Revision ChangesPath
1.1 jmx/src/main/test/stress/timer/TimerSUITE.java
In
User: ejort
Date: 02/04/20 04:37:50
Added: src/main/test/stress StressSUITE.java
Log:
Improved Timer and Monitor Services
Revision ChangesPath
1.1 jmx/src/main/test/stress/StressSUITE.java
Index: StressSUITE.java
=
User: ejort
Date: 02/04/20 04:27:12
jmx/src/main/test/stress - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: ejort
Date: 02/04/20 04:27:37
jmx/src/main/test/stress/timer - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Hello I agree for the optional thing, and clustering should definitively go in the
optional folder!
Cheers,
sacha
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
38 matches
Mail list logo
