To get an idea of what's taking time in XB during the AS start-up, I
added simple time checks for three things:
- creation of unmarshaller instances (parsers)
- schema binding (parsing of JBossXB/JAXB annotations)
- unmarshalling (parsing xml + assembling the Java graph)
I started the default AS configuration 10 times and here are the average
AS start-up time: 31226 ms
Init unmarshallers (94 instances): 99 ms
Binding (13 schemas): 1194 ms
Unmarshalling (71 files): 1764 ms
Total xb time: 3057 ms
Which is around 10%.
I think first, I'm going to look into serializing/precompiling bindings,
e.g. metadata projects could already include in the releases serialized
Booting Embedded I've got a fun exception informing me that methods
"!GET,POST" are not allowed while creating a WebResourcePermission.
These are the identical parameters passed in while running AS in
Standalone. Where are the allowed HTTP methods configured? Does this
ring any bells to anyone?
17:25:01,895 ERROR [AbstractKernelController] Error installing to Real:
state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying:
Caused by: java.lang.IllegalArgumentException: Could not create resource
permission with pattern "/restricted/*" and methods: !GET,POST
Caused by: java.lang.IllegalArgumentException: illegal HTTP method
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
Ok, I am a bit tired of switching Java versions around and try to redo
maven releases (I know about the target 1.5 also). :) But I think it is
high time we made the Branch_5_x of JBAS to be JDK6+
Jason was telling me that it should not be a problem.
As part of the Servlet 3.0 development, AS trunk will have to be
switched to JBoss Web 3. Most is just a one time API change that is
not very difficult, and it should provide the same level of
functionality than JBW 2.1 (the new features need many deployer
updates), but the JSP changes are more intrusive.
Of particular interest is the new handling for tag library
descriptors, where instead of having Japser parse them "magically"
(and in a very hackish way ;) ) parse them, metadata will have to be
created in the container (Stan in particular asked for that ;) ). For
example, for JSTL and JSF, some deployer or listener could be
processing their taglibs using the new metadata classes and add them
to the Tomcat deployer as "shared" taglib metadata, which would then
be added to every webapps. This could be done by with the service that
would be looking for ServletConteainerInitializers in shared
Given the amount of stuff that is involved, I don't see how to do the
thing in one pass, so I was posting to inquire about the development
strategy. Should this be done in trunk, accepting that JSP taglib
support is not going to be functional for a little while ? [note: it
might be possible to hack in a temporary solution by using Catalina's
taglib processing for now] In a separate branch of AS ? (but given the
rate of change, merging could be very difficult)
I have committed the split metadata now. The details are below. I'd like
to get feedback from the projects that use it.
I couldn't execute mvn deploy. It would fail with e.g.
[INFO] Error retrieving previous build number for artifact
'org.jboss.metadata:metadata-common:jar': repository metadata for:
data:metadata-common:2.0.0-SNAPSHOT' could not be retrieved from
repository: snapshots.jboss.org due to an error: Authorization failed:
So, if you want to build e.g. EJB metadata you have to check out ejb and
common projects, build and install common and then build ejb.
New metadata structure
Metadata project (version 1.0.X) has been split into several: common
project + one project per specific technology. The initial version for
all the new projects is 2.0.0-SNAPSHOT. The current list of the projects is:
The common one contains stuff which is used by other projects, plus
common Java EE metadata, common JBoss metadata and WS metadata. These
could further be extracted to their own projects if needed.
All technology-specific projects declare dependency on the common project.
The main location is
https://svn.jboss.org/repos/jbossas/projects/metadata/. Under which each
project's trunk is located under project_name/trunk, e.g. common/trunk,
groupId remains the same, i.e. org.jboss.metadata.
artifactId is metadata-project_name, e.g. metadata-common, metadata-ejb,
Things that were removed
Packages org.jboss.ejb3.metamodel and org.jboss.metamodel.descriptor
weren't copied. I am not sure if they are used now.
The same for org.jboss.metadata.test.ejb3 and
JAWS DTDs weren't copied neither (they shouldn't have been there from
I am planning to updade AS trunk to use the new split metadata which is
currently only in snapshots. So, I would like to know whether everybody
working on or using metadata is ready for it. I know Remy is.
If there are no objections, I'll do it tomorrow.
PS: I'll also upgrade XB to the latest release.
I just updated Branch_5_x and am seeing these logs for each WAR deployment:
14:57:00,635 WARN [JBossJSFConfigureListener] No such ValidatorFactory
in VDF layer, creating new instance.
14:57:00,641 INFO [ValidationXmlParser] No META-INF/validation.xml
found. Using annotation based configuration only!
Could we reduce the logging level of these, since it doesn't look like
these should be logged at WARN or INFO.
I keep running into compile errors showing up that do not make sense as
the dependencies for the classes that cannot be found are in the
MAVEN2_CLASSPATH_CONTAINER dependencies. Currently there are errors
related to not being able to resolve the
class, even though the classpath contains the
I'm also seeing this error for every project it tries to build:
8/10/09 12:04:19 PM PDT: Build errors for testsuite;
org.apache.maven.lifecycle.LifecycleExecutionException: Invalid or
missing parameters: [Mojo parameter [name: 'rules'; alias: 'null']] for
I have tried throwing the workspace away and reimporting it, but that
resulted in the same set of errors. Up to this point some combination of
updating dependencies, rebuilding clean, rebuilding the workspace has
worked, but now it is not.
Anyone else have eclipse working off of the current trunk?