[jira] [Comment Edited] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790094#comment-13790094 ] Anand V Nath edited comment on TRINIDAD-2406 at 10/9/13 6:58 AM: - Today we load the skins as part of the configurator initialization (GlobalConfiguratorImpl). The skins are loaded upfront and populate into SkinFactory. We cache the skins in SkinFactory and reload it, based on the skin state (DIRTY, READY, RELOADING) set on the SkinFactory. With SkinProvider we support skin repositories external to the skin framework. For each skin repository externally maintained, the user can register SkinProvider SPI. The registered SPI has the responsibility to manage the skins. SkinProvider API is designed based on the API SkinFactory currently exposes. Every time the SkinProvider is queried for a Skin, it can either reload the skin or return the cached skin. This is completely under the control of the SkinProvider implementation. SkinProvider also exposes a quick way to gather information of the Skins that it publishes, by means of SkinMetadata. SkinProvider should be able to provide this information without loading the Skins, thus supporting the idea of lazy loading. SkinProvider lazy loading concept. Currently all the queries to get a Skin lands up in SkinFactory. SkinFactory then returns the cached skin to the caller, or returns the reloaded skin (when required / dirtied). With SkinProvider, SkinProviderRegisry will be single point of entry to query any Skins defined in the system, either internal or external to skinning framework. SkinProviderRegistry keeps track of all the registered SkinProvider SPIs and supplies the skin requested by invoking each SkinProvider to find a matching Skin. For example: if SkinProviderRegistry receives request to load SkinA which is part of SkinProviderA and has the following heirarchy: SkinA - skyros - simple-desktop SkinProviderRegistry will go over the registered SPIs first and thus query SkinProviderA for SkinA. SkinProviderA will query SkinProviderRegistry for skyros skin since SkinA uses skyros as its base and this fact is known to SkinProviderA which manages SkinA. Thus a request for skyros will land on SkinProviderRegistry. SkinProviderRegistry again goes on its way of invoking the registered SPIs and Trinidad internal SPIs. Since skyros is internal skin the request lands up with the internal SkinProvider. Internal SkinProvider finds that skyros needs simple-desktop to be available, so the internal SkinProvider queries SkinProviderRegistry for simple-desktop. Since simple-desktop is the top most skin and does not have any parent skin, that gets loaded by internal SkinProvider. Once simple-desktop skin is loaded, skyros is loaded using that and so an so forth. If there is a request following this for another skin, say SkinB which has the following hierarchy: SkinB - skyros - simple-desktop then we do the same thing, but the difference is that internal base skins will be cached after it is loaded first time (while loading SkinA, in this case) by the internal SkinProvider implementation, and reloaded only if dirtied. With these changes SkinFactory becomes obsolete and will be deprecated. SkinProviderRegistry will ask SkinFactory if non of the SkinProvider implementations were able to return the required skin, and thus provide backward compatibility with those third party who is registering their skins using SkinFactory. Also SkinFactory will delegate the getSkin requests to SkinProviderRegistry as existing usecases are expecting trinidad skins and other base skins to be returned from SkinFactory. was (Author: anand.v.n...@oracle.com): Today we load the skins as part of the configurator initialization (GlobalConfiguratorImpl). The skins are loaded upfront and populate into SkinFactory. We cache the skins in SkinFactory and reload it, based on the skin state (DIRTY, READY, RELOADING) set on the SkinFactory. With SkinProvider we support skin repositories external to the skin framework. For each skin repository externally maintained, the user can register SkinProvider SPI. The registered SPI has the responsibility to manage the skins. SkinProvider API is designed based on the API SkinFactory currently exposes. Every time the SkinProvider is queried for a Skin, it can either reload the skin or return the cached skin. This is completely under the control of the SkinProvider implementation. SkinProvider also exposes a quick way to gather information of the Skins that it publishes, by means of SkinMetadata. SkinProvider should be able to provide this information without loading the Skins, thus supporting the idea of lazy loading. SkinProvider lazy loading concept. Currently all the queries to get a Skin lands up in SkinFactory. SkinFactory then returns the cached skin to the
[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790094#comment-13790094 ] Anand V Nath commented on TRINIDAD-2406: Today we load the skins as part of the configurator initialization (GlobalConfiguratorImpl). The skins are loaded upfront and populate into SkinFactory. We cache the skins in SkinFactory and reload it, based on the skin state (DIRTY, READY, RELOADING) set on the SkinFactory. With SkinProvider we support skin repositories external to the skin framework. For each skin repository externally maintained, the user can register SkinProvider SPI. The registered SPI has the responsibility to manage the skins. SkinProvider API is designed based on the API SkinFactory currently exposes. Every time the SkinProvider is queried for a Skin, it can either reload the skin or return the cached skin. This is completely under the control of the SkinProvider implementation. SkinProvider also exposes a quick way to gather information of the Skins that it publishes, by means of SkinMetadata. SkinProvider should be able to provide this information without loading the Skins, thus supporting the idea of lazy loading. SkinProvider lazy loading concept. Currently all the queries to get a Skin lands up in SkinFactory. SkinFactory then returns the cached skin to the caller, or returns the reloaded skin (when required / dirtied). With SkinProvider, SkinProviderRegisry will be single point of entry to query any Skins defined in the system, either internal or external to skinning framework. SkinProviderRegistry keeps track of all the registered SkinProvider SPIs and supplies the skin requested by invoking each SkinProvider to find a matching Skin. For example: if SkinProviderRegistry receives request to load SkinA which is part of SkinProviderA and has the following heirarchy: SkinA - skyros - simple-desktop SkinProviderRegistry will go over the registered SPIs first and thus query SkinProviderA for SkinA. SkinProviderA will query SkinProviderRegistry for skyros skin since SkinA uses skyros as its base and this fact is known to SkinProviderA which manages SkinA. Thus a request for skyros will land on SkinProviderRegistry. SkinProviderRegistry again goes on its way of invoking the registered SPIs and Trinidad internal SPIs. Since skyros is internal skin the request lands up with the internal SkinProvider. Internal SkinProvider finds that skyros needs simple-desktop to be available, so the internal SkinProvider queries SkinProviderRegistry for simple-desktop. Since simple-desktop is the top most skin and does not have any parent skin, that gets loaded by internal SkinProvider. Once simple-desktop skin is loaded, skyros is loaded using that and so an so forth. If there is a request following this for another skin, say SkinB which has the following hierarchy: SkinB - skyros - simple-desktop then we do the same thing, but the difference is that internal base skins will be cached after it is loaded first time (while loading SkinA, in this case) by the internal SkinProvider implementation, and reloaded only if dirtied. With these changes SkinFactory becomes obsolete and will be deprecated. SkinProviderRegistry will ask SkinFactory if non of the SkinProvider implementations were able to return the required skin, and thus provide backward compatibility with those third party who is registering their skins using SkinFactory. Also SkinFactory will delegate the getSkin requests to SkinProviderRegistry as existing usecases are expecting trinidad skins and other base skins to be returned from SkinFactory. We assume that there are no practical chances of collision in this approach and that no two SkinProvider will respond for the same Skin. This situation will be solved separately if and when it arises. externalize skin repositories by using SkinProvider SPI --- Key: TRINIDAD-2406 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework. Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match. Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml). Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available. Make SkinExtension part of public API so that users can use
[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[
https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790143#comment-13790143
]
Anand V Nath commented on TRINIDAD-2406:
API and internal changes for implementing this are:
1. Create an object to capture metadata about skin:
org.apache.myfaces.trinidad.skin.SkinMetadata
public final class SkinMetadata
{
SkinMetadata(id, family, renderKit, parentSkin, ... )
public String getBaseSkinId()
public String getId()
public String getFamily()
public String getRenderKit()
public SkinVersion getVersion()
public SkinFeatures getFeatures()
public CustomMetadata getMetadata()
public String getStyleSheetName()
public String getResourceBundleName()
public ValueExpression getTranslationSource()
}
Include a static inner builder class for:
org.apache.myfaces.trinidad.skin.SkinMetadata,
org.apache.myfaces.trinidad.skin.SkinMetadata.Builder for easy instantiation of
the SkinMetadata. Since we have too many parameters to be captured for
SkinMetadata, we use a builder.
public final class SkinMetadata {
private SkinMetadata(Builder b)
{
}
...
public static final class Builder
{
public Builder()
// setters for optional items
public Builder id(String id)
public Builder family(String family)
public Builder parent(String parent)
public Builder version(SkinVersion version)
public Builder styleSheetName(String styleSheetName)
public Builder resourceBundleName(String resourceBundleName)
public Builder translationSource(ValueExpression translationSource)
public Builder baseSkinId(String baseSkinId)
public Builder feature(SkinFeatures features)
public Builder metadata(CustomMetadata metadata)
// build method to create SkinMetadata object
public SkinMetadata build()
}
}
For example the client code would look like:
new
SkinMetadata.Builder().id(skinId).family(family).renderKitId(renderKitId).version(version).build();
2. Create org.apache.myfaces.trinidad.skin.SkinProvider SPI
public abstract class SkinProvider
{
/**
* Returns the Skin for the given skin ID.
*
* The returned skin is not cached by the framework and thus it
* is the responsibility of the provider to return the same instance
* of the skin should it desire so.
*/
public abstract Skin getSkin(FacesContext context, SkinMetadata metadata)
/**
* A provider can optionally return information about some or all of the
skins it provides.
* Typically this information is generated without loading the skins
* as this is a quick way to find out about the Skins in the provider and
also thereby
* supporting lazy loading of Skins.
* SkinMetadata for a Skin should contain only features and metadata that it
* explicitly supports. It should not contain the features and metadata that
* belongs only to its parent skins.
* @param context
* @return
*/
public CollectionSkinMetadata getSkinMetadata(FacesContext context)
{
return Collections.emptyList();
}
}
3. org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider extends
org.apache.myfaces.trinidad.skin.SkinProvider to abstract all common
functionality of trinidad internal providers.
public abstract class BaseSkinProvider extends SkinProvider
{
public Skin getSkin(FacesContext context, SkinMetadata skinMetadata)
{
// common implementation shared between the internal trinidad skin
providers.
}
public CollectionSkinMetadata getSkinMetadata(FacesContext context)
{
// common implementation shared between the internal trinidad skin
providers.
}
}
4. Implement
org.apache.myfaces.trinidadinternal.skin.provider.TrinidadBaseSkinProvider
extends BaseSkinProvider to load all trinidad base skins and to be consistent
with the SPI - This extracts logic from SkinUtils.registerBaseSkins
public final class TrinidadBaseSkinProvider extends BaseSkinProvider
{
// Implement the methods for handling all base trinidad skins currently
registered using SkinUtils.registerBaseSkins
}
5. Implement
org.apache.myfaces.trinidadinternal.skin.provider.TrinidadSkinProvider extends
BaseSkinProvider to read all the trinidad-skins.xml - This will consolidate
code from SkinUtils.registerSkinExtensions
public final class TrinidadSkinProvider extends BaseSkinProvider
{
// Implement the methods for handling all skins defined using
trinidad-skins.xml
// use this class as a wrapper on top on SkinFactory
// remove any pre caching done in SkinFactory
// load skins from SkinFactory only on need basis
public CollectionSkinMetadata getSkinMetadata()
{
// return the information inside trinidad-skins.xml
}
}
6. Implement
org.apache.myfaces.trinidadinternal.skin.provider.ExternalSkinProvider extends
[jira] [Comment Edited] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[
https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790143#comment-13790143
]
Anand V Nath edited comment on TRINIDAD-2406 at 10/9/13 7:56 AM:
-
API and internal changes for implementing this are:
1. Create an object to capture metadata about skin:
org.apache.myfaces.trinidad.skin.SkinMetadata
{code}
public final class SkinMetadata
{
SkinMetadata(id, family, renderKit, parentSkin, ... )
public String getBaseSkinId()
public String getId()
public String getFamily()
public String getRenderKit()
public SkinVersion getVersion()
public SkinFeatures getFeatures()
public CustomMetadata getMetadata()
public String getStyleSheetName()
public String getResourceBundleName()
public ValueExpression getTranslationSource()
}
{code}
Include a static inner builder class for:
org.apache.myfaces.trinidad.skin.SkinMetadata,
org.apache.myfaces.trinidad.skin.SkinMetadata.Builder for easy instantiation of
the SkinMetadata. Since we have too many parameters to be captured for
SkinMetadata, we use a builder.
{code}
public final class SkinMetadata {
private SkinMetadata(Builder b)
{
}
...
public static final class Builder
{
public Builder()
// setters for optional items
public Builder id(String id)
public Builder family(String family)
public Builder parent(String parent)
public Builder version(SkinVersion version)
public Builder styleSheetName(String styleSheetName)
public Builder resourceBundleName(String resourceBundleName)
public Builder translationSource(ValueExpression translationSource)
public Builder baseSkinId(String baseSkinId)
public Builder feature(SkinFeatures features)
public Builder metadata(CustomMetadata metadata)
// build method to create SkinMetadata object
public SkinMetadata build()
}
}
{code}
For example the client code would look like:
{code}
new
SkinMetadata.Builder().id(skinId).family(family).renderKitId(renderKitId).version(version).build();
{code}
2. Create org.apache.myfaces.trinidad.skin.SkinProvider SPI
{code}
public abstract class SkinProvider
{
/**
* Returns the Skin for the given skin ID.
*
* The returned skin is not cached by the framework and thus it
* is the responsibility of the provider to return the same instance
* of the skin should it desire so.
*/
public abstract Skin getSkin(FacesContext context, SkinMetadata metadata)
/**
* A provider can optionally return information about some or all of the
skins it provides.
* Typically this information is generated without loading the skins
* as this is a quick way to find out about the Skins in the provider and
also thereby
* supporting lazy loading of Skins.
* SkinMetadata for a Skin should contain only features and metadata that it
* explicitly supports. It should not contain the features and metadata that
* belongs only to its parent skins.
* @param context
* @return
*/
public CollectionSkinMetadata getSkinMetadata(FacesContext context)
{
return Collections.emptyList();
}
}
{code}
3. org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider extends
org.apache.myfaces.trinidad.skin.SkinProvider to abstract all common
functionality of trinidad internal providers.
{code}
public abstract class BaseSkinProvider extends SkinProvider
{
public Skin getSkin(FacesContext context, SkinMetadata skinMetadata)
{
// common implementation shared between the internal trinidad skin
providers.
}
public CollectionSkinMetadata getSkinMetadata(FacesContext context)
{
// common implementation shared between the internal trinidad skin
providers.
}
}
{code}
4. Implement
org.apache.myfaces.trinidadinternal.skin.provider.TrinidadBaseSkinProvider
extends BaseSkinProvider to load all trinidad base skins and to be consistent
with the SPI - This extracts logic from SkinUtils.registerBaseSkins
{code}
public final class TrinidadBaseSkinProvider extends BaseSkinProvider
{
// Implement the methods for handling all base trinidad skins currently
registered using SkinUtils.registerBaseSkins
}
{code}
5. Implement
org.apache.myfaces.trinidadinternal.skin.provider.TrinidadSkinProvider extends
BaseSkinProvider to read all the trinidad-skins.xml - This will consolidate
code from SkinUtils.registerSkinExtensions
{code}
public final class TrinidadSkinProvider extends BaseSkinProvider
{
// Implement the methods for handling all skins defined using
trinidad-skins.xml
// use this class as a wrapper on top on SkinFactory
// remove any pre caching done in SkinFactory
// load skins from SkinFactory only on need basis
public CollectionSkinMetadata getSkinMetadata()
{
// return the information inside
[jira] [Updated] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand V Nath updated TRINIDAD-2406: --- Status: Patch Available (was: Open) externalize skin repositories by using SkinProvider SPI --- Key: TRINIDAD-2406 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Attachments: er-skin-provider-review3.patch Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework. Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match. Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml). Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available. Make SkinExtension part of public API so that users can use this class to create the Skin objects which they expose through their SkinProvider SPIs -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[
https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790143#comment-13790143
]
Anand V Nath edited comment on TRINIDAD-2406 at 10/9/13 7:57 AM:
-
API and internal changes for implementing this are:
1. Create an object to capture metadata about skin:
org.apache.myfaces.trinidad.skin.SkinMetadata
{code}
public final class SkinMetadata
{
SkinMetadata(id, family, renderKit, parentSkin, ... )
public String getBaseSkinId()
public String getId()
public String getFamily()
public String getRenderKit()
public SkinVersion getVersion()
public SkinFeatures getFeatures()
public CustomMetadata getMetadata()
public String getStyleSheetName()
public String getResourceBundleName()
public ValueExpression getTranslationSource()
}
{code}
Include a static inner builder class for:
org.apache.myfaces.trinidad.skin.SkinMetadata,
org.apache.myfaces.trinidad.skin.SkinMetadata.Builder for easy instantiation of
the SkinMetadata. Since we have too many parameters to be captured for
SkinMetadata, we use a builder.
{code}
public final class SkinMetadata {
private SkinMetadata(Builder b)
{
}
...
public static final class Builder
{
public Builder()
// setters for optional items
public Builder id(String id)
public Builder family(String family)
public Builder parent(String parent)
public Builder version(SkinVersion version)
public Builder styleSheetName(String styleSheetName)
public Builder resourceBundleName(String resourceBundleName)
public Builder translationSource(ValueExpression translationSource)
public Builder baseSkinId(String baseSkinId)
public Builder feature(SkinFeatures features)
public Builder metadata(CustomMetadata metadata)
// build method to create SkinMetadata object
public SkinMetadata build()
}
}
{code}
For example the client code would look like:
{code}
new
SkinMetadata.Builder().id(skinId).family(family).renderKitId(renderKitId).version(version).build();
{code}
2. Create org.apache.myfaces.trinidad.skin.SkinProvider SPI
{code}
public abstract class SkinProvider
{
/**
* Returns the Skin for the given skin ID.
*
* The returned skin is not cached by the framework and thus it
* is the responsibility of the provider to return the same instance
* of the skin should it desire so.
*/
public abstract Skin getSkin(FacesContext context, SkinMetadata metadata)
/**
* A provider can optionally return information about some or all of the
skins it provides.
* Typically this information is generated without loading the skins
* as this is a quick way to find out about the Skins in the provider and
also thereby
* supporting lazy loading of Skins.
* SkinMetadata for a Skin should contain only features and metadata that it
* explicitly supports. It should not contain the features and metadata that
* belongs only to its parent skins.
* @param context
* @return
*/
public CollectionSkinMetadata getSkinMetadata(FacesContext context)
{
return Collections.emptyList();
}
}
{code}
3. org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider extends
org.apache.myfaces.trinidad.skin.SkinProvider to abstract all common
functionality of trinidad internal providers.
{code}
public abstract class BaseSkinProvider extends SkinProvider
{
public Skin getSkin(FacesContext context, SkinMetadata skinMetadata)
{
// common implementation shared between the internal trinidad skin
providers.
}
public CollectionSkinMetadata getSkinMetadata(FacesContext context)
{
// common implementation shared between the internal trinidad skin
providers.
}
}
{code}
4. Implement
org.apache.myfaces.trinidadinternal.skin.provider.TrinidadBaseSkinProvider
extends BaseSkinProvider to load all trinidad base skins and to be consistent
with the SPI - This extracts logic from SkinUtils.registerBaseSkins
{code}
public final class TrinidadBaseSkinProvider extends BaseSkinProvider
{
// Implement the methods for handling all base trinidad skins currently
registered using SkinUtils.registerBaseSkins
}
{code}
5. Implement
org.apache.myfaces.trinidadinternal.skin.provider.TrinidadSkinProvider extends
BaseSkinProvider to read all the trinidad-skins.xml - This will consolidate
code from SkinUtils.registerSkinExtensions
{code}
public final class TrinidadSkinProvider extends BaseSkinProvider
{
// Implement the methods for handling all skins defined using
trinidad-skins.xml
// use this class as a wrapper on top on SkinFactory
// remove any pre caching done in SkinFactory
// load skins from SkinFactory only on need basis
public CollectionSkinMetadata getSkinMetadata()
{
// return the information inside
[jira] [Resolved] (MYFACES-3801) Passthrough attributes does not require URI encoding like in writeURIAttribute
[ https://issues.apache.org/jira/browse/MYFACES-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3801. - Resolution: Fixed Fix Version/s: 2.2.0 Passthrough attributes does not require URI encoding like in writeURIAttribute -- Key: MYFACES-3801 URL: https://issues.apache.org/jira/browse/MYFACES-3801 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 In the renderkit javadoc of jsf 2.2 spec says this (Rendering Pass Through Attributes): ... The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute(). ... Note here it says attributes are rendered as if they were passed, instead say ... attributes are encoded and rendered as if Black box testing against RI shows that there is no URI encoding at all in this part, so in this case the best is do the same here. After all, it is resposibility of the one who set the passthrough attribute to do the proper encoding in cases when a URI is provided. There are some simple use cases like the one provided here: http://markmail.org/message/bpqolsarmnsakhl6 That shows that do any URI encoding here is not wanted. However, that does not means the attribute should not be encoded as other attributes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3802) CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation)
Martin Kočí created MYFACES-3802: Summary: CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation) Key: MYFACES-3802 URL: https://issues.apache.org/jira/browse/MYFACES-3802 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Martin Kočí Priority: Minor https://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/flow/cdi/FlowBuilderFactoryBean.java declares @javax.faces.bean.ApplicationScoped; but I think that should be javax.enterprise.context.ApplicationScoped (=CDI ApplicationScoped) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3802) CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation)
[ https://issues.apache.org/jira/browse/MYFACES-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kočí updated MYFACES-3802: - Status: Patch Available (was: Open) CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation) Key: MYFACES-3802 URL: https://issues.apache.org/jira/browse/MYFACES-3802 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Martin Kočí Priority: Minor Attachments: MYFACES-3802.patch https://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/flow/cdi/FlowBuilderFactoryBean.java declares @javax.faces.bean.ApplicationScoped; but I think that should be javax.enterprise.context.ApplicationScoped (=CDI ApplicationScoped) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790719#comment-13790719 ] Leonardo Uribe commented on MYFACES-3786: - This problem is not about CDI at all. Is about support of JavaEE 5 and 6 annotations, and that includes CDI too. In this case we need to track down not only JSF spec but JavaEE spec too. I have done some tests and now I have an idea how to fix it properly. It seems we need a CDI extension for this one, but only as a fallback in those cases where there is not a JavaEE server (for example, when you are using CDI and Tomcat or Jetty only). I'll start to work on a patch for this one, the trick with this one is how to assemble all pieces together. Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans) -- Key: MYFACES-3786 URL: https://issues.apache.org/jira/browse/MYFACES-3786 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, cdiValidator.war This issue is all about how to inject beans into jsf artifacts. See JSF 2.2 section 5.4.1 The problem here is in some point we need to give the control to the underlying environment to inject beans into the artifacts, but we don't know much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] Release Tobago 2.0.0-alpha-2
Hello, here is my +1 Regards Bernd On Mon, Oct 7, 2013 at 2:47 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: Hello, I would like to release Tobago 2.0.0-alpha-2. For a detail list please consult the release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273version=12324818 The version is available at the staging repository (Nexus). Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-136/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards, Udo
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790836#comment-13790836 ] Gerhard Petracek commented on MYFACES-3786: --- @dora: that isn't appropriate. you can't handle those artifacts the same way as it is done for MYFACES-3797. those dependent-scoped instances are bound to the application lifetime (and not the lifetime of a request). Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans) -- Key: MYFACES-3786 URL: https://issues.apache.org/jira/browse/MYFACES-3786 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, cdiValidator.war This issue is all about how to inject beans into jsf artifacts. See JSF 2.2 section 5.4.1 The problem here is in some point we need to give the control to the underlying environment to inject beans into the artifacts, but we don't know much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3802) CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation)
[ https://issues.apache.org/jira/browse/MYFACES-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790843#comment-13790843 ] Gerhard Petracek commented on MYFACES-3802: --- @martin: that's correct CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation) Key: MYFACES-3802 URL: https://issues.apache.org/jira/browse/MYFACES-3802 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Martin Kočí Priority: Minor Attachments: MYFACES-3802.patch https://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/flow/cdi/FlowBuilderFactoryBean.java declares @javax.faces.bean.ApplicationScoped; but I think that should be javax.enterprise.context.ApplicationScoped (=CDI ApplicationScoped) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3802) CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation)
[ https://issues.apache.org/jira/browse/MYFACES-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3802: Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Martin Koci for provide this patch CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation) Key: MYFACES-3802 URL: https://issues.apache.org/jira/browse/MYFACES-3802 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Martin Kočí Assignee: Leonardo Uribe Fix For: 2.2.0 Attachments: MYFACES-3802.patch https://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/flow/cdi/FlowBuilderFactoryBean.java declares @javax.faces.bean.ApplicationScoped; but I think that should be javax.enterprise.context.ApplicationScoped (=CDI ApplicationScoped) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13791143#comment-13791143
]
Leonardo Uribe commented on MYFACES-3786:
-
There is a confusion behind how CDI affects JSF artifacts. To be clear, JSF
artifacts are managed by JSF, not by CDI. Why? because in this case those
objects does are not bound to an specific scope inside CDI, and there is no
delegation of the instantiation process to CDI.
In that sense, the existing rules related to CDI beans like hold the
CreationalContext until destroy and so on does not apply. What we need here is
implement these 3 steps:
- Injection
- invoke PostConstruct methods
- invoke PreDestroy methods
There is already an SPI interface for that in JSF called LifecycleProvider. The
idea is we have an interface called LifecycleProvider2 with these methods:
Object newInstance(String className)
void postConstruct(Object o)
void destroyInstance(Object o)
This has worked well for a long time, and server vendors have usually a custom
implementation of this interface. This is used to handle servlet 2.5 annotation
in jsf managed beans (this is the clue left in JSF 2.2 spec section 5.4.1).
Unfortunately, LifecycleProvider2 was an interface added to fix an issue and to
avoid break things. As part of the cleanup for JSF 2.2 we need to provide a new
SPI interface for this point.
Taking into account the CDI InjectionTarget:
voidinject(T instance, CreationalContextT ctx)
voidpostConstruct(T instance)
voidpreDestroy(T instance)
I would like to add the following spi interface:
public abstract class org.apache.myfaces.spi.InjectionLifecycleProvider
{
public abstract Object createNewInstanceAndInject(String className) throws
InjectionLifecycleProviderException;
public abstract void inject(Object instance) throws
InjectionLifecycleProviderException;
public abstract void postConstruct(Object instance) throws
InjectionLifecycleProviderException;
public abstract void preDestroy(Object instance) throws
InjectionLifecycleProviderException;
}
Other model to keep in mind is the one used by Mojarra for the same case:
public interface InjectionProvider {
public void inject(Object managedBean) throws InjectionProviderException;
public void invokePreDestroy(Object managedBean) throws
InjectionProviderException;
public void invokePostConstruct(Object managedBean) throws
InjectionProviderException;
}
Basically the diffence against the implementation in Mojarra is the use of an
abstract class instead of a interface and the addition of a method
createNewInstanceAndInject(String className), which most of the time comes in
handy (and follows the old approach).
The default implementation theorically should just call existing
LifecycleProvider stuff, and try to use createNewInstanceAndInject(String
className) instead inject(...) as much as possible. The problem is there is a
chance we need the inject(...) method, so it is better to include it since
start.
Note CDI has something similar in order to work with the underlying web server,
so one option is use that integration, but in some cases that's not true (for
example if we are not in a JavaEE compliant server and CDI are added as a
library, we also need to deal with that logic).
I don't like very much the idea of provide a new spi InjectionLifecycleProvider
to do almost the same as LifecycleProvider2, but in this case really we don't
have choice. That's what we need to get it done right.
Web Container injection support should be provided for additional lifecycle
artifacts (not just managed beans)
--
Key: MYFACES-3786
URL: https://issues.apache.org/jira/browse/MYFACES-3786
Project: MyFaces Core
Issue Type: Task
Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: cdiELresolverWeb.zip, cdiELResolver.zip,
cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch,
cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip,
cdiValidator.war
This issue is all about how to inject beans into jsf artifacts.
See JSF 2.2 section 5.4.1
The problem here is in some point we need to give the control to the
underlying environment to inject beans into the artifacts, but we don't know
much about how to properly do it, so we need to try with examples.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13791143#comment-13791143
]
Leonardo Uribe edited comment on MYFACES-3786 at 10/10/13 3:27 AM:
---
There is a confusion behind how CDI affects JSF artifacts. To be clear, JSF
artifacts are managed by JSF, not by CDI. Why? because in this case those
objects are not bound to an specific scope inside CDI, and there is no
delegation of the instantiation process to CDI.
In that sense, the existing rules related to CDI beans like hold the
CreationalContext until destroy and so on does not apply. What we need here is
implement these 3 steps:
- Injection
- invoke PostConstruct methods
- invoke PreDestroy methods
There is already an SPI interface for that in JSF called LifecycleProvider. The
idea is we have an interface called LifecycleProvider2 with these methods:
Object newInstance(String className)
void postConstruct(Object o)
void destroyInstance(Object o)
This has worked well for a long time, and server vendors have usually a custom
implementation of this interface. This is used to handle servlet 2.5 annotation
in jsf managed beans (this is the clue left in JSF 2.2 spec section 5.4.1).
Unfortunately, LifecycleProvider2 was an interface added to fix an issue and to
avoid break things. As part of the cleanup for JSF 2.2 we need to provide a new
SPI interface for this point.
Taking into account the CDI InjectionTarget:
voidinject(T instance, CreationalContextT ctx)
voidpostConstruct(T instance)
voidpreDestroy(T instance)
I would like to add the following spi interface:
public abstract class org.apache.myfaces.spi.InjectionLifecycleProvider
{
public abstract Object createNewInstanceAndInject(String className) throws
InjectionLifecycleProviderException;
public abstract void inject(Object instance) throws
InjectionLifecycleProviderException;
public abstract void postConstruct(Object instance) throws
InjectionLifecycleProviderException;
public abstract void preDestroy(Object instance) throws
InjectionLifecycleProviderException;
}
Other model to keep in mind is the one used by Mojarra for the same case:
public interface InjectionProvider {
public void inject(Object managedBean) throws InjectionProviderException;
public void invokePreDestroy(Object managedBean) throws
InjectionProviderException;
public void invokePostConstruct(Object managedBean) throws
InjectionProviderException;
}
Basically the diffence against the implementation in Mojarra is the use of an
abstract class instead of a interface and the addition of a method
createNewInstanceAndInject(String className), which most of the time comes in
handy (and follows the old approach).
The default implementation theorically should just call existing
LifecycleProvider stuff, and try to use createNewInstanceAndInject(String
className) instead inject(...) as much as possible. The problem is there is a
chance we need the inject(...) method, so it is better to include it since
start.
Note CDI has something similar in order to work with the underlying web server,
so one option is use that integration, but in some cases that's not true (for
example if we are not in a JavaEE compliant server and CDI are added as a
library, we also need to deal with that logic).
I don't like very much the idea of provide a new spi InjectionLifecycleProvider
to do almost the same as LifecycleProvider2, but in this case really we don't
have choice. That's what we need to get it done right.
was (Author: lu4242):
There is a confusion behind how CDI affects JSF artifacts. To be clear, JSF
artifacts are managed by JSF, not by CDI. Why? because in this case those
objects does are not bound to an specific scope inside CDI, and there is no
delegation of the instantiation process to CDI.
In that sense, the existing rules related to CDI beans like hold the
CreationalContext until destroy and so on does not apply. What we need here is
implement these 3 steps:
- Injection
- invoke PostConstruct methods
- invoke PreDestroy methods
There is already an SPI interface for that in JSF called LifecycleProvider. The
idea is we have an interface called LifecycleProvider2 with these methods:
Object newInstance(String className)
void postConstruct(Object o)
void destroyInstance(Object o)
This has worked well for a long time, and server vendors have usually a custom
implementation of this interface. This is used to handle servlet 2.5 annotation
in jsf managed beans (this is the clue left in JSF 2.2 spec section 5.4.1).
Unfortunately, LifecycleProvider2 was an interface added to fix an issue and to
avoid break things. As part of the cleanup for JSF 2.2 we need to provide a new
SPI interface for this point.
Taking into account the CDI InjectionTarget:
voidinject(T instance, CreationalContextT
