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, 9 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, 9 months
Maven Multi-Module Test Gotcha
by Jason T. Greene
A few days ago I committed a test to a module in the jboss-deployers
project that broke subclassed test cases in other sibling modules.
However, when I ran the full jboss-deployers test suite, everything
passed. Paul looked into it, and it turns out there is a maven bug [1]
that causes modules to use the local repository (and alternatively the
remote repo) over the test class path for dependencies on sibling
modules. So unless you install everything first you will likely end up
with the wrong classpath, and thus invalid results. Unfortunately the
bug is only fixed in 3.x.
So, as a workaround, make sure you always do "mvn install; mvn test" on
root projects when you have modules that share test classes.
[1] http://jira.codehaus.org/browse/MNG-3043
--
Jason T. Greene
JBoss, a division of Red Hat
16 years, 9 months
Re: [jboss-dev] FindBugs Reports
by Shelly McGowan
David,
Yes, they have their own:
http://findbugs.sourceforge.net/api/edu/umd/cs/findbugs/annotations/Suppr....
For enhancements on the report, you can add to this JIRA:
https://jira.jboss.org/jira/browse/JBAS-7295
Shelly
----- Original Message -----
From: "David M. Lloyd" <david.lloyd(a)redhat.com>
To: "JBoss.org development list" <jboss-development(a)lists.jboss.org>
Cc: "Shelly McGowan" <smcgowan(a)redhat.com>
Sent: Tuesday, September 29, 2009 11:29:48 AM GMT -05:00 US/Canada Eastern
Subject: Re: [jboss-dev] FindBugs Reports
Does FindBugs support using @SuppressWarnings() or similar? This is what I
do with IDEA and it works well. I use @SuppressWarnings (on classes,
members, or local var declarations) or "//noinspection" for other cases,
and then add a comment beforehand explaining why the problem isn't really a
problem.
- DML
On 09/29/2009 08:38 AM, Jesper Pedersen wrote:
> Hi.
>
> Please, add a FindBugs filter file to the configuration where we can add
> exclusions - f.ex. org.jfree (unless someone wants to submit patches
> upstream).
>
> Feel free to rip the JBJCA setup :)
>
> Best regards,
> Jesper
>
> On Monday 28 September 2009 22:33:22 Shelly McGowan wrote:
>> I've published the FindBugs report set up by the JBoss QA team run against
>> JBoss AS. The reports can be viewed here:
>>
>> http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbugs/
>> 8/findbugsResult
>>
>> This report shows a total of 5675 warnings, 877 of which are categorized as
>> High Priority.
>>
>>
>> The report for Branch_5_x can be viewed here:
>>
>> http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/2/
>> findbugsResult/
>>
>> The Branch_5_x report has 6089 warnings, 977 High Priority.
>>
>>
>> These issues should be addressed when committing to trunk or Branch_5_x.
>> Take time out to look at the report data. Most of the warnings can be
>> easily addressed.
>>
>> I've started a parent JIRA task for tracking:
>>
>> https://jira.jboss.org/jira/browse/JBAS-7295
>>
>> and will create subtasks as needed after additional review of the report
>> data.
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
16 years, 9 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, 10 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, 10 months
Client Compilation Assembly for AS
by Andrew Lee Rubinger
We currently have jbossall-client.jar, which is all of the runtime
libraries required to invoke upon a JBoss instance remote to the current
JVM.
With Embedded AS entering the mix I'm finding the need for a new
assembly containing only the compilation resources required of a client:
* Everything in org.jboss.javaee (Servlet, EJB3, JMS, etc JavaEE
annotations/stuff)
* All of our proprietary extensions (for instance ejb3-ext-api)
jbossall-client.jar is overkill for this case; it'd leak out too many
internals. Consider the following:
* Unit Test
* Should require minimal dependencies
* Launched with the required deps upon the classpath
* Classes in classpath JARs loaded by application ClassLoader
* Embedded launcher comes along, pointing to JBOSS_HOME, makes a
URLClassLoader to bring in all of the AS runtime deps
* Something loaded by Application ClassLoader references something not
in jbossall-client.jar (leak), but visible to the URLCL.
* NoClassDefFoundError, because we've just tried to do parent>child
delegation.
In short I'd like to have one dependency that we can give our users:
"Bring in this one JAR and that's everything you need to compile an
integration test for an application using JBossAS". (In actuality it
may be 2 JARs, one for the deps and one for the Embedded launcher, but
you get the point).
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
16 years, 10 months
YourKit Profiler licenses
by Thomas Diesler
Hi Folks,
do we have spare YourKit Profiler (http://www.yourkit.com) licenses
available? If not I would like to go ahead and by one.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 10 months
