Adding Classes at Run-time
by Jason Lee
I have an odd question. I have a situation where I'm manually opening a
JAR and adding its classes to the ClassLoader. What I'd like to be able
to do is have Weld scan these classes for any relevant annotations and
take the proper actions, just as if the JARs were in the classpath when
the application started. I've been staring at the JavaDocs (build
locally, btw, as I can't find them on the web :| ) but I don't see any
way to request that Weld inspect a given class. Is it there and I'm
missing it? Am I going to have cobble together that functionality? Am
I asking for something that can't be done (right now)? Any nudges in
the right direction would be much appreciated. :)
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
13 years, 11 months
Ordering of servlet listeners
by Nicklas Karlsson
Hi,
I'm tinkering with the servlet listener -> CDI event bridge in the
seam-servlet module and noticed that currently the WeldListener is placed
last in the PostWebMetadataDeployer in weld-int.
I changed this (and verified it with the debugger) but still my own servlet
listener fires first (expecting the contexts to be up), causing problems.
Any theories as to why this is? How could we guarantee that
the WeldListener is the first one to fire?
---
Nik
16 years
proper handling of Events for beans in inactive Contexts?
by Mark Struberg
Hi!
I have the following scenario:
*) A ServletFilter fires a UserLoggedInEvent
*) A @ConversationScoped MyBean @Observes UserLoggedInEvent with Reception.ALWAYS
The problem here is that the Conversation is not yet 'opened' at the time the ServletFilter fires that event. Thus ConversationContext.isActive() == false and I cannot create this bean.
A similar situation appears if you try to send an event to a @ViewScoped bean from a JSF phase where the ViewMap doesn't yet exist.
So since there is no way to create a contextual instance, the obvious solution is to not send the notification to this very bean.
I didn't find this covered in the spec and I don't yet see much we can do in this case. This may cause some not so obvious behaviour and user may wonder why they don't get the event.
So, should we log some info in this case or silently swallow it?
txs and LieGrue,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
16 years
Running TCK Tests
by Gurkan Erdogdu
Hello folks;
I have been trying to run TCK tests but trouble into some weird situation. Some of the tests are sometimes passed and sometimes failed, and I did not find any reason for it. For example, I run ResolutionByTypeTest, sometimes it has passed all tests, sometimes 2 of them failed, sometimes one of them failed, sometimes 3 of them failed. But always failed tests are "testGenericBeanTypesOnManagedBean","testGenericBeanTypesOnProducerMethod",testGenericBeanTypesOnProducerField.
I have trouble with some other tests also, for example "ResolutionByNameTest#testAmbiguousELNamesResolved", it has passed %95 and failed %5 of time
What is the reason for all of these weird sitatuions ? I use Eclipse with TestNG plugin for testing.
Thanks;
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
16 years
JNDI binding for CDI
by Marius Bogoevici
Hi,
I released v. 6.0.0.Beta11 which fixes the JNDI stuff for Weld - thanks Carlo for the support on the EJB side. One change is that BeanManager is now binding to java:comp instead of the previous java:app (which was not conforming to the spec), so we'll need to do a sweep of the Weld and TCK code in order to make sure that the we use the correct namespace.
Marius
16 years
standard servlet context attribute for the BeanManager
by Dan Allen
At the last Seam team meeting, the issue came up (once again) of how to get
the BeanManager from a non-contextual resource. The reality is that there
are certain lifecycle classes in Java EE that did not get categorized as
components (e.g., PhaseListener) and therefore do not support injection.
They are "outside" of CDI. We are working on an SPI for JSF to make these
classes CDI beans, but there will always be other cases.
In the current version of the spec, the standard way of looking up the
BeanManager is to use JNDI. However, JNDI is not consistently supported in
environments for which we want to write portable extensions (whether we like
it or not, people use servlet containers). Weld puts the BeanManager in a
servlet context attribute equal to the FQCN of BeanManager. Pete suggested
that we submit a change request to have this location standardized when
running in a servlet environment.
With this change, the BeanManager can be obtained as follows:
BeanManager manager = (BeanManager)
getServletContext().getAttribute(BeanManager.class.getName());
This requires no change in Weld, since Weld is already doing this.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
16 years
[TCK] adding serialization tests?
by Mark Struberg
Hi folks!
It seems that the TCK doesn't have powerful tests to ensure that the passivation requirements are really fit.
What I think of is to build a scenario with a @MyOwnSerializableScoped bean which gets a few @ApplicationScoped, @SessionScoped, @Dependent beans, with some interceptors and decorators injected, and then serialize this MySerializableContext to a byte[] and read it back.
wdyt?
The reason for this is that I experience a lot problems in that very area while using the @ViewScoped in JSF.
txs and LieGrue,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
16 years
Ant dist build
by Jay Balunas
Hi All,
So I'm starting to refactor the RichFaces 4.0 build and I am looking at what
other projects are doing. This includes weld and seam 3 builds ( especially
because we have a similar module concept ).
I'm looking for some lessons learned and what you would change if you could.
- Does the single parent pom work well when you have different modules with
very different dependencies?
- Do you guys have any scripts in your back pocket for making the svn
co/update, and build easier? We have a top level pom that does nothing but
build all our modules from their trunk. Might be worth checking in ( or I
might of just missed it ).
- Dist building - I was thinking of modularizing our dist builds so CDK
could be responsible for building CDK dist, UI would do the same, while
having a top level build put these together into the primary dist. Was
there thoughts of this for weld/seam 3? It appears to me that there is
really only a top level distribution build. I think both have merits, just
wondering what the thoughts were.
- I know you guys are using ant builds instead of mvn assembly plugin. Was
this just because the assembler sucks, or something else?
FYI - I think a lot of the build wiki pages are great, and has good details
( RF needs the same for release process). I made a minor update to the
http://seamframework.org/Weld/WeldCoreReleases page, but agree with other
posts that some of the process is "learn as you go". It is still much
better than many other projects, and I'll help out if I get the time, but I
can't promise anything right now.
More question to come for sure,
- Jay
--
blog: http://in.relation.to/Bloggers/Jay
16 years
Proxyability of private methods
by Marius Bogoevici
Hi,
Looking at: http://www.seamframework.org/Community/ScalaJSF20OnJboss6DeploymentError - the discussion originated in a Scala issue, but, in a more general way, a class like this:
@SessionScoped
public class ElusiveClass
{
public void publicBehaviour() {}
private final privateBehaviour() {}
}
is not proxyable, according to 5.4.1. I wonder if it makes sense to change this in a future revision of the spec, by saying that a proxyable class must not have final methods, *except for the private ones*.
I don't think that relaxing the conditions in this way would undermine the intent of 5.4.1 as it stands now, since those methods cannot be overridden/proxified anyway.
WDYT?
Marius
16 years
