jboss-head status
by Scott M Stark
There are still a number of sporadic
InstanceNotFoundException/NullPointerException errors are due to the
inconsistent handling of mbean services as services to be managed by the
ServiceController. In a number places there is code like this in the
EntityContainer:
// Try to register the instance cache as an MBean
try
{
ObjectName containerName = super.getJmxName();
Hashtable props = containerName.getKeyPropertyList();
props.put("plugin", "cache");
ObjectName cacheName = new
ObjectName(containerName.getDomain(), props);
server.registerMBean(instanceCache, cacheName);
}
catch(Throwable t)
{
log.debug("Failed to register cache as mbean", t);
}
Subsequent use of this mbean as a jboss mbean service can result in the
ServiceController taking ownership of the mbean and removing it on
undeployment, and this can cause the InstanceNotFoundException when a
container redundantly tries to remove the mbean it registered. This has
to be cleaned up to only use the ServiceController to manage the mbeans.
The issue is, this is all deployer code that needs to be updated to the
vdf anyway. Maybe this should be done as it will have to be done
regardless, but I don't want to waste too much time away from getting
deployers ported to the VDF.
The NullPointerExceptions showing up tend to result in a failure at one
point triggering a cascade of destroys on services that were never fully
created. Its sporadic so I don't know if its because of some lifecycle
calls not going through the controller, configuration of mbeans
happening outside of lifecycle, etc.
19 years, 7 months
Rebuildable jbossall-client.jar
by Jason T. Greene
We have historically had pluggable web service stacks in JBoss AS,
typically for the purpose of backwards compatibility. More recently, we
have also been providing updates that are pluggable on a particular
version of AS. For example, right now you can update a 4.0.4 instance to
use jbossws 1.0.2. I am sure that as time goes on other projects will be
doing similar things.
The problem with providing pluggable components in AS is that if any
part of that component is contained in jbossall-client.jar, it is likely
to contain conflicting or stale classes.
I can envision two solutions:
1. It is the responsibility of the component provider to have some kind
of install process that updates the jbossall-client.jar.
2. We provide a jboss/bin/rebuild-allclient.sh that reconstructs the
jar.
Any thoughts on this?
Thanks,
-Jason
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Jason T. Greene
Senior Software Engineer
JBoss division, RedHat Inc.
Xxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 7 months
RE: [JBoss-dev] AbstractKernelController behavior inconsistent
by Anil Saldhana
Ok. The Branch_4_0 and HEAD tests are synched up (and they use the
ServiceController for service related ops and to query the state of a
service).
While the 4.0 test is merry, the one in HEAD clearly shows that on a
service that has been created but failed to start:
a) I cannot set an attribute. (I am guessing I should, as the MBean is
registered)
b) I cannot destroy or deal with that service anymore.
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: Wednesday, August 23, 2006 7:25 PM
To: JBoss.org development list
Subject: Re: [JBoss-dev] AbstractKernelController behavior inconsistent
Correct. This was a wrong track as a similar test under 4.0.x also does
not have the start exception propagated to the caller.
Adrian Brock wrote:
> I don't think your test is valid, since it shows the same message
> with the OldServiceController?
>
> 2580 WARN [OldServiceController] Problem starting service
> jboss.test:type=test
> java.lang.Error: Did not see expected ERRORINSTART from:
> jboss.test:contained=SimpleMBean,type=test
> at
>
org.jboss.test.system.controller.support.ContainedMBeanService.startServ
ice(ContainedMBeanService.java:87)
> at
>
org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupp
ort.java:289)
> at
>
org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBean
Support.java:245)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
>
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.
java:157)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at
>
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav
a:264)
> at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.test.system.controller.legacy.OldServiceController
> $ServiceProxy.invoke(OldServiceController.java:862)
> at $Proxy0.start(Unknown Source)
> at
>
org.jboss.test.system.controller.legacy.OldServiceController.start(OldSe
rviceController.java:334)
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
19 years, 7 months
RE: [JBoss-dev] common project structure changes
by Ruel Loehr
1) 1.0.1 & 1.0.2 came out of the trunk…..this is where Thomas had made his changes
2) Are we to the point that we should eliminate the seperation of code lines? E.g., should both head and 4.0 build against the same version of common
a. If so, would we shoot for jboss 4.0.6
3) No, we can create an archives directory for all of the old branches, tags, much like we have for jbossas
4) Yes.
Ruel Loehr
JBoss QA
-----------------------------
512-342-7840 ext 2011
Yahoo: ruelloehr
Skype: ruelloehr
AOL: dokoruel
_____
From: Dimitris Andreadis
Sent: Thursday, August 24, 2006 5:26 AM
To: JBoss.org development list
Cc: Ruel Loehr; Scott M Stark
Subject: RE: [JBoss-dev] common project structure changes
I think we need to clean-up the status of the common project, a bit.
We have in repository a common project with versions, none of which is tracked in JIRA (HYPERLINK "http://jira.jboss.com/jira/browse/JBCOMMON"http://jira.jboss.com/jira/browse/JBCOMMON)
snapshot-Branch_4_0
snapshot
1.0.2
1.0.1
- Out of which trunck/branch were the versions 1.0.1, 1.0.2 produced?
- I've renamed the common Branch_4_0 to Branch_1_0 as we originally discussed. From this we'll produce jboss-common 1.0.0.CR1 (for jboss 4.0.5.CR1), so the repository versions 1.0.1, 1.0.2 should not really be there. I need to update the jboss project and repository accordingly.
(I would even argue we could keep the common stuff of Branch_4_0 inside the application server module, if nobody else is using it?)
- The refactored common version that will go to jboss head should be 2.0.0.x, right?
- I guess we don't need in the common module all those branches & tags carried over from jboss? The history is stored in the jboss module anyway.
- With the latest break-up, jboss xb could really be on its own.
_____
From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Ruel Loehr
Sent: Tuesday, August 15, 2006 9:13 PM
To: JBoss.org development list
Subject: [JBoss-dev] common project structure changes
We’ve been working on the file structure of the jboss common project and are now ready to merge the changes back into the trunk. The changes are substantial, so I want to make sure everyone is clear before I commit them in.
Currently the common project consists of 1 source tree which creates 4 artifacts:
Jboss-archive-browsing.jar
Jboss-common.jar
Jboss-common-client.jar
Namespace.jar
The project has been refactored in a branch (HYPERLINK "https://svn.jboss.org/repos/common/branches/logging_refactoring/"https://svn.jboss.org/repos/common/branches/logging_refactoring/ )
It has been broken into 5 projects
Common-core
Common-logging-jdk
Common-logging-log4j
Common-logging-spi
Jbossxb
Each of these projects builds a single jar. A maven build has been setup for each of these projects. The idea behind these changes is to cleanly separate each project into its own entity.
After these changes are committed, binaries will be published to the repository for all projects and then they will be integrated to jbossAS/trunk.
These changes apply only to the trunk version, not the 4.0 branch.
Thoughts or concerns?
Ruel Loehr
JBoss QA
--
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.5/425 - Release Date: 8/22/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.5/425 - Release Date: 8/22/2006
19 years, 7 months
RE: jboss-cache-testsuite Build Timed Out
by Rajesh Rajasekaran
The tests have timed out at different points on the earlier runs.
http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/200608
21005336/tests.log
http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/200608
18220127/tests.log
Probably with more no of tests to the cache testsuite this takes more
than 2 hrs now.
I m increasing the timeout to 4hrs.
________________________________
From: Ryan Campbell
Sent: Wednesday, August 23, 2006 3:54 PM
To: Dev - JBossCache; QA; jboss-development(a)lists.jboss.org
Subject: RE: jboss-cache-testsuite Build Timed Out
Hangs on the stress tests:
stresstests:
[junit] Running org.jboss.cache.BuddyReplicationStressTest
________________________________
From: qa(a)jboss.com [mailto:qa@jboss.com]
Sent: Wednesday, August 23, 2006 3:52 PM
To: Dev - JBossCache; QA; jboss-development(a)lists.jboss.org
Subject: jboss-cache-testsuite Build Timed Out
Importance: High
View results here ->
http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log
=log20060823145121
BUILD TIMED OUT
Ant Error Message: build timeout
Date of build: 08/23/2006 14:51:21
Time to build:
Last changed: 08/22/2006 16:37:53
Last log entry: move MarshalledValueOutputStream out of recursive
marshallTransientState method
Unit Tests: (0) Total Errors and Failures: (0)
Modifications since last build: (first 50 of 1591)
1.2
modified
msurtani
tests-50/functional/org/jboss/cache/pojo/util/ObjectUtilTest.java
migrated to new configurators
1.3
deleted
bwang
tests-50/functional/org/jboss/cache/pojo/util/ObjectUtilAopTest.java
Name changes
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/util/ObjectUtilTest.java
Name changes
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/util/ObjectUtilAopTest.java
Refctoring and moved some classes to impl dir.
1.4
modified
bwang
tests-50/functional/org/jboss/cache/pojo/util/MethodCallTest.java
upd
1.3
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/Node.java
Changed annotation to pojo from aop.
1.3
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/PropagationMan
ager.java
Changed annotation to pojo from aop.
1.3
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/StateItem.java
Changed annotation to pojo from aop.
1.3
modified
bwang
tests-50/functional/org/jboss/cache/pojo/util/MethodCallTest.java
Renamed CacheInterceptor to CacheFieldInterceptor
1.3
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/Person.java
Renamed CacheInterceptor to CacheFieldInterceptor
1.3
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/Student.java
Renamed CacheInterceptor to CacheFieldInterceptor
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/util/MethodCallTest.java
Relocated the dynamic interceptors
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/util/MethodCallTest.java
Added undo interceptor stack.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/NonSerializableObject.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/Person.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/Resource.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/SpecialSerializedAddress.j
ava
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/Student.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/TestNode.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/ValueObject.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/Node.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/PropagationMan
ager.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/PropagationRul
e.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/StateItem.java
Ported more test cases.
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/util/ObjectUtilAopTest.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/AbstractP
ropagtionRule.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/NodeImpl.
java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/ORSummary
Rule.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/Propagati
onManagerImpl.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/Propagati
onRuleFactory.java
Ported more test cases.
1.2
modified
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/StateItem
Impl.java
Ported more test cases.
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/NonSerializableObject.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/Person.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/Resource.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/SerializedAddress.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/SpecialAddress.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/SpecialSerializedAddress.j
ava
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/Student.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/TestNode.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/ValueObject.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/Node.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/PropagationMan
ager.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/PropagationRul
e.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/StateItem.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/AbstractP
ropagtionRule.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/NodeImpl.
java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/ORSummary
Rule.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/Propagati
onManagerImpl.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/Propagati
onRuleFactory.java
Test cases for PC2.0
1.1
added
bwang
tests-50/functional/org/jboss/cache/pojo/test/propagation/impl/StateItem
Impl.java
Test cases for PC2.0
19 years, 7 months
RE: [JBoss-dev] common project structure changes
by Heiko Braun
Thomas created 1.0.2 and 1.0.1.
Unfortunately he's on vacation this week and I don't know how these
version have been produced.
He will be back on Monday. Maybe you could wait until then to discuss it
with him.
There have been reasons for this that are unknown to me and I want to
avoid breaking jbossws/branch_4_0,
because we are in the middle of the 1.0.3 release.
I think it doesn't matter if it goes back into the application server
module,
but at least it should be separated from xb.
/Heiko
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Dimitris
Andreadis
Sent: Thursday, August 24, 2006 12:26 PM
To: JBoss.org development list
Subject: RE: [JBoss-dev] common project structure changes
I think we need to clean-up the status of the common project, a bit.
We have in repository a common project with versions, none of which is
tracked in JIRA (http://jira.jboss.com/jira/browse/JBCOMMON)
snapshot-Branch_4_0
snapshot
1.0.2
1.0.1
- Out of which trunck/branch were the versions 1.0.1, 1.0.2 produced?
- I've renamed the common Branch_4_0 to Branch_1_0 as we originally
discussed. From this we'll produce jboss-common 1.0.0.CR1 (for jboss
4.0.5.CR1), so the repository versions 1.0.1, 1.0.2 should not really be
there. I need to update the jboss project and repository accordingly.
(I would even argue we could keep the common stuff of Branch_4_0 inside
the application server module, if nobody else is using it?)
- The refactored common version that will go to jboss head should be
2.0.0.x, right?
- I guess we don't need in the common module all those branches & tags
carried over from jboss? The history is stored in the jboss module
anyway.
- With the latest break-up, jboss xb could really be on its own.
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Ruel
Loehr
Sent: Tuesday, August 15, 2006 9:13 PM
To: JBoss.org development list
Subject: [JBoss-dev] common project structure changes
We've been working on the file structure of the jboss common
project and are now ready to merge the changes back into the trunk.
The changes are substantial, so I want to make sure everyone is clear
before I commit them in.
Currently the common project consists of 1 source tree which
creates 4 artifacts:
Jboss-archive-browsing.jar
Jboss-common.jar
Jboss-common-client.jar
Namespace.jar
The project has been refactored in a branch
(https://svn.jboss.org/repos/common/branches/logging_refactoring/ )
It has been broken into 5 projects
Common-core
Common-logging-jdk
Common-logging-log4j
Common-logging-spi
Jbossxb
Each of these projects builds a single jar. A maven build has
been setup for each of these projects. The idea behind these changes is
to cleanly separate each project into its own entity.
After these changes are committed, binaries will be published to
the repository for all projects and then they will be integrated to
jbossAS/trunk.
These changes apply only to the trunk version, not the 4.0
branch.
Thoughts or concerns?
Ruel Loehr
JBoss QA
--
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date:
8/15/2006
19 years, 7 months
RE: [JBoss-dev] common project structure changes
by Dimitris Andreadis
I think we need to clean-up the status of the common project, a bit.
We have in repository a common project with versions, none of which is
tracked in JIRA (http://jira.jboss.com/jira/browse/JBCOMMON)
snapshot-Branch_4_0
snapshot
1.0.2
1.0.1
- Out of which trunck/branch were the versions 1.0.1, 1.0.2 produced?
- I've renamed the common Branch_4_0 to Branch_1_0 as we originally
discussed. From this we'll produce jboss-common 1.0.0.CR1 (for jboss
4.0.5.CR1), so the repository versions 1.0.1, 1.0.2 should not really be
there. I need to update the jboss project and repository accordingly.
(I would even argue we could keep the common stuff of Branch_4_0 inside
the application server module, if nobody else is using it?)
- The refactored common version that will go to jboss head should be
2.0.0.x, right?
- I guess we don't need in the common module all those branches & tags
carried over from jboss? The history is stored in the jboss module
anyway.
- With the latest break-up, jboss xb could really be on its own.
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Ruel
Loehr
Sent: Tuesday, August 15, 2006 9:13 PM
To: JBoss.org development list
Subject: [JBoss-dev] common project structure changes
We've been working on the file structure of the jboss common
project and are now ready to merge the changes back into the trunk.
The changes are substantial, so I want to make sure everyone is clear
before I commit them in.
Currently the common project consists of 1 source tree which
creates 4 artifacts:
Jboss-archive-browsing.jar
Jboss-common.jar
Jboss-common-client.jar
Namespace.jar
The project has been refactored in a branch
(https://svn.jboss.org/repos/common/branches/logging_refactoring/ )
It has been broken into 5 projects
Common-core
Common-logging-jdk
Common-logging-log4j
Common-logging-spi
Jbossxb
Each of these projects builds a single jar. A maven build has
been setup for each of these projects. The idea behind these changes is
to cleanly separate each project into its own entity.
After these changes are committed, binaries will be published to
the repository for all projects and then they will be integrated to
jbossAS/trunk.
These changes apply only to the trunk version, not the 4.0
branch.
Thoughts or concerns?
Ruel Loehr
JBoss QA
--
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date:
8/15/2006
19 years, 7 months
