Delver output for Seam 2.1.1.CR1
by Jozef Hartinger
This is a library diff between Seam 2.1.0.GA and Seam 2.1.1.CR1. Please
review.
Added:
/lib/htmlparser.jar
/lib/openid4java.jar - version 0.9.4.339,,
/lib/openxri-client.jar
/lib/openxri-syntax.jar
/lib/stax-api.jar
Removed:
/lib/jsr173_api.jar
15 years, 5 months
Code freeze for 2.1.1.CR1
by Pete Muir
All,
2.1.1.CR1 is now done, so please consider trunk frozen until Norman
gives the word that he is happy for you to commit again.
Jay, Jozef, the tag isn't done (Norman, please do that), but you can
probably start testing on trunk...
Pete
15 years, 5 months
On leave this week
by Shane Bryzak
Guys,
I'm on leave this week, although I won't be going far and I'll be
checking my e-mail every night. As soon as the remaining issues are
cleared (either fixed or slipped to CR2) can we please get SVN tagged
for release.
Thanks!
15 years, 5 months
OC4J 10 reference guide update?
by Jay Balunas
Hi Guys,
Oracle has dropped OC4J 11g (tech preview) which is what our OC4J
reference guide chapter is written with. Even though OC4J is not a
priority container we should at least update the chapter using OC4J
10.X so that we are aware the issues, and can give guidance to the
community. We had several open issues related to this that have been
closed because the container is effectively in its end of life phase.
I'm looking for some opinions on whether or not this should be
reincarnated and the OC4J chapter updated one last time for 10.X.
This would not be a high priority - although if it is not done
relatively soon there may be little point :-)
If we decide to do this I will reopen the older jira's and create a
new one describing the reasoning for it. I'll mark it for community
contribute requested, and if anyone in the community would like to
work on it great. I'm not sure how much time we can spend with it.
Regards,
Jay
15 years, 6 months
Updated Hudson build notifications to include links to the public hudson server
by Jay Balunas
Hello all,
Previously all build messages from hudson contained links to hudson
servers that were behind the redhat VPN. This meant that no one could
access build information unless they were connected to and had access
to Red Hat's VPN.
I updated all Seam, WebBeans, and RichFaces builds so that the
messages now include both the original link, and a new link that
points to the public hudson server. The new links will take you to
the effected hudson job, but not the exact build. There is no way to
make that work at the moment.
Please let me know if I got any of the links wrong, or missed any of
the important builds. They should be all set, but I am not positive,
until the messages actually get sent.
By the way the notification criteria can be customized to some extent,
but as of now all the effected builds have the same scheme. In all of
these situations - failed, unstable, still-failed, still-unstable,
fixed - users who have made commits to the current, fixed, or still
failing/unstable builds will receive the email.
Let me know if we want changes made.
Regards,
Jay
15 years, 6 months
Performance Review of current Seam trunk fo 2.1.1
by Jay Balunas
Performance Review of current Seam trunk fo 2.1.1
--------------------------------------------------------
Working with the latest trunk from today (r9557) and testing the
performance changes that were made. Previous tests were done with (r9017).
Just as a refresher my baseline test uses the wiki example with all of the
sfwk.org data up to July 31st 2008.
For these tests I use JBoss AS 4.2.3 with JDK5 on my linux machine. Jmeter
is used to load test and calculate the results and graphs. I then use
JProfiler to to identify either blocking threads, call graphs, and CPU
usage.
Unfortunately the results were not good. I was using a mixture of 25 and
50 users - hitting the server 25 times each. As before they were accessing
the first page of the user forum.
With r9017 the 25 user x 25 requests averaged 3 seconds a request.
With trunk they were 100+ seconds. Thinking something was wrong with the
system I replaced the 9557 wiki.war with the 9017 and reran with all other
variables the same. Again the 9017 saw about 3 seconds for the average over
the 625 requests.
I then profiled the server under load as I did before. The methods below
appear to be the primary offenders although as with most blocking threads
there are some others waiting on the same monitor. I'll follow up this
email with the stack traces, and more information from my investigation.
-----------------------------------
1) com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate.findLock(..)
- This appears to be the biggest issue. Every requests are generating
many of these calls.
-
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/labs/labs/jbosstm/branches/JBO...
- It looks like every interaction with any transaction causing
synchronization issues with this call.
- We'll need to find a way to limit these calls.
- I'm guessing some of the changes made for JBSEAM-3519 may be the cause
although I have not had time to look deeper.
- See :
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/transa...
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/W...
-----------------------------------
2) org.jboss.naming.ENCFactory.getObjectInstance()
javax.naming.Context.lookup(java.lang.String)
This appears to be the second biggest offender and it looks like we are no
longer blocking on retrieving the InitialContext, but now blocking on
performing the lookups using the context.
-----------------------------------
3)
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection()
org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection()
This is the third biggest issue, but much less than the others. 1 or 2
dozen blocks on 60 requests. These are all related to hibernate calls and
database access from what I've seen so far.
-----------------------------------
I'll follow up this email tomorrow with the typical stack traces seen for
each of these.
Shane could you review, and I'll get more information on these tomorrow.
Thanks,
-Jay
--
blog: http://in.relation.to/Bloggers/Jay
15 years, 6 months
incremental outjection
by Dan Allen
The bijection interceptor changed in Seam 2.1 to accommodate a
multi-threaded component (such as an application-scoped component). In
order for this to work, the bijection process is now stretched across
all concurrent invocation of a component using client counting, such
that injection happens when the first client thread invokes the
component and outjection/disinjection happens when the last thread
leaves.
This raises the question of whether we should have incremental
outjection, where outjection would take place as soon as a thread
finished invoking the component. First, do we want to do this? It
seems to make sense to me. Second, in order to do this, we will have
to distinguish between reentrant calls from the same thread and
separate threads (2 types of "clients" so to speak). I think that to
differentiate rentry from invocation by a sibling thread, we need to
introduce a thread-local variable. Is that correct? I guess a
secondary solution would be to put information in the method context.
I'm looking for two answers:
1) Should we do incremental outjection?
2) How would you suggest detecting when it should be done?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
15 years, 6 months
Followup to discussion of view co-existence
by Clint Popetz
Hi,
(Thanks for all your welcome messages...I'm glad to be able to help
out. And it looks like I'm active in Jira at last, so assign away!)
Pete asked me to follow-up to the list about the state of my attempts
to have multiple view layers, in particular jsf and wicket, co-exist
in the same deployment. This comes down to needing to choose an
implementation-specific sublass of components like Manager and
StatusMessages on a per-request basis.
Working with Pete in IM, we were trying to invent a general mechanism
for this, and came up with the idea of an application-scoped
"instantiator" component that uses events to register possible
implementations. The base component then uses this instantiator
within an @Unwrap. So, in pseudocode:
@Scope(Event)
Manager
{
@Unwrap unwrap()
{
return ((Instantiator<Manager>)
Component.getInstance(ManagerInstantiator.class)).selectImplementation();
}
}
And the instantiator:
@Scope(Application)
ManagerInstantiator extends Instantiator<Manager>
{
@Create
registerImplementations()
{
//use events to build a list of implementation components...components
// like FacesManager listen to these events
}
public Manager
selectImplementation()
{
//go through the list, find the active implementation, return it.
}
}
It's a little more complicated than that because of re-entrancy
concerns and needing a default implementation for cases like
initialization, when there is no request and thus an implementation
cannot be chosen. (See attached patch.) But that's the basic idea.
This is currently working except for one problem: we need to be able
to use components.xml to configure things like the manager:
<core:manager conversation-id-parameter="myCidName"/>
and that configuration needs to be applied to the implementation,
which doesn't happen with @Unwrap or @Factory. I see a couple options
at this point.
(1) Propagate properties from the base Manager to the selected
implementation by hand in my @Unwrap. Not a good general solution,
error prone, etc.
(2) Use Component.forName("org.jboss.seam.Manager").initialize(selectedImpl)
to initialize the Manager subclass after we've selected it in @Unwrap.
This is, I'm guessing, a subversion of the initialize() method, and
would work. But it's not a general solution.
(3) Refactor Manager so that these configurable parameters are in a
separate ManagerSettings component that Manager then uses. Possible,
still not a general solution, and this would require people to change
their components.xml to refer to this class, or to have
ManagerSettings have the "org.jboss.seam.core.Manager" name and make
the real manager have a different name, which breaks backward
compatibility for anyone referring to the manager by name and not
using injection or the static Manager.getInstance().
(4) Let xml-specified initialization properties be applied to the
results of @Factories by changing
Initialization.installComponentFromXmlElement to check for a @Factory
for the name/className if a class with a @Name cannot be found, and by
running any initializers in Component.handleFactoryMethodResult.
(5) Provide a new decorator that is similar to @Unwrap but describes a
method that returns a delegate component that should assume the name
of the original in the context, and should have configuration applied
to it. So if you do:
Component.getInstance("org.jboss.seam.core.Manager",true)
and the instance isn't found, that component is created as usual, but
if it has a method annotated as:
@DelegateComponent
public Manager getDelegateManager()
{
...
}
then the following happens:
(1) initializers that describe the base Manager are applied to the
returned delegate
(2) the resulting object is placed in the context replacing the original
The latter is a performance issue, which is especially crucial for the
Manager component, which gets looked up many times per request and we
don't want to repeat the selectImplementation() process for each
lookup. (Pete, I profiled this, and it was indeed an issue.)
Thanks for reading all of this, and I'd appreciate any feedback. In
particular, I'd be interested if there's a direction that the design
of web beans would suggest we take.
Thanks,
-Clint
15 years, 6 months
