Time to get on the same "page" with docs
by David M. Lloyd
We have a fairly small window available to us to get our AS 7
documentation together. So far, we have a bunch of miscellaneous
Confluence pages in various state of repair and a docbook repository for
a developer quick start which is reasonably underway, as well as
possibly other docbook repositories which have been begun by various
parties.
Before we invest too much in these disparate architectures, it's time to
hit the brakes and make sure we're all going in the same direction here.
It has been decided that our community documentation for AS 7 will be
hosted in Confluence. The process for generating the final
documentation files will be driven from here.
This means that we need a real page structure here. The top-level
documents ("books") we should define are currently:
* Developer Quick Start Guide (Pete's guide)
* Administration Guide
* Developer Reference Guide
The Developer Quick Start Guide is, in addition to Pete's stuff,
probably where the "How do I ...?" question sections should go. Jim,
this will be up to you to complete, otherwise we'll probably drop these
pages (most of them do not contain much if any content currently). This
guide is the top priority; if we have no other document ready by the
final 7.0 release, we should at least have this one. This means that
the docbook structure(s) we currently have should be imported and
cleaned up ASAP.
The Administration Guide is where we'd put descriptions of the
configuration file, operation descriptions, and how to perform
operations from the CLI and web console. Much of this guide can
probably be generated programmatically out of our operation
descriptions, at least for the initial version.
The Developer Reference Guide will cover details of every deployment
descriptor, annotation, and API we make available to deployments. It
should also cover embedding, eventually, and would be the place where we
put more esoteric stuff.
Once these three docs are complete, it would be really nice to
ultimately have a "JavaEE howto" guide to get people started with JavaEE
development, from an EE6 perspective (EJB3, CDI, etc.), but this is
clearly a much lower priority.
Questions?
--
- DML
14 years, 11 months
Project Leads: AS7 Public User APIs
by Andrew Lee Rubinger
Hi everyone:
I've a patch for AS7-650. The idea here is to expose all of the AS7
*public* APIs in one unified space. So users of AS7 can bring in our
vendor extensions to the spec easily and reliably.
If you're a project lead with a public API, please send me the Maven
coordinates you'd like exposed. For instance:
* org.jboss.shrinkwrap:shrinkwrap-api
* Hibernate Annotations
* JBoss EJB3 Annotations
* HornetQ
* Infinispan
* ...most importantly, what I haven't accounted for here.
Thanks!
S,
ALR
14 years, 11 months
JBoss AS 7 Getting Started Guide for developers + Docs repo
by Pete Muir
In preparation for the AS7 release, I've written an getting started guide for developers for AS 7. The focus of this guide is on the standalone mode of JBoss AS 7, and the EE 6 programming model, and consequently how you can write some simple apps using AS 7. It also includes instructions for using the AS7/EE 6 archetype that we will release alongside the guide.
I've added the guide + quickstart samples that live alongside it to the docs repo on github - https://github.com/jbossas/docs. This repo also includes a a distro script for building a zip, and some basic development instructions for quickstarts in the README. I just want to emphasise though, that the quickstarts are aimed at users, and so aim to be as simple as possible - we've elminated as many xml files as possible, made the pom as simple as possible etc. This (especially in the pom) means that things are quite as optimised as they might be (e.g. no shared parent in the quickstart poms). This is 100% intentional - the aim here is to have something people can copy and change easily - a shared parent isn't good for this!.
Anyway, please review, and add any other guides as you wish :-)
Pete
14 years, 11 months
CR1 Pushed to Monday (20th)
by Jason T. Greene
We have a number of pending blockers that are just too close for comfort
on such an important release including:
- Management Sync / New Controllers
- EJB Security Updates
- HornetQ release which includes HORNETQ-681
I want to make sure we have a valid release for getting feedback, so I
am pushing CR1 to Monday. Please get your changes in with ample time
before that.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
14 years, 11 months
JVM settings
by Matt Brasier
Is there a way to set arbritrary settings to be passed to the server JVM in
domain mode?
For example -XX:+UseCompressedOOPs
Matt
Matt Brasier
Head of Consulting
C2B2
Providing the foundations for Enterprise Scale Java.
T: 08450 539457
M: 07920 100625
W: <http://www.c2b2.co.uk/> www.c2b2.co.uk
E: <mailto:smillidge@c2b2.co.uk> mbrasier(a)c2b2.co.uk
Twitter: @mbrasier,@c2b2consulting
C2B2 Consulting Limited
Unit 33, Malvern Hills Science Park
Geraldine Road
Malvern
Worcestershire
WR14 3SZ
Registered in England and Wales: 4563419
Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire
14 years, 11 months
Something out of sync with StandaloneXml.writeServerProfile
by Scott Stark
If something (such as a hot deployment) modifies the standalone.xml, I'm
seeing the following error on restart:
17:55:07,494 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to
start service jboss.as.server-controller:
org.jboss.msc.service.StartException in service
jboss.as.server-controller:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
Failed to parse configuration
at
org.jboss.as.server.ServerControllerService.start(ServerControllerService.java:154)
[jboss-as-server-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
Caused by:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
Failed to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:113)
at
org.jboss.as.server.ServerControllerService.start(ServerControllerService.java:152)
[jboss-as-server-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
... 4 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[32,5]
Message: Unexpected attribute 'name' encountered
at
org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:83)
at
org.jboss.as.controller.parsing.ParseUtils.requireNoAttributes(ParseUtils.java:146)
at
org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:293)
at
org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:158)
This is due to
org.jboss.as.controller.parsing.StandaloneXml.writeServerProfile
outputing the name attribute:
private void writeServerProfile(final XMLExtendedStreamWriter
writer, final ModelMarshallingContext context) throws XMLStreamException {
ModelNode profileNode = context.getModelNode();
writer.writeStartElement(Element.PROFILE.getLocalName());
writer.writeAttribute(Attribute.NAME.getLocalName(),
profileNode.get(PROFILE_NAME).asString());
while parseServerProfile disallows attributes:
private void parseServerProfile(final XMLExtendedStreamReader
reader, final ModelNode address, final List<ModelNode> list) throws
XMLStreamException {
// Attributes
requireNoAttributes(reader);
I guess it was decided that there should not be a profile name, but the
write was not updated. This looks like this still is the latest version,
so the fix is a one-liner deletion of the writeAttribute in red.
14 years, 11 months
Keep having conflicts on files I never change
by Scott Stark
I keep running into conflicts when doing '|git pull --rebase upstream
master' on files I have never modified, for example, the root pom.xml. I
must be doing something wrong in my workflow to introduce this. I'm
guessing it is because of doing push -f from my local to remote repo. I
have just reset my local repo to a state prior to the last conflicts I'm
seeing, fetchd and rebased to upstream/master, and now must use -f to
get my remote repo in sync. Is that the correct thing to do, and if it
is, should I be seeing conflicts when pulling from upstream in the future?
Hopefully I'm missing a step (like the fetch and rebase I'm showing here
as I'm not sure I always do that) that is introducing the conflicts.
[183](ironmaiden:jboss-as) > git status
# On branch master
# Your branch is behind 'origin/master' by 7 commits, and can be
fast-forwarded.
#
nothing to commit (working directory clean)
[184](ironmaiden:jboss-as) > git fetch upstream
remote: Counting objects: 631, done.
remote: Compressing objects: 100% (207/207), done.
remote: Total 489 (delta 161), reused 435 (delta 125)
Receiving objects: 100% (489/489), 153.46 KiB | 64 KiB/s, done.
Resolving deltas: 100% (161/161), completed with 64 local objects.
From git://github.com/jbossas/jboss-as
7f6625f..baf9acc master -> upstream/master
[185](ironmaiden:jboss-as) > git rebase -i upstream/master
Successfully rebased and updated refs/heads/master.
[186](ironmaiden:jboss-as) > git push
Password:
To https://starksm64@github.com/starksm64/jboss-as.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to
'https://starksm64@github.com/starksm64/jboss-as.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.|
14 years, 11 months
Simplifying testsuite structure
by Thomas Diesler
Folks,
the current state is
+ demos
+ api
+ internals
+ legacy
+ spec
+ testsuite
+ api
+ benchmark
+ domain
+ integration
+ smoke
+ spec
+ stress
some of these modules are empty. It is hard to find the "right location"
for new tests. The demos are not self verifying. Instead I propose a
simplified structure like this
+ (demos removed)
+ testsuite
+ benchmark
+ domain
+ integration
+ smoke
+ stress
#1 demos removed
The artefacts in the various demos modules are currently reused by
testsuite modules (mainly smoke). demos are collapsed into smoke. I
believe a well documented smoke testsuite can serve the purpose of demos
and be a standalone deliverable. To be standalone you need to add a mvn
repository entry to smoke/pom.xml. Users can download this as a binary
and run 'mvn test' on it. Test cases should be organised in packages
according to their functional area. It is guaranteed that the demos work
because the smoke tests run on every build. Smoke tests should be well
documented.
#2 Collapse testsuite api+spec into integration
The integration testsuite should only have dependencies on spec and api
modules. Where this is not the case (i.e. a test depends on internal
impl) the dependency could be flagged and an api module could be made
available. Test cases should be organised in packages according to their
functional area. There may be test packages that reference jiras (e.g.
as835
<https://github.com/tdiesler/jboss-as/tree/master/testsuite/integration/sr...>).
The main motivation is, that it is intuitively clear where to put a
test. Even more importantly, where to look for already existing test
coverage.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 11 months
