Reorg of SVN
by Pete Muir
All,
I am working through Weld SVN right now, and will then move onto Seam SVN, reorganizing SVN to better fit the module structure we have been discussing here recently. I'll post some links to wiki pages describing the structure once I am done.
Pete
14 years, 5 months
Seam 3/Weld extensions planning notes
by Pete Muir
Here is a list of modules we discussed, in no particular priority order. I will follow up with what we saw as priorities.
We split the module list into three parts - Seam modules, CDI modules, and view layer integrations, we felt this separation would ensure that our modules are usable outside a particular view layer...
I've indicated where we agreed a lead (in parentheses), and where a lead is needed.
We clearly need to get this all onto a wiki page. Unless some kind soul feels like doing this, I will get to this next week :-)
CDI extensions
1) Seam 2 backwards compat (Norman)
- access Seam 2 components from CDI
- natively run Seam 2 apps in CDI (possibly? a later step)
2) support for other languages such as Groovy or Scala (a future direction, looking for a lead per language)
* in general, this more writing tests and examples, than specific integration code
Seam modules/areas
3) Examples (lead needed)
* In general, an example should be ported by the person working on that area
* we need an overall lead (TBC)
* we went through the example list, and decided on some we definitely want to get rid of
4) Support for replicating managed entities
* this is something we supported in Seam 2, but it caused problems. I have previously spoken to the JBoss Clustering team about this, and they plan to add this support to JBoss AS. IMO we should use this support, and not try to implement it ourselves, so we should check with them to find out the status.
5) jBPM support (Joram Barez/Pete)
* Joram Barez for the jBPM team would like to look at this, sometime early in the new year. Seam PE.
6) Drools support (Tiho)
* Tiho has done a lot of work improving our support for Drools 5, all that remains is porting this over to the CDI model. I think this is a perfect candidate for the first release as a result... Seam PE (Tiho to lead)
7) Hot-deploy support (Pete)
* this is something we supported in Seam 2
* splits into two parts:
- redeploy of underlying class definitions
- rebuild of associated bean and class metadata
* IMO the class redeploy should be dealt with by the container, not Seam/Weld, but this may not happen quickly
- placing a jar into the deploy/ dir of JBoss AS is a workaround for this
* rebuild of bean and class metadata probably belongs in the Weld core
* Max suggests taking a look a JRebel for the class bit.
8) JAX-RS integration (Jozef? and Christian?)
9) Resource module for Seam (?)
* DocumentStore
* Classloading stuff from Seam
* I would prefer to not have this if at all possible
10) I8ln support (?)
11) Servlet support (as a CDI PE?) (Nik)
12) Security (Shane)
* Also going to get Shane together for a couple of days with Anil soon so that they can work out how we can better reuse the support JBoss Security provides (e.g. using their SSO, NTLM, Kerberos etc. support)
13) TX and persistence (?)
* question: do we want to support pre-EE5 environments, sounds from Gavin's email like he thinks we should
14) Mail (?, Tomaz are you interested?)
15) Pageflow (?)
16) Reporting
- PDF (Norman)
- Excel (Daniel and Nik)
18) Seam application framework (Dan/Jozef)
16) JMS (Shane or community member)
- basic (injection of JMS resources)
- bridge the event bus over JMS
17) JBoss ESB 5 integration (Kev Connor leading with Pete)
View layer integrations
17) Faces (Dan)
- includes JSF controls for other modules
- Seam Managed Transactions
- Nested conversations
- JSF Scopes
- No more pages.xml
- Debug page
18) Wicket (UE Weld extension) (Clint)
19) GWT (Pete and Heiko)
20) Javascript remoting (Shane)
21) RSS (Nik)
22) CDI portable XML layer (Shane)
Other tasks
23) Weld bugfixing (Pete to lead)
24) Seam documentation review and overhaul (?)
25) Weld extension docs (Dan/Gavin)
26) Testing JBoss Tools support for CDI (everyone!)
27) Unit testing/integration testing support
- Embedded JBoss (ALR leading)
- MockFaces (enhanced version of the JSF mocks and lifecycle mocks from Seam test) (Alex Smirnov leading )
- Shrinkwrap & Arquillian (testing support for containers ALR/Aslak/Pete leading)
28) JIRA cleanup (Gavin/Pete)
14 years, 5 months
Next steps
by Gavin King
So, folks, I want us to get a plan together for the first raft of CDI
extensions. I think there's three kinds of "things" we will be working
on:
* Unportable extensions (UEs), that integrate with proprietary SPIs in Weld
* Portable extensions (PEs) with the Weld brand
* Portable extensions (PEs) with the Seam brand
I imagine that we will distribute UEs along with Weld and cover them
in the Weld documentation. Hopefully there will not be too many of
these.
Weld PEs are going to be things that:
* are general purpose,
* are simple, and
* don't pull in extra dependencies.
Things which don't fit this description get the Seam brand.
We already have:
(1) weld-se
(2) weld-servlet and weld-tomcat
(3) weld-wicket
These are all UEs, I suppose. Or are some of them PEs?
So here's the things that I would like to see us release soon:
(1) A weld-ext module with:
* logger injection,
* @Exact,
* @Introduces,
* abstract producer methods,
* beans declared at constructor level, and
* @Named packages.
These are all very easy to implement except @Introduces, which
requires a little javassist magic.
(I would just package weld-logger in here, I don't see why it needs to
be in its own module.)
(2) A seam2-int module with:
* use of @Inject to inject of Seam2 beans into CDI beans (i.e. Weld
delegates bean instantiation to Seam when there is a @Name)
* (hopefully) support for @Inject in Seam2 beans, if this is not
too hard to implement
I have already done a rough impl of the first part.
(3) A spring-int module.
(4) a seam-transactions module with:
* support for declarative JPA EntityTransaction management
* support for injection of the EntityTransaction
* (hopefully) support for the same things with a UserTransaction
provided by JBoss Transactions
* support for the same things with a Hibernate Transaction
I have already done a rough impl of the first part.
(5) a seam-persistence module with:
* support for injection of JPA EntityManagers with various scopes
* (hopefully) support for injection of Hibernate Sessions with various scopes
I have already done a rough impl of the first part.
(6) a seam-web module with:
* injection of FacesContext
* injection of servlet contexts
These are both easy.
(7) a seam-jms module with:
* injection of all the various JMS objects for a resource of type
Topic or Queue
Is there anything I'm missing?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
14 years, 5 months
Annotated.getBaseType()
by Stuart Douglas
What is annotated.getBaseType() supposed to return?
At the moment I am assuming
AnnotatedConstructor : the class that declared the constructor
AnnotatedField : the type of field
AnnotatedMethod: the return type of the method
AnnotatedParameter: the type of the parameter
is this correct?
14 years, 5 months
Seam examples - what to keep :-)
by Pete Muir
In general, we have too many copies of the booking example and these need to be merged or removed.
Again, let's make this into a wiki page, and try to rationalize a bit further!
We do need an overall lead on examples, anyone want to take that?
Seam 3 examples
* Blog has become Permalink in Weld
* Booking (needs overhaul and all booking examples need merging)
* Contact list (Seam application framework)
* Numberguess (Drools, should be different to jBPM example)
* DVDStore (jBPM processes and pageflow)
* Excel
* Booking (Groovy)
* Guicebar
* Booking (Hibernate)
* Booking (ICEFaces)
* IText
* Booking (JEE5)
* Booking (JPA)
* Mail
* Messages (JSP, remove)
* Booking (Metawidget)
* DVDStore (Metawidget)
* Booking (Nested)
* Numberguess (Pageflow)
* OpenId
* Portal (see portal project)
* Seampay (Quartz)
* Seampay (EJB Async)
* Registration (trivial example for tutorial, so keep)
* Remoting/*
* Seambay (JAX-RS)
* RSS
* Seambay (old WS, replaced by JAX-RS support, remove)
* Seamdiscs (Trinidad integration, CRUD, maybe remove)
* Seamspace (security)
* Booking (Spring)
* Tasks (JAX-RS)
* Todo (jBPM process)
* UI (testing example, remove)
* Booking (Wicket)
* Wiki
14 years, 5 months
Moderation policy
by Pete Muir
Until now we have been operating a moderation policy whereby new users to the list had to be approved to post. The reason to this was to help with the spam problem. In the meantime, the spam filters on lists.jboss.org have got better, and it has become very apparent this has not scaled well, so I have switched the lists to use the standard "any member may post" scheme.
HTH :-)
14 years, 5 months
Weld/Seam in the cloud
by Pete Muir
Whilst we were in Antwerp, Manik, Shane, Rodney and I sat down to think a bit about what this means. A few of the salient points we discussed are:
Good clustering support (Pete)
---------------------------------
* Ensure we always externalize any application state e.g. store it in the session, CDI supports this beautifully!
* Make sure we can externalize "framework" state i.e. any state we store in the framework that can't be trivially rediscovered when a new node starts. The Weld core works like this, as do portable extensions which are coded well, and use Contextual to store state.
- An idea is to add the ability to generate the class metadata (and perhaps even the bean metadata?) at compile time, and store in some binary format inside the jar. This can then be read in when the app starts, rather than using reflection to study the classes. This may lead to faster boot (needs research!)
* Think about replication when we write the core, extensions and apps, and ensure that we allow for efficient replication
Multi-tennanted apps (Shane is going to lead this effort)
-----------------------------
* How are they configured externally from the app itself (e.g. the idea for how to read in properties Gavin blogged about)
* Isolation
* Security?
* Integrating with distributed datastores such as Infinispan, this is intrusive into your data model as some things which work well in RDBMS don't work so well here
Testing (Pete)
----------
* Mainly infrastructure for us, may be useful for others?
* How do we test in GAE?
* How do we test in EC2/Rackspace (talk to Bob McWhirter)
Images (Shane)
----------
* Thincrust images e.g. with Weld installed onto Tomcat (useful for getting started?)
14 years, 5 months
Fwd: [JBoss JIRA] Created: (JBSEAM-4474) Hibernate class org.hibernate.lob.ReaderInputStream is now org.hibernate.engine.jdbc.ReaderInputStream and that breaks Seam
by Scott Marlow
Hi,
There is a Seam reference to a Hibernate class that recently was renamed
(package changed as part of a refactoring). This is currently causing a
problem (described in the jira) for the use of Seam + Hibernate
3.5.0.Beta-2.
The ReaderInputStream code could probably be inlined as there isn't much
left to it:
"
public class ReaderInputStream extends InputStream {
private Reader reader;
public ReaderInputStream(Reader reader) {
this.reader = reader;
}
public int read() throws IOException {
return reader.read();
}
"
Could JBSEAM-4474 be fixed in Seam to not depend on the Hibernate
ReaderInputStream class (or something like that)? :-)
Scott
14 years, 5 months
