Ideas for a replacement of the seam 2 PDF tags/engine in a CDI/JSF 2.0 world?
by Denis Forveille
What thing we like in seam 2 is the pdf engine based on JSF components taylored for iText
As we are moving to CDI, we a re looking for an equivalent engine to produce PDF reports
Seam 3 does not seem to have such an engine ready
Flyingsaucer (http://code.google.com/p/flying-saucer) is almost doing this except that it uses plain JSF/faelets tags, not specific
iText tags/components
I'm thinking on writing such an engine, based on reusing the seam2 JSF-iText tags/components and on the principle described here:
http://today.java.net/pub/a/today/2006/10/31/combine-facelets-and-flying-...
ie:
- write an xhtml report with the seam 2 JSF/iText tags/components exactly as in seam 2
At runtime, have a filter that intercepts the request for such a PDF document (based on extension or request parameter), forward the
request to the JSF engine as a standard request to compose the response
-> the tags will generate a iText document and attach it in a scoped variable
- the filter read the iText object, and read send it to the reponse object
or
use something similar to what ios described here for rendering the response programatically : http://www.bradchen.com/node/36
This engine would obviously depends on JSF and iText, and maybe on CDI
Does this already exist?
WDYT?
12 years, 2 months
- 3
- 4
CDI EG requires feedback
by Pete Muir
All, the CDI EG requires feedback on an item in the spec which is not clear, and has been implemented differently between implementations, and is not TCK tested. As Seam-dev contains lots of extensions authors, requesting feedback. Please either send direct to me, or post to cdi-dev(a)lists.jboss.org :-)
Stuart, your feedback on this would be good, as it relates to XML config.
------------------------------------------------------------------------------------------------------------------------------------------------
Multiple Annotated Types
====================
https://issues.jboss.org/browse/CDI-58
This concerns whether there can be greater than one annotated type per class instance in the JVM. Gavin intended there should be, principally to support an XML configuration dialect, which could introduce multiple versions of a class, each with a different qualifier. However, this is not TCK tested, and implementations vary in how they support this.
We discussed that this makes an implementation considerably more complex (as there is no easy way to uniquely identify an annotated type e.g. for serialization), and also is pretty confusing for a user (as you now get multiple ProcessAnnotatedType events for each class, making it hard to know which one you want to change).
We looked at alternative solutions, and concluded that if all use cases can be satisfied by adding a new bean, rather than a new annotated type, we would like to explicitly specify that there is only one annotated type per class instance. In CDI 1.1 it is already much easier to add and manipulate beans from annotated types, so we believe that the correct thing here is take this route.
------------------------------------------------------------------------------------------------------------------------------------------------
Does anyone create multiple AnnotatedTypes per class instance? If so, can you please describe:
a) why you need to do this
b) whether you could reimplement by directly creating beans (given that CDI 1.1 allows you to [1])
c) how much effort it would be to reimplement/how much of your codebase this would affect
Thanks!
Pete
[1]
BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
Bean b = beanManager.createBean(ba, clazz, it);
or
BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
Bean b = beanManager.createBean(ba, clazz, p);
The Bean can then be registered using
afterBeanDiscovery.addBean(b);
12 years, 3 months
- 3
- 3
- ← Newer
- 1
- Older →