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?)
16 years, 3 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)
16 years, 3 months
XML Extensions
by Stuart Douglas
I have created a project for this on launchpad and have it at the stage where it can set up simple beans and add annotations to beans and fields. It is still early stages, but I don't think it will be as big a job as it appears at first glance. I am trying to stay true to the format specified in the web beans spec.
The project is called jbraze and it can be checked out with bazaar using:
bzr co lp:jbraze
Hopefully I will have a 90% functional version by the end of the week for review.
16 years, 3 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 :-)
16 years, 4 months
Abstract decorators
by Marius Bogoevici
The specification allows for decorators to be abstract classes, but this
is currently not supported in Weld (defect WELD-298).
Since allowing decorator classes to be abstract is the only stated
requirement, here are the general lines I think we should follow for
supporting this:
- abstract decorator classes can have injected fields, injected
constructor parameters and concrete initializer methods, but abstract
initializer methods should be forbidden (DefinitionException), or at the
very least be non-portable.
- abstract decorator classes cannot have abstract decorating methods
(DefinitionException)
WDYT?
Marius
16 years, 4 months
Portable extension for injecting Seam beans
by Gavin King
Folks, would someone please try out the following portable extension
for me. It should be enough to let you typesafe-inject a Seam2
component using Weld, e.g.
@Inject @Qualifier MySeamComponent msc;
It's not enough to allow the use of typesafe injection in the seam
component itself, however.
Please test this for me, thanks!
++++
package org.seamframework;
import java.util.Collections;
import java.util.Set;
import javax.enterprise.context.RequestScoped;
import javax.enterprise.context.spi.CreationalContext;
import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.AnnotatedType;
import javax.enterprise.inject.spi.BeforeBeanDiscovery;
import javax.enterprise.inject.spi.Extension;
import javax.enterprise.inject.spi.InjectionPoint;
import javax.enterprise.inject.spi.InjectionTarget;
import javax.enterprise.inject.spi.ProcessInjectionTarget;
import javax.enterprise.util.AnnotationLiteral;
import org.jboss.seam.Component;
import org.jboss.seam.annotations.Name;
public class SeamComponentExtension implements Extension {
void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bbd) {
bbd.addStereotype(Name.class, new AnnotationLiteral<RequestScoped>()
{}); //TODO: put it in a @StatelessScope!
}
<X> void processInjectionTarget(@Observes final
ProcessInjectionTarget<X> pit) {
final AnnotatedType<X> at = pit.getAnnotatedType();
if ( at.isAnnotationPresent(Name.class) ) {
if ( !pit.getInjectionTarget().getInjectionPoints().isEmpty() ) {
throw new RuntimeException("CDI injection points not supported for
Seam2 components");
}
InjectionTarget<X> it = new InjectionTarget<X>() {
@Override
public void inject(X instance, CreationalContext<X> ctx) {
//TODO figure out a way to inject into the Seam component
}
@Override
public void postConstruct(X instance) {}
@Override
public void preDestroy(X instance) {}
@Override
public void dispose(X instance) {}
@Override
public Set<InjectionPoint> getInjectionPoints() {
return Collections.EMPTY_SET;
}
@Override
public X produce(CreationalContext<X> ctx) {
//TODO: it would be better to override
Component.instantiateJavaBean() to call
// it.produce(), in order to get injection, etc, but then we
would have
// to figure out a way to replace the Seam Component object
return (X) Component.getInstance( at.getJavaClass(), true );
}
};
pit.setInjectionTarget(it);
}
}
}
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 4 months
