[jira] Created: (EXTCDI-139) rename internal examples
rename internal examples Key: EXTCDI-139 URL: https://issues.apache.org/jira/browse/EXTCDI-139 Project: MyFaces CODI Issue Type: Task Affects Versions: 0.9.2 Reporter: Gerhard Petracek currently the examples shipped with codi are only playgrounds for the dev process. we should rename them to indicate that users shouldn't learn codi by looking at those examples. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (EXTCDI-139) rename internal examples
[ https://issues.apache.org/jira/browse/EXTCDI-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-139. - Resolution: Fixed Fix Version/s: 0.9.3 rename internal examples Key: EXTCDI-139 URL: https://issues.apache.org/jira/browse/EXTCDI-139 Project: MyFaces CODI Issue Type: Task Affects Versions: 0.9.2 Reporter: Gerhard Petracek Fix For: 0.9.3 currently the examples shipped with codi are only playgrounds for the dev process. we should rename them to indicate that users shouldn't learn codi by looking at those examples. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (EXTCDI-139) rename internal examples
[ https://issues.apache.org/jira/browse/EXTCDI-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996754#comment-12996754 ] Mark Struberg commented on EXTCDI-139: -- I'd rather fill them with good content. So let's polish them to a degree that they can really serve as good examples. rename internal examples Key: EXTCDI-139 URL: https://issues.apache.org/jira/browse/EXTCDI-139 Project: MyFaces CODI Issue Type: Task Affects Versions: 0.9.2 Reporter: Gerhard Petracek Fix For: 0.9.3 currently the examples shipped with codi are only playgrounds for the dev process. we should rename them to indicate that users shouldn't learn codi by looking at those examples. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (EXTCDI-139) rename internal examples
[ https://issues.apache.org/jira/browse/EXTCDI-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996755#comment-12996755 ] Gerhard Petracek commented on EXTCDI-139: - imo we should add further examples similar to http://code.google.com/a/apache-extras.org/p/myfaces-codi-examples/ we need both - examples for users and internal examples. e.g. examples for users which contain use-cases for illustrating current problems aren't a good idea (but we need them for an easier communication). rename internal examples Key: EXTCDI-139 URL: https://issues.apache.org/jira/browse/EXTCDI-139 Project: MyFaces CODI Issue Type: Task Affects Versions: 0.9.2 Reporter: Gerhard Petracek Fix For: 0.9.3 currently the examples shipped with codi are only playgrounds for the dev process. we should rename them to indicate that users shouldn't learn codi by looking at those examples. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3048) Missing myfaces-api-2.0.5-SNAPSHOT-tests.jar prevent building trunk
Missing myfaces-api-2.0.5-SNAPSHOT-tests.jar prevent building trunk --- Key: MYFACES-3048 URL: https://issues.apache.org/jira/browse/MYFACES-3048 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.0.5-SNAPSHOT Environment: Win XP, Ant 2.2.1 Reporter: Oliver Bayer Following exception is thrown while building the trunk: Downloading: http://repository.apache.org/snapshots/org/apache/myfaces/core/myfaces-api/2.0.5-SNAPSHOT/myfaces-api-2.0.5-SNAPSHOT-tests.jar [INFO] Unable to find resource 'org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve dependencies for one or more projects in the reactor. Reason: Missing: -- 1) org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.myfaces.core -DartifactId=myfaces-api -Dversion=2.0.5-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/pa th/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.myfaces.core -DartifactId=myfaces-api -Dversion=2.0.5-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.myfaces.core:myfaces-impl:jar:2.0.5-SNAPSHOT 2) org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.myfaces.core:myfaces-impl:jar:2.0.5-SNAPSHOT from the specified remote repositories: apache.snapshots (http://repository.apache.org/snapshots), tomcat (http://tomcat.apache.org/dev/dist/m2-repository), central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/2) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3048) Missing myfaces-api-2.0.5-SNAPSHOT-tests.jar prevent building trunk
[ https://issues.apache.org/jira/browse/MYFACES-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-3048. Resolution: Invalid Fix Version/s: 2.0.5-SNAPSHOT Missing myfaces-api-2.0.5-SNAPSHOT-tests.jar prevent building trunk --- Key: MYFACES-3048 URL: https://issues.apache.org/jira/browse/MYFACES-3048 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.0.5-SNAPSHOT Environment: Win XP, Ant 2.2.1 Reporter: Oliver Bayer Fix For: 2.0.5-SNAPSHOT Following exception is thrown while building the trunk: Downloading: http://repository.apache.org/snapshots/org/apache/myfaces/core/myfaces-api/2.0.5-SNAPSHOT/myfaces-api-2.0.5-SNAPSHOT-tests.jar [INFO] Unable to find resource 'org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve dependencies for one or more projects in the reactor. Reason: Missing: -- 1) org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.myfaces.core -DartifactId=myfaces-api -Dversion=2.0.5-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/pa th/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.myfaces.core -DartifactId=myfaces-api -Dversion=2.0.5-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.myfaces.core:myfaces-impl:jar:2.0.5-SNAPSHOT 2) org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.myfaces.core:myfaces-impl:jar:2.0.5-SNAPSHOT from the specified remote repositories: apache.snapshots (http://repository.apache.org/snapshots), tomcat (http://tomcat.apache.org/dev/dist/m2-repository), central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/2) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3048) Missing myfaces-api-2.0.5-SNAPSHOT-tests.jar prevent building trunk
[ https://issues.apache.org/jira/browse/MYFACES-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996762#comment-12996762 ] Jakob Korherr commented on MYFACES-3048: You need to run mvn clean install in core/trunk or current20, and not directly in impl itself. This way myfaces-api will be built before myfaces-impl and the tests.jar will be available in your local repository. In addition, I found the tests.jar in the apache snapshots repo: e.g. https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/core/myfaces-api/2.0.5-SNAPSHOT/myfaces-api-2.0.5-20110218.200458-7-tests.jar Closing this issue as invalid. Missing myfaces-api-2.0.5-SNAPSHOT-tests.jar prevent building trunk --- Key: MYFACES-3048 URL: https://issues.apache.org/jira/browse/MYFACES-3048 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.0.5-SNAPSHOT Environment: Win XP, Ant 2.2.1 Reporter: Oliver Bayer Fix For: 2.0.5-SNAPSHOT Following exception is thrown while building the trunk: Downloading: http://repository.apache.org/snapshots/org/apache/myfaces/core/myfaces-api/2.0.5-SNAPSHOT/myfaces-api-2.0.5-SNAPSHOT-tests.jar [INFO] Unable to find resource 'org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve dependencies for one or more projects in the reactor. Reason: Missing: -- 1) org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.myfaces.core -DartifactId=myfaces-api -Dversion=2.0.5-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/pa th/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.myfaces.core -DartifactId=myfaces-api -Dversion=2.0.5-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.myfaces.core:myfaces-impl:jar:2.0.5-SNAPSHOT 2) org.apache.myfaces.core:myfaces-api:jar:tests:2.0.5-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.myfaces.core:myfaces-impl:jar:2.0.5-SNAPSHOT from the specified remote repositories: apache.snapshots (http://repository.apache.org/snapshots), tomcat (http://tomcat.apache.org/dev/dist/m2-repository), central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/2) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[RESULTS] Release of Trinidad 2.0.0 Beta 2
Hey everybody, thanks for Voting. Here are the final results for the Release of Trinidad 2.0.0 Beta 2[1]: +1: Scott O'Bryan, Max Starets, Matthias Wessendorf, Matt Cooper, Nathan Hokanson, Blake Sullivan +0: None -1: None Thanks everyone for voting. I'll complete the release. Scott O'Bryan [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg51504.html
[jira] Created: (EXTCDI-140) explicitely annotate @Dependent scoped beans and make them non-final
explicitely annotate @Dependent scoped beans and make them non-final Key: EXTCDI-140 URL: https://issues.apache.org/jira/browse/EXTCDI-140 Project: MyFaces CODI Issue Type: Bug Reporter: Mark Struberg Assignee: Mark Struberg Currently we have lots of Producers which are not annotated with any scope. That means they will be treated as @Dependent scoped beans by default. I suggest to explicitly annotate them either @Dependent or @ApplicationScoped (if no state information is being used) because the automatic pickup as @Dependent has side effects which not all people are aware off. I also suggest to _not_ declare any bean as _final_ because this prohibits the CDI container to create a proxy for such classes. This currently doesn't happen with @Dependent scoped beans, but this might get changed in future spec versions (auto serialisation support). It also makes it impossible to @Specializes such producers. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tobago 1.0.34
Here is my +1 On Thu, Feb 17, 2011 at 3:16 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Am 17.02.11 08:37, schrieb Matthias Wessendorf: +1 I did a download of the source-drop and the build went fine! On Wed, Feb 16, 2011 at 11:29 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, I would like to release Tobago 1.0.34. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316162 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-019 The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
Re: [VOTE] Release Tobago 1.5.0-alpha-2
Here is my +1 On Thu, Feb 17, 2011 at 3:16 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Am 17.02.11 10:20, schrieb Volker Weber: hi, +1 Regards, Volker 2011/2/17 Bernd Bohmannbernd.bohm...@atanion.com: Hello, I would like to release Tobago 1.5.0-alpha-2. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12314340 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-018 The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
MyFaces PMC += Mark Struberg
Dear MyFaces community, please welcome our new MyFaces PMC member Mark Struberg. Mark is working on several things at Apache MyFaces and became a valuable member of our community. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. @Mark: Please update your status on the site: http://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Thanks, Gerhard
[jira] Resolved: (EXTCDI-140) explicitely annotate @Dependent scoped beans and make them non-final
[ https://issues.apache.org/jira/browse/EXTCDI-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-140. -- Resolution: Fixed explicitely annotate @Dependent scoped beans and make them non-final Key: EXTCDI-140 URL: https://issues.apache.org/jira/browse/EXTCDI-140 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 0.9.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.9.3 Currently we have lots of Producers which are not annotated with any scope. That means they will be treated as @Dependent scoped beans by default. I suggest to explicitly annotate them either @Dependent or @ApplicationScoped (if no state information is being used) because the automatic pickup as @Dependent has side effects which not all people are aware off. I also suggest to _not_ declare any bean as _final_ because this prohibits the CDI container to create a proxy for such classes. This currently doesn't happen with @Dependent scoped beans, but this might get changed in future spec versions (auto serialisation support). It also makes it impossible to @Specializes such producers. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (EXTCDI-141) use maven-failsafe-plugin for running integration tests
use maven-failsafe-plugin for running integration tests --- Key: EXTCDI-141 URL: https://issues.apache.org/jira/browse/EXTCDI-141 Project: MyFaces CODI Issue Type: Bug Components: Base-Test-Infrastructure Affects Versions: 0.9.2 Reporter: Mark Struberg Assignee: Mark Struberg we currently use the maven-surefire-plugin for our cargo integration tests, but using the maven-failsafe-plugin is better suited for IT scenarios (separate verify phase, etc). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (EXTCDI-141) use maven-failsafe-plugin for running integration tests
[ https://issues.apache.org/jira/browse/EXTCDI-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-141. -- Resolution: Fixed use maven-failsafe-plugin for running integration tests --- Key: EXTCDI-141 URL: https://issues.apache.org/jira/browse/EXTCDI-141 Project: MyFaces CODI Issue Type: Bug Components: Base-Test-Infrastructure Affects Versions: 0.9.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.9.3 we currently use the maven-surefire-plugin for our cargo integration tests, but using the maven-failsafe-plugin is better suited for IT scenarios (separate verify phase, etc). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-2995) Make method of determinine app context in FactoryFinder pluggable
[
https://issues.apache.org/jira/browse/MYFACES-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996886#comment-12996886
]
Leonardo Uribe commented on MYFACES-2995:
-
I thought a lot about FactoryFinder and how we can extend it. I'll do a
resume, describing the problem in detail and providing some alternatives. This
could be a little bit redundant, but it is necessary to gain a better
understanding about what's going on and the direction to take.
FactoryFinder is a class with three methods:
public final class FactoryFinder
{
public static Object getFactory(String factoryName) throws FacesException
{...}
public static void setFactory(String factoryName, String implName) {...}
public static void releaseFactories() throws FacesException {...}
}
The javadoc describe the intention of FactoryFinder class:
... FactoryFinder implements the standard discovery algorithm for all factory
objects specified in the JavaServer Faces APIs. For a given factory class name,
a corresponding implementation class is searched for based on the following
algorithm
On the javadoc there is more information from the point of view of the author
(classloading stuff and so on), but just ignore it for a moment, because it
only makes things confusing.
In few words, this class allows to find JSF factory classes. The necessary
information to create factory instances is loaded on initialization time, but
which locations contains such information (for more information see JSF 2.0
spec section 11.4.2) (we are only interested in jsf factories initialization
information) ?
- Look factories on META-INF/services/[factoryClassName]
- Look META-INF/faces-config.xml or META-INF/[prefix].faces-config.xml
- Look the files pointed by javax.faces.CONFIG_FILES web config param (note
WEB-INF/web.xml is taken into consideration)
- Look the applicationFacesConfig on WEB-INF/faces-config.xml
Based on the previous facts, the first conclusion to take into account arise:
Configuration information is gathered per web context. What is a web
context? In simple terms, is the space where a web application is deployed.
Let's suppose an EAR file with two WAR files: a.war and b.war. Both contains
different web applications and when are deployed has different web context,
so both can provide different factory configuration, because both has different
WEB-INF/web.xml and WEB-INF/faces-config.xml files.
Now, given a request, how the web container identify a web context? At start,
it receives the request information and based on that it decides which web
application should process it. After that, it assign to a thread from is thread
pool to be processed and the control is passed to the proper filters/servlets.
So, if we don't have a servlet context/portlet context/whatever context, how to
identify a web context? The answer is using the thread, but the one who knows
how to do that is the web container, not the jsf implementation.
The existing problem is caused by a shortcut taken to make things easier.
Instead use the current thread, it is taken as advantage the fact that each
web application deployed has a different classloader. That is true for a lot of
application servers, so the current implementation of FactoryFinder is based on
that fact too and has worked well since the beginning.
Now let's examine in detail how a single classloader per EAR option could
work. If the EAR has two WAR files (a.war and b.war), we have two web context,
and the initialization code is executed twice. When all FactoryFinder methods
are called?
- FactoryFinder.setFactory is called on initialization
- FactoryFinder.releaseFactories is called on shutdown
- FactoryFinder.getFactory is called after initialization configuration is done
but before shutdown call to FactoryFinder.setFactory .
Remember all methods of FactoryFinder are static.
One possible solution could be:
1. Create a class called FactoryFinderProvider, that has the same three method
but in a non static version.
2. A singleton component is provided that holds the information of the
FactoryFinderProviderFactory. This one works per classloader, so the singleton
is implemented using an static variable. To configure it, the static method
should be called when the classloader realm is initialized, before any web
context is started (the WAR is deployed). Usually the EAR is started as a
single entity, so this should occur when the EAR starts, but before the WAR
files are started (or the web context are created). The singleton will be
responsible to decide which FactoryFinderProvider should be used, based on the
current thread information.
3. Add utility methods to retrieve the required objects and call the methods
using reflection from javax.faces.FactoryFinder
I provided a patch a patch for this one
(MYFACES-2995-FactoryFinderProvider-1.patch)
If no objections I'll
Re: Issue 2995 - Leo please read
Hi
I thought a lot about FactoryFinder and how we can extend it. I'll do a
resume, describing the problem in detail and providing some alternatives.
This could be a little bit redundant, but it is necessary to gain a better
understanding about what's going on and the direction to take.
FactoryFinder is a class with three methods:
public final class FactoryFinder
{
public static Object getFactory(String factoryName) throws
FacesException {...}
public static void setFactory(String factoryName, String implName) {...}
public static void releaseFactories() throws FacesException {...}
}
The javadoc describe the intention of FactoryFinder class:
... FactoryFinder implements the standard discovery algorithm for all
factory objects specified in the JavaServer Faces APIs. For a given factory
class name, a corresponding implementation class is searched for based on
the following algorithm
On the javadoc there is more information from the point of view of the
author (classloading stuff and so on), but just ignore it for a moment,
because it only makes things confusing.
In few words, this class allows to find JSF factory classes. The necessary
information to create factory instances is loaded on initialization time,
but which locations contains such information (for more information see JSF
2.0 spec section 11.4.2) (we are only interested in jsf factories
initialization information) ?
- Look factories on META-INF/services/[factoryClassName]
- Look META-INF/faces-config.xml or META-INF/[prefix].faces-config.xml
- Look the files pointed by javax.faces.CONFIG_FILES web config param (note
WEB-INF/web.xml is taken into consideration)
- Look the applicationFacesConfig on WEB-INF/faces-config.xml
Based on the previous facts, the first conclusion to take into account
arise: Configuration information is gathered per web context. What is a
web context? In simple terms, is the space where a web application is
deployed. Let's suppose an EAR file with two WAR files: a.war and b.war.
Both contains different web applications and when are deployed has
different web context, so both can provide different factory
configuration, because both has different WEB-INF/web.xml and
WEB-INF/faces-config.xml files.
Now, given a request, how the web container identify a web context? At
start, it receives the request information and based on that it decides
which web application should process it. After that, it assign to a thread
from is thread pool to be processed and the control is passed to the proper
filters/servlets.
So, if we don't have a servlet context/portlet context/whatever context, how
to identify a web context? The answer is using the thread, but the one who
knows how to do that is the web container, not the jsf implementation.
The existing problem is caused by a shortcut taken to make things easier.
Instead use the current thread, it is taken as advantage the fact that
each web application deployed has a different classloader. That is true for
a lot of application servers, so the current implementation of FactoryFinder
is based on that fact too and has worked well since the beginning.
Now let's examine in detail how a single classloader per EAR option could
work. If the EAR has two WAR files (a.war and b.war), we have two web
context, and the initialization code is executed twice. When all
FactoryFinder methods are called?
- FactoryFinder.setFactory is called on initialization
- FactoryFinder.releaseFactories is called on shutdown
- FactoryFinder.getFactory is called after initialization configuration is
done but before shutdown call to FactoryFinder.setFactory .
Remember all methods of FactoryFinder are static.
One possible solution could be:
1. Create a class called FactoryFinderProvider, that has the same three
method but in a non static version.
2. A singleton component is provided that holds the information of the
FactoryFinderProviderFactory. This one works per classloader, so the
singleton is implemented using an static variable. To configure it, the
static method should be called when the classloader realm is initialized,
before any web context is started (the WAR is deployed). Usually the EAR is
started as a single entity, so this should occur when the EAR starts, but
before the WAR files are started (or the web context are created). The
singleton will be responsible to decide which
FactoryFinderProvider should be used, based on the current thread
information.
3. Add utility methods to retrieve the required objects and call the methods
using reflection from javax.faces.FactoryFinder
I provided a patch a patch for this one
(MYFACES-2995-FactoryFinderProvider-1.patch)
This patch has the following advantages:
1. No additional module is required
2. The default code works if no FactoryFinderProviderFactory is set, so the
spec javadoc is respected.
3. Code that is used as service provider interface (SPI) is where it should
be (on myfaces-impl class org.apache.myfaces.spi).
4. Solution is
Logos for Bridge and Trinidad
Hey all, I uploaded representations of the Bridge and Trinidad logos into JIRA. Let me know if there are any issues.
myfaces sub-/project logos
hi @ all, i committed all new logos to [1] (with transparent background!). regards, gerhard [1] https://svn.apache.org/repos/asf/myfaces/resources/logos/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: myfaces sub-/project logos
Flipping sweet Gerard. I used the old logo for the Bridges' JIRA logo. I'm going to used a cropped version of yours, it will square better. ;) I'll see about updating the Trinidad and Bridge sites as well. Thanks!! Scotr On Feb 19, 2011, at 5:46 PM, Gerhard gerhard.petra...@gmail.com wrote: hi @ all, i committed all new logos to [1] (with transparent background!). regards, gerhard [1] https://svn.apache.org/repos/asf/myfaces/resources/logos/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2995) Make method of determinine app context in FactoryFinder pluggable
[ https://issues.apache.org/jira/browse/MYFACES-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996947#comment-12996947 ] David Jencks commented on MYFACES-2995: --- Since it's been about 2 1/2 months before this issue was really responded to I'd appreciate a few days to review your patch before you commit it. At the moment I don't understand how a per-ear object could possibly be of any use. IMO depending on the app server either a classloader based strategy as is used at present will work fine or the app server will need to use something else for every ear. There is little chance that one app server will use different classloading strategies for different ears and want to therefore use different code to distinguish jsf contexts for different ears. However I may have misunderstood your comments as I have not yet had a chance to look at your patch. Make method of determinine app context in FactoryFinder pluggable - Key: MYFACES-2995 URL: https://issues.apache.org/jira/browse/MYFACES-2995 Project: MyFaces Core Issue Type: Improvement Components: SPI Affects Versions: 2.0.3-SNAPSHOT Reporter: David Jencks Attachments: MYFACES-2995-FactoryFinderProvider-1.patch, MYFACES-2995.patch As discussed on dev list geronimo would like to explicitly mark component boundaries rather than relying on the TCCL changing. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-2995) Make method of determinine app context in FactoryFinder pluggable
[ https://issues.apache.org/jira/browse/MYFACES-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996973#comment-12996973 ] Leonardo Uribe commented on MYFACES-2995: - The example of the EAR is just a help to understand the problem, but it is not a limitation. The important concept is FactoryFinderProviderFactory instance is an static var that should be initialized when the classloader context is initialized. For example, if I have 5 EAR files and all share the same myfaces implementation (by some specific classloading configuration done by the server), the container should initialize this instance before deploy/start any of the 5 EAR. I was thinking on make some changes on FactoryFinderProviderFactory, removing the code that set FactoryFinder._initialized to false. Instead, check if FactoryFinder has been initialized and if that so, log a warning indicating the instance will not be changed. I'll be pending of your review so we can close this issue. Make method of determinine app context in FactoryFinder pluggable - Key: MYFACES-2995 URL: https://issues.apache.org/jira/browse/MYFACES-2995 Project: MyFaces Core Issue Type: Improvement Components: SPI Affects Versions: 2.0.3-SNAPSHOT Reporter: David Jencks Attachments: MYFACES-2995-FactoryFinderProvider-1.patch, MYFACES-2995.patch As discussed on dev list geronimo would like to explicitly mark component boundaries rather than relying on the TCCL changing. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
