building the documentation for JBoss public and private API...
by Scott Marlow
We were just talking about building a list of all JBoss AS public API
calls. This will be used to document the public API versus what is
considered private (we will include only the public API in this "public
api" documentation).
One idea mentioned already is that we could use an annotation (e.g.
something like @publicAPI mentioned elsewhere
http://www.opends.org/promoted-builds/2.0.0-RC1/javadoc/org/opends/server...).
We would then build the "public API" documentation based on the
@publicAPI annotations (the how to be determined).
We might want to also include a @privateAPI tag, for source files that
contain a mix of public and private API (or maybe we should move
anything private into separate modules).
Just to throw it out there, one alternative approach would be to include
this same level of information (e.g. "this class is part of public API")
in the AS Javadoc.
Thoughts on either approach?
Thanks,
Scott
17 years, 1 month
Redeploy an app if xml is added to metadata location?
by Jaikiran Pai
I just noticed that we redeploy an entire application if a xml file gets
added/removed from the metadata locations of a application. For example,
if in an exploded WAR file we add a somefile.xml to the WEB-INF folder
the application gets redeployed (easily reproducible in ROOT.war). Why
do we do this? I thought redeploy would be triggered by touching the
deployment descriptor of the app (i.e. changing the last modified time
of web.xml). Looks to be intentional from what i see in the
configurations (profile.xml):
<!-- This just checks metadata locations -->
<bean name="MetaDataStructureModificationChecker"
class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker">
<constructor>
<parameter><inject bean="MainDeployer" /></parameter>
</constructor>
<property name="cache"><inject bean="StructureModCache" /></property>
<property name="filter"><bean
class="org.jboss.system.server.profile.basic.XmlIncludeVirtualFileFilter"
/></property>
</bean>
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasStructureBeenModifed(...):
// do we have some new files or some were deleted
if (leaves != null && children != null &&
leaves.size() != children.size())
{
if (log.isTraceEnabled())
log.trace("Metadata files number changed, old: "
+ leaves + ", now: " + children);
return true;
}
Why do we have to redeploy the application if a xml is added to the
metadata folder of a application?
-Jaikiran
17 years, 1 month
Components in trunk are out of date
by David M. Lloyd
This is a diff of component-matrix/pom.xml from 5.x ('-') to trunk ('+')...
This first chunk is... well, whatever. I guess Paul Gier will know what's
up with this :-)
--
@@ -10,7 +10,7 @@
<parent>
<groupId>org.jboss</groupId>
<artifactId>jboss-parent</artifactId>
- <version>4</version>
+ <version>5-beta-1</version>
</parent>
<!-- POM Model Version -->
--
Next chunk is obvious version stuff...
--
@@ -20,7 +20,7 @@
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-component-matrix</artifactId>
<packaging>pom</packaging>
- <version>5.2.0-SNAPSHOT</version>
+ <version>6.0.0-SNAPSHOT</version>
<name>JBossAS Component Matrix</name>
<description>
Contract for Consumers of JBossAS Components, defining and
--
Now here's the components (remember, - is 5.x and + is trunk):
--
@@ -34,14 +34,14 @@
<version.jacorb>2.3.0jboss.patch6-brew</version.jacorb>
<version.javax.faces>1.2_12</version.javax.faces>
<version.jboss.jaxr>1.2.1.GA</version.jboss.jaxr>
- <version.jboss.jbossts>4.6.1.GA</version.jboss.jbossts>
+ <version.jboss.jbossts>4.4.0.GA</version.jboss.jbossts>
<version.jboss.jbossws-common>1.2.0.Beta1</version.jboss.jbossws-common>
<version.jboss.jbossws-framework>3.2.0.Beta1</version.jboss.jbossws-framework>
<version.jboss.jbossws-spi>1.2.0.Beta1</version.jboss.jbossws-spi>
<version.jboss.jbossws>3.2.0.Beta1</version.jboss.jbossws>
<version.jboss.jms-integration-tests>1.0.1.GA</version.jboss.jms-integration-tests>
- <version.jboss.messaging>1.4.3.GA</version.jboss.messaging>
- <version.jboss.web>2.1.3.GA</version.jboss.web>
+ <version.jboss.messaging>1.4.1.GA</version.jboss.messaging>
+ <version.jboss.web>2.1.2.GA</version.jboss.web>
<version.jgroups>2.6.10.GA</version.jgroups>
<version.junit>3.8.2</version.junit>
<version.org.hibernate.annotations>3.4.0.GA</version.org.hibernate.annotations>
--
Three diffs in this chunk - ALL of which show older components in trunk
than in 5.x.
Here's a bigger chunk:
--
@@ -50,66 +50,62 @@
<version.org.hibernate.entity.manager>3.4.0.GA</version.org.hibernate.entity.manager>
<version.org.hibernate.validator>3.1.0.GA</version.org.hibernate.validator>
<version.org.hibernate>3.3.1.GA</version.org.hibernate>
- <version.org.jboss.aop>2.1.1.GA</version.org.jboss.aop>
+ <version.org.jboss.aop>2.1.0.CR2</version.org.jboss.aop>
<version.org.jboss.aspects.currentinvocation>1.0.0.GA</version.org.jboss.aspects.currentinvocation>
<version.org.jboss.aspects.remoting>1.0.1.GA</version.org.jboss.aspects.remoting>
<version.org.jboss.aspects.security>1.0.0.GA</version.org.jboss.aspects.security>
-
<version.org.jboss.bootstrap.impl.as>0.1.2</version.org.jboss.bootstrap.impl.as>
-
<version.org.jboss.bootstrap.impl.base>0.1.2</version.org.jboss.bootstrap.impl.base>
-
<version.org.jboss.bootstrap.impl.mc>0.1.2</version.org.jboss.bootstrap.impl.mc>
- <version.org.jboss.bootstrap.spi>0.1.2</version.org.jboss.bootstrap.spi>
-
<version.org.jboss.bootstrap.spi.as>0.1.2</version.org.jboss.bootstrap.spi.as>
-
<version.org.jboss.bootstrap.spi.mc>0.1.2</version.org.jboss.bootstrap.spi.mc>
<version.org.jboss.aspects.transaction>1.0.0.GA</version.org.jboss.aspects.transaction>
+ <version.org.jboss.bootstrap>1.0.0-Beta-2</version.org.jboss.bootstrap>
<version.org.jboss.cache.core>3.1.0.GA</version.org.jboss.cache.core>
<version.org.jboss.cache.pojo>3.0.0.GA</version.org.jboss.cache.pojo>
- <version.org.jboss.cl>2.0.6.GA</version.org.jboss.cl>
+ <version.org.jboss.cl>2.0.3.GA</version.org.jboss.cl>
<version.org.jboss.cluster.cache.jbc>2.0.0.GA</version.org.jboss.cluster.cache.jbc>
<version.org.jboss.cluster.cache.spi>2.0.0.GA</version.org.jboss.cluster.cache.spi>
<version.org.jboss.cluster.client>1.1.1.GA</version.org.jboss.cluster.client>
<version.org.jboss.cluster.server.api>1.1.1.GA</version.org.jboss.cluster.server.api>
- <version.org.jboss.common.core>2.2.14.GA</version.org.jboss.common.core>
- <version.org.jboss.deployers>2.0.7.GA</version.org.jboss.deployers>
+ <version.org.jboss.common.core>2.2.12.GA</version.org.jboss.common.core>
+ <version.org.jboss.deployers>2.0.5.GA</version.org.jboss.deployers>
<version.org.jboss.ejb3.common.client>1.0.0</version.org.jboss.ejb3.common.client>
<version.org.jboss.ejb3.core.client>1.1.6</version.org.jboss.ejb3.core.client>
+
<version.org.jboss.ejb3.endpoint.deployer>0.1.3</version.org.jboss.ejb3.endpoint.deployer>
<version.org.jboss.ejb3.proxy.impl.client>1.0.2</version.org.jboss.ejb3.proxy.impl.client>
<version.org.jboss.ejb3.proxy.spi.client>1.0.0</version.org.jboss.ejb3.proxy.spi.client>
<version.org.jboss.ejb3.proxy.clustered.client>1.0.1</version.org.jboss.ejb3.proxy.clustered.client>
<version.org.jboss.ejb3.security.client>1.0.0</version.org.jboss.ejb3.security.client>
- <version.org.jboss.ejb3>1.1.7-alpha-1</version.org.jboss.ejb3>
-
<version.org.jboss.ejb3.endpoint.deployer>0.1.3</version.org.jboss.ejb3.endpoint.deployer>
+ <version.org.jboss.ejb3>1.1.6</version.org.jboss.ejb3>
<version.org.jboss.integration>5.1.0.GA</version.org.jboss.integration>
- <version.org.jboss.jbossxb>2.0.1.GA</version.org.jboss.jbossxb>
- <version.org.jboss.jopr>1.2.0.GA</version.org.jboss.jopr>
+ <version.org.jboss.jbossxb>2.0.0.GA</version.org.jboss.jbossxb>
<version.org.jboss.jpa>1.0.0</version.org.jboss.jpa>
- <version.org.jboss.logbridge>1.0.0.GA</version.org.jboss.logbridge>
- <version.org.jboss.logmanager>1.0.0.GA</version.org.jboss.logmanager>
- <version.org.jboss.man>2.1.1.Beta2</version.org.jboss.man>
+ <version.org.jboss.logbridge>1.0.0.CR3</version.org.jboss.logbridge>
+ <version.org.jboss.logmanager>1.0.0.CR3</version.org.jboss.logmanager>
+ <version.org.jboss.man>2.1.0.SP1</version.org.jboss.man>
<version.org.jboss.mdr>2.0.1.GA</version.org.jboss.mdr>
- <version.org.jboss.metadata>1.0.1.GA</version.org.jboss.metadata>
-
<version.org.jboss.microcontainer>2.0.6.GA</version.org.jboss.microcontainer>
+ <version.org.jboss.metadata>1.0.0.CR16</version.org.jboss.metadata>
+
<version.org.jboss.microcontainer>2.0.4.GA</version.org.jboss.microcontainer>
+ <version.org.jboss.mx>6.0.0.Beta1</version.org.jboss.mx>
<version.org.jboss.naming>5.0.3.GA</version.org.jboss.naming>
<version.org.jboss.reflect>2.0.2.GA</version.org.jboss.reflect>
- <version.org.jboss.remoting>2.5.1</version.org.jboss.remoting>
- <version.org.jboss.security>2.0.3.SP1</version.org.jboss.security>
-
<version.org.jboss.security.negotiation>2.0.3.SP1</version.org.jboss.security.negotiation>
+ <version.org.jboss.remoting>2.5.0.SP2</version.org.jboss.remoting>
+ <version.org.jboss.security>2.1.0.20090318</version.org.jboss.security>
<version.org.jboss.threads>1.0.0.GA</version.org.jboss.threads>
- <version.org.jboss.vfs>2.1.2.GA</version.org.jboss.vfs>
+ <version.org.jboss.vfs>2.1.0.GA</version.org.jboss.vfs>
+
<version.org.jboss.security.negotiation>2.0.3.SP1</version.org.jboss.security.negotiation>
<version.org.jboss.xnio.metadata>1.0.0.GA</version.org.jboss.xnio.metadata>
- <version.org.jboss.xnio>1.2.1.GA</version.org.jboss.xnio>
- <version.org.slf4j>1.5.6</version.org.slf4j>
+ <version.org.jboss.xnio>1.2.0.GA</version.org.jboss.xnio>
<version.org.springframework>2.5.5</version.org.springframework>
<version.oswego-concurrent.concurrent>1.3.4-jboss-update1</version.oswego-concurrent.concurrent>
- <version.seam.integration>5.1.0.CR1</version.seam.integration>
+ <version.seam.integration>5.0.2.GA</version.seam.integration>
<version.staxex>2.1.1</version.staxex>
<version.streambuffer>2.1.1</version.streambuffer>
<version.suffix.org.jboss.javaee>.GA</version.suffix.org.jboss.javaee>
<version.sun-jaxws>2.1.3</version.sun-jaxws>
- <version.sun.jaxb>2.1.9-brew</version.sun.jaxb>
- <version.webbeans.integration>5.2.0.Beta2</version.webbeans.integration>
+ <version.sun.jaxb>2.1.9</version.sun.jaxb>
+ <version.webbeans.integration>5.2.0.BETA1</version.webbeans.integration>
<version.xdoclet>1.2.3</version.xdoclet>
</properties>
+ <!-- Build Configuration -->
+
<!-- Dependency Management -->
<dependencyManagement>
<dependencies>
--
OK that was a big one, but it shows that apart from ALR's bootstrap work,
pretty much everything in trunk is older than what we put in 5.x (including
VFS, meaning my beloved performance enhancements aren't in trunk yet). OK
I'm not guiltless here either.
There's a few more bits that are significant which don't use version
properties (why not?). They're pretty long so I'm going to edit them down a
little...
--
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-spi</artifactId>
- <version>2.1.0.GA</version>
+ <version>2.0.5.GA</version>
</dependency>
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-jdk</artifactId>
- <version>2.1.0.GA</version>
+ <version>2.0.5.GA</version>
</dependency>
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-log4j</artifactId>
- <version>2.1.0.GA</version>
+ <version>2.0.6.GA</version>
<exclusions>
<exclusion>
<groupId>apache-log4j</groupId>
--
This is all logging stuff, so I feel comfortable bumping it all to 2.1.0.GA.
--
+ <dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
- <version>${version.org.slf4j}</version>
+ <version>1.5.0</version>
</dependency>
<dependency>
<groupId>org.jboss.slf4j</groupId>
<artifactId>slf4j-jboss-logging</artifactId>
- <version>1.0.2.GA</version>
+ <version>1.0.0.GA</version>
</dependency>
--
More logging stuff.
But this stuff seems important:
--
@@ -1301,7 +1266,7 @@
<dependency>
<groupId>org.jboss.test</groupId>
<artifactId>jboss-test</artifactId>
- <version>1.1.5-alpha-2</version>
+ <version>1.1.4.GA</version>
<exclusions>
<exclusion>
<groupId>apache-log4j</groupId>
@@ -1313,7 +1278,7 @@
<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-server-manager</artifactId>
- <version>1.0.3-alpha-2</version>
+ <version>1.0.2.GA</version>
<exclusions>
<exclusion>
<groupId>org.jboss.jbossas</groupId>
--
That's it! It's probably not safe to do a blanket update of everything, so
I won't, but treat this as a reminder to update your stuff if you haven't.
- DML
17 years, 1 month
Re: [jboss-dev] Components in trunk are out of date
by Shelly McGowan
David,
jboss-test and jboss-server-manager alpha releases were done as part of the AS BootStrap changes.
For trunk, jboss-server-manager 1.0.2.GA and jboss-test 1.1.4.GA releases are correct - for now.
Shelly
FYI, The release notes for these alpha releases which are in Branch_5_x are shown below.
Release Notes - JBoss AS Server Manager - Version 1.0.3
** Bug
* [JBASM-30] - System Property "java.endorsed.dirs" is not set in ServerController.getStartCommandLine
** Feature Request
* [JBASM-31] - Set System Property "xb.builder.useUnorderedSequence=true" in ServerController.getStartCommandLine
Release Notes - JBoss Test - Version 1.1.5
Task
* [JBTEST-12] - Upgrade jboss-test to server-manager:1.0.3-alpha-1
As discussed here:
http://lists.jboss.org/pipermail/jboss-development/2009-May/014419.html
And tracked here:
https://jira.jboss.org/jira/browse/JBASM-32
https://jira.jboss.org/jira/browse/JBAS-6924
But this stuff seems important:
--
@@ -1301,7 +1266,7 @@
<dependency>
<groupId>org.jboss.test</groupId>
<artifactId>jboss-test</artifactId>
- <version>1.1.5-alpha-2</version>
+ <version>1.1.4.GA</version>
<exclusions>
<exclusion>
<groupId>apache-log4j</groupId>
@@ -1313,7 +1278,7 @@
<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-server-manager</artifactId>
- <version>1.0.3-alpha-2</version>
+ <version>1.0.2.GA</version>
<exclusions>
<exclusion>
<groupId>org.jboss.jbossas</groupId>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
17 years, 2 months
do we want to marshal metadata?
by Alexey Loubyansky
MC team has started working on MC tools and one thing they tried was to
marshal MC metadata into XML. Which didn't work since unmarshalling has
evolved a lot and marshalling never been used was left behind.
Marshalling was developed to cover contract with JBossWS. It uses
different and now (comparing to unmarshalling) much more primitive
binding means/metadata.
So, the question is do we want to be able to marshal metadata (MC or any
other) with XB? If so, marshalling will have to catch up.
Thanks,
Alexey
17 years, 2 months
AS trunk update
by Alessio Soldano
Hi,
is there any specific reason for the org.jboss.deployers and
org.jboss.vfs dependencies being a couple of GA version old in trunk?
(2.05.GA and 2.1.0.GA while we have 2.0.7.GA and 2.1.2.GA on Branch_5_x)
Asking as I'd need to align something in the webservice module, but that
requires them to be aligned first.
Thanks
Alessio
--
Alessio Soldano
Web Service Lead
JBoss, a division of Red Hat
17 years, 2 months
