M2 planning and timeline
by Jason T. Greene
Hi Guys,
Now that M1 is out lets talk about M2 and what can make the release. The
tentative release plan we have talked about is a integration freeze on
Feb 1, with an eventual freeze in late Feb. However, before we get more
absolute dates we really need to nail down on what we aim to deliver in
that time frame.
From an EE perspective it seems the following are close enough that
they could make such a schedule:
Full Servlet 3
Full JPA 2
Some EJB 3.1 capabilities (but which ones?)
Other updates that have been proposed:
- Inclusion of Remoting 3 (but full service porting to occur later)
- Inclusion of HornetQ (need to understand more about the effort to migrate)
If your project is on the above list, let me know what your schedule is
like, and if it can fit the above timeline.
If your project update is not on the list, but would like to have it
included, and the above timeframe is workable, let me know.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
14 years, 11 months
Further profling: Where should I focus?
by Bill Burke
IIRC, from the JBoss AS meeting you already knew this but...
I was doing further times on no things in deploy/ and just deploying
what deployers don't have dependencies in deploy/.
12.5 secs with the deployer sorting optimization
10.6 secs if you remove AOPDependencyBuilder
8.8 secs if you remove AOPJoinputFactory
I did a profile after removing the AOP stuff and found that:
~35-40% is in creating classloaders with the majority of that time being
spent in discovering package names
~5-10% is in classloader.getResource()
But, talking to people, I'm pretty sure you already know this. The
question is, where can I help? I know work on VFS3 is going on. Should
I help there? I could also volunteer to work on removing AOP
dependencies that currently exist for some components.
After fixing those 2 problems, my bet is further reductions will be
found in optimizing resolveContexts().
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
14 years, 11 months
Different Boottimes from pruning
by Bill Burke
Ok, I did some performance analisys without a profiler or knowledge of
the codebase.
default/ profile: 33s
Next I removed everything in deploy. I also had to remove
jbossweb.deployer, weld.deployer to get things to run:
2nd profile: 18.65 seconds
Now, an interesting thing. I removed jbossws.deployer.
No jbossws.deployer: 12.22 seconds.
So, wow! jbossws.deployer is taking 6 seconds to deploy!
But why? I took a wild guess and maybe it was classloading, jar
indexing, or scanning because jbossws.deployer is around 3megs and
dwarfs other .deployers in deployers/ directory. So, I combined the
seam jar with jacorb. No significant startup time. This leads me to
believe this isn't a VFS problem.
So, maybe its jbossws? Well, I look at the beans created, and they
really aren't doing anything significant. BUT there is a SHIT LOAD of
beans being deployed.
This leads me to believe this is something fundamental with MC.
BUT...
You probably already know this.
Cheers.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
15 years
Remove unused components from trunk
by Dimitris Andreadis
Together with the code review in JBAS-7500 regarding the 6.0.0.M1/trunk differences, I think
it's a good time to remove any dead code, components rarely used, and other things that we
want to remove from AS 6 going forward.
https://jira.jboss.org/jira/browse/JBAS-7508
Things that come to my mind:
- web-console
- aop aspects???
- misc varia stuff
- jmx remoting impl (there is now the jdk one)
- ... add your own
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://dandreadis.blogspot.com/
15 years
M2 Release/AS Lead Announcement
by Jason T. Greene
Hi Everyone,
I will be going away on paternity leave sometime soon. While, I am gone
Brian Stansberry will be in charge of leading the AS project. This
starts with the M2 release, which he is officially in charge of
effective immediately. Please help him to ensure that M2 is a success.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
15 years
Re: [jboss-dev] App Server Startup Time and Memory Footprint Comparisons
by Ales Justin
https://jira.jboss.org/jira/browse/JBDEPLOY-229
Bill Burke wrote:
> A simple *initial* solution could be to add a
> addDeployers(List<Deployer>) method and only do the sort once.
>
> WebServices adds like 29 deployers. I'm not saying this is bad, just
> that there's no reason the sort can't be done for those 29 deployers
> once and only once.
>
> Maybe even create a bean: DeploymentList and each subsystem (EJB,
> WebServicdes, etc.) could use that to deploy all their deployers.
>
> Then, after this simple thing is done, you can talk the harder problem
> of sorting.
>
> Ales Justin wrote:
>> This is the code that sorts it.
>> *
>> http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep...
>>
>>
>> Any suggestion how to fix it is welcome.
>>
>> Andrew Lee Rubinger wrote:
>>> I have a test which confirms it.
>>>
>>> @Test
>>> public void testAddLotsOfDeployers() throws Throwable
>>> {
>>> // Get the MainDeployer
>>> MainDeployer mainDeployer = (MainDeployer)
>>> getKernel().getController().getInstalledContext(NAME_MC_MAIN_DEPLOYER)
>>> .getTarget();
>>> TestCase.assertNotNull(MainDeployer.class.getName() + "
>>> instance was not installed into MC", mainDeployer);
>>>
>>> // Add Deployers
>>> for (int i = 0; i < 100; i++)
>>> {
>>> // Install a deployer
>>> final Deployer deployer = new AbstractDeployer()
>>> {
>>>
>>> @Override
>>> public void deploy(final DeploymentUnit unit) throws
>>> DeploymentException
>>> {
>>> //NOOP
>>> }
>>> };
>>> final String deployerName =
>>> deployer.getClass().getSimpleName() + i;
>>> final BeanMetaDataBuilder bmdb = BeanMetaDataBuilder
>>> .createBuilder(deployerName,
>>> deployer.getClass().getName());
>>> getKernel().getController().install(bmdb.getBeanMetaData(),
>>> deployer);
>>> }
>>> }
>>>
>>> That takes 163s on my machine.
>>>
>>> S,
>>> ALR
>>>
>>> On 12/17/2009 10:03 AM, Dimitris Andreadis wrote:
>>>> 2 seconds doing Deployer sorting??? either a bug or a bad measurement.
>>>>
>>>> Bill Burke wrote:
>>>>> I just did some profiling. 30% of boottime if you remove deploy/
>>>>> directory (30% is 6-7 seconds out of 18) is because of Deployer
>>>>> sorting. WebServices adds a TON of deployers, and a sort is happening
>>>>> after each add of each deployer.
>>>>>
>>>>> Ales Justin wrote:
>>>>>>> Ales told me he had a tool which draws out the dependencies of all
>>>>>>> beans in the AS. This needs some work, but I think it could be used
>>>>>>> in helping to (a) identify which beans need dependency annotations
>>>>>>> and (b) check whether all dependencies are correct (e.g. no
>>>>>>> cycles)...
>>>>>>
>>>>>> http://in.relation.to/Bloggers/MicrocontainerToolsGrapher
>>>>>>
>>>>>> MC 2.2.x will include some of the problems we've encountered and
>>>>>> tackled:
>>>>>> * ControllerState::equals
>>>>>> * MDR's ScopeKey sorting
>>>>>> * beans per class indexing
>>>>>> * annotation plugin matching
>>>>>> * ...
>>>>>>
>>>>>> After I include new MC 2.2.x in AS, I'll spend the time identifying
>>>>>> the potential lazy & on_demans beans + other tweaks.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
15 years
MC+VDF Bootstrap
by Andrew Lee Rubinger
@see https://jira.jboss.org/jira/browse/RELOADED-10
In the last design call I noted one approach to building slimmer
runtimes was to take Carlo's notion of Reloaded, but instead of taking
from the AS configs get things as trim as possible and only bring up
what's needed for VDF/MainDeployer. Ales was kind enough to point me to
some precanned stuff already used in the jboss-deployers testsuite, so I
stole a bunch of that and coupled it with jboss-bootstrap-impl-mc.
The basic test is able to install a new Deployer to the chain and ensure
it's used when a new Deployment is deployed via MainDeployer. Takes
about 1.9 seconds on my machine from JVM start to shutdown.
http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/vdf-bootst...
I think the next steps are as we've already discussed:
1) Make this into an extensible component which can be
reused/extended/composed
2) Bring up ProfileService in another extension
Thoughts?
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger
15 years
Validating XML documents
by Emmanuel Bernard
Sorry for the stupid question but how do we validate XML InputStream that are following an XSD?
I've got something like
DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance();
docBuilderFactory.setValidating( true ); //apparently useless cause it's for DTDs only
docBuilderFactory.setNamespaceAware( true );
//this one seems to do nothing either
docBuilderFactory.setSchema(
SchemaFactory.newInstance( javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI )
.newSchema( new StreamSource( getStreamFromClasspath( "persistence_1_0.xsd" ) ) ) );
InputSource source = new InputSource( is );
DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
docBuilder.setEntityResolver( resolver );
docBuilder.setErrorHandler( new ErrorLogger( "XML InputStream", errors, resolver ) );
Document doc = docBuilder.parse( source );
if ( errors.size() != 0 ) {
throw new PersistenceException( "invalid persistence.xml", (Throwable) errors.get( 0 ) );
}
But even with illegal elements in the XML (well-formed though), I get no error :(
15 years
