Hi Scott,
You need to add this to make it work.
classpath archives=jbosscx.sar/
I'm not sure this is the correct solution?
Regards,
Adrian
After updating my cvs snaphost again the
hsqldb-default-service.xml
is failing to deploy due to
org.jboss.resource.ConnectionFactoryLoader
not
Hello,
I fully agree with Greg's message.
- We need to do it in pure Java
- we don't need to be 100% sticky (99.99% is enough)
- Let's make a first version that don't have fancy things but, at least, that
work!
- java.nio is the way (plus giving a doc about
Bugs item #527328, was opened at 2002-03-08 11:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=527328group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Hamann (thomash76)
Assigned
User: juhalindfors
Date: 02/03/08 02:38:48
Modified:src/main/org/jboss/mx/interceptor
MBeanAttributeInterceptor.java
Log:
invoker already unwrapped the attribute value
Revision ChangesPath
1.2 +6 -3
User: juhalindfors
Date: 02/03/08 02:36:36
Modified:src/main/javax/management/modelmbean
ModelMBeanInfoSupport.java
Log:
setDescriptor impl.
Revision ChangesPath
1.6 +31 -4
User: juhalindfors
Date: 02/03/08 02:41:11
Modified:src/main/org/jboss/mx/service ServiceConstants.java
Log:
we will need to support legacy schemas from previous versions as well..
Revision ChangesPath
1.3 +10 -4
Juha,
The ObjectReferenceInterceptor was based on the (then current) version of
MBeanAttributeInterceptor and so it expects an Attribute.
Can you please propagate your change to the ObjectReferenceInterceptor.
Thanks,
Trevor
_
View
User: juhalindfors
Date: 02/03/08 03:50:44
Modified:src/main/org/jboss/mx/server/registry
BasicMBeanRegistry.java
Log:
give lil more detail in the RegistrationException message
Revision ChangesPath
1.9 +2 -2
User: juhalindfors
Date: 02/03/08 03:49:18
Modified:src/main/javax/management JMException.java
ReflectionException.java
Log:
nice exceptions give their rootcause in toString()
Revision ChangesPath
1.3 +1 -0
User: juhalindfors
Date: 02/03/08 03:53:01
Modified:src/main/org/jboss/mx/metadata XMLMetaData.java
Added: src/main/org/jboss/mx/metadata JBossXMBean10.java
XMBeanMetaData.java
Log:
separate parsing of different DTDs (so we can keep supporting older
User: juhalindfors
Date: 02/03/08 03:56:27
Added: src/main/test/implementation/modelmbean/support/xml
jboss_xmbean_1_0.dtd
Log:
Revision ChangesPath
1.1
User: juhalindfors
Date: 02/03/08 03:57:01
Modified:src/main/test/implementation/modelmbean XMBeanTEST.java
Log:
Revision ChangesPath
1.3 +38 -9 jmx/src/main/test/implementation/modelmbean/XMBeanTEST.java
Index: XMBeanTEST.java
User: juhalindfors
Date: 02/03/08 03:55:47
Modified:src/main/test/implementation/modelmbean/support/xml User.xml
Log:
David, I changed this to use a SYSTEM id so I don't need a network connection
to run the tests
Revision ChangesPath
1.2 +2 -2
The other solution would be to put jbosscx.sar in lib. I think I prefer
the classpath solution, it is more explicit.
david jencks
On 2002.03.08 04:59:36 -0500 Adrian Brock wrote:
Hi Scott,
You need to add this to make it work.
classpath archives=jbosscx.sar/
I'm not sure this is
This is a really cool feature :)
Will you in future handle local caches so not everything is downloaded each time or
when you are off-line?
/Lennart
_
View thread online: http://main.jboss.org/thread.jsp?forum=66thread=10434
Hi there,
is it (or should it) still be possible to deploy
already extracted web-applications with Jetty?
In version 1.53 of org.jboss.jetty.Jetty, there is a
property called unpackWars (default set to true?)
which seems to force Jetty to JarExtract every
deployment it gets hold
I'm using 2.4.4 and seeing the same thing, when I have the line:
Class-Path: automarkinventory.jar
In my Manifest.mf file it appears to look on the filesystem for the jar file, why not
inside my ejb jar file?
I am just wondering if I'm doing something wrong here.
[INFO,J2eeDeployer]
User: mclaugs
Date: 02/03/08 06:44:07
Modified:varia/src/main/org/jboss/mail MailService.java
Log:
removed extra call to org.jboss.management.j2ee.JavaMail.create()
Revision ChangesPath
1.5 +1 -2 contrib/varia/src/main/org/jboss/mail/MailService.java
User: squirest
Date: 02/03/08 06:40:42
Modified:src/main/org/jboss/mx/interceptor
ObjectReferenceInterceptor.java
Log:
apply similar fix that Juha did for MBeanAttributeInterceptor
Revision ChangesPath
1.2 +1 -1
User: squirest
Date: 02/03/08 06:53:37
Modified:src/main/javax/management/modelmbean
ModelMBeanInfoSupport.java
Log:
fixed constructor
Revision ChangesPath
1.7 +50 -46
jmx/src/main/javax/management/modelmbean/ModelMBeanInfoSupport.java
I normally build jboss-mx under Unix or NT but just tried to build.bat under WinME and
get loads of errors about command not found (seemingly related to doing a call on a
label).
Is this supposed to work under WinME?
Thanks,
Trevor
_
Hi Trevor,
I normally build jboss-mx under Unix or NT but just tried to
build.bat under WinME and get loads of errors about command
not found (seemingly related to doing a call on a label).
Is this supposed to work under WinME?
WinME normally barfs when:
1 - long shell commands are
So what changed to require this? If I add classpath
archives=jbosscx.sar/
reference I now get a second exception for the NoTransDS, but the DefaultDS
is ok. Please cleanup the connector/pooling jars to fix this.
07:14:47,950 INFO [NoTransDS] Bound connection factory for resource adapter
User: juhalindfors
Date: 02/03/08 07:28:16
Modified:src/main/javax/management/modelmbean
ModelMBeanAttributeInfo.java
Log:
fix for missing default constructors, clone, javadoc
Revision ChangesPath
1.2 +127 -20
User: juhalindfors
Date: 02/03/08 07:32:03
Modified:src/main/javax/management/modelmbean DescriptorSupport.java
Log:
implements Serializable
cleared up clone
Revision ChangesPath
1.4 +13 -8 jmx/src/main/javax/management/modelmbean/DescriptorSupport.java
User: juhalindfors
Date: 02/03/08 07:36:27
Modified:src/main/javax/management/modelmbean
ModelMBeanOperationInfo.java
Log:
implements cloneable
Revision ChangesPath
1.4 +8 -3
User: juhalindfors
Date: 02/03/08 07:40:58
Modified:.build.xml
Log:
removed TEMP
Revision ChangesPath
1.27 +1 -4 jmx/build.xml
Index: build.xml
===
RCS file:
Cool! I hope nobody took offense to any of my comments! I was hoping to
generate a discussion exactly like this! More comments follow...
While using DNS may well be a naive, I think it is more naive to
think that user space code running on a general purpose computer is
a good solution if
User: mclaugs
Date: 02/03/08 07:49:47
Modified:src/main/org/jboss/management/j2ee JDBCDataSource.java
Log:
j2eeType changed from JDBC to JDBCResource
Revision ChangesPath
1.12 +2 -2 jboss/src/main/org/jboss/management/j2ee/JDBCDataSource.java
Index:
I fixed the problem that was causing
javax.management.InstanceAlreadyExistsException
the jsr77 objects were modified to the current version of the spec last night.
JDBCDataSource was looking for its parent with the wrong tpye, j2eeType=JDBC when it
should have been j2eeType=JDBCResource
User: juhalindfors
Date: 02/03/08 08:09:54
Modified:src/main/test/implementation/modelmbean XMBeanTEST.java
Log:
simple test for standard - modelmbean
Revision ChangesPath
1.4 +45 -36jmx/src/main/test/implementation/modelmbean/XMBeanTEST.java
Index:
User: juhalindfors
Date: 02/03/08 08:09:02
Added: src/main/test/implementation/modelmbean/support Trivial.java
TrivialMBean.java
Log:
Revision ChangesPath
1.1 jmx/src/main/test/implementation/modelmbean/support/Trivial.java
Hi All
Sometimes, I see that for the passivation , it takes a lot of time. What is
the reason and how to solve it. Please give some suggestion.
[21:30:25,721(809769); LRUEnterpriseContextCachePolicy::debug:106]TimerTask
Thread Scheduling for passivation overaged bean SupplierCompanyBean with id
I fixed the problem by modifying the jms-service.xml classpath. Instead of lib, *, I
used ., and jbosscx.sar.
Then everything worked perfectly.
_
View thread online: http://main.jboss.org/thread.jsp?forum=66thread=10455
Hi Scott
Damn, thanx for your help.
Andy
I fixed the problem that was causing
javax.management.InstanceAlreadyExistsException
the jsr77 objects were modified to the current version of the spec last
night. JDBCDataSource was looking for its parent with the wrong tpye,
j2eeType=JDBC when it
I don't know what you are responding to... what packaging are you using and
why should it work?
david jencks
On 2002.03.08 09:24:31 -0500 Cameron Tabor wrote:
I'm using 2.4.4 and seeing the same thing, when I have the line:
Class-Path: automarkinventory.jar
In my Manifest.mf file it
User: squirest
Date: 02/03/08 09:04:43
Modified:src/main/javax/management/modelmbean
ModelMBeanNotificationInfo.java
Log:
setDescriptor handling in constructors and clone impl
Revision ChangesPath
1.2 +31 -9
User: cgjung
Date: 02/03/08 09:24:34
Modified:jboss.net/testsuite/src/main/org/jboss/test/net/jmx
JmxUnitTestCase.java
Log:
when you change config, change the depending unit tests too, stupid!
time4weekend.
Revision ChangesPath
1.4 +9
User: cgjung
Date: 02/03/08 09:51:13
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
Why did someone remove the web service
archive (.wsr) sub-package deployment, again?
I know that jboss.net is not yet a standard-module, but it never will be
if I need 4
User: ejort
Date: 02/03/08 10:11:19
jmx/src/main/test/performance/timer - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: ejort
Date: 02/03/08 10:21:59
Added: src/main/test/performance/timer TimerSUITE.java
TimerTortureTestCase.java
Log:
Better timer tests
Revision ChangesPath
1.1 jmx/src/main/test/performance/timer/TimerSUITE.java
User: ejort
Date: 02/03/08 10:21:59
Modified:src/main/test/performance PerformanceSUITE.java
Log:
Better timer tests
Revision ChangesPath
1.3 +3 -1 jmx/src/main/test/performance/PerformanceSUITE.java
Index: PerformanceSUITE.java
User: ejort
Date: 02/03/08 10:21:59
Modified:src/main/test/compliance/timer TimerSUITE.java
Added: src/main/test/compliance/timer
TimerNotificationTestCase.java
Removed: src/main/test/compliance/timer BasicTEST.java
This is maybe a bit offtopic, and a bit long, but this is one of those
serindipitous occasions where a conversation strikes on something
somebody else is already working on...
Greg Wilkins wrote:
+ Use java.nio as:
* if you care about performance you should be using jdk1.4 anyway
* if
User: ejort
Date: 02/03/08 10:21:59
Modified:src/main/javax/management/timer Timer.java
Log:
Better timer tests
Revision ChangesPath
1.6 +15 -16jmx/src/main/javax/management/timer/Timer.java
Index: Timer.java
What happened at last with this (CL and JSPs)? I mean, my app has servlets
and JSPs; servlets can find every classes they need, but JSPs don't. This
behaviour started at Jan or so, and that forced me to stop building fresh
CVS content.
Seems that the correct classpath is set. From the log:
JSP
User: d_jencks
Date: 02/03/08 12:22:48
Modified:src/etc/deploy hsqldb-default-service.xml jms-service.xml
Log:
put the classpaths back in again
Revision ChangesPath
1.3 +3 -1 jboss/src/etc/deploy/hsqldb-default-service.xml
Index:
User: d_jencks
Date: 02/03/08 12:37:06
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCCommandFactory.java
Log:
removed unnecessary use of jndi name
Revision ChangesPath
1.18 +20 -26
User: d_jencks
Date: 02/03/08 12:59:28
Modified:src/main/org/jboss/deployment EARDeployerMBean.java
Log:
fixes for bug 526465, failed deployments don't clean up very well. Reorganized a
little bit also: bind into jndi on create step, and setup references to other
resources in
User: d_jencks
Date: 02/03/08 12:59:28
Modified:src/main/org/jboss/ejb Container.java EjbModule.java
Log:
fixes for bug 526465, failed deployments don't clean up very well. Reorganized a
little bit also: bind into jndi on create step, and setup references to other
resources in
User: d_jencks
Date: 02/03/08 12:59:28
Modified:src/main/org/jboss/proxy/ejb ProxyFactory.java
Log:
fixes for bug 526465, failed deployments don't clean up very well. Reorganized a
little bit also: bind into jndi on create step, and setup references to other
resources in start
User: d_jencks
Date: 02/03/08 13:02:06
Modified:src/main/org/jboss/test/jmx/test
EarDeploymentUnitTestCase.java
Added: src/main/org/jboss/test/jmx/test
UndeployBrokenPackageUnitTestCase.java
Log:
testcase for bug 526465, make
User: d_jencks
Date: 02/03/08 13:02:05
Added: src/main/org/jboss/test/jmx/ejb EntityABean.java
EntityBBean.java
Log:
testcase for bug 526465, make sure failed deploys cleans up after itself
Revision ChangesPath
1.1
User: d_jencks
Date: 02/03/08 13:02:07
Modified:.build.xml
Log:
testcase for bug 526465, make sure failed deploys cleans up after itself
Revision ChangesPath
1.87 +38 -1 jbosstest/build.xml
Index: build.xml
I'm trying to use a jar from inside my ejb-jar by specifying it in the Manifest.mf
file. It seems to look on the filesystem to do the class loading instead of looking
inside the ejb-jar. I may be mistaken, but I thought you could do that.
-Cameron
On 2002.03.08 16:19:36 -0500 Cameron Tabor wrote:
I'm trying to use a jar from inside my ejb-jar by specifying it in the
Manifest.mf file. It seems to look on the filesystem to do the class
loading instead of looking inside the ejb-jar. I may be mistaken, but I
thought you could do that.
User: squirest
Date: 02/03/08 14:09:20
Modified:src/main/javax/management/modelmbean
ModelMBeanAttributeInfo.java
ModelMBeanNotificationInfo.java
ModelMBeanOperationInfo.java
Log:
stuck in basic implementation
Bugs item #526465, was opened at 2002-03-06 16:28
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=526465group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Thomas Hamann (thomash76)
User: mnf999
Date: 02/03/08 14:48:37
Modified:src/docs index.jsp
Log:
Updated index page (changed word)
Revision ChangesPath
1.45 +1 -1 newsite/src/docs/index.jsp
Index: index.jsp
===
Bugs item #516953, was opened at 2002-02-13 13:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=516953group_id=22866
Category: None
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Harris (charris)
Assigned to:
User: schaefera
Date: 02/03/08 15:19:44
Modified:varia/src/main/org/jboss/mail MailService.java
Log:
Final adjustments to the current JSR-77 specification. Because the spec.
is still changing I replaced the J2EE-Type name by a static attribute
called J2EE_TYPE with each JSR-77
Any way we could override printStackTrace() to show the target
throwables trace? Might want to look/copy the bits in
org.jboss.util.NestedThrowable.
--jason
Juha Lindfors wrote:
User: juhalindfors
Date: 02/03/08 03:49:18
Modified:src/main/javax/management JMException.java
It seems a little strange to put a deployable into lib/... even though
all of those do get deployed... Any reason why we don't split this? Do
away with the .sar?
--jason
David Jencks wrote:
The other solution would be to put jbosscx.sar in lib. I think I prefer
the classpath solution, it
That is a definite possibility... probably easy to implement too.
--jason
Lennart Petersson wrote:
This is a really cool feature :)
Will you in future handle local caches so not everything is downloaded each time or
when you are off-line?
/Lennart
.sar is in the deployment directory... which causes a mess when trying
to get NetBoot to function correctly.
Isn't there a patch to remove the lib bits from this .sar and place them
in lib/? That would be a better short-term solution.
--jason
Adrian Brock wrote:
Hi Scott,
You need to add
ME falls into the 95-98 category... where some advanced (or really quite
basic) shell features just are not available.
You can probably get it working with Cygwin.
--jason
Trevor Squires wrote:
I normally build jboss-mx under Unix or NT but just tried to build.bat under WinME
and get loads
Guys,
I've just been refactoring some of the Jetty stuff, and it works fine
except for one thing. The second undeploy/deploy (of the plugin) cycle
barfs out trying to destroy Jetty with an IllegalAccessError.
23:59:31,861 INFO [MainDeployer] Undeploying
This could not be because the ClassLoader is being asked for a class that it no longer
has the jar for - could it. That would be a ClassNotFound
Jules
Jules Gosnell wrote:
Guys,
I've just been refactoring some of the Jetty stuff, and it works fine
except for one thing. The second
Can you just put the current jbosscx.sar in lib for now? I think the jca
rewrite I am working on may eliminate this problem. Don't spend any more
time than you need to on this, and try not to increase the number of files
we have to deal with.
david jencks
On 2002.03.08 19:05:51 -0500 Jason
JBoss daily test results
SUMMARY
Number of tests run: 528
Successful tests: 498
Errors:23
Failures: 7
[time of test: 9 March 2002 0:51 GMT]
[java.version:
Lib it will be.
--jason
David Jencks wrote:
Can you just put the current jbosscx.sar in lib for now? I think the jca
rewrite I am working on may eliminate this problem. Don't spend any more
time than you need to on this, and try not to increase the number of files
we have to deal with.
david
On 2002.03.08 19:39:30 -0500 Jules Gosnell wrote:
This could not be because the ClassLoader is being asked for a class that
it no longer has the jar for - could it. That would be a
ClassNotFound
I don't know what is the relationship between JettyService and the
jetty-plugin.sar?
Just a quick thought, which if possible would reduce config issues when
running two intances on the same host.
Can WebService/WebServer run with a dynamicly asigned port number?
Similar to the RMI port number for the JRMPInvoker, or rather when you
don't specify one?
--jason
User: patriot1burke
Date: 02/03/08 17:18:02
Modified:src/main/org/jboss/metadata ConfigurationMetaData.java
Log:
client interceptors now pluggable xml. See standardjboss.xml for examples.
Revision ChangesPath
1.24 +30 -1
User: patriot1burke
Date: 02/03/08 17:18:18
Modified:src/main/org/jboss/proxy/ejb ProxyFactory.java
Log:
client interceptors now pluggable xml. See standardjboss.xml for examples.
Revision ChangesPath
1.11 +131 -123
User: patriot1burke
Date: 02/03/08 17:21:03
Modified:src/main/org/jboss/test/cts/keys AccountPK.java
Log:
somebody forgot to implement hashCode. This was causing the removing bean lock and
it has tx set!
errors
Revision ChangesPath
1.3 +10 -0
Nope... this won't work... SARDeployer only pays attention to .jar or
.zip files...
--jason
David Jencks wrote:
Can you just put the current jbosscx.sar in lib for now? I think the jca
rewrite I am working on may eliminate this problem. Don't spend any more
time than you need to on this,
No, no, no... this just won't work. I tried adding specific classpath
element after the * to just include this, but naming isn't up then so
it can't properly bind references...
I think the easiest thing would be to split up this file into 2.
--jason
Jason Dillon wrote:
Lib it will be.
JBoss daily test results
SUMMARY
Number of tests run: 535
Successful tests: 506
Errors:21
Failures: 8
[time of test: 9 March 2002 1:35 GMT]
[java.version:
On 2002.03.08 20:19:56 -0500 Jason Dillon wrote:
Nope... this won't work... SARDeployer only pays attention to .jar or
.zip files...
Well, unless you want to make SARDeployer deploy anything plausible it
finds, I guess you better split it up.
david
--jason
David Jencks wrote:
Can
On 2002.03.08 20:30:57 -0500 Jules Gosnell wrote:
The problem only happens with the new code.
The old service is constructed, JMX configuration calls are made on it.
It stores the state of all of these, does nothing with createService(),
creates and configures a Jetty instance in
JBoss daily test results
SUMMARY
Number of tests run: 535
Successful tests: 509
Errors:21
Failures: 5
[time of test: 9 March 2002 2:18 GMT]
[java.version:
Perhaps SARDeployer should bounce back to MainDeployer to deal with
this... but for now splitting them up is the simplest solution I can
think of.
--jason
David Jencks wrote:
On 2002.03.08 20:19:56 -0500 Jason Dillon wrote:
Nope... this won't work... SARDeployer only pays attention to .jar
User: user57
Date: 02/03/08 18:29:43
jbosscx/src/etc - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: user57
Date: 02/03/08 18:42:12
Modified:src/etc/conf/default jboss-service.xml
Log:
o fixed typeo
o removed ../../deploy it might confuse someone
Revision ChangesPath
1.35 +4 -5 jboss/src/etc/conf/default/jboss-service.xml
Index:
User: user57
Date: 02/03/08 18:43:25
Modified:src/etc/deploy hsqldb-default-service.xml jms-service.xml
Log:
o jbosscx.sar is not used for now
Revision ChangesPath
1.4 +1 -3 jboss/src/etc/deploy/hsqldb-default-service.xml
Index:
User: user57
Date: 02/03/08 18:44:03
Modified:.build.xml
Log:
o Building jboss-jca.jar, using local manifest
Revision ChangesPath
1.29 +13 -28jbosscx/build.xml
Index: build.xml
User: user57
Date: 02/03/08 18:44:03
Added: src/etc default.mf
Log:
o Building jboss-jca.jar, using local manifest
Revision ChangesPath
1.1 jbosscx/src/etc/default.mf
Index: default.mf
User: user57
Date: 02/03/08 18:45:34
Modified:jbossbuild.xml
Log:
o re-enable jboss-pool.jar copy to lib
o minor hack to reuse jca-sar jboss-service.xml
Revision ChangesPath
1.104 +21 -2 build/jboss/build.xml
Index: build.xml
User: user57
Date: 02/03/08 18:45:34
Modified:.build.xml
Log:
o re-enable jboss-pool.jar copy to lib
o minor hack to reuse jca-sar jboss-service.xml
Revision ChangesPath
1.21 +3 -3 jbosspool/build.xml
Index: build.xml
This should be resolved now.
--jason
David Jencks wrote:
On 2002.03.08 20:19:56 -0500 Jason Dillon wrote:
Nope... this won't work... SARDeployer only pays attention to .jar or
.zip files...
Well, unless you want to make SARDeployer deploy anything plausible it
finds, I guess you better
User: user57
Date: 02/03/08 18:48:02
Modified:jbossbuild.xml
Log:
o drop jboss- prefix
Revision ChangesPath
1.105 +2 -2 build/jboss/build.xml
Index: build.xml
===
RCS file:
User: user57
Date: 02/03/08 18:52:13
Modified:.build.xml
Log:
o fixed module include
Revision ChangesPath
1.30 +2 -2 jbosscx/build.xml
Index: build.xml
===
RCS file:
User: user57
Date: 02/03/08 19:05:57
Modified:src/etc/server/j2ee/conf jboss-service.xml
Log:
o fixed up j2ee config to work based on jca changes and jsr77 name change
Revision ChangesPath
1.3 +6 -9 netboot-demo/src/etc/server/j2ee/conf/jboss-service.xml
Bill Burke wrote:
Cool! I hope nobody took offense to any of my comments! I was hoping to
generate a discussion exactly like this! More comments follow...
There have been several requests for something like this over the last
year or so - this discussion was good to get me to actually start
Thought about this some more... well not a whole lot, but more. If there was a common
interface for MainDeployer-like things, aka, something that has deploy(URL) and
undeploy(URL), then we could easily add another component between URLDeploymentScanner
and MainDeployer which could implement
Any thoughts on renaming DeployerMBean to DeploymentControllerMBean?
From looking at the methods exposed, it seems to be more of a
controller of deployments (start/stop/init|create...)
If we rename this, then we can add a Deployer/DeployerMBean interface
which can be used to hook up future
User: user57
Date: 02/03/08 19:19:00
Modified:src/main/org/jboss/deployment DeployerMBean.java
Log:
o dropped some unused imports
Revision ChangesPath
1.2 +3 -6 jboss-system/src/main/org/jboss/deployment/DeployerMBean.java
Index: DeployerMBean.java
User: user57
Date: 02/03/08 19:21:50
Modified:src/docs/demo/netboot advanced.jsp
Log:
o scan period changed
Revision ChangesPath
1.6 +4 -2 newsite/src/docs/demo/netboot/advanced.jsp
Index: advanced.jsp
JBoss daily test results
SUMMARY
Number of tests run: 535
Successful tests: 508
Errors:21
Failures: 6
[time of test: 9 March 2002 3:25 GMT]
[java.version:
1 - 100 of 120 matches
Mail list logo
