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, 3 months
AS Testsuite Regressions
by Brian Stansberry
For anyone who made any commits to AS trunk last week, particularly
those who do did external library upgrades, please have a look at the
latest testsuite result[1] comparing it to the previous semi-stable
run[2] to see whether your commit introduced any regressions.
Last week there were a number of major updates in AS trunk that all
happened within a couple days. Following that there were several days
where a few problems introduced dozens of failures. That "noise" has now
been cleaned up, so the latest testsuite result is much more useful for
spotting regressions.
Let's keep knocking the failure count down so any regressions that come
in with the next round of updates are obvious. I expect the next
significant round of updates mid next week, so we should shoot for a
minimal number of failures by early next week.
Thanks.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
[1]
http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSui...
[2]
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
Apologies to anyone without internal hudson access that this run is no
longer visible on the external hudson.
14 years, 3 months
Re: [jboss-dev] AS6 Documentation Update
by Stan Silvert
Brian Stansberry wrote:
> Can this be discussed on jboss-dev instead of privately? Community
> feedback could be useful.
Sure. I wanted to be careful at first, but I'll copy both lists from
now on.
>
> I like the basic structure. :)
>
> What are your thoughts re: versioning? Separate subspace per version?
It won't strictly be Spaces, since we'll be using Magnolia instead of
Clearspace. But whether or not we will have a similar concept of a
space for each version is an open question. DocBook versioning is
relatively simple because the source is held in SVN. For the static
pages, I'm not sure what will happen. I think it's probably a question
better left to the time when we get closer to completion of AS6.0.0.GA.
>
> On 01/18/2010 08:19 AM, Stan Silvert wrote:
>> I want to fill everyone in on where we are with this project. I was
>> able to have a nice talk with Mark Newton, who set me straight on
>> tooling. What I didn't realize was that ClearCase is not the right tool
>> for building the site used to find our documents. Right now, we have
>> this wiki-style page:
>> https://community.jboss.org/wiki/JBossApplicationServerOfficialDocumentat...
>>
>>
>> I've felt all along that we need something more comprehensive than just
>> a few links to a few documents. We need a site that organizes everything
>> a user needs to get things done with AS6. This not only includes
>> "Getting Started" and "Admin" guides, but also includes things such as
>> javadoc, sample code, and JEE spec info. For these static pages that
>> organize the content, Magnolia is the right tool.
>>
>> So, the three tools we will use are:
>> *DocBook for Content: * We've already discussed this. The content will
>> be done primarily in DocBook.
>> *Magnolia for Doc Site:* We will have an AS6 documentation site broken
>> up into several sections that roughly reflects the structure of the
>> development teams.
>> *ClearCase for Feedback: *ClearCase is really meant as a collaboration
>> and feedback tool. A nice feature Mark told me about is that you can
>> embed a bit of javascript onto any html page and allow a ClearCase
>> discussion about the page. So we can do this for the HTML version of all
>> our DocBook content and get feedback on each page.
>>
>> Almost everyone who writes code that goes into AS will need to write
>> some community documentation using DocBook. The strategy here is divide
>> and conquer. We will break up much of the existing docs into smaller
>> chunks and add new chunks as we go.
>>
>> Here is how I see the documentation being laid out on the web site. The
>> site outlined here is not set in stone, nor is it comprehensive:
>>
>> *Main Doco Page:* Mostly just contains links to the subsections below.
>>
>> *AS6 Core Sections* (Each has its own static HTML page created in
>> Magnolia)
>>
>> * AS6 Core Getting Started Page
>> * Tools Page (like Twiddle and JMX Console)
>> * Administration and Tuning Page
>> * Core Architecture Page
>> * Security Page
>>
>> *AS6 Component Sections* (each has its own static HTML page created in
>> Magnolia)
>>
>> * Messaging
>> * Clustering
>> * Remoting
>> * Transactions
>> * Web Services
>> * Web Container
>> * JSF
>> * EJB
>> * Weld
>> * etc.
>>
>> Each of the pages above contain links to DocBook pages, javadoc, specs,
>> etc. I'll be building out a skeleton site this week and I'll figure out
>> how we can get it published for all to see. When that is done we will
>> all have something to look at and then we can talk more specifically
>> about content.
>>
>> *But each developer can help with this starting now.* If you write code
>> that eventually makes it into AS6 then please start thinking about the
>> user documentation. Think about what a community user needs to know
>> about to use your code in AS6. Even start writing some doc if you
>> have time.
>>
>> More to follow.
>>
>> Stan
>>
>>
>
>
14 years, 3 months
Re: [jboss-dev] as trunk build failure
by Adrian Brock
It should be fixed already?
On Mon, 2010-01-18 at 14:32 -0500, Scott Marlow wrote:
> Adrian,
>
> I did a clean AS build (cleaned my local maven repo also) after updating
> and get the following build error.
>
> /work/as/trunk5/trunk/system-jmx/src/main/java/org/jboss/system/deployers/managed/ServiceMetaDataICF.java:[216,81] getAttributeMap(javax.management.MBeanServer,javax.management.ObjectName) has private access in org.jboss.system.ServiceConfigurator
>
> Scott
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 3 months
Re: [jboss-dev] [hibernate-dev] Solution for failing Isolated query cache tests in Hibernate trunk
by galder＠jboss.org
Thanks Brian for this valuable information. I've created:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4814
The JIRA can possibly affect both Infinispan and JBC. Once one's done, doing the other should be straightfwd.
----- Original Message -----
From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
To: jboss-development(a)lists.jboss.org
Sent: Thursday, January 14, 2010 9:34:32 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [jboss-dev] [hibernate-dev] Solution for failing Isolated query cache tests in Hibernate trunk
Looking again, the custom type is used in the test as a query param. The
test would be better if it also used some sort custom type as the
primary key.
On 01/14/2010 02:11 PM, Brian Stansberry wrote:
> Hmm, I think I may have dropped something in translation when I ported
> this test from the JBoss AS/EJB3 testsuite.
>
> These tests originate in AS tests that check whether the JBC 2nd level
> cache integration handles cases where the "key" Hibernate passes as a
> param to cache write operations uses custom types. That is:
>
> 1) The primary key for a cached entity is not a simple JDK type but a
> custom type.
> 2) The params for a cached query involve custom types.
>
> At least in the past, those keys were not serialized, they were the
> unserialized objects. And since they are keys the Region impl can't
> manipulate them in ways that may effect equals/hashcode, so it just
> stores them directly in the cache. Doing that can cause problems on
> remote nodes (remote node can't deserialize a replication message)
> unless the Region impl has taken steps to ensure JBC/Infinispan knows
> how to find the correct classloader to use.
>
> That's what the original tests were meant to be testing. Looking briefly
> at this one today though, it looks like my porting job messed up; the
> custom type here is just an ordinary field in the entity (not the
> primary key) and isn't used as a param in any cached queries.
>
> On 01/14/2010 01:23 PM, Steve Ebersole wrote:
>> Also, you seem to have a quite elaborate functional test that simply
>> checks whether SerializationHelper is able to handle deserialing a class
>> from an "isolated classloader" via the SerializableType. Couldn't we
>> just have a simple unit test that asserted exactly that?
>>
>>
>> On Wed, 2010-01-13 at 20:25 +0100, Galder Zamarreno wrote:
>>>
>>> On 01/13/2010 07:10 PM, Steve Ebersole wrote:
>>>>> For completion, getReturnedClass().getClassLoader() will always return
>>>>> null because SerializableType is initialised with java.io.Serializable
>>>>> as returned class, and it's classloader returns null (quite likely cos
>>>>> it's a system class?).
>>>> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getClassLoad...
>>>>
>>>> null generally indicates the loader is the "boot loader".
>>>>
>>>> The nullness itself is not an issue, the issue is the lack of
>>>> visibility.
>>>>
>>>>> So, getReturnedClass().getClassLoader() is not the answer here.
>>>> There is the only answer unfortunately. Really you'd want the Class of
>>>> the class implementing Serializable, but given how Hibernate's "type
>>>> system" works currently, that's not an option.
>>>
>>> If it's not an option, why don't u throw an error or exception?
>>>
>>>>
>>>>>
>>>>> Steve, from a chat earlier you indicated that you're not happy passing
>>>>> Thread.currentThread().getContextClassLoader() but I don't understand
>>>>> what issue do you have with this.
>>>> The main issue is that this relies on:
>>>> 1) when the call is made
>>>> 2) the classloader layout of the environment in which the call occurs.
>>>> OSGI comes to mind in which case there is actually no tccl afaik.
>>>>
>>>>> Finally, it might be worth understanding what, apart from query cache,
>>>>> is Hibernate's SerializationHelper used for. If it's only for caching,
>>>>> you could maybe delegate serialization work to the cache providers?
>>>> Thats really a simple matter of a usage search in your IDE.
>>>>
>>>>
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
14 years, 3 months
Component integration cutoff of AS 6.0.0 M2
by Brian Stansberry
Time flies when you're having fun. :)
Just a reminder that the cutoff for getting updated versions of external
libraries into the AS trunk component-matrix it January 31, less than 2
weeks away.
That's a Sunday, so unless you enjoy working weekends doing a release
and then running the full AS testsuite to ensure it creates no
regressions, it's wise to plan on integrating your component a few days
before that. :)
Please do not integrate your component on the 31st, run only the
smoke-tests target, and then count on hudson to check for other problems.
Thanks to everyone for all the good communication you've been giving me
regarding what your plans are for M2; it's been very helpful.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
14 years, 3 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, 3 months
Strange maven exclude problem
by Adrian Brock
I've been playing "whack-a-mole" trying to exclude the
references to org.jboss.microcontainer.
But, I've got one strange one I can seem to exclude.
I've tried excluding it on jbossws-framework and ejb3-common
(the latter is duplicated in the webservices project?)
I think it has something to do with it having a qualifier in
component-matrix but not in the webservices pom?
This is part of the output from "mvn dependency:tree"
in the testsuite.
[INFO] +-
org.jboss.jbossas:jboss-as-webservices:jar:6.0.0-SNAPSHOT:compile
[INFO] | +- org.jboss.ws:jbossws-common:jar:1.2.2.GA:compile
[INFO] | +- org.jboss.ws:jbossws-framework:jar:3.2.2.GA:compile
[INFO] | \- org.jboss.ejb3:jboss-ejb3-common:jar:1.0.1:compile
[INFO] | \-
org.jboss.microcontainer:jboss-kernel:jar:2.0.0.CR5:compile
[INFO] | \-
org.jboss.microcontainer:jboss-dependency:jar:2.0.0.CR5:compile
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 3 months
Re: [jboss-dev] [hibernate-dev] Solution for failing Isolated query cache tests in Hibernate trunk
by Galder Zamarreno
On 01/13/2010 05:31 PM, Galder Zamarreno wrote:
> Hi all,
>
> In Hibernate trunk, the following tests are failing:
>
> In JBC 2LC provider:
> MVCCIsolatedClassLoaderTest.testClassLoaderHandlingNamedQueryRegion
> MVCCIsolatedClassLoaderTest.testClassLoaderHandlingStandardQueryCache
>
> In Infinispan 2LC provider:
> IsolatedClassLoaderTest.testClassLoaderHandlingNamedQueryRegion
> IsolatedClassLoaderTest.testClassLoaderHandlingStandardQueryCache
>
> They're failing because AccountHolder is being loaded with the system
> classloader rather than the SelectedClassnameClassLoader.
>
> The reason for this is that as a result of
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-2990,
> SerializationHelper.CustomObjectInputStream now takes the classloader in
> the constructor. And during the test, SerializableType.fromBytes passes
> null as classloader to this constructor. The null comes from
> getReturnedClass().getClassLoader() below, which has been added as a
> result of 2990.
>
> private Object fromBytes(byte[] bytes) throws SerializationException {
> return SerializationHelper.deserialize( bytes,
> getReturnedClass().getClassLoader() );
> }
>
> Now, shouldn't we use Thread.currentThread().getContextClassLoader()
> instead of getReturnedClass().getClassLoader()? Previously, that's what
> would have happened. I dunno why getReturnedClass().getClassLoader() was
> added though.
>
> I've just tested using Thread.currentThread().getContextClassLoader()
> change and the tests pass now. Steve?
For completion, getReturnedClass().getClassLoader() will always return
null because SerializableType is initialised with java.io.Serializable
as returned class, and it's classloader returns null (quite likely cos
it's a system class?).
So, getReturnedClass().getClassLoader() is not the answer here.
Steve, from a chat earlier you indicated that you're not happy passing
Thread.currentThread().getContextClassLoader() but I don't understand
what issue do you have with this.
Also, I'm not an expect on
Thread.currentThread().getContextClassLoader().loadClass() vs
Class.forName(String,boolean,Thread.currentThread().getContextClassLoader())
to be able to say whether either would work fine in an AS environment.
The test pass when you use the latter.
Finally, it might be worth understanding what, apart from query cache,
is Hibernate's SerializationHelper used for. If it's only for caching,
you could maybe delegate serialization work to the cache providers?
>
> Cheers,
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
14 years, 3 months
