[JSF2] spec issue ? (was: Trinidad 2 JIRA: TRINIDAD-1724)
Hey guys, background: https://issues.apache.org/jira/browse/TRINIDAD-1724 Max, so you are saying the changed the API (XSD) file for the facelettaglibrary (not the faces-config, right?) But the online version of it, simply lacks the method-signature: http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd So does the MyFaces 2 version of it: http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facelettaglibrary_2_0.xsd?view=log So, not sure if there was some errata for this, but I guess we need to add that to our MyFaces XSD as well. So, let me file a myfaces bug... Max/Andy: Is one of you guys aware of a bug ticket, for when the RI added the change to their facelettaglibrary? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [JSF2] spec issue ? (was: Trinidad 2 JIRA: TRINIDAD-1724)
Ok, here is the bug: https://issues.apache.org/jira/browse/MYFACES-2554 -Matthias On Sat, Feb 13, 2010 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote: Hey guys, background: https://issues.apache.org/jira/browse/TRINIDAD-1724 Max, so you are saying the changed the API (XSD) file for the facelettaglibrary (not the faces-config, right?) But the online version of it, simply lacks the method-signature: http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd So does the MyFaces 2 version of it: http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facelettaglibrary_2_0.xsd?view=log So, not sure if there was some errata for this, but I guess we need to add that to our MyFaces XSD as well. So, let me file a myfaces bug... Max/Andy: Is one of you guys aware of a bug ticket, for when the RI added the change to their facelettaglibrary? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2554) myfaces's facelettaglibrary XSD incomplete
myfaces's facelettaglibrary XSD incomplete -- Key: MYFACES-2554 URL: https://issues.apache.org/jira/browse/MYFACES-2554 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Matthias Weßendorf See this thread: http://markmail.org/message/p3wjlge73qhdkhse looks like the official online version of the XSD is outdated. Not sure when (and what RI/SPEC bug?) they added the things. At least we don't have the method-signature in our version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1725) Component metadata is still going against JSF version 1.2
Component metadata is still going against JSF version 1.2 - Key: TRINIDAD-1725 URL: https://issues.apache.org/jira/browse/TRINIDAD-1725 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.2-core Reporter: Matthias Weßendorf See: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x/trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/Choose.xml we need to update the metadata to point to the correct version -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2553) Handle MethodExpressions on composite:attribute correctly
[ https://issues.apache.org/jira/browse/MYFACES-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833370#action_12833370 ] Jakob Korherr commented on MYFACES-2553: A really good solution, Leonardo :) Handle MethodExpressions on composite:attribute correctly --- Key: MYFACES-2553 URL: https://issues.apache.org/jira/browse/MYFACES-2553 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 There are currently problems when composite:attribute refers to a MethodExpression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: [Ext-CDI] @Transactional
Hi Gerhard, Did you mean i used UserTransaction? If not, how do you receive your EntityTransaction? I am working on a solution to get request-scoped EntityManagers injected within a servlet-container that does not even support the web-profile (which are the current jetty and the current tomcat). I am not able to get an EntityManager injected via @PersistenceContext in that environment. So it would be nice if there were some CDI-Extension to achieve this. The implementation would be pretty straight-forward except the configuration of the persistence-unit name and the handling of different persistence-units within one CDI-deployment unit. Using JTA-Transactions vs. resource-local EntityTransactions is another issue here. Regards, Arne -- Arne Limburg - Enterprise Developer OpenKnowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 - 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 arne.limb...@openknowledge.de http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 12. Februar 2010 19:59 An: MyFaces Development Betreff: Re: [Ext-CDI] @Transactional hi arne, yes - i used EntityTransaction in the prototype and it works pretty well in a servlet container (that was the base idea). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/12 Arne Limburg arne.limb...@openknowledge.demailto:arne.limb...@openknowledge.de Hi folks, I saw the discussion of adding an @Transactional-Annotation to your CDI extensions. I think Gerhard wrote it. I wonder if it deals with JTA transactions (which indeed would be pretty straight-forward) or with EntityTransactions of an resource-local EntityManager. I am working on the latter one and just would want to know if someone else is working on such stuff. I think it would be great, when we could archive injection of resource-local EntityManagers with transaction-support to deploy it on a tomcat or jetty. What do you think? Regards, Arne -- Arne Limburg - Enterprise Developer OpenKnowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 - 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 arne.limb...@openknowledge.demailto:arne.limb...@openknowledge.de http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann
Re: [Ext-CDI] @Transactional
hi arne, i used the EntityManager to get an EntityTransaction. you have to use cdi to create and inject it. (i used some producer methods.) i created @PersistenceUnit which is a cdi qualifier and @Transactional which is a cdi interceptor binding. basically it works and it isn't hard to use. however, we have to think about an approach to provide as much as possible in a generic way. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/13 Arne Limburg arne.limb...@openknowledge.de Hi Gerhard, Did you mean „i used UserTransaction”? If not, how do you receive your EntityTransaction? I am working on a solution to get request-scoped EntityManagers injected within a servlet-container that does not even support the web-profile (which are the current jetty and the current tomcat). I am not able to get an EntityManager injected via @PersistenceContext in that environment. So it would be nice if there were some CDI-Extension to achieve this. The implementation would be pretty straight-forward except the configuration of the persistence-unit name and the handling of different persistence-units within one CDI-deployment unit. Using JTA-Transactions vs. resource-local EntityTransactions is another issue here. Regards, Arne -- Arne Limburg - Enterprise Developer OpenKnowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 - 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 arne.limb...@openknowledge.de http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 12. Februar 2010 19:59 *An:* MyFaces Development *Betreff:* Re: [Ext-CDI] @Transactional hi arne, yes - i used EntityTransaction in the prototype and it works pretty well in a servlet container (that was the base idea). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/12 Arne Limburg arne.limb...@openknowledge.de Hi folks, I saw the discussion of adding an @Transactional-Annotation to your CDI extensions. I think Gerhard wrote it. I wonder if it deals with JTA transactions (which indeed would be pretty straight-forward) or with EntityTransactions of an resource-local EntityManager. I am working on the latter one and just would want to know if someone else is working on such stuff. I think it would be great, when we could archive injection of resource-local EntityManagers with transaction-support to deploy it on a tomcat or jetty. What do you think? Regards, Arne -- Arne Limburg - Enterprise Developer OpenKnowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 - 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 arne.limb...@openknowledge.de http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann
AW: [Ext-CDI] @Transactional
Hi Gerhard,
OK, I got what you did, basically I did the same. You are right, that was
pretty straight-forward, but I had to hard-code the persistence-unit name.
I have two ideas to inject the persistence-unit name into the producer-method
for the EntityManager:
First idea: A @PersistenceUnitName qualifier-annotation to inject the name into
the producer-method. Client code would have somethink like
public class Configuration {
@Produces @PersistenceUnitName
String getPersistenceUnitName() {
...
Not really nice, but the simplest solution to generify it.
Second idea:
The @PersistenceContext qualifier has a @Nonbind attribute persistenceUnitName
which we can extract in the producer method. But then we get in scoping issues.
Especially when having multiple persistence-units within one deployment. The
second problem is: How can the @Transactional annotation know the
persistence-unit-name.
Any other ideas?
Regards,
Arne
--
Arne Limburg - Enterprise Developer
OpenKnowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 - 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Samstag, 13. Februar 2010 14:32
An: MyFaces Development
Betreff: Re: [Ext-CDI] @Transactional
hi arne,
i used the EntityManager to get an EntityTransaction.
you have to use cdi to create and inject it.
(i used some producer methods.)
i created @PersistenceUnit which is a cdi qualifier and
@Transactional which is a cdi interceptor binding.
basically it works and it isn't hard to use.
however, we have to think about an approach to provide as much as possible in a
generic way.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/13 Arne Limburg
arne.limb...@openknowledge.demailto:arne.limb...@openknowledge.de
Hi Gerhard,
Did you mean i used UserTransaction? If not, how do you receive your
EntityTransaction?
I am working on a solution to get request-scoped EntityManagers injected within
a servlet-container that does not even support the web-profile (which are the
current jetty and the current tomcat). I am not able to get an EntityManager
injected via @PersistenceContext in that environment. So it would be nice if
there were some CDI-Extension to achieve this. The implementation would be
pretty straight-forward except the configuration of the persistence-unit name
and the handling of different persistence-units within one CDI-deployment unit.
Using JTA-Transactions vs. resource-local EntityTransactions is another issue
here.
Regards,
Arne
--
Arne Limburg - Enterprise Developer
OpenKnowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 - 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limb...@openknowledge.demailto:arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Von: Gerhard Petracek
[mailto:gerhard.petra...@gmail.commailto:gerhard.petra...@gmail.com]
Gesendet: Freitag, 12. Februar 2010 19:59
An: MyFaces Development
Betreff: Re: [Ext-CDI] @Transactional
hi arne,
yes - i used EntityTransaction in the prototype and it works pretty well in a
servlet container (that was the base idea).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/12 Arne Limburg
arne.limb...@openknowledge.demailto:arne.limb...@openknowledge.de
Hi folks,
I saw the discussion of adding an @Transactional-Annotation to your CDI
extensions. I think Gerhard wrote it. I wonder if it deals with JTA
transactions (which indeed would be pretty straight-forward) or with
EntityTransactions of an resource-local EntityManager. I am working on the
latter one and just would want to know if someone else is working on such
stuff. I think it would be great, when we could archive injection of
resource-local EntityManagers with transaction-support to deploy it on a tomcat
or jetty. What do you think?
Regards,
Arne
--
Arne Limburg - Enterprise Developer
OpenKnowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 - 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limb...@openknowledge.demailto:arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
AW: [Ext-CDI] @Transactional
Hi!
The JSR-299 spec defines that we have to support injection of EE-Resources.
This was more explicit in the old version of the spec, but unless the wording
got shortened, I still think injection of @PersistenceUnit and
@PersistenceContext must be supported by any JSR-299 container (at least in an
EE environment).
For OpenWebBeans, you can simply use our openwebbeans-resource plugin. Please
note that this is necessary because OWB is modular, and openwebbeans-impl (the
core) will have no EE dependencies at all (not even JSF, JPA, etc!) This will
get picked up automatically if it is available in the classpath, e.g. you can
simply define the following maven dependency:
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-resource/artifactId
version${owb.version}/version
/dependency
OWB supports 2 different scenarios. If you are not running in a JTA aware
container like e.g. OpenEJB, you will automatically use a simple resource
version of an SPI implementation which uses
Persistence#createEntityManagerFactory(unitName) for injecting (Thus getting an
extended EM). If you use e.g. OpenEJB, we are able to get the injectable
resources directly from there (thus getting a transactional EM).
Once this is available, you can simply create a producer method for the
EntityManager:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/util/EntityManagerUtil.java
There is also an example on how to implement a TransactionalInterceptor:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/intercept/TransactionalInterceptor.java
In my company, I already implemented a TransactionalInteceptor which is capable
of handling multiple databases at a time and also correctly handles nested
transactions. I hope to migrate this over to CODI in the near future.
LieGrue,
strub
--- Arne Limburg arne.limb...@openknowledge.de schrieb am Sa, 13.2.2010:
Von: Arne Limburg arne.limb...@openknowledge.de
Betreff: AW: [Ext-CDI] @Transactional
An: 'MyFaces Development' dev@myfaces.apache.org
Datum: Samstag, 13. Februar 2010, 14:42
Hi Gerhard,
OK, I got what you did,
basically I did the same. You are right,
that was pretty straight-forward, but I had to hard-code
the persistence-unit
name.
I have two ideas to inject the
persistence-unit name into the
producer-method for the EntityManager:
First idea: A
@PersistenceUnitName qualifier-annotation to
inject the name into the producer-method. Client code would
have somethink like
public class Configuration
{
@Produces
@PersistenceUnitName
String
getPersistenceUnitName() {
…
Not really nice, but the
simplest solution to generify it.
Second idea:
The @PersistenceContext
qualifier has a @Nonbind attribute
persistenceUnitName which we can extract in the producer
method. But then we
get in scoping issues. Especially when having multiple
persistence-units within
one deployment. The second problem is: How can the
@Transactional annotation
know the persistence-unit-name.
Any other ideas?
Regards,
Arne
--
Arne Limburg - Enterprise
Developer
OpenKnowledge GmbH,
Oldenburg
Bismarckstraße 13, 26122
Oldenburg
Mobil: +49 (0) 151 - 108 22
942
Tel: +49 (0) 441 -
4082-0
Fax: +49 (0) 441 -
4082-111
arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht
Oldenburg, HRB 4670
Geschäftsführer: Lars
Röwekamp, Jens Schumann
Von: Gerhard Petracek
[mailto:gerhard.petra...@gmail.com]
Gesendet: Samstag, 13. Februar 2010 14:32
An: MyFaces Development
Betreff: Re: [Ext-CDI] @Transactional
hi arne,
i used the EntityManager to get
an EntityTransaction.
you have to use cdi to create and
inject it.
(i used some producer methods.)
i create...@persistenceunit which
is a cdi qualifier and
@Transactional which is a cdi
interceptor binding.
basically it works and it isn't
hard to use.
however, we have to think about an
approach to provide as
much as possible in a generic way.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/13 Arne Limburg arne.limb...@openknowledge.de
Hi
Gerhard,
Did
you mean „i used
UserTransaction”? If not, how do you receive your
EntityTransaction?
I am
working on a solution to
get request-scoped
AW: [Ext-CDI] @Transactional
Hi Mark,
thank you for your feedback. I was aware of the requirement of CDI-containers
to inject JavaEE resources in a JavaEE-environment, but Gerhard and I are
thinking about a generic non-JavaEE-solution for EntityManager-injection. And
at least weld does no injection of JavaEE-resources in this case. How does
OpenWebBeans?
I am afraid supporting multiple persistence-units in that scenario is very
difficult...
Nonetheless it would be nice to see your multiple-database-handling
TransactionInterceptor in CODI.
Regards,
Arne
--
Arne Limburg - Enterprise Developer
OpenKnowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 - 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Samstag, 13. Februar 2010 15:39
An: MyFaces Development
Betreff: AW: [Ext-CDI] @Transactional
Hi!
The JSR-299 spec defines that we have to support injection of EE-Resources.
This was more explicit in the old version of the spec, but unless the wording
got shortened, I still think injection of @PersistenceUnit and
@PersistenceContext must be supported by any JSR-299 container (at least in an
EE environment).
For OpenWebBeans, you can simply use our openwebbeans-resource plugin. Please
note that this is necessary because OWB is modular, and openwebbeans-impl (the
core) will have no EE dependencies at all (not even JSF, JPA, etc!) This will
get picked up automatically if it is available in the classpath, e.g. you can
simply define the following maven dependency:
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-resource/artifactId
version${owb.version}/version
/dependency
OWB supports 2 different scenarios. If you are not running in a JTA aware
container like e.g. OpenEJB, you will automatically use a simple resource
version of an SPI implementation which uses
Persistence#createEntityManagerFactory(unitName) for injecting (Thus getting an
extended EM). If you use e.g. OpenEJB, we are able to get the injectable
resources directly from there (thus getting a transactional EM).
Once this is available, you can simply create a producer method for the
EntityManager:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/util/EntityManagerUtil.java
There is also an example on how to implement a TransactionalInterceptor:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/intercept/TransactionalInterceptor.java
In my company, I already implemented a TransactionalInteceptor which is capable
of handling multiple databases at a time and also correctly handles nested
transactions. I hope to migrate this over to CODI in the near future.
LieGrue,
strub
--- Arne Limburg arne.limb...@openknowledge.de schrieb am Sa, 13.2.2010:
Von: Arne Limburg arne.limb...@openknowledge.de
Betreff: AW: [Ext-CDI] @Transactional
An: 'MyFaces Development' dev@myfaces.apache.org
Datum: Samstag, 13. Februar 2010, 14:42
Hi Gerhard,
OK, I got what you did,
basically I did the same. You are right,
that was pretty straight-forward, but I had to hard-code
the persistence-unit
name.
I have two ideas to inject the
persistence-unit name into the
producer-method for the EntityManager:
First idea: A
@PersistenceUnitName qualifier-annotation to
inject the name into the producer-method. Client code would
have somethink like
public class Configuration
{
@Produces
@PersistenceUnitName
String
getPersistenceUnitName() {
…
Not really nice, but the
simplest solution to generify it.
Second idea:
The @PersistenceContext
qualifier has a @Nonbind attribute
persistenceUnitName which we can extract in the producer
method. But then we
get in scoping issues. Especially when having multiple
persistence-units within
one deployment. The second problem is: How can the
@Transactional annotation
know the persistence-unit-name.
Any other ideas?
Regards,
Arne
--
Arne Limburg - Enterprise
Developer
OpenKnowledge GmbH,
Oldenburg
Bismarckstraße 13, 26122
Oldenburg
Mobil: +49 (0) 151 - 108 22
942
Tel: +49 (0) 441 -
4082-0
Fax: +49 (0) 441 -
4082-111
arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht
Oldenburg, HRB 4670
Geschäftsführer: Lars
Röwekamp, Jens Schumann
Von: Gerhard Petracek
[mailto:gerhard.petra...@gmail.com]
Gesendet: Samstag, 13. Februar 2010 14:32
An: MyFaces Development
AW: [Ext-CDI] @Transactional
I am afraid supporting multiple persistence-units in that
scenario is very difficult...
Nope, it's really easy. I simply use Qualifiers to distinguish between them.
@Qualifier
public @instance Core {}
@Qualifier
public @instance Other {}
@RequestScoped
public class EMProducer {
private @PersistenceContext(unitName=core) EntityManager emCore;
private @PersistenceContext(unitName=other) EntityManager emOther;
public @Produces @Core EntityManager getCoreEM() {return emCore;}
public @Produces @Other EntityManager getOtherEM() {return emOther;}
Injection happens with
private @Inject @Core EntityManager
Got the idea?
LieGrue,
strub
--- Arne Limburg arne.limb...@openknowledge.de schrieb am Sa, 13.2.2010:
Von: Arne Limburg arne.limb...@openknowledge.de
Betreff: AW: [Ext-CDI] @Transactional
An: MyFaces Development dev@myfaces.apache.org
Datum: Samstag, 13. Februar 2010, 20:06
Hi Mark,
thank you for your feedback. I was aware of the requirement
of CDI-containers to inject JavaEE resources in a
JavaEE-environment, but Gerhard and I are thinking about a
generic non-JavaEE-solution for EntityManager-injection. And
at least weld does no injection of JavaEE-resources in this
case. How does OpenWebBeans?
I am afraid supporting multiple persistence-units in that
scenario is very difficult...
Nonetheless it would be nice to see your
multiple-database-handling TransactionInterceptor in CODI.
Regards,
Arne
--
Arne Limburg - Enterprise Developer
OpenKnowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 - 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Samstag, 13. Februar 2010 15:39
An: MyFaces Development
Betreff: AW: [Ext-CDI] @Transactional
Hi!
The JSR-299 spec defines that we have to support injection
of EE-Resources.
This was more explicit in the old version of the spec, but
unless the wording got shortened, I still think injection of
@PersistenceUnit and @PersistenceContext must be supported
by any JSR-299 container (at least in an EE environment).
For OpenWebBeans, you can simply use our
openwebbeans-resource plugin. Please note that this is
necessary because OWB is modular, and openwebbeans-impl (the
core) will have no EE dependencies at all (not even JSF,
JPA, etc!) This will get picked up automatically if it is
available in the classpath, e.g. you can simply define the
following maven dependency:
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-resource/artifactId
version${owb.version}/version
/dependency
OWB supports 2 different scenarios. If you are not running
in a JTA aware container like e.g. OpenEJB, you will
automatically use a simple resource version of an SPI
implementation which uses
Persistence#createEntityManagerFactory(unitName) for
injecting (Thus getting an extended EM). If you use e.g.
OpenEJB, we are able to get the injectable resources
directly from there (thus getting a transactional EM).
Once this is available, you can simply create a producer
method for the EntityManager:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/util/EntityManagerUtil.java
There is also an example on how to implement a
TransactionalInterceptor:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/intercept/TransactionalInterceptor.java
In my company, I already implemented a
TransactionalInteceptor which is capable of handling
multiple databases at a time and also correctly handles
nested transactions. I hope to migrate this over to CODI in
the near future.
LieGrue,
strub
--- Arne Limburg arne.limb...@openknowledge.de
schrieb am Sa, 13.2.2010:
Von: Arne Limburg arne.limb...@openknowledge.de
Betreff: AW: [Ext-CDI] @Transactional
An: 'MyFaces Development' dev@myfaces.apache.org
Datum: Samstag, 13. Februar 2010, 14:42
Hi Gerhard,
OK, I got what you did,
basically I did the same. You are right,
that was pretty straight-forward, but I had to
hard-code
the persistence-unit
name.
I have two ideas to inject the
persistence-unit name into the
producer-method for the EntityManager:
First idea: A
@PersistenceUnitName qualifier-annotation to
inject the name into the producer-method. Client code
would
have somethink like
public class Configuration
{
@Produces
@PersistenceUnitName
String
getPersistenceUnitName() {
…
AW: [Ext-CDI] @Transactional
Hi Mark,
yes, that is simple when you have a working @PersistenceContext(unitName=...)
annotation. In none-EE-environments you don't have that and generic
producer-methods are more complicated since you have to inject your unit-name.
Regards,
Arne
--
Arne Limburg - Enterprise Developer
OpenKnowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 - 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Samstag, 13. Februar 2010 20:27
An: MyFaces Development
Betreff: AW: [Ext-CDI] @Transactional
I am afraid supporting multiple persistence-units in that
scenario is very difficult...
Nope, it's really easy. I simply use Qualifiers to distinguish between them.
@Qualifier
public @instance Core {}
@Qualifier
public @instance Other {}
@RequestScoped
public class EMProducer {
private @PersistenceContext(unitName=core) EntityManager emCore;
private @PersistenceContext(unitName=other) EntityManager emOther;
public @Produces @Core EntityManager getCoreEM() {return emCore;}
public @Produces @Other EntityManager getOtherEM() {return emOther;}
Injection happens with
private @Inject @Core EntityManager
Got the idea?
LieGrue,
strub
--- Arne Limburg arne.limb...@openknowledge.de schrieb am Sa, 13.2.2010:
Von: Arne Limburg arne.limb...@openknowledge.de
Betreff: AW: [Ext-CDI] @Transactional
An: MyFaces Development dev@myfaces.apache.org
Datum: Samstag, 13. Februar 2010, 20:06
Hi Mark,
thank you for your feedback. I was aware of the requirement
of CDI-containers to inject JavaEE resources in a
JavaEE-environment, but Gerhard and I are thinking about a
generic non-JavaEE-solution for EntityManager-injection. And
at least weld does no injection of JavaEE-resources in this
case. How does OpenWebBeans?
I am afraid supporting multiple persistence-units in that
scenario is very difficult...
Nonetheless it would be nice to see your
multiple-database-handling TransactionInterceptor in CODI.
Regards,
Arne
--
Arne Limburg - Enterprise Developer
OpenKnowledge GmbH, Oldenburg
Bismarckstraße 13, 26122 Oldenburg
Mobil: +49 (0) 151 - 108 22 942
Tel: +49 (0) 441 - 4082-0
Fax: +49 (0) 441 - 4082-111
arne.limb...@openknowledge.de
http://www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Samstag, 13. Februar 2010 15:39
An: MyFaces Development
Betreff: AW: [Ext-CDI] @Transactional
Hi!
The JSR-299 spec defines that we have to support injection
of EE-Resources.
This was more explicit in the old version of the spec, but
unless the wording got shortened, I still think injection of
@PersistenceUnit and @PersistenceContext must be supported
by any JSR-299 container (at least in an EE environment).
For OpenWebBeans, you can simply use our
openwebbeans-resource plugin. Please note that this is
necessary because OWB is modular, and openwebbeans-impl (the
core) will have no EE dependencies at all (not even JSF,
JPA, etc!) This will get picked up automatically if it is
available in the classpath, e.g. you can simply define the
following maven dependency:
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-resource/artifactId
version${owb.version}/version
/dependency
OWB supports 2 different scenarios. If you are not running
in a JTA aware container like e.g. OpenEJB, you will
automatically use a simple resource version of an SPI
implementation which uses
Persistence#createEntityManagerFactory(unitName) for
injecting (Thus getting an extended EM). If you use e.g.
OpenEJB, we are able to get the injectable resources
directly from there (thus getting a transactional EM).
Once this is available, you can simply create a producer
method for the EntityManager:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/util/EntityManagerUtil.java
There is also an example on how to implement a
TransactionalInterceptor:
https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/reservation/src/main/java/org/apache/webbeans/reservation/intercept/TransactionalInterceptor.java
In my company, I already implemented a
TransactionalInteceptor which is capable of handling
multiple databases at a time and also correctly handles
nested transactions. I hope to migrate this over to CODI in
the near future.
LieGrue,
strub
--- Arne Limburg arne.limb...@openknowledge.de
schrieb am Sa, 13.2.2010:
Von: Arne Limburg arne.limb...@openknowledge.de
[jira] Created: (MYFACES-2555) org.apache.myfaces.config.annotation.LifecycleProvider context parameter is ignored
org.apache.myfaces.config.annotation.LifecycleProvider context parameter is ignored --- Key: MYFACES-2555 URL: https://issues.apache.org/jira/browse/MYFACES-2555 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Jetty 6, Google App Engine Reporter: Ali Ok org.apache.myfaces.config.annotation.LifecycleProvider context parameter is ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2555) org.apache.myfaces.config.annotation.LifecycleProvider context parameter is ignored
[ https://issues.apache.org/jira/browse/MYFACES-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok updated MYFACES-2555: Status: Patch Available (was: Open) org.apache.myfaces.config.annotation.LifecycleProvider context parameter is ignored --- Key: MYFACES-2555 URL: https://issues.apache.org/jira/browse/MYFACES-2555 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Jetty 6, Google App Engine Reporter: Ali Ok Original Estimate: 0.08h Remaining Estimate: 0.08h org.apache.myfaces.config.annotation.LifecycleProvider context parameter is ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ExpressionFactoryImpl
Hi, On Jsp2.0 environment using Myfaces 2.0 beta, users should provide the ExpressionFactory implementation. And if Jasper EL Impl or Sun's RI is available on the classpath, they are automatically set. However, impl class name of RI may be wrong. Until revision 761982, it was com.sun.el.ExpressionFactoryImpl, which is correct class name. Then it became com.sun.facelets.el.ExpressionFactoryImpl, that I couldn't find anywhere (spec, facelets.dev.java.net, etc. ) Is this change correct? You can see the code on Jsp20FacesInitializer#EL_RI_EXPRESSION_FACTORY_IMPL. It is still com.sun.el.ExpressionFactoryImpl on Myfaces 1.2.8. It is not big deal, I can override it with a context parameter; but running Myfaces out-of-the-box is important :) Regards, Ali
