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.
The reason for this is that I experience a lot problems in that very area while using the @ViewScoped in JSF.
txs and LieGrue,
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
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,
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?
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
> 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
> seam-dev mailing list