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
15 years, 9 months
jbossas -beans.xml opt
by Ales Justin
I'm looking for volunteers or the people responsible for the existing
-jboss-beans.xml files in jbossas. :-)
The reason is a new way to optimize boot time a bit.
We have two new annotations we can add to our beans.
(1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
This one takes two attributes:
(a) Class<? extends Annotation>[] value() default {};
(b) boolean ignore() default false
With (a) you can provide a set of annotation classes that might be used
on your bean/class to use MC's IoC.
e.g. @org.jboss.beans.metadata.api.annotations.Inject
Only matching plugins will be then used, instead of all.
With (b) you can simply say ignore any @annotation MC IoC lookup.
This is probably mostly true for all beans.
(2) @org.jboss.aop.microcontainer.annotations.DisableAOP
This one instructs MC to ignore transparent AOP usage when handling your
bean.
It will not look for aspect dependencies or try to create an AOP proxy.
It will simply fall back to plain POJO handling.
If you use @JMX or anything similar, this should then *not* be used.
But for anything else it should be good to use it.
How to use this?
(a) either annotate your service/bean classes
(b) simply use xml way of annotating your beans
e.g.
<annotation>@org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
<annotation>@org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
(c) if you know that none of your beans in <deployment> (-beans.xml
file) uses any of the needed features,
you can simply add xml way to the <deployment> element.
This way all beans inherit the annotation from deployment.
So, let's get busy "annotating" those jbossas beans. ;-)
ps: how should we proceed with this? :-)
15 years, 12 months
Project ByteMan
by Andrew Dinn
Hi Foax,
After several false starts and concomitant rethinks legal have finally
agreed that I can use the name ByteMan (aka JBoss ByteMan) for the tool
formerly known as TOAST. The name abbreviates 'Byte Manipulation' rather
than identifying some nerdy superhero -- although I am still toying with
the idea of presenting at Jazoon in mask, tights and cape. Mark Newton
is currently in the process of setting up a ByteMan project with
repository, forum etc. In the meantime I would like to claim the package
space org.jboss.byteman for all code products associated with the
project. I believe this does not clash with any existing code. If you
know otherwise please inform me ASAP.
regards,
Andrew Dinn
-----------
16 years
Developer javadoc is essential!
by Jason T. Greene
Hi Guys,
The javadoc/code comments in our core modules are VERY lacking, so it is
incredibly difficult for new folks to understand how anything is
supposed to work (I have been hearing some groaning about this recently).
All of our code, especially SPI or API classes must have javadoc which
explains in detail the following things:
1) How the module is supposed to be used (and how it is actually used if
known)
2) The intended behavior, and any aspect of it that is known to be
broken or a hack (so that someone can differentiate between a design
problem and just an unimplemented section that needs to be fixed)
3) Crticial preconditions (e.g. "this class expects that the same vfs
handle instance be reused during a redeploy")
4) Thread-access design (e.g. "this class is thread-safe and can be
accessed from multiple threads", "this class is not thread-safe, and all
callers must use a shared lock to access", "this class is intended to
have an instance-per-thread")
If we can't answer these simple questions, then it is likely our design
is flawed.
--
Jason T. Greene
JBoss, a division of Red Hat
16 years
Abstract classes?
by Jaikiran Pai
I have seen many classes in some JBoss core projects whose names start
with "Abstract" but the classes are *not* abstract. Just to cite an
example, there's AbstractInjectionValueMetaData - not picking on this
specific class, but this is just an example. Any reason why we are
naming them Abstract?
regards,
-Jaikiran
16 years
Logging Opinions?
by Andrew Lee Rubinger
https://jira.jboss.org/jira/browse/JBBOOT-61
In some effort to address frequent user feedback that our logging is
difficult to weed through, I'm considering changing the server info dump
to something like:
12:02:08,263 INFO [JBossASServerImpl] Server Configuration:
Bootstrap URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
JBOSS_HOME URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
Common Base URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
Common Library URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
Server Name: default
Server Base URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
Server Library URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
Server Config URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
Server Home URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
Server Data URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
Server Log URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
Server Temp URL:
file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
Do we like the additional whitespace to separate this stuff out from the
rest? We've done a similar thing in EJB3 where we print out the target
JNDI names.
Ultimately we should probably look at each INFO statement on AS boot and
decide if it should really be there or not.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
16 years
Change location of bindings.xml
by Heiko W.Rupp
Hi,
(see also http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155987
)
Within one install of a JBossAS should be only one instance of the
service bindings.xml file which serves all
configurations a user creates. Usually users, when using the SBM just
duplicate 'default' and rename it (e.g. to
ports-01). Now with the current setup the user changes a setting in
default/conf/bootstrap/bindings.xml, but this
does not get reflected into ports-01/conf/bootstrap/bindings.xml.
So bindings.xml should by default go into a location common to all
configurations. In AS4 this was the default,
as users normally did not move the service-bindings.xml from docs/
examples/ into a different location, but just
commented in the SBM-Mbean in conf/jboss-service.xml to use it.
This "singleton" bindings.xml is I think also important for Jopr /
admin console to have a consistent view on the
bindings.
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
Charles Cachera
16 years, 1 month
JBossAS 5.1.0.GA released
by Rajesh Rajasekaran
JBoss AS 5.1.0.GA is released and is available for download.
http://www.jboss.org/jbossas/downloads/
Along with many bug fixes and enhancements, this is the first general
release to include our new, significantly improved open-source console.
Highlights
* New Web Console - This release includes our new administration
console. Several updates have been made since the CR1 release, including
the introduction of WAR metrics.
* Web Beans Update - In addition, this release includes an updated tech
preview of the new JSR-299 Web Beans RI.
* Farming Returns - Due to popular demand, the farming service is back!
For detailed release notes, visit here:
http://www.jboss.org/jbossas/docs/Release_Notes/510GA/readme.html
Happy Memorial Day to all folks in the US!
Thanks
Rajesh
16 years, 1 month
JBoss Bootstrap, Embedded & Reloaded
by Carlo de Wolf
Where to begin?
This question is actually the one we are going to debate. Where does
Application Server begin and where does it end?
But there is more to it: I want to be able to unit test EJB3 before
bringing it to AS. (I think it should become a requirement of any
component to be able to run/test standalone before coming to AS/EAP, but
that's another discussion.)
Let's start with the simple one: JBoss Bootstrap:
As of AS 5.1 the application server no longer performs the bootstrapping
of profile service. Instead AS defines a bootstrap descriptor and
delegates bootstrapping it to JBoss Bootstrap.
Effectively this allows anybody to create an arbitrary bootstrap, for
example:
<?xml version="1.0" encoding="UTF-8"?>
<bootstrap xmlns="urn:jboss:bootstrap:1.0">
<url>bootstrap/naming.xml</url>
<url>bootstrap/jmx-jdk.xml</url>
<url>bootstrap/jbossts.xml</url>
</bootstrap>
Voilà instant JTA compliant transaction server.
The best part is, that it's using the same components as the real AS, so
it should be close to 100% compatible.
Now the most complex one in terms of definition: JBoss Embedded.
It's *not* Embedded JBoss ( http://www.jboss.org/community/docs/DOC-9690
), which was a preview of AS 5 capabilities (previously known as EJB 3.0
Embeddable).
It is *not* EJB 3 Embedded, which is a preview of EJB 3.1 Embeddable
specification.
The scope of JBoss Embedded is currently defined as:
* Software component which, in tandem with an arbitrary AS
distribution, launches JBossAS in preexisting JVM.
* Conforms to all existing AS TestSuites and TCK (fully-compatible) when
in a JavaSE environment. Whether AS is launched from run.sh or Embedded
should be transparent to applications.
Which leaves the following bits out of scope:
* Bundling alongside JBossAS (in the AS release cycle)
* Virtual JAR deployment. This may later be handled by user extensions
into VFS, such that user code may assemble an EAR or JAR view
programatically, and pass that along to the AS deployment mechanism.
* Compatibility from launch inside arbitrary runtimes like Tomcat,
WebSphere.
What I've really left out so far is the goal we're trying to achieve:
unit testing. I would say both unit testing of user applications & unit
testing of services.
So there I was sitting behind my screen setting up a new component:
ejb3-jndibinder. Recreating another bootstrap...
Hmm, that's not how I want to do it with every component.
In comes JBoss Reloaded, because I actually want to have a single
component dependency which gives me the proper environment to run my
unit test in. So I only should need: jpa-profile (whichs depends on
jta-profile, which depends on naming-profile (I'll leave jca-profile out
of scope for a moment)).
For this to work Reloaded defines a vdf-bootstrap /
profile-service-bootstrap and it should also provide a facility to plug
profiles.
http://www.jboss.org/community/docs/DOC-13453
To plug stuff into the bootstrap descriptor itself it uses
repoclassloader ( https://jira.jboss.org/jira/browse/RELOADED-2 ).
And to make it more extensible allow for compound classloaders (
https://jira.jboss.org/jira/browse/RELOADED-4 ).
Now the bits where it gets real fun: JBoss Embedded & JBoss Reloaded can
both boot AS 5.0.1, AS 5.1 and AS 6. :-)
JBoss Embedded does this by virtue of the fact that all these three AS
versions adhere to the same Bootstrap contract, so it can point
Bootstrap to the proper descriptors.
JBoss Reloaded does this by virtue of defining a proper bootstrap and
booting up the right Profile Service (from the repository) and pointing
that Profile Service to the AS (
https://jira.jboss.org/jira/browse/RELOADED-3 as a showcase ).
Which brings us to the question of where should Application Server
begin? Where does it get it's Main from?
The bootstrap descriptors themselves are going to be moved to
jboss-reloaded-vdf-bootstrap. Note that this still requires components
to be broken out of AS.
By answering these question we can lock down the scope of Embedded &
Reloaded.
Carlo
16 years, 1 month
