xb in start up time
by Alexey Loubyansky
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
results.
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
schema bindings.
16 years, 11 months
Where are allowable methods configured?
by Andrew Lee Rubinger
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?
Thx. :)
17:25:01,895 ERROR [AbstractKernelController] Error installing to Real:
name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/
state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying:
jboss.jacc:service=jacc,id="vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/invoker.war/",parent="http-invoker.sar"
at
org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at ...
Caused by: java.lang.IllegalArgumentException: Could not create resource
permission with pattern "/restricted/*" and methods: !GET,POST
at
org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:229)
at
org.jboss.deployment.security.WarJaccPolicy.createPermissions(WarJaccPolicy.java:55)
at
org.jboss.deployment.security.WarJaccPolicy.createPermissions(WarJaccPolicy.java:38)
at org.jboss.deployment.security.JaccPolicy.create(JaccPolicy.java:94)
...
Caused by: java.lang.IllegalArgumentException: illegal HTTP method
at
javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
at
javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
at
org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:225)
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
16 years, 11 months
Branch_5_x of JBAS to require JDK6?
by Anil Saldhana
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.
Any objections/thoughts?
16 years, 11 months
Moving microcontainer -> kernel
by Kabir Khan
We plan to make some changes to the microcontainer project over the
next few days/week, and wanted to give you all a bit of advance
warning. The reason is that the microcontainer project has grown since
its inception and is an umbrella for numerous sub-projects: jboss-
reflect, jboss-man, jboss-mdr, jboss-mdr-cache, jboss-cl, jboss-
deployers, jboss-vfs as well as the 'microcontainer' project, which is
really the kernel.
Hence, we plan to rebrand the existing 'microcontainer' core as
'kernel', and here is what will change:
*** JIRA ***
We have already moved it in JIRA, so the old JBMICROCONT issues have
been moved to JBKERNEL.
The existing JBMICROCONT project will be kept to deal with global
microcontainer issues.
*** SVN ***
https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/
will move to
https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/
But we will leave the existing tags under
https://svn.jboss.org/repos/jbossas/projects/microcontainer/tags/
as well as the branch these releases have been taken from:
https://svn.jboss.org/repos/jbossas/projects/microcontainer/branches/Bran...
The plan is for the
https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/
to be come a holder projects for things like tools, docs etc. that
bind together the individual sub-projects.
The upcoming 2.2.x releases will be tagged from
https://svn.jboss.org/repos/jbossas/projects/kernel/branches/
Branch_2_2 (this branch will be created later once we're ready for
2.2.x )
*** MAVEN ***
From 2.2.0 onwards the existing microcontainer artifacts will have a
new groupId
org.jboss.microcontainer -> org.jboss.kernel
The 2.0.x releases will keep on using org.jboss.microcontainer.
Cheers,
Kabir
16 years, 11 months
Migrating to JBoss Web 3
by Rémy Maucherat
Hi,
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
libraries.
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)
Comments ?
Rémy
17 years
split metadata
by Alexey Loubyansky
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:
'snapshot org.jboss.meta
data:metadata-common:2.0.0-SNAPSHOT' could not be retrieved from
repository: snapshots.jboss.org due to an error: Authorization failed:
Not authorized
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:
- common
- EJB
- WEB
- RAR
- EAR
- client
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.
SVN repository
--------------
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,
ejb/trunk, etc.
Maven
-----
groupId remains the same, i.e. org.jboss.metadata.
artifactId is metadata-project_name, e.g. metadata-common, metadata-ejb,
etc.
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
org.jboss.metadata.test.generator.
JAWS DTDs weren't copied neither (they shouldn't have been there from
the beginning).
17 years
metadata upgrade in AS trunk
by Alexey Loubyansky
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.
Thanks,
Alexey
PS: I'll also upgrade XB to the latest release.
17 years
ValidationXmlParser and JBossJSFConfigureListener logging levels
by Jaikiran Pai
Hello everyone,
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.
-Jaikiran
17 years
Returned mail: see transcript for details
by MAILER-DAEMON
The original message was received at Thu, 20 Aug 2009 11:03:52 +0800 from 101.233.231.212
----- The following addresses had permanent fatal errors -----
jboss-development(a)lists.jboss.org
17 years
m2eclipse build issues
by Scott Stark
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
org/jboss/bootstrap/spi/server/Server
class, even though the classpath contains the
org/jboss/bootstrap/jboss-bootstrap-spi/2.0.0-alpha-2/jboss-bootstrap-spi-2.0.0-alpha-2.jar
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
mojo: org.apache.maven.plugins:maven-enforcer-plugin:1.0-beta-1:enforce
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?
17 years
