AS trunk boot time back to poor?
by Jaikiran Pai
After today's "svn up" of my workspace, i see that the "default"
instance boot in around 48 to 50 seconds:
19:10:18,431 INFO [org.jboss.bootstrap.impl.base.server.AbstractServer]
JBossAS [6.0.0.SNAPSHOT (build: SVNTag=JBoss_6.0.0-SNAPSHOT
date=r99718)] Started in 48s:36ms
The only noticeable change that i have seen is related to admin-console
being included in AS trunk. So i removed the admin-console.war from the
deploy folder and the server boots in 23 to 25 seconds. Adding it back
to deploy folder takes the boot time to 48 to 50 seconds consistently. I
haven't yet looked at where the time is being spent for deploying this
single app. But clearly it increases the boot time by almost 25 seconds.
Anyone else seeing this drastic change in boot time?
regards,
-Jaikiran
15 years, 12 months
Javaee Spec Jars
by Paul Gier
Hi everyone,
There was some discussion about naming conventions and svn structure for the
javaee api spec projects this morning. There is also more info in jira [1].
Here is the plan at this point.
GroupId: org.jboss.spec.<sun groupId>
ArtifactId: <spec name>_<spec version>_spec
Version: Standard OSGI versions starting with 1.0.0
For example:
<dependency>
<groupId>org.jboss.spec.javax.servlet</groupId>
<artifactId>servlet-api_2.5_spec</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
The structure in svn will look similar to the structure that the geronimo
project uses for their spec jars [2]. Meaning that each spec version will have
a separate trunk and a separate release cycle.
In addition to deploying the spec jars (and pom) to the Maven repository, there
will also be an aggregate pom, but not an aggregate jar. The aggregate pom will
be a project with packaging "pom" and will list each included spec in the
dependencyManagement and dependencies sections. This will allow the app server
build to declare a single dependency on the combined javaee pom and it will
automatically get all the individual spec jars added to the dependency tree.
Going forward, we would like to have all spec jars in same area in svn, and each
will have it's own release lifecycle and projects that need the spec jars can
either depend on the individual jars or on the aggregator pom.
[1]https://jira.jboss.org/jira/browse/JBEE-15
[2]http://svn.apache.org/repos/asf/geronimo/specs/trunk/
16 years
Planning to revert
by Brian Stansberry
When I get back from eating in an hour or so, I'm going to revert 2
recent changes:
1) The resteasy stuff that's breaking the build due to missing
resteasy-jettison-provider 2.0-beta-1. Unless it's fixed by then. :)
2) The jboss-cl upgrade to 2.2.0.Alpha1. I'll discuss with Ales, Adrian
and Thomas how to deal w/ getting the ClassCircularityErrors we're
seeing fixed.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
16 years
WarAnnotationMetaDataDeployer and AOP failures
by Kabir Khan
Flavia and I are debugging the scoped AOP test failures in AS and have found something odd going on when deploying an ear with a war with classes. Basically WarAnnotationMetaDataDeployer loads all the classes in the war [1] before the AOPDeploymentAopMetaDataDeployer has the chance to add the bindings to the aspect manager [2]. This means that the classes in the war are loaded before the bindings are added, so they do not get woven. The deployers are in the same deployer stage POST_CLASSLOADER, what is the best way to change their orders around?
[1]
Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended (breakpoint at line 69 in SuperClassesFirstWeavingStrategy))
SuperClassesFirstWeavingStrategy.translate(AspectManager, String, ClassLoader, byte[]) line: 69
ScopedVFSClassLoaderDomain(AspectManager).translate(String, ClassLoader, byte[]) line: 1071
ScopedVFSClassLoaderDomain(AspectManager).transform(ClassLoader, String, Class, ProtectionDomain, byte[]) line: 1015
AOPTransformer.aspectTransform(String, ClassLoader, Class<?>, ProtectionDomain, byte[]) line: 87
AOPTransformer.transform(ClassLoader, String, Class<?>, ProtectionDomain, byte[]) line: 75
TransformerManager.transform(ClassLoader, String, Class, ProtectionDomain, byte[]) line: 169
InstrumentationImpl.transform(ClassLoader, String, Class, ProtectionDomain, byte[], boolean) line: 365
ClassLoader.defineClass1(String, byte[], int, int, ProtectionDomain, String) line: not available [native method]
BaseClassLoader(ClassLoader).defineClass(String, byte[], int, int, ProtectionDomain) line: 698
BaseClassLoader.access$200(BaseClassLoader, String, byte[], int, int, ProtectionDomain) line: 64
BaseClassLoader$2.run() line: 577
BaseClassLoader$2.run() line: 537
AccessController.doPrivileged(PrivilegedAction<T>, AccessControlContext) line: not available [native method]
BaseClassLoader.loadClassLocally(String, boolean) line: 535
BaseClassLoader.loadClassLocally(String) line: 512
FilteredDelegateLoader(BaseDelegateLoader).loadClass(String) line: 134
FilteredDelegateLoader.loadClass(String) line: 131
ClassLoadingTask$ThreadTask.run() line: 455
ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 267
ClassLoaderManager.process(Thread, ClassLoadingTask) line: 166
ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String, boolean) line: 265
ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String) line: 1124
BaseClassLoader.loadClassFromDomain(String, boolean) line: 805
BaseClassLoader.loadClass(String, boolean) line: 445
BaseClassLoader(ClassLoader).loadClass(String) line: 250
AnnotatedClassFilter.accepts(VirtualFile) line: 121
AnnotatedClassFilter.visit(VirtualFile) line: 102
WrappingVirtualFileHandlerVisitor.visit(VirtualFileHandler) line: 62
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 362
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor) line: 307
VFS.visit(VirtualFile, VirtualFileVisitor) line: 438
VirtualFile.visit(VirtualFileVisitor) line: 448
WarAnnotationMetaDataDeployer.getClasses(VFSDeploymentUnit, VirtualFile) line: 172
WarAnnotationMetaDataDeployer.processMetaData(VFSDeploymentUnit, List<VirtualFile>) line: 146
WarAnnotationMetaDataDeployer.deploy(VFSDeploymentUnit) line: 125
WarAnnotationMetaDataDeployer.deploy(DeploymentUnit) line: 78
DeployerWrapper.deploy(DeploymentUnit) line: 179
DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1378
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1431
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1319
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019
AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1073
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 887
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 602
DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 898
MainDeployerImpl.process() line: 677
MainDeployer.deploy(URL) line: 370
MainDeployer.redeploy(URL) line: 277
[2]
Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended (breakpoint at line 146 in AspectBinding))
AspectBinding.start() line: 146
GeneratedMethodAccessor192.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
ReflectionUtils.invoke(Method, Object, Object[]) line: 59
ReflectMethodInfoImpl.invoke(Object, Object[]) line: 151
BasicMethodJoinPoint.dispatch() line: 66
KernelControllerContextAction$JoinpointDispatchWrapper.execute() line: 257
KernelControllerContextAction$JoinpointDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47
KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 125
KernelControllerContextAction.dispatchJoinPoint(KernelControllerContext, Joinpoint) line: 72
StartStopLifecycleAction(LifecycleAction).installActionInternal(KernelControllerContext) line: 202
StartStopLifecycleAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54
StartStopLifecycleAction(InstallsAwareAction).installAction(ControllerContext) line: 42
StartStopLifecycleAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62
StartStopLifecycleAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71
KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51
AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378
ScopedKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890
ScopedKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019
ScopedKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251
ScopedKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175
ScopedKernelController(AbstractController).resolveContexts(boolean) line: 1073
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1104
AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 842
AbstractKernelController(AbstractController).install(ControllerContext) line: 589
AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.deploy(FakeComponentUnit, BeanMetaData) line: 363
AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.access$100(AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer, FakeComponentUnit, BeanMetaData) line: 329
AOPDeploymentAopMetaDataDeployer(AbstractAopMetaDataDeployer<T>).deployBeans(VFSDeploymentUnit, AopMetaDataDeployerOutput) line: 269
AOPDeploymentAopMetaDataDeployer(AbstractAopMetaDataDeployer<T>).deploy(VFSDeploymentUnit, T) line: 133
AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, AOPDeployment) line: 46
AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, Object) line: 36
AOPDeploymentAopMetaDataDeployer(AbstractSimpleVFSRealDeployer<T>).deploy(DeploymentUnit, T) line: 56
AOPDeploymentAopMetaDataDeployer(AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) line: 62
AOPDeploymentAopMetaDataDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 55
DeployerWrapper.deploy(DeploymentUnit) line: 179
DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1378
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1431
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1319
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019
AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1073
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 887
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 602
DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 898
MainDeployerImpl.process() line: 677
MainDeployer.deploy(URL) line: 370
MainDeployer.redeploy(URL) line: 277
16 years
Fwd: Instability in AS testsuite
by Ales Justin
Fwd-ing to ml, as it was meant for all, not just Brian. :-)
Sent from my iPod
Begin forwarded message:
> From: Ales Justin <ales.justin(a)gmail.com>
> Date: 29. januar 2010 0:07:16 GMT+0100
> To: Brian Stansberry <brian.stansberry(a)redhat.com>
> Subject: Re: Instability in AS testsuite
>
> Yes and no.
>
> The right fix is that this input is added as one of the multiple
> inputs - via addInput, not as *the* input - which is what this
> proprty setting does.
>
> You can use install element to invoke this addInput.
>
> Sent from my iPod
>
> On 29.1.2010, at 0:03, Brian Stansberry
> <brian.stansberry(a)redhat.com> wrote:
>
>> I've got what I think is the answer; am testing it now. We need to
>> add this to the xml for WebAnnotationMetaDataDeployer:
>>
>> <property name="allInputs">true</property>
>>
>> Otherwise the addition of <property
>> name=
>> "input"
>> >org.jboss.aop.asintegration.jboss5.AopMetaDataDeployerOutput</
>> property> causes this to return false in DeployersImpl.isRelevant():
>>
>> if (deployer.isAllInputs() == false)
>> {
>> // No attachment for the input type
>> Class<?> input = deployer.getInput();
>> if (input != null && unit.isAttachmentPresent(input) == false)
>> return false;
>> }
>>
>>
>>
>> On 01/28/2010 03:40 PM, Brian Stansberry wrote:
>>> Have a look at the AS trunk tomcat module's
>>> o.j.web.tomcat.service.TomcatInjectionContainer class. The
>>> TomcatInjectionContainer is instantiated as part of
>>> o.j.w.t.service.deployer.TomcatDeployment's performDeployInternal(),
>>> which itself is called as part of the start() phase of the mbean
>>> representing the web module (webapp deployment is still mbean-
>>> based).
>>>
>>> And, sorry to say, that about exhausts my knowledge on the
>>> subject. :(
>>>
>>> I'll be poking around at this for the rest of the day as well.
>>>
>>> On 01/28/2010 02:23 PM, Kabir Khan wrote:
>>>> Neither Flavia (I assume) nor I know anything about resource
>>>> injection, can somebody please explain a bit what is involved?
>>>> Does it
>>>> use AOP?
>>>>
>>>> On 28 Jan 2010, at 20:20, Ales Justin wrote:
>>>>
>>>>> Looks like @Resource injection doesn't kick in.
>>>>> (running org.jboss.test.jpa.test.WebLibsJPAUnitTestCase)
>>>>>
>>>>> @Resource
>>>>> private UserTransaction ut;
>>>>>
>>>>> protected void doGet(HttpServletRequest req, HttpServletResponse
>>>>> resp) throws ServletException, IOException
>>>>> {
>>>>> try
>>>>> {
>>>>> ut.begin(); //<----- ut == null
>>>>>
>>>>>
>>>>> 21:15:28,125 ERROR
>>>>> [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].
>>>>> [/jpa-test].[TestServlet]]
>>>>> Servlet.service() for servlet TestServlet threw exception:
>>>>> java.lang.NullPointerException
>>>>> at org.jboss.test.jpa.servlet.TestServlet.doGet(TestServlet.java:
>>>>> 59)
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>> (ApplicationFilterChain.java:336)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>> (ApplicationFilterChain.java:242)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke
>>>>> (StandardWrapperValve.java:276)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.StandardContextValve.invoke
>>>>> (StandardContextValve.java:191)
>>>>>
>>>>> at
>>>>> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke
>>>>> (SecurityAssociationValve.java:183)
>>>>>
>>>>> at
>>>>> org.jboss.web.tomcat.security.JaccContextValve.invoke
>>>>> (JaccContextValve.java:95)
>>>>>
>>>>>
>>>>> Flavia Rainone wrote:
>>>>>> Sure, I'll take a look.
>>>>>> On 01/28/2010 05:43 PM, Kabir Khan wrote:
>>>>>>> Copying Flavia,
>>>>>>>
>>>>>>> Flavia can you please take a look? I am tied up with another
>>>>>>> problem.
>>>>>>> If there is something affecting the web stuff, a wild guess
>>>>>>> would
>>>>>>> be the changing of the order of the deployers done here
>>>>>>> http://fisheye.jboss.org/changelog/JBossAS/?cs=100000
>>>>>>> However, without this fix AOP fails, since the
>>>>>>> WarAnnotationMetaDataDeployer loads all the classes as
>>>>>>> mentioned on
>>>>>>> dev list a day or two ago
>>>>>>>
>>>>>>> On 28 Jan 2010, at 19:29, Brian Stansberry wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Copying Ales and Scott Marlow, as an FYI. You all have been
>>>>>>>> chasing WebJPA failures, so thought you might be interested.
>>>>>>>> We've
>>>>>>>> already determined that the JBW upgrade did not cause the new
>>>>>>>> failures; it was something in the #1 or #2 changesets below.
>>>>>>>>
>>>>>>>> On 01/28/2010 12:22 PM, Brian Stansberry wrote:
>>>>>>>>
>>>>>>>>> Looks like we have some new failures in the AS testsuite:
>>>>>>>>>
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Changes between this run and the last run to completion are
>>>>>>>>> listed in
>>>>>>>>> the links below. Myself, Kabir, Carlo and Remy made changes;
>>>>>>>>> please have
>>>>>>>>> a look and fix ASAP. (Carlo I'm quite sure yours didn't break
>>>>>>>>> anything
>>>>>>>>> :) ).
>>>>>>>>>
>>>>>>>>> The changes:
>>>>>>>>>
>>>>>>>>> 1)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note that before the #528 testsuite run hung and was killed, a
>>>>>>>>> lot of
>>>>>>>>> the new failures had appeared there; you'd have to scroll
>>>>>>>>> through
>>>>>>>>> the
>>>>>>>>> #528 console log to see exactly which.
>>>>>>>>>
>>>>>>>>> 2)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 3)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 4)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This was the JBW update. I'll quickly check out trunk at this
>>>>>>>>> revision
>>>>>>>>> and run some of the newly failing tests to see if any of
>>>>>>>>> them go
>>>>>>>>> back
>>>>>>>>> this far.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Lead, AS Clustering
>>>>>>>> JBoss by Red Hat
>>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss by Red Hat
16 years
AS ClassLoading in Embedded Environments
by Andrew Lee Rubinger
Open call for comments/suggestions. I'm running low on ideas.
ClassLoading in AS has a few phases:
1) Launch (application classpath, run.jar, some minimal APIs only)
2) Bootstrap (A bunch of JARs in $JBOSS_HOME/lib, enough to start the
Kernel and deploy the bootstraps)
3) Service Deployments (jboss-cl takes over, adding in support from
$JBOSS_HOME/common as appropriate)
In an Embedded environment, the client is in the same JVM as the server.
The TCCL of the Main Thread needs to be able to:
* Establish a JNDI Context via "new InitialContext();"
* Deploy
For these, TCCL needs to have access to runtime internals provided via
jbossall-client.jar. If this is loaded by a parent CL of something it
references, we get NCDFE. For instance:
java.lang.NoClassDefFoundError:
org/jboss/deployers/vfs/spi/client/VFSDeploymentFactory
at
org.jboss.embedded.core.server.JBossASEmbeddedServerImpl.deploy(JBossASEmbeddedServerImpl.java:256)
Here the AS deployment mechanism is loaded in a ClassLoader higher in
the hierarchy than VFS Deployers SPI. I could move where we load VFS
Deployers SPI higher up, which would then leak out something else, and
on and on.
I currently cannot concoct an environment where:
* User has a minimal application ClassPath
* Other ClassLoading is transparent
* Everything works
Some attempt to use an isolated ClassLoader result in ClassCastException
when equal FQNs end up w/ separate defining ClassLoaders.
I believe I'm trying in vain to hack around the underlying problem where
the AS module system is not separated out to support this kind of use.
We have ClassLoading requirements not being met:
* JARs safe for client use at all CL levels (ie. no references to
outside dependencies which would also need to be loaded by the same CL)
* JARs for compilation only, and runtime will be provided by the
container (ie. Maven scope "provided")
* JARs used by AS internals *only*.
For now I think the only way forward is to either put:
1) Every single one of AS's dependencies on the application ClassPath
* http://community.jboss.org/docs/DOC-14441
2) Use a JBossHomeClassLoader which refers out to every AS runtime
dependency in $JBOSS_HOME/lib, $JBOSS_HOME/common/lib, and the server libs.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger
16 years
Startup issues with testsuite's jacc-securitymgr config
by Brian Stansberry
Ales, the last AS testsuite run failed to complete due to failure to
start the jacc-securitymgr config[1], which happens as part of the
tests-jacc-securitymgr ant target. There's not much in the hudson
artifact logs[2] so I've been trying it myself with boot logging to
configured to log everything at TRACE to boot.log.
./run.sh -c jacc-securitymgr -Djboss.boot.server.log.level=TRACE
-Djboss.boot.server.log.file.level=TRACE
With that I get a bunch of NPEs (more below). What's weird is I just did
a simple
./run.sh -c jacc-securitymgr
and it started cleanly. A little while ago it had failed to start with
the same uninformative logging seen at [2].
Anyway, an NPE is obviously no good. The NPE is in
AbstractControllerContext, line 1315
log.trace("Already installing " + name + " for " +
toState.getStateString());
Perhaps something that came in with 2.2.0.Alpha3? The stack trace:
12:16:54,570 WARN [ServiceController] Problem starting service
jboss.system:service=ServiceBindingManager: java.lang.NullPointerException
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1315)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1136)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1073)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:887)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602)
at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
at org.jboss.system.ServiceController.start(ServiceController.java:443)
at
org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at
org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:151)
at
org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at
org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
at
org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:304)
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
at
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1864)
at
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1829)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1028)
at
org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1251)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1175)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1073)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:842)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:589)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:180)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at
org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1660)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1378)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1399)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1319)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:378)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1890)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1019)
at
org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1251)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1175)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1073)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:887)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:898)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:677)
at
org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at
org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at
org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:378)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1890)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1019)
at
org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1251)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1175)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1073)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:842)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:589)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:259)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:100)
at
org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:860)
at
org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:441)
at java.lang.Thread.run(Thread.java:619)
[1]
https://hudson.jboss.org/hudson/job/JBoss-AS-6.0.x-testSuite-sun16/532/co...
[2]
https://hudson.jboss.org/hudson/job/JBoss-AS-6.0.x-testSuite-sun16/532/ar...
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
16 years
FreeNode IRC upgrade
by David M. Lloyd
Users of FreeNode IRC should be aware that on Saturday, they're going to be
migrating to a new ircd. They seem optimistic about it but I'm sure it
will mean at least several hours of outage, and possible issues for the
following week or two.
For more information, see this page:
http://blog.freenode.net/2010/01/migration-to-new-ircd/
- DML
16 years
