VFS3 (in AS trunk) - Non .jar file handling
by Jaikiran Pai
I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
rename existing jar files to end with .bak name and replace them with
the new patched jar file. So for example, if i had a fix in
jboss-ejb3-core.jar, i would:
1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
3) Restart the server
The server would then pickup the new patched jar file and ignore the
.bak file. After testing the fix, i would then revert back to the
original jar file by renaming it back to its original name.
However, with the recent upgrade to VFS3 in AS trunk, i notice that even
the .bak is used for classloading (following is the output from
-verbose:class JVM argument):
[Loaded org.jboss.ejb3.EJBContainer from
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
Looks like VFS3 picks up this non .jar suffix file for classloading. Is
this expected? Shouldn't it be looking for only .jar files (atleast in
this context)?
regards,
-Jaikiran
14 years, 5 months
Small boottime improvement
by Kabir Khan
I have been doing some work on profiling and optimizing the jboss-dependency project [1] for kernel 2.2.0.Alpha6 and it seems to have had a small, but still measurable impact :-)
I did a few startups of AS with jboss kernel 2.2.0.Alpha5 and with a local snapshot. This snapshot contains the work done for Alpha6 with the addition of removing the break in the resolveContexts loop as mentioned in the forum thread.
The startups were done on a freshly rebooted machine with nothing else running. The startup orders are given in brackets, so I started Alpha5 twice, then SNAPSHOT twice and so on.
2.2.0-Alpha5
----------------------
37s:247ms (1)
20s:573ms (2)
20s:275ms (5)
20s:127ms (7)
20s:433ms (9)
20s:329ms (10)
20s:890ms (13)
2.2.0-SNAPSHOT
------------------------
29s:563ms (3)
19s:965ms (4)
19s:821ms (6)
20s:332ms (8)
19s:618ms (10)
19s:905ms (12)
19s:900ms (14)
One strange thing is that the first time I started each server they took loads longer than the other times, does somebody know the reason for that?
Ignoring those initial times leaves me with average start times of:
Alpha5: 20s437ms
SNAPSHOT: 19s923ms
I'm going to have a final look at jboss-dependency to see if there are any other obvious and easy fixes before moving on to have a look at jboss-kernel.
[1] http://community.jboss.org/message/525047#525047
14 years, 11 months
Trunk Unfrozen
by Jason T. Greene
I have tagged M3, so the trunk is open for changes.
--
Jason T. Greene
JBoss, a division of Red Hat
15 years
xml validation of jboss deployments
by Alexey Loubyansky
I've revisited
https://jira.jboss.org/jira/browse/JBAS-6744
"remove xb.builder.useUnorderedSequence=true from AS run scripts"
A couple of bound classes that need to be fixed:
- org.jboss.remoting3.metadata.LocalClientMetaData
https://jira.jboss.org/jira/browse/JBAS-7967
- org.jboss.xnio.metadata.ChannelListenerMetaData
https://jira.jboss.org/jira/browse/JBAS-7968
There are a number of XML files that will fail to parse because they are
not consistent with their schema (the list is below). Perhaps we should
add tests in the testsuite similar to XmlValidationUnitTestCase which
validates testsuite deployment descriptors.
But they are easy to fix (most common error is incallback elements
appear after property elements). If there are no objects I can fix these.
deployers.xml
profile.xml
ejb3.deployer/META-INF/ejb3-as-deployers-jboss-beans.xml@45,31
jboss-jca.deployer/META-INF/jca-deployers-jboss-beans.xml@90,35
jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml@167,37
ear-deployer-jboss-beans.xml@48,36
ejb-deployer-jboss-beans.xml@48,55
ejb3-deployers-jboss-beans.xml@14,41
jbossweb.sar/META-INF/jboss-beans.xml@21,39
ejb3-container-jboss-beans.xml@11,111
hornetq/hornetq-jboss-beans.xml@19,30
profileservice-jboss-beans.xml@45,46
15 years, 1 month
javassist 3.12.0.GA released to new JBoss maven repository
by Andrew Dinn
The 3.12.0.GA release of javassist which was tagged last Friday has
finally been deployed to the new jboss maven repository. Release notes
are included below.
regards,
Andrew Dinn
-----------
Release Notes - Javassist - Version 3.12.0.GA
** Bug
* [JASSIST-42] - Proxy serialization loses inner data objects
* [JASSIST-85] - IllegalAccessError when trying to call clone() on
a class generated by ProxyFactory
* [JASSIST-89] - The implementation of isInheritable() in
CtNewClass is wrong.
* [JASSIST-94] - Typos in ParameterAnnotationsAttribute javadoc
* [JASSIST-97] - Javassist doesn't serialize the handler along with
the proxy
* [JASSIST-98] - javassist appears to be iinstalling invalid local
variable tables
* [JASSIST-99] - Javassist causes java.lang.ClassFormatError:
Invalid length 561 in LocalVariableTable in class file
* [JASSIST-102] - Bug report for CtNewMethod.copy
* [JASSIST-104] - Proxy cache fails to guard against circular
references which inhibits GC of classloaders
* [JASSIST-110] - CtClassType.isModified does not check for edited
attributes in the ClassFile
* [JASSIST-111] - AnnotationMemberValue fails if a member is an array
* [JASSIST-113] - Possible regression in ProxyFactory.createClass()
when super interface is non-public
** Feature Request
* [JASSIST-95] - StackMap attribute of J2ME CLDC1.1
* [JASSIST-105] - Add ClassFile.JAVA_7
* [JASSIST-107] - Update pom and build script to support release of
snapshot builds
15 years, 1 month
Weird thought of the day: maven-based booting
by Bill Burke
instead of the way our JBoss AS distribution is structure now, why not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through <dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
15 years, 1 month
