AS and the new Bootstrap Implementation
by Andrew Lee Rubinger
Over the past few weeks I've been rebuilding the bootstrap component as
a true project, with the following goals:
* Tested
* User-friendly API
* No reliance upon a full AS
* Base for AS Main, AS Embedded, Standalone Project Runtimes
SVN: http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/
JIRA: https://jira.jboss.org/jira/browse/JBBOOT
There are a few subprojects:
* spi : Plain Server SPI
* spi-mc : Adds MC-aware support to the Server (ie. getKernel())
* spi-as : Adds AS-specific constructs such as JBOSS_HOME,
jboss.server.home.url, etc.
* impl-base : Plain base implementation of server, configs, etc
* impl-mc : Base implementation for MC-based servers
* impl-as : The full AS bootstrap
Contrary to the older implementation (which I'm calling "legacy") are
the following:
* jboss-bootstrap now leaves ClassLoading (mostly) out of scope.
Clients should be ensuring that the server is loaded/started under an
appropriate ClassLoader. This may take the form of a test classpath set
up by Maven, Ant, or a specialized URLClassLoader to define exactly what
you'd like visible. This opens up using bootstrap to a much wider range
of deployment scenarios.
* The new implementation is not API-compatible. I drew a line in the
sand to create a new SPI which should be ultimately easier to
use/understand.
* jboss-bootstrap no longer supports the exit/halt operations. Whoever
starts the server is responsible for stopping it. To kill the VM should
not be a concern of the server, as the there may be other operations
running upon full shutdown (like tests, or a web container, or even
another server).
The patch to bring this into AS has been under development in:
http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x_BootstrapLegac...
...and I plan on bringing this into Branch_5_x once both 5.1.0 is cut
and I can verify no regression in the AS TestSuite.
*Issues*
The following are outstanding, possible points of discussion:
1) Non-daemon Threads after AS shutdown keeping VM active
https://jira.jboss.org/jira/browse/JBAS-6919
If launched from AS Main, server shutdown should allow the VM to exit.
The presence of non-daemon Threads hanging around after the shutdown
lifecycle has existed prevents this. Please take a look at the thread
dump I've attached to the JIRA and ensure your project is not
contributing to the remaining Threads. Subtasks referencing JBAS-6919
should be forthcoming.
2) Static set of JAR names for boot lib, shouldn't it be everything in
$JBOSS_HOME/lib?
https://jira.jboss.org/jira/browse/JBAS-6920
AS Main declares a set of JARs to be included on the boot ClassPath. Is
my understanding correct that *everything* within $JBOSS_HOME/lib is
eligible? If that's correct, I'll clear out /lib of everything that's
not needed and make the logic scan the dir and add everything in there.
3) JMXKernel shutdown calls Runtime.exit Hack
https://jira.jboss.org/jira/browse/JBAS-6916
Because I've taken Runtime.exit out of the concern of bootstrap, and
because of the non-Daemon Threads after shutdown, I needed to add this
hack to JMXKernel to tell the whole VM to go down.
4) I'm doing this backwards.
Typically I'd merge into trunk *before* Branch_5_x, but I want this in
the open and getting tested for as long as possible before the next few
AS releases. Ping me if this is a problem.
*Roadmap*
The bootstrap subprojects are currently at 0.1.2. Looking forward:
1.0.0-alpha-x : Once merged into AS Branch_5_x
1.0.0-beta-x : SPI freeze
1.0.0 : Formal release
*What Can it Do For You?*
The MCServer itself is especially handy for testing your subproject in
standalone fashion. The JCA Standalone Container, for instance, is to
be built atop the MCServer. The process is:
1) Create a new Server
2) Configure it, pointing it at your main bootstrap
3) Call start()
You might find that this eases in your project's unit testing and
enables you to cut dev time by cutting reliance upon the AS TestSuite.
@see
http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-mc/s...
*Where are the Docs?*
I need to make a few Wiki pages; I'll email the list with locations when
I do. Until then everything is JavaDoc'd and should be self-documenting
via the unit tests. Or ask me on Design of POJO Server Forum.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
15 years, 7 months
WARNING: Changes to app server distribution build
by Paul Gier
Hi Everyone,
I'm about to merge build.xml with build-dist.xml in the AS build in trunk. In
addition, I'm removing any usage of buildmagic and the thidparty libraries.ent
file. Instead, the maven ant tasks will resolve all the dependencies in the
thirdparty pom and make them available via properties.
So a dependency in the thirdparty/pom.xml that looks like this:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
</dependency>
Will be available as a property in the form "groupId:artifactId:type".
${javax.servlet:jstl:jar}
For future maintenance of the AS dist build, I'd like to take the approach of
having an ant target that pulls in files for each module of the project. For
example, a target called "module-hibernate-int" will pull in any files from the
"hibernate-int" module. This is basically the way the build works now. The
difference is that I've moved a lot of the copying of thirdparty jars to the
"thirdparty" target instead of in the individual modules like they were before.
Please let me know if you have any questions about this and/or suggestions about
improving the way the dist build or other parts of the build work.
Thanks!
15 years, 7 months
Something funny with hot deployment scanning
by David M. Lloyd
It seems that 5.x latest isn't picking up new files named
"*-jboss-beans.xml" or "*-beans.xml" in the deploy/ directory. Strangely I
can "touch" existing -jboss-beans.xml files and cause them to undeploy;
it's just *my* particular file is being ignored. If I start the server
with my file in the deploy dir (in other words, no HDScanner), it's found.
What's the deal?
- DML
15 years, 7 months
@JMX and @DisableAOP live happily together
by David M. Lloyd
So why should @DisableAOP be the annotation with enabling AOP being the
default?
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
<bean name="TestBean" class="javax.management.monitor.GaugeMonitor">
<annotation>@org.jboss.aop.microcontainer.annotations.DisableAOP()</annotation>
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(exposedInterface=javax.management.monitor.GaugeMonitorMBean,name="test:name=Banana",registerDirectly=false)</annotation>
</bean>
</deployment>
- DML
15 years, 7 months
Locks on eclipse files in svn
by Adrian Brock
Andrew,
You appear to have an old lock on some eclipse files in svn
can you remove it? I'm trying to update trunk to use the
mvn eclipse:eclipse generated files now that the project is
fully mavenised.
$ svn info https://svn.jboss.org/repos/jbossas/trunk/ejb3/.project
Path: .project
Name: .project
URL: https://svn.jboss.org/repos/jbossas/trunk/ejb3/.project
Repository Root: https://svn.jboss.org/repos/jbossas
Repository UUID: 84be2c1e-ba19-0410-b317-a758671a6fc1
Revision: 89010
Node Kind: file
Last Changed Author: ejort
Last Changed Rev: 29674
Last Changed Date: 2005-03-22 19:37:16 +0100 (Tue, 22 Mar 2005)
Lock Token: opaquelocktoken:cc9885ac-c73c-0410-839a-d44aa957f212
Lock Owner: ALRubinger
Lock Created: 2007-10-18 19:23:17 +0200 (Thu, 18 Oct 2007)
Lock Comment (1 line):
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 7 months
metadata 1.0.1.GA
by Alexey Loubyansky
I'd like to include metadata 1.0.1.GA into AS 5.1.0.GA. 1.0.1.GA
contains only one fix for https://jira.jboss.org/jira/browse/JBMETA-200
There are no structural changes in the schemas, types or elements
(except one duplicated element was removed but this schema has never
been used by anybody except the tests, so there won't affected users).
The fixes are useful for external tools, for JBoss there won't be a
difference.
Thanks,
Alexey
15 years, 7 months
Re: [jboss-dev] Fresh 1.0.0.Alpha1 - CLI for JBossAS
by Ales Justin
> The auto discovery of executables is first of the new features we
> would like to implement and of course tools to interact with jopr.
This should be trivial to add,
if we can get off the new instance per command invocation.
MC has this cool feature: incallback --> contextual matching.
See MainDeployer and StructureDeployers.
Perhaps we could add something like this:
interface ExectableFactory
{
Executable create();
}
And we can then keep the instance/invocation.
Plus have this EF interfaces automagically picked up by MC. ;-)
15 years, 7 months
Changing the default of unordered
by Jason T. Greene
Hi Alexey,
Since we didn't have time to correct all the schemas, and we are adding
the unordered property everywhere anyway, can you temporarily switch the
default of unordered to true, for the AS GA release?
The tools team is worried about people trying out the latest AS, and
having it fail on them.
15 years, 7 months
Can't build AS5 Administration_And_Configuration_Guide
by Scott Stark
Trying to build the Administration_And_Configuration_Guide fails with
the following CCE:
[509][valkyrie: Administration_And_Configuration_Guide]$ mvn package
...
[INFO] [jdocbook:resources]
[INFO] unpacking dependency resource
[/home/svn/repository.jboss.org/maven2/org/jboss/jbossorg-jdocbook-style/1.0.0/jbossorg-jdocbook-style-1.0.0.jdocbook-style]
to staging-dir
[/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/staging]
[INFO] Expanding:
/home/svn/repository.jboss.org/maven2/org/jboss/jbossorg-jdocbook-style/1.0.0/jbossorg-jdocbook-style-1.0.0.jdocbook-style
into
/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/staging
[INFO] [jdocbook:generate]
[INFO] applying DocBook profiling
[/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/work/profile/en-US/Administration_And_Configuration_Guide.xml]
May 15, 2009 9:49:29 AM org.apache.fop.hyphenation.Hyphenator
getHyphenationTree
SEVERE: Couldn't find hyphenation pattern en
May 15, 2009 9:49:30 AM org.apache.fop.fo.flow.ExternalGraphic bind
SEVERE: Image not available:
url(file:/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/staging/images/images/community/docbook/note.svg)
May 15, 2009 9:49:30 AM org.apache.fop.fo.flow.ExternalGraphic bind
SEVERE: Image not available:
url(file:/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/staging/images/images/community/docbook/note.svg)
May 15, 2009 9:49:30 AM org.apache.fop.fo.FONode attributeWarning
WARNING: Warning(-1/-1): fo:table, table-layout="auto" is currently not
supported by FOP
May 15, 2009 9:49:30 AM org.apache.fop.fo.PropertyList
convertAttributeToProperty
SEVERE: Ignoring property: column-width="proportional-column-width(1)"
(proportional-column-width() function may only be used when fo:table has
table-layout="fixed".; property:'column-width')
May 15, 2009 9:49:30 AM org.apache.fop.fo.FONode attributeWarning
WARNING: Warning(-1/-1): fo:table, table-layout="auto" is currently not
supported by FOP
May 15, 2009 9:49:30 AM org.apache.fop.fo.PropertyList
convertAttributeToProperty
SEVERE: Ignoring property: column-width="proportional-column-width(1)"
(proportional-column-width() function may only be used when fo:table has
table-layout="fixed".; property:'column-width')
May 15, 2009 9:49:30 AM org.apache.fop.fo.flow.ExternalGraphic bind
SEVERE: Image not available:
url(file:/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/staging/images/images/community/docbook/note.svg)
May 15, 2009 9:49:31 AM
org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm
updateData2
WARNING: Line 1 of a paragraph overflows the available area. (fo:block,
location: -1/-1)
May 15, 2009 9:49:31 AM org.apache.fop.fo.flow.ExternalGraphic bind
SEVERE: Image not available:
url(file:/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/staging/images/images/community/docbook/note.svg)
May 15, 2009 9:49:31 AM org.apache.fop.fo.flow.ExternalGraphic bind
SEVERE: Image not available:
url(file:/Users/svn/JBossHead/5/Administration_And_Configuration_Guide/target/docbook/staging/images/images/community/docbook/note.svg)
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] org.apache.fop.layoutmgr.inline.WrapperLayoutManager
[INFO]
------------------------------------------------------------------------
[INFO] Trace
java.lang.ClassCastException:
org.apache.fop.layoutmgr.inline.WrapperLayoutManager
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:76)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:272)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:554)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:264)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:263)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:157)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:385)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:148)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
at
com.icl.saxon.output.ContentHandlerProxy.endElement(ContentHandlerProxy.java:137)
at com.icl.saxon.output.ProxyEmitter.endElement(ProxyEmitter.java:91)
at
com.icl.saxon.output.NamespaceEmitter.endElement(NamespaceEmitter.java:150)
at
com.icl.saxon.output.GeneralOutputter.writeEndTag(GeneralOutputter.java:681)
at
com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:293)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:255)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at
com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:289)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at com.icl.saxon.Controller.defaultAction(Controller.java:271)
at com.icl.saxon.Controller.applyTemplates(Controller.java:236)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLIf.process(XSLIf.java:78)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at com.icl.saxon.Controller.run(Controller.java:178)
at com.icl.saxon.Controller.transformDocument(Controller.java:1086)
at com.icl.saxon.Controller.transform(Controller.java:953)
at
org.jboss.jdocbook.render.impl.BasicRenderer.performRendering(BasicRenderer.java:123)
at
org.jboss.jdocbook.render.impl.BasicRenderer.render(BasicRenderer.java:115)
at
org.jboss.maven.plugins.jdocbook.GenerationMojo.process(GenerationMojo.java:117)
at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.doExecute(AbstractDocBookMojo.java:260)
at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.execute(AbstractDocBookMojo.java:292)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 51 seconds
[INFO] Finished at: Fri May 15 09:49:31 PDT 2009
[INFO] Final Memory: 11M/59M
[INFO]
------------------------------------------------------------------------
[509][valkyrie: Administration_And_Configuration_Guide]$
15 years, 7 months
Re: [jboss-dev] Fresh 1.0.0.Alpha1 - CLI for JBossAS
by John Mazzitelli
All we have is the source itself right now:
http://svn.rhq-project.org/repos/rhq/trunk/modules/enterprise/client/
What I know about it is that it uses JBoss/Remoting to tunnel remote requests from CLI to Jopr Server which in turn invokes EJB SLSB business methods to do the things it needs to do.
----- Original Message -----
From: "Marko Štrukelj" <strukelj(a)parsek.net>
To: "Ales Justin" <ales.justin(a)gmail.com>, "John Mazzitelli" <mazz(a)redhat.com>, "JBoss.org development list" <jboss-development(a)lists.jboss.org>
Cc: "Tomaž Cerar" <cerar(a)parsek.com>
Sent: Friday, May 15, 2009 9:42:38 AM GMT -05:00 US/Canada Eastern
Subject: RE: [jboss-dev] Fresh 1.0.0.Alpha1 - CLI for JBossAS
I didn't spend any time with Jopr, but I don't see why Fresh couldn't be used ...
Any pointers where to look for how Jopr uses its current CLI ?
> -----Original Message-----
> From: Ales Justin [mailto:ales.justin@gmail.com]
> Sent: Friday, May 15, 2009 3:26 PM
> To: John Mazzitelli; JBoss.org development list
> Cc: Tomaž Cerar; Marko Štrukelj
> Subject: Re: [jboss-dev] Fresh 1.0.0.Alpha1 - CLI for JBossAS
>
> > Actually, this is the first I ever heard of that adminclient that ian
> > wrote :}
>
> Yeah, it surprised me as well.
>
> > Jopr has the start of its own CLI, but its not fully baked yet. I'm
> > wondering if we could use this Fresh utility instead :)
>
> Sure.
> But I guess this is more of a question for Tomaz and Marko.
> I'm just a messenger and their MC advisor. :-)
>
15 years, 7 months
