[JBoss AS7 Development] - NPE in StandaloneClientImpl.isDeploymentNameUnique
by Thomas Diesler
Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] created the discussion
"NPE in StandaloneClientImpl.isDeploymentNameUnique"
To view the discussion, visit: http://community.jboss.org/message/570720#570720
--------------------------------------------------------------
Caused by: org.jboss.as.protocol.mgmt.ManagementException: Failed to check deployment name uniqueness.
at org.jboss.as.standalone.client.impl.StandaloneClientImpl.isDeploymentNameUnique(StandaloneClientImpl.java:130)
at org.jboss.as.standalone.client.impl.StandaloneClientDeploymentManager$1.distributeDeploymentContent(StandaloneClientDeploymentManager.java:59)
at org.jboss.as.standalone.client.impl.deployment.DeploymentPlanBuilderImpl.add(DeploymentPlanBuilderImpl.java:187)
at org.jboss.as.standalone.client.impl.deployment.DeploymentPlanBuilderImpl.add(DeploymentPlanBuilderImpl.java:182)
at org.jboss.osgi.plugin.jbossas7.DeployerClientImpl.deploy(DeployerClientImpl.java:85)
... 31 more
Caused by: java.lang.NullPointerException
at org.jboss.as.standalone.client.impl.StandaloneClientImpl.isDeploymentNameUnique(StandaloneClientImpl.java:128)
... 35 more
This repeatedly happens on the http://jbmuc.dyndns.org:8280/hudson/job/jbosgi-remote/34/testReport/junit... EC2 Hudson instance, but cannot be reproduces locally.
boolean isDeploymentNameUnique(String name) {
try {
128: return new CheckUnitDeploymentNameOperation(name).executeForResult(getConnectionStrategy());
} catch (Exception e) {
throw new ManagementException("Failed to check deployment name uniqueness.", e);
}
}
Any idea, how a NPE is even possible given the trace above.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/570720#570720]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months
[JBoss AS7 Development] - How I work with github jboss-as
by Thomas Diesler
Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] created the discussion
"How I work with github jboss-as"
To view the discussion, visit: http://community.jboss.org/message/573577#573577
--------------------------------------------------------------
Probably like everybody else I fork https://github.com/jbossas/jboss-as https://github.com/jbossas/jboss-as using the github web UI.
Then I clone my fork to my local workspace
$ git clone git@github.com:jbosgi/jboss-as.git
$ cd jboss-as
I never commit anything to master. Instead, I checkout a feature branch and create a remote config to the upstream repo
$ git remote add upstream git://github.com/jbossas/jboss-as.git
$ git checkout -b the-next-cool-thing
Switched to a new branch 'the-next-cool-thing'
When the upstream master moves on I pull those changes in my master and push it to my public fork
$ git checkout master
Switched to branch 'master'
$ git pull upstream master
remote: Counting objects: 581, done
$ git push origin master
...
To git@github.com:jbosgi/jboss-as.git
b55e9a0..bcad431 master -> master
This can be done by a cronjob and keeps my master in sync with the upstream master
I don't rebase a branch that I've pushed to a public repo because it breaks forks that where taken from that branch. Instead I regularly merge the changes from master to my feature branch.
$ git checkout the-next-cool-thing
$ get merge master
Updating b55e9a0..bcad431
Fast-forward
$ git push origin the-next-cool-thing
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:jbosgi/jboss-as.git
* [new branch] the-next-cool-thing -> the-next-cool-thing
The beauty of git is that it can detect commits that were already applied. So my merges from master can be reapplied to master any time. When I'm done with the next cool thing I send a pull request to http:// jbossas-pull-requests(a)lists.jboss.org and wait for however long it takes for my changes to show up on master. I resolve the issue in JIRA and reopen/assign to somebody who can take care of the pull to upstream.
When I'm done I delete the feature branch from my public repo
$ git push origin :the-next-cool-thing
To git@github.com:jbosgi/jboss-as.git
- [deleted] the-next-cool-thing
Generally I found that rebasing generates a lot of work especially when you have multiple feature branches and people building ontop of your work.
May this be useful
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/573577#573577]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months
[IronJacamar Development] - TestSuite - multithreaded tests and stress test
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] created the discussion
"TestSuite - multithreaded tests and stress test"
To view the discussion, visit: http://community.jboss.org/message/573167#573167
--------------------------------------------------------------
I'm convincing that we need to develop some tests in our test suite running concurrently to stress some multithread feature in our code. Of course needs of this kind of tests isn't immediately exposed by a coverage tool, but a deep analysis of our code base make it surely needed.
In fact also old AS5/6 test suite has some of these tests, both to prove features/behaviors and to make some kind of stress tests.
What I don't like of these tests is that is easily become ard to read and understand, putting a lot of threading code into tests it self.
I'm instead thinking about to some external tool (maybe something to write, inside or outside ironjacamar code base, but not as part of testssuite for sure) to hide this threading infos, and trying to make threading pure declarative in tests.
TestNG does something like that, but it doesn't seems perfect at a first look. I'll come back with some proposal very soon.
bye
S.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/573167#573167]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months
[IronJacamar Development] - TestSuite - Coverage
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] created the discussion
"TestSuite - Coverage"
To view the discussion, visit: http://community.jboss.org/message/573329#573329
--------------------------------------------------------------
Hi all,
>From a coverage point of view our test suite is quite good. The question is how much coverage is our target, but much more important which package/module should have top priority in terms of test coverage.
ant cobertura
generate the coverage report into reports/cobertura/html/index.html. Please have a look to get an idea of current status.
As you can see there we have a good coverage in our implementations, while we are not testing a lot in an abstract way (using interfaces from javax) instead of stress the real implementation. It's a choice of course: it makes test more readable and much more linked to real implementation. Of course a more abstract tests would verify that we are providing correctly what the specs require. Of course the TCK is doing that for us, so we can leave tests stressing our own implementation safely.
Anyway in both cases, IMHO we should fine tune cobertura report to exclude from the reports classes and interface we are not stressing for a choice, and maybe (I'm not sure it's possible, I'm verifying) also method/classes that doesn't make sense to stress. I'm thinking about for example to pojo geteer and setter that is dropping down the finale coverage percentage wrongly.
let me know your thought and eventually the priority you would assign to not-well covered packages.
best regards
S.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/573329#573329]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months