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
Re: [weld-dev] [seam-dev] Will Seam 3 be "batch" friendly, ie be able to minimally run outside any container?
by Pete Muir
Yes :-)
We're quite a long way there already, with Weld-SE support.
Pete R, are you interested/able to work on an example for Weld SE that adds JPA support?
Pete
On 7 Apr 2010, at 01:13, denis.forveille(a)gmail.com wrote:
> Are there plan to have a way to run a pure j2se+JPA+CDI+Weld application
> containing Seam 3 components?
>
> In it's time, I have open this JIRA/feature request to add this feature
> to Seam 2: https://jira.jboss.org/jira/browse/JBSEAM-1680
>
> Most of our applications have a need to run "batch" processes that run
> outside a container, ie process thousand of "items" during off peak
> hours (ie at night), but share many of the business logic and the JPA
> model. Our applications are designed to isolated "shared" business logic
> (ie batch+web) in a separate module and use only "Application Scope"
> Seam 2 components
>
> Currently we use some kind of "JUnit" techniques to boostrap our apps,
> ie manual bootstratp of the JPA data source (Hibernate), manual control
> of the transaction boundaries and manually injecting Application Scope
> Components.
> We have written a kind of "SeamTest" class that scans all of our
> components that may be called by the batch process and inject the base
> objects (logguer, other managers, EM etc..).
> Something that we currently miss is to reuse the PDF and Excel
> components as they depends on facelets/JSF and cannot easily run outside
> some kind of container...
>
> I don't have a deep knowledge of CDI and Weld, but it seem those should
> help for this. The questions remains for Seam 3.
>
> Is there some interest for this? The first thing could be to define the
> specs and "limits" of what can be done and what cannot (Define the
> authorized scopes, the way the EM ans transactions are managed, what
> "modules" (I18N, PDF etc ) can be used. Of course anything related to
> web woule not be allowed (Security, "pages.xml/navigation", etc..), and
> maybe define some kind of "SeamBatch" class that would take care of all
> the Seam components, and maybe add some batch specific annotations (or
> non-container specific) for transaction boundaries
>
> Thx
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
16 years
