from:"Gerhard Petracek \(JIRA\)"

[jira] [Resolved] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-10 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-317.
-
Resolution: Won't Fix

that's a known issue and should be fixed with wls 12.1.3 (and not a bug in 
codi).
at least apache deltaspike was tested with it.
it sounds like you are starting to use codi - in that case you should move to 
deltaspike (also this scope is ported to deltaspike already).
if you have to stick with wls 12.1.2, it won't be the last issue you will face 
(most blockers are fixed in 12.1.3 and tested with deltaspike).

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-10 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240874#comment-14240874
 ] 

Gerhard Petracek commented on EXTCDI-317:
-

afaik the patch for 12.1.3 was backported to 12.1.2. you have to ask them, if 
they provide it officially.
however, in any case i would upgrade to 12.1.3 asap.

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-05 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235407#comment-14235407
 ] 

Gerhard Petracek commented on EXTCDI-317:
-

please provide the concrete version of wls you are using.

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-05 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235407#comment-14235407
 ] 

Gerhard Petracek edited comment on EXTCDI-317 at 12/5/14 12:09 PM:
---

please try it with wls 12.1.3


was (Author: gpetracek):
please provide the concrete version of wls you are using.

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-19 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14140330#comment-14140330
]

Gerhard Petracek commented on EXTCDI-316:
-

please don't mix the view-scope (@ViewScoped) and the codi scopes (per window):
@WindowScoped, @ConversationScoped, @ViewAccessScoped.
the bridge for the view-scope just transforms a jsf-bean to a cdi bean and via
a PreDestroyViewMapEvent listener codi gets notified by the jsf-implementation
to destroy the corresponding cdi-beans. however, afair esp. mojarra used to
have issues with those events in the beginning - so i wouldn't use it before
ee7 (which supports that out-of-the-box and has to handle it internally).

#closeWindowContext is just a helper to do a full cleanup including the
component-tree. in deltaspike we don't have that any longer to keep it simpler.

@timeout:
yes and no - if the user-session gets closed (due to a timeout or manually) all
those codi-scoped beans get dropped as well.
however, there is e.g. also a window-timeout which is shorter than the
session-timeout (usually - see
WindowContextConfig#getWindowContextTimeoutInMinutes). in deltaspike we dropped
that as well - there you only have the session-timeout which destroys the
windows as well.

yes @WindowScoped (and WindowContext) can get to a session per browser-tab
easily. that is the use-case for it/them. therefore you have
@ConversationScoped and @ViewAccessScoped which are more fine-grained. using
@WindowScoped isn't that usual compared to the other two scopes (which are also
stored in the current window and therefore support the window-id implicitly -
see e.g.
https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-Scopes).
@WindowScoped helps e.g. if you like to store the nav.history per window or the
menu-state independent of the component-tree. WindowContext is just the storage
per window you (as user) usually don't need to touch manually. (you just need
it to handle your use-case with iframes.)

you could introduce a new url-parameter and add it on the client-side once you
replace the iframe-content there. something like oldWindowIdToDrop - just
destroy the window on the server-side via a phase-listener (or in your own
WindowHandler) once you detect your custom url-parameter.

Close window context view leakge - JSF 2.1 Multiple Iframes per page

Key: EXTCDI-316
URL: https://issues.apache.org/jira/browse/EXTCDI-316
Project: MyFaces CODI
Issue Type: Bug
Components: Core
Affects Versions: 1.0.3
Environment: Oracle GlassFish Server 3.1.2.5 (build 2), jdk1.6.0_45
Reporter: Nuno G. de M
Original Estimate: 72h
Remaining Estimate: 72h

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-18 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14138666#comment-14138666
]

Gerhard Petracek commented on EXTCDI-316:
-

no - that's the reason i didn't mention it (mojarra vs. myfaces-core).
codi is compatible with both and we know users with huge codi/jsf (with
mojarra) based projects.
leo just mentioned that myfaces-core is smarter when it comes to state-saving
and the chance is higher that you won't see (some of) the issues you saw with
mojarra caused by the usage of iframes.
e.g. once the fallback to WindowContextIdHolderComponent is used to resolve the
window-id, the proper handling depends on the quality of the state-saving
algorithm (provided by the jsf implementation).

once you call #close for the correct window manually, you don't see a leak in
codi.
however, since there is no jsf-api for it, codi can't trigger a cleanup of the
view-state.
jsf 2.2 introduced the window-concept (based on apis introduced by codi and
similar frameworks).
however, even with jsf 2.2, the jsf implementation is responsible for doing a
cleanup of the state internally (there is no explicit api for it).
the benefit for users is that the jsf implementation is aware of windows (as a
concept) and can do improvements (more easily) for handling the state in a
better way (but there is no specified rule for it).

@iframes:
it sounds like the major issue in your case is that you replace the content
of the iframe on the client-side.
a lot really depends on details of your implementation and maybe even on other
details like the used browser (you wouldn't belief how hard it is to support
something simple like the proper handling after open in new tab across the
major browsers).

Close window context view leakge - JSF 2.1 Multiple Iframes per page

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-17 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137035#comment-14137035
]

Gerhard Petracek commented on EXTCDI-316:
-

i'm not sure about all the details you have in your application.

if you need such manual manipulations (on the client-side), you have to ensure
(yourself) that those changes are recognized correctly (and immediately) on
the server-side. further hints for implementing a custom WindowHandler for your
setup are quite hard to provide without a (maven based) demo-app which
illustrates the details of your setup (and even then it won't be a easy task
since the std. cases for window-handling are quite complex already). some parts
you need should be in the wiki - e.g. see
https://cwiki.apache.org/confluence/display/EXTCDI/Alternative+Configuration#AlternativeConfiguration-Providingotheralternativeimplementations
the contract specified by WindowHandler is quite simple, however, a proper
implementation for your cases isn't an easy task.
imo you have to fix the state-saving issues first. otherwise you have almost no
chance to get a solid result.
(e.g. you would get issues with WindowContextIdHolderComponent and many other
topics).

Close window context view leakge - JSF 2.1 Multiple Iframes per page

Hi, and thank you for your support.
First, I would just like to stat that I am unsure if the issue detected in
our application is a real issue within CODI, or if it is we that are misusing
the framework. Therefore, I would be happy to get your input on the issue I
am about to detail.
ISSUE SUMMARY:
- we have a ui architecture comprised by several Iframes within a main page,
where each iframe has its own CODI window context. After several clicks
replacing the content that of a targetIfram by new content, we were having
CODI view context leakage as well as JSF view state leakage.
ISSUE DETAILS:
For historical as well performance reasons reasons, we have a UI that is
composed into several IFrames within a parent portal iframe. This decomposing
of the view into sub-views means the JSF context to serialize-deserialize per
iframe/.xhtml present in the UI is smaller. As opposed to a single big-ui
view state.
An overview of the core iframes invovled would be:
(1) window.top - Contains the Header and a left-side navigation menu
(2) window.top.contentIfram - Iframe Contains your typical page conent
(.xhtml)
(3) window.top.footer - iframe containing a dynamic footer (its own .xhtml)
(4) wintow.top.applet - Iframe that includes an applet
(5) window.top.special - an auxiliary .xhtml that complements the applet data
(6) window.top.clean - iframe that contains an .xhtml to do CODI window
context and JSF sever state cleanup (created to deal with the issue being
explained here)
The BUG in view navigation is the following:
Each time the user interacts with the UI, e.g by clicing on an menu command
button, or on a applet view element, prompting for a new .xhtml view to be
loaded and replace the old .xhtml loaded on a target iframe we leak both a
JSF and CODI window context.
Our steps are the following:
(1) we change the src of the iframe to point to the new view to be loaded
e.g iframe.src = 'urlTonewPageToBeLoaded.xhtml?requestViewParameters'
In this request we do not inclode the old windowId of the iframe being
replaced. Meaning codi will have to create a new view ID for this new page
load.
(2) We also trigger an ajax request to server to have the old codi window
context being closed.
Intially here did:
(2.1)WindowContext wContext =
windowContextManager.getWindowContext('windowIdToClose);
wContext.close()
It turns out that as we did these two steps we had two leakages.
After about 64 clicks on the applet, if we interatcted with views that the
applet had been loading we would have no issues. If we clicked on some of
the older views that had been loaded after the login and not interacted with
since then (e.g. the footer) we would have a view timeout exception.
This happened because with each new iframe.src='newView', CODI was not
cleaning up its window context map, namely the following line:
this.windowContextMap.remove(editableWindowContext.getId());
is not executed during a WindowContext.close().
So despite our class to close the window context, the map would continue to
hold the view just closed. After 64 clicks the view uffer of CODI would

[jira] [Resolved] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-17 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gerhard Petracek resolved EXTCDI-316.
-
Resolution: Won't Fix

reason:
we could just support such use-cases with a separated WindowHandler (like it's
done with ServerSideWindowHandler, ClientSideWindowHandler). however, an
implementation would depend a lot on the manipulation (and its details) used on
the client-side and therefore we can't provide a generic solution for it.

Close window context view leakge - JSF 2.1 Multiple Iframes per page

[jira] [Resolved] (EXTCDI-175) introduce @ViewParam annotation for page beans

2014-09-17 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-175.
-
Resolution: Won't Fix

 introduce @ViewParam annotation for page beans
 --

 Key: EXTCDI-175
 URL: https://issues.apache.org/jira/browse/EXTCDI-175
 Project: MyFaces CODI
  Issue Type: New Feature
Reporter: Mark Struberg

 When using the ViewConfig in CODI we not only get type safe navigation but 
 also know the 'connection' between views and their backing beans. We already 
 support annotations like @PreRenderView and likes for such beans. 
 We should also support the direct annotation of view parameters directly in 
 the backing beans.
 instead of declaring the view parameters in the xhtml:
 f:metadata
   f:viewParam id=versionParam name=version 
 value=#{backingbean.versionString} required=false/
   f:viewParam id=searchString name=s value=#{backingbean.searchString} 
 required=false/
 /f:metadata
 we can maybe use an annotation directly in the backing bean:
 @Named
 @RequestScoped
 public class Backingbean {
   @ViewParam(required=false, name=version)
   private String versionString;
   @ViewParam(required=false, name=s)
   private String searchString;
   @PreRenderView
   private void dosomeinit() {
   ...
   }
 }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-16 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136267#comment-14136267
]

Gerhard Petracek commented on EXTCDI-316:
-

#1 if your view-state leaks, it's the first indication that your approach is
just not correct for jsf.
#2 codi doesn't support multiple logical pages per physical page (per default).
however, you can provide your own approach with a custom
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.spi.WindowHandler
#3 the number of windows (per user-session) is restricted by
WindowContextConfig#getMaxWindowContextCount - per default 64 windows per
session are allowed. - the eldest window in the session gets closed to get a
free slot for the new window. you can change this default (just provide a
specialized WindowContextConfig or implement a custom
WindowContextQuotaHandler).

Close window context view leakge - JSF 2.1 Multiple Iframes per page

[jira] [Commented] (EXTVAL-161) ExtVal breaks JSF 2.2 ClientWindow support

2014-06-28 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046952#comment-14046952
 ] 

Gerhard Petracek commented on EXTVAL-161:
-

right now we don't have a version for 2.2.
as you said - there are some incompatible spec changes and therefore we need a 
separated version.

 ExtVal breaks JSF 2.2 ClientWindow support
 --

 Key: EXTVAL-161
 URL: https://issues.apache.org/jira/browse/EXTVAL-161
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.8
Reporter: Moritz Bechler
Assignee: Gerhard Petracek
Priority: Critical
 Attachments: EXTVAL-161.patch


 ExtValLifecycleWrapper implements a wrapper for Lifecycle and lacks the 
 attachWindow method. Therefore calls to attachWindow never get delegated. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014569#comment-14014569
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

i haven't tried it, however, you could try to use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTVAL-159.
-

Resolution: Won't Fix

primefaces is creating a renderer in a renderer.

see SelectOneMenuRenderer#getConvertedValue
calls
context.getRenderKit().getRenderer(javax.faces.SelectOne, 
javax.faces.Menu).getConvertedValue(...);

we could only fix that by inspecting the callstack (in 
ExtValRenderKit#createWrapper) which introduces an overhead. since both 
(primefaces as well as extval) are using tricks, one side needs to improve it. 
please reopen this ticket, if they can't change it.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014603#comment-14014603
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

basically you can use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.
due to the constellation in primefaces it won't work as it is.
in UniqueFacesMessageStorage#isUnique you need an additional check against 
FacesContext.getCurrentInstance().getMessageList().

add e.g.:
{code}
//...
if (result)
{
for(FacesMessage currentMessage : 
FacesContext.getCurrentInstance().getMessageList())
{
if (isSame(currentMessage, facesMessage)
{
return false;
}
}
   }
return result;
}
{code}

with that you still have the duplicated validation, but only one message.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014603#comment-14014603
 ] 

Gerhard Petracek edited comment on EXTVAL-159 at 5/31/14 10:52 AM:
---

basically you can use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.
due to the constellation in primefaces it won't work as it is.
in UniqueFacesMessageStorage#isUnique you need an additional check against 
FacesContext.getCurrentInstance().getMessageList().

add e.g.:
{code}
//...
if (result)
{
for(FacesMessage currentMessage : 
FacesContext.getCurrentInstance().getMessageList())
{
if (isSame(currentMessage, facesMessage)
{
return false;
}
}
}
return result;
}
{code}

with that you still have the duplicated validation, but only one message.


was (Author: gpetracek):
basically you can use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.
due to the constellation in primefaces it won't work as it is.
in UniqueFacesMessageStorage#isUnique you need an additional check against 
FacesContext.getCurrentInstance().getMessageList().

add e.g.:
{code}
//...
if (result)
{
for(FacesMessage currentMessage : 
FacesContext.getCurrentInstance().getMessageList())
{
if (isSame(currentMessage, facesMessage)
{
return false;
}
}
   }
return result;
}
{code}

with that you still have the duplicated validation, but only one message.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014604#comment-14014604
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

changed to minor since there is a workaround and the issue isn't caused by 
extval only.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
Priority: Minor
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTVAL-127) Support for noSelectionOption on selectItem (JSF 2.0)

2014-05-31 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTVAL-127.
-

   Resolution: Fixed
Fix Version/s: 2.0.7

i just saw a working demo with it. please reopen the issue, if you have issues 
with it.

 Support for noSelectionOption on selectItem (JSF 2.0)
 -

 Key: EXTVAL-127
 URL: https://issues.apache.org/jira/browse/EXTVAL-127
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Bean Validation, Property Validation
Affects Versions: 2.0.4
Reporter: Rudy De Busscher
Assignee: Rudy De Busscher
Priority: Minor
 Fix For: 2.0.7


 With JSF 2.0, there is a new attribute noSelectionOption available on 
 f:selectItem tag.  When the attribute value evaluates to true and the 
 selectXXXmenu is required, selecting this item should results in a validation 
 error.
 See for example JSF 2.0 javadoc spec, UISelectOne#validateValue



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTVAL-127) Support for noSelectionOption on selectItem (JSF 2.0)

2014-05-31 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTVAL-127.
-

Resolution: Not a Problem

 Support for noSelectionOption on selectItem (JSF 2.0)
 -

 Key: EXTVAL-127
 URL: https://issues.apache.org/jira/browse/EXTVAL-127
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Bean Validation, Property Validation
Affects Versions: 2.0.4
Reporter: Rudy De Busscher
Assignee: Rudy De Busscher
Priority: Minor

 With JSF 2.0, there is a new attribute noSelectionOption available on 
 f:selectItem tag.  When the attribute value evaluates to true and the 
 selectXXXmenu is required, selecting this item should results in a validation 
 error.
 See for example JSF 2.0 javadoc spec, UISelectOne#validateValue



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (EXTVAL-127) Support for noSelectionOption on selectItem (JSF 2.0)

2014-05-31 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek reopened EXTVAL-127:
-


 Support for noSelectionOption on selectItem (JSF 2.0)
 -

 Key: EXTVAL-127
 URL: https://issues.apache.org/jira/browse/EXTVAL-127
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Bean Validation, Property Validation
Affects Versions: 2.0.4
Reporter: Rudy De Busscher
Assignee: Rudy De Busscher
Priority: Minor

 With JSF 2.0, there is a new attribute noSelectionOption available on 
 f:selectItem tag.  When the attribute value evaluates to true and the 
 selectXXXmenu is required, selecting this item should results in a validation 
 error.
 See for example JSF 2.0 javadoc spec, UISelectOne#validateValue



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-26 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14008669#comment-14008669
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

ok - if you have a demo-application which illustrates the issue, it would be 
great if you attach it here.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek

 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (EXTVAL-160) update notice files

2014-05-25 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTVAL-160:
---

 Summary: update notice files
 Key: EXTVAL-160
 URL: https://issues.apache.org/jira/browse/EXTVAL-160
 Project: MyFaces Extensions Validator
  Issue Type: Task
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTVAL-160) update notice files

2014-05-25 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTVAL-160.
-

   Resolution: Fixed
Fix Version/s: 2.0.8

 update notice files
 ---

 Key: EXTVAL-160
 URL: https://issues.apache.org/jira/browse/EXTVAL-160
 Project: MyFaces Extensions Validator
  Issue Type: Task
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 2.0.8






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-25 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14008375#comment-14008375
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

please provide more information about it. e.g. if it also happens with other 
input-components from primefaces.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer

 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (MYFACESTEST-70) customizable ClassLoader

2014-05-19 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACESTEST-70:
---

 Summary: customizable ClassLoader
 Key: MYFACESTEST-70
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-70
 Project: MyFaces Test
  Issue Type: Improvement
Affects Versions: 1.0.6
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


per default 
 - AbstractJsfTestContainer
 - AbstractMyFacesTestCase
 - AbstractJsfTestContainer
 - AbstractMyFacesTestCase
use URLClassLoader which causes issues with other libs.

we should extract that part (protected method...) - if needed, it's possible 
to customize the active ClassLoader.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTVAL-156) Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor

2014-04-07 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTVAL-156.
-

Resolution: Fixed

 Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor
 

 Key: EXTVAL-156
 URL: https://issues.apache.org/jira/browse/EXTVAL-156
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Alexey Shakov
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-156_first_step.patch, 
 EXTVAL-156_second_step.patch, EXTVAL-156_third_step.patch


 Following use case does not work:
   h:selectOneMenu ...
 f:ajax event=change render=main 
 listener=#{bean.bypassValidation} execute=@form /
   /h:selectOneMenu
 where bean.bypassValidation is defined as:
 @SkipConstraintValidation
 public String bypassValidation() {
 return success;
 }
 @SkipConstraintValidation is not evaluated in this case:  onchange-event 
 forces all form fields to be validated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTVAL-155) Re-implement @BypassValidation for EXTVAL 2.x

2014-04-07 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTVAL-155.
-

Resolution: Fixed

 Re-implement @BypassValidation for EXTVAL 2.x
 -

 Key: EXTVAL-155
 URL: https://issues.apache.org/jira/browse/EXTVAL-155
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Core
Reporter: Alexey Shakov
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-155.patch


 bypass add-on (which defines @BypassValidation) is not compatible with EXTVAL 
 2.x. 
 Please re-implement it (if possible, than integrate in EXTVAL)
 see also 
 http://mail-archives.apache.org/mod_mbox/myfaces-users/201311.mbox/%3CCAGJtJfH10ZypWbhcc%2ByW0_1WYHochiNHqrYS9%3DsN%2BJY%2BnPvudw%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (MYFACES-3878) ViewHandlerWrapper is broken

2014-04-03 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3878:
-

 Summary: ViewHandlerWrapper is broken
 Key: MYFACES-3878
 URL: https://issues.apache.org/jira/browse/MYFACES-3878
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.2
Reporter: Gerhard Petracek
Priority: Blocker


ViewHandlerWrapper doesn't contain the new methods
addProtectedView, removeProtectedView, getProtectedViewsUnmodifiable



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTVAL-158) improve ProxyHelper

2014-03-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTVAL-158.
-

   Resolution: Fixed
Fix Version/s: 2.0.8

 improve ProxyHelper
 ---

 Key: EXTVAL-158
 URL: https://issues.apache.org/jira/browse/EXTVAL-158
 Project: MyFaces Extensions Validator
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-158.patch






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (EXTVAL-158) improve ProxyHelper

2014-03-27 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTVAL-158:
---

 Summary: improve ProxyHelper
 Key: EXTVAL-158
 URL: https://issues.apache.org/jira/browse/EXTVAL-158
 Project: MyFaces Extensions Validator
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Attachments: EXTVAL-158.patch





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (EXTCDI-315) merge back DELTASPIKE-546

2014-03-24 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-315:
---

 Summary: merge back DELTASPIKE-546
 Key: EXTCDI-315
 URL: https://issues.apache.org/jira/browse/EXTCDI-315
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.6
Reporter: Rafael
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTCDI-315) merge back DELTASPIKE-546

2014-03-24 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-315.
-

   Resolution: Fixed
Fix Version/s: 1.0.7

 merge back DELTASPIKE-546
 -

 Key: EXTCDI-315
 URL: https://issues.apache.org/jira/browse/EXTCDI-315
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.6
Reporter: Rafael
Assignee: Gerhard Petracek
 Fix For: 1.0.7






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (EXTCDI-308) EAR support for Websphere 8

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-308.
-

Resolution: Fixed

 EAR support for Websphere 8
 ---

 Key: EXTCDI-308
 URL: https://issues.apache.org/jira/browse/EXTCDI-308
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: gonzalad
 Fix For: 1.0.6


 When codi-bundle is packaged in EAR, I get the following exception [1] on 
 application startup on Websphere 8.0.0.4.
 It seems package level access is not supported for CDI bean classes or CDI 
 bean methods on WAS 8.0.0.4.
 [1]
 {code}
 [3/26/13 16:52:53:494 CET] 00bc
 webappE
 com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet
 Error]-[Faces Servlet]: java.lang.RuntimeException: by
 java.lang.IllegalAccessError:
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
 at
 javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509)
 at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486)
 at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422)
 at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394)
 {code}
 See also 
 http://mail-archives.apache.org/mod_mbox/myfaces-users/201303.mbox/%3c1364314920.26443.yahoomail...@web172405.mail.ir2.yahoo.com%3E.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-307) EAR support for JBoss 7

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-307.
-

Resolution: Won't Fix

please test the phase-listener handling with deltaspike

 EAR support for JBoss 7
 ---

 Key: EXTCDI-307
 URL: https://issues.apache.org/jira/browse/EXTCDI-307
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: gonzalad

 @ViewAccessScoped is not working when deploying an EAR on JBoss 7.1.0 (tested 
 it with 7.1.3
 same result).
 The @ViewAccessScoped bean is reinstantiated each time we call a page (even 
 if it's the same page as the previous one).
 See 
  * 
 http://mail-archives.apache.org/mod_mbox/myfaces-users/201303.mbox/%3c1363791901.52665.yahoomail...@web172402.mail.ir2.yahoo.com%3E



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-309) look for phase listeners in parent classloader too

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-309.
-

Resolution: Won't Fix

it's just a minor feature. it's always possible to use a std. phase-listener.

 look for phase listeners in parent classloader too
 --

 Key: EXTCDI-309
 URL: https://issues.apache.org/jira/browse/EXTCDI-309
 Project: MyFaces CODI
  Issue Type: Improvement
Reporter: Romain Manni-Bucau

 In ear phaselisteners can be in lib part of the ear too so in 
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.PhaseListenerExtension#consumePhaseListeners
  the phaselisteners should be looked up from parent loader too (if 
 (classloader != systemLoader) ...)
 It is underspecified but it doesn't work in tomee for instance



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-230) Tobago Support Module for CODI

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-230.
-

Resolution: Won't Fix

afaik it isn't needed any longer

 Tobago Support Module for CODI
 --

 Key: EXTCDI-230
 URL: https://issues.apache.org/jira/browse/EXTCDI-230
 Project: MyFaces CODI
  Issue Type: Wish
Reporter: Bernd Bohmann
Priority: Minor

 It would be nice to have a Tobago Support Module for CODI. This module should 
 provide a solution for adding the WindowContextIdHolderComponent without 
 intercepting the ResponseWriter.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-224) Support REQUIRES_NEW and other javax.ejb.TransactionAttributeTypes in our @Transactional

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-224.
-

Resolution: Won't Fix

 Support REQUIRES_NEW and other javax.ejb.TransactionAttributeTypes in our 
 @Transactional
 

 Key: EXTCDI-224
 URL: https://issues.apache.org/jira/browse/EXTCDI-224
 Project: MyFaces CODI
  Issue Type: New Feature
  Components: JEE-JPA1-Module
Affects Versions: 1.0.1
Reporter: Mark Struberg
Assignee: Mark Struberg

 We currently have the REQUIRED behaviour as default for our @Transactional 
 interceptor. 
 Imo we should _not_ import the javax.ejb.TransactionAttributeType to not add 
 any additional dependency, but we should stay very close to it.
 I intend to implement the following TransactionAttributeTypes:
 * REQUIRED (as default)
 * REQUIRES_NEW
 * NEVER
 * SUPPORTS
 * MANDATORY
 not sure about the other ones
 A good overview can be found in OpenEJB: 
 http://openejb.apache.org/3.0/transaction-annotations.html



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-245) update bundle configs

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-245.
-

Resolution: Won't Fix

 update bundle configs
 -

 Key: EXTCDI-245
 URL: https://issues.apache.org/jira/browse/EXTCDI-245
 Project: MyFaces CODI
  Issue Type: Task
Affects Versions: 1.0.1
Reporter: Gerhard Petracek
Assignee: Mark Struberg





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-306) lightweight dialogs aren't supported by default

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-306.
-

Resolution: Won't Fix

 lightweight dialogs aren't supported by default
 ---

 Key: EXTCDI-306
 URL: https://issues.apache.org/jira/browse/EXTCDI-306
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Trinidad Support
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Priority: Minor

 workaround: disable parts only needed by alternative window-handlers



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-282) interceptors should support lifecycle-callbacks

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-282.
-

Resolution: Won't Fix

 interceptors should support lifecycle-callbacks
 ---

 Key: EXTCDI-282
 URL: https://issues.apache.org/jira/browse/EXTCDI-282
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JPA1-Module, JEE-JSF12-Module, JEE-JSF20-Module
Reporter: Gerhard Petracek
Priority: Minor

 important restrictions are analyzed at:
 http://blog.dblevins.com/2010/09/ejbnext-interceptor-improvements-method.html
 workaround (- minor issue):
 implementation of a custom interceptor binding
 - inject the corresponding InterceptorStrategy and delegate to it.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-297) merge back DELTASPIKE-212

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-297.
-

Resolution: Fixed

 merge back DELTASPIKE-212
 -

 Key: EXTCDI-297
 URL: https://issues.apache.org/jira/browse/EXTCDI-297
 Project: MyFaces CODI
  Issue Type: Task
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-295) merge back DELTASPIKE-175

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-295.
-

Resolution: Won't Fix

 merge back DELTASPIKE-175
 -

 Key: EXTCDI-295
 URL: https://issues.apache.org/jira/browse/EXTCDI-295
 Project: MyFaces CODI
  Issue Type: Task
  Components: JEE-JPA1-Module
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-281) merge back DELTASPIKE-67

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-281.
-

Resolution: Won't Fix

 merge back DELTASPIKE-67
 

 Key: EXTCDI-281
 URL: https://issues.apache.org/jira/browse/EXTCDI-281
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Priority: Trivial





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-294) merge back DELTASPIKE-191

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-294.
-

   Resolution: Won't Fix
Fix Version/s: (was: 1.0.6)

 merge back DELTASPIKE-191
 -

 Key: EXTCDI-294
 URL: https://issues.apache.org/jira/browse/EXTCDI-294
 Project: MyFaces CODI
  Issue Type: Task
  Components: Core
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-235) add javadoc to DefaultWindowContextManager#closeAllWindowContexts

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-235.
-

Resolution: Won't Fix

 add javadoc to DefaultWindowContextManager#closeAllWindowContexts
 -

 Key: EXTCDI-235
 URL: https://issues.apache.org/jira/browse/EXTCDI-235
 Project: MyFaces CODI
  Issue Type: Task
  Components: JEE-JSF12-Module, JEE-JSF20-Module
Affects Versions: 1.0.2
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Priority: Trivial

 esp. the difference to WindowContext#close (see e.g. attributes.clear())



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-283) support for multiple entity-managers

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-283.
-

Resolution: Won't Fix

 support for multiple entity-managers
 

 Key: EXTCDI-283
 URL: https://issues.apache.org/jira/browse/EXTCDI-283
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JPA1-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek

 the default PersistenceStrategy should use the injected entity-manager/s - 
 no qualifier is needed for @Transactional and multiple entity-managers per 
 transactional bean(-method) are supported - only a manual lookup of an 
 entity-manager won't work



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-251) support @javax.decorator.Delegate in ConfiguredArtifactUtils#findInjectionPointForDefaultImplementation

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-251.
-

Resolution: Won't Fix

 support @javax.decorator.Delegate in 
 ConfiguredArtifactUtils#findInjectionPointForDefaultImplementation
 ---

 Key: EXTCDI-251
 URL: https://issues.apache.org/jira/browse/EXTCDI-251
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.2
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Priority: Minor





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-314) preparations for v1.0.6

2014-02-28 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-314:
---

 Summary: preparations for v1.0.6
 Key: EXTCDI-314
 URL: https://issues.apache.org/jira/browse/EXTCDI-314
 Project: MyFaces CODI
  Issue Type: Task
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-314) preparations for v1.0.6

2014-02-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-314.
-

   Resolution: Fixed
Fix Version/s: 1.0.6

 preparations for v1.0.6
 ---

 Key: EXTCDI-314
 URL: https://issues.apache.org/jira/browse/EXTCDI-314
 Project: MyFaces CODI
  Issue Type: Task
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (MYFACESTEST-66) pre-configured containers

2014-02-05 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACESTEST-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved MYFACESTEST-66.
-

   Resolution: Fixed
Fix Version/s: 1.0.6-SNAPSHOT

 pre-configured containers
 -

 Key: MYFACESTEST-66
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-66
 Project: MyFaces Test
  Issue Type: New Feature
  Components: Mock Objects
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe
 Fix For: 1.0.6-SNAPSHOT


 currently other frameworks like deltaspike have to use mocked containers for 
 every version of jsf (one example can be found at 
 https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob;f=deltaspike/modules/test-control/impl/src/main/java/org/apache/deltaspike/testcontrol/impl/jsf/MockedJsf2TestContainer.java;h=e6e2b2bec6cf443c141035643cb5816e1118e6d6;hb=HEAD
  ). in a lot of cases it's just required to have a simple control over the 
 mocked container (methods like #addConfigEntry, #boot, #shutdown, 
 #activateView, #startScope, #stopScope). those methods are independent of the 
 jsf-api. - if every new version of myfaces-test provides a correctly mocked 
 container with such independent methods, frameworks like deltaspike could 
 delegate to it (instead of hosting a correctly mocked container for every 
 version of the jsf-api).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (MYFACES-3851) replace listener-config

2014-01-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACES-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated MYFACES-3851:
--

Status: Patch Available  (was: Open)

 replace listener-config
 ---

 Key: MYFACES-3851
 URL: https://issues.apache.org/jira/browse/MYFACES-3851
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
 Attachments: MYFACES-3851.patch


 tld - web-fragment.xml
 users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
 listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (MYFACES-3851) replace listener-config

2014-01-28 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3851:
-

 Summary: replace listener-config
 Key: MYFACES-3851
 URL: https://issues.apache.org/jira/browse/MYFACES-3851
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
 Attachments: MYFACES-3851.patch

tld - web-fragment.xml

users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (MYFACES-3844) move StartupServletContextListener config to web-fragment.xml

2014-01-18 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3844:
-

 Summary: move StartupServletContextListener config to 
web-fragment.xml
 Key: MYFACES-3844
 URL: https://issues.apache.org/jira/browse/MYFACES-3844
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-313) ee7 support

2014-01-13 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-313:
---

 Summary: ee7 support
 Key: EXTCDI-313
 URL: https://issues.apache.org/jira/browse/EXTCDI-313
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core, JEE-BV1-Module, JEE-JSF12-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-313) ee7 support

2014-01-13 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-313.
-

Resolution: Fixed

tested with GF4

 ee7 support
 ---

 Key: EXTCDI-313
 URL: https://issues.apache.org/jira/browse/EXTCDI-313
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core, JEE-BV1-Module, JEE-JSF12-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (MYFACESTEST-66) preconfigred containers

2014-01-08 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACESTEST-66:
---

 Summary: preconfigred containers
 Key: MYFACESTEST-66
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-66
 Project: MyFaces Test
  Issue Type: New Feature
  Components: Mock Objects
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


currently other frameworks like deltaspike have to use mocked containers for 
every version of jsf (one example can be found at 
https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob;f=deltaspike/modules/test-control/impl/src/main/java/org/apache/deltaspike/testcontrol/impl/jsf/MockedJsf2TestContainer.java;h=e6e2b2bec6cf443c141035643cb5816e1118e6d6;hb=HEAD
 ). in a lot of cases it's just required to have a simple control over the 
mocked container (methods like #addConfigEntry, #boot, #shutdown, 
#activateView, #startScope, #stopScope). those methods are independent of the 
jsf-api. - if every new version of myfaces-test provides a correctly mocked 
container with such independent methods, frameworks like deltaspike could 
delegate to it (instead of hosting a correctly mocked container for every 
version of the jsf-api).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-312) support for weld 2.0.x

2014-01-07 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-312:
---

 Summary: support for weld 2.0.x
 Key: EXTCDI-312
 URL: https://issues.apache.org/jira/browse/EXTCDI-312
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JSF12-Module, JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek


in case of weld 1.x and 2.1.x instances of type 
javax.enterprise.context.spi.Contextual also implement 
javax.enterprise.inject.spi.Bean. however, that isn't the case with weld 2.0.x.
- we can backport the workaround used in deltaspike.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-312) support for weld 2.0.x

2014-01-07 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-312.
-

   Resolution: Fixed
Fix Version/s: 1.0.6

 support for weld 2.0.x
 --

 Key: EXTCDI-312
 URL: https://issues.apache.org/jira/browse/EXTCDI-312
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JSF12-Module, JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6


 in case of weld 1.x and 2.1.x instances of type 
 javax.enterprise.context.spi.Contextual also implement 
 javax.enterprise.inject.spi.Bean. however, that isn't the case with weld 
 2.0.x.
 - we can backport the workaround used in deltaspike.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-311) merge back DELTASPIKE-471

2013-12-17 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-311:
---

 Summary: merge back DELTASPIKE-471
 Key: EXTCDI-311
 URL: https://issues.apache.org/jira/browse/EXTCDI-311
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Resolved] (EXTCDI-311) merge back DELTASPIKE-471

2013-12-17 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTCDI-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek resolved EXTCDI-311.
-

   Resolution: Fixed
Fix Version/s: 1.0.6

 merge back DELTASPIKE-471
 -

 Key: EXTCDI-311
 URL: https://issues.apache.org/jira/browse/EXTCDI-311
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (EXTVAL-156) Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor

2013-11-21 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/EXTVAL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated EXTVAL-156:


Status: Patch Available  (was: Open)

 Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor
 

 Key: EXTVAL-156
 URL: https://issues.apache.org/jira/browse/EXTVAL-156
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Alexey Shakov
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-156_first_step.patch


 Following use case does not work:
   h:selectOneMenu ...
 f:ajax event=change render=main 
 listener=#{bean.bypassValidation} execute=@form /
   /h:selectOneMenu
 where bean.bypassValidation is defined as:
 @SkipConstraintValidation
 public String bypassValidation() {
 return success;
 }
 @SkipConstraintValidation is not evaluated in this case:  onchange-event 
 forces all form fields to be validated.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-04 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812762#comment-13812762
]

Gerhard Petracek commented on MYFACES-3816:
---

@dora:
that wasn't the topic. without an initial redirect or including the window-id
in ajax-requests and/or rewriting the url via js, users get unexpected issues
even after the second request (if you only use ajax-requests until a
browser-refresh).

if we would get issues with the tck, we could still do #2 and #3.

i never said that a redirect is the only choice we have.
(it just has less unexpected effects, esp. if you have special logic in your
application.)

missing window-handling for initial requests

Key: MYFACES-3816
URL: https://issues.apache.org/jira/browse/MYFACES-3816
Project: MyFaces Core
Issue Type: Bug
Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

for an initial request there is no window-id added to the url.
(tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
- in case of a page refresh a new window-id will be created and it isn't
possible to get back the original one. that can also happen with a
page-refresh after multiple requests, if only ajax requests are used.
that's a major issue for all scopes based on the window-id.
it can be done with an initial redirect (default in codi) or js (with html5
compliant browsers)

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-04 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812775#comment-13812775
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

that's a completely different story.
an initial redirect (to the same url+window-id) would happen even before the 
jsf-request-lifecycle starts (after Lifecycle#attachWindow and before 
Lifecycle#execute).

a std. redirect-url should always contain the window-id.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-04 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812787#comment-13812787
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

that's a different topic. server-side state-saving uses the window-id as 
additional information to find the correct state.
- server-side state-saving is influenced/improved by the window-handling and 
not the other way round.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3816) missing window-handling for initial requests

2013-11-04 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812762#comment-13812762
]

Gerhard Petracek edited comment on MYFACES-3816 at 11/4/13 1:03 PM:

@dora:
that wasn't the topic. without an initial redirect or rewriting the url via js,
users get unexpected issues even after the second request (if you only use
ajax-requests until a browser-refresh).

if we would get issues with the tck, we could still do #2.

i never said that a redirect is the only choice we have.
(it just has less unexpected effects, esp. if you have special logic in your
application.)

was (Author: gpetracek):
@dora:
that wasn't the topic. without an initial redirect or including the window-id
in ajax-requests and/or rewriting the url via js, users get unexpected issues
even after the second request (if you only use ajax-requests until a
browser-refresh).

if we would get issues with the tck, we could still do #2 and #3.

i never said that a redirect is the only choice we have.
(it just has less unexpected effects, esp. if you have special logic in your
application.)

missing window-handling for initial requests

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3816) missing window-handling for initial requests

2013-11-04 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812762#comment-13812762
]

Gerhard Petracek edited comment on MYFACES-3816 at 11/4/13 1:05 PM:

if we would get issues with the tck, we could still do #2.

i never said that a redirect is the only choice we have.
(it just has less unexpected effects, esp. if you have special logic in your
application. furthermore, it doesn't require html5 compliant browsers.)

was (Author: gpetracek):
@dora:
that wasn't the topic. without an initial redirect or rewriting the url via js,
users get unexpected issues even after the second request (if you only use
ajax-requests until a browser-refresh).

if we would get issues with the tck, we could still do #2.

i never said that a redirect is the only choice we have.
(it just has less unexpected effects, esp. if you have special logic in your
application.)

missing window-handling for initial requests

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3816:
-

 Summary: missing window-handling for initial requests
 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


for an initial request there is no window-id added to the url.
(tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
- in case of a page refresh a new window-id will be created and it isn't 
possible to get back the original one. that can also happen with a page-refresh 
after multiple requests, if only ajax requests are used.

that's a major issue for all scopes based on the window-id.

it can be done with an initial redirect (default in codi) or js (with html5 
compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812396#comment-13812396
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

#1 broken in mojarra doesn't mean that we have to repeat the same mistake
#2 the client-mode is something different and has a higher impact on 
applications

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812396#comment-13812396
 ] 

Gerhard Petracek edited comment on MYFACES-3816 at 11/3/13 3:29 PM:


#1 broken in mojarra doesn't mean that we have to repeat the same mistake
#2 the client-mode is something different and has a higher impact on 
applications
#3 it would be better to provide an useful std. mode and only for special cases 
one without a redirect (that's what we did in codi and there were not a lot of 
users who deactivated it)


was (Author: gpetracek):
#1 broken in mojarra doesn't mean that we have to repeat the same mistake
#2 the client-mode is something different and has a higher impact on 
applications

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812401#comment-13812401
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

no - it's just broken. if you enter information via ajax requests and press 
refresh afterwards, everything you entered is lost.
codi is fine - see WindowContextManagerObserver#processGetRequest

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812406#comment-13812406
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

there is nothing in the spec./javadoc which mandates that we aren't allowed to 
do it correctly. if no window-id was found, it is required to create a new id. 
but there is no statement (or restriction) about the steps afterwards.

that can't be an issue with compatibility - otherwise we would have to 
implement all other mojarra issues as well.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812406#comment-13812406
 ] 

Gerhard Petracek edited comment on MYFACES-3816 at 11/3/13 4:06 PM:


there is nothing in the spec./javadoc which mandates that we aren't allowed to 
do it correctly. if no window-id was found, it is required to create a new id. 
but there is no statement (or restriction) about the steps afterwards.

that can't be a compatibility-issue - otherwise we would have to implement all 
other mojarra issues as well.


was (Author: gpetracek):
there is nothing in the spec./javadoc which mandates that we aren't allowed to 
do it correctly. if no window-id was found, it is required to create a new id. 
but there is no statement (or restriction) about the steps afterwards.

that can't be an issue with compatibility - otherwise we would have to 
implement all other mojarra issues as well.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812408#comment-13812408
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

yes - i know this paragraph and there is nothing in there which prevents a 
redirect afterwards.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812413#comment-13812413
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

in #decode we can set a flag and do the redirect afterwards (lazily) - there 
is no violation of the rules specified for #decode

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812423#comment-13812423
]

Gerhard Petracek commented on MYFACES-3816:
---

because it just leads to an useless std. mode and users can get issues with it
easily.
it might even look like a random behavior (since it depends on the interaction
before the refresh).
the only useful alternative is to log a clear warning at startup (in case of
the configured url-mode) that the url-mode is broken and a different mode
should be used.

i know - mark and i told ed about the url mode initially (even before the
eg-discussion started) and we also said that this use-case is important. the
known/accepted issues we talked about are about constellations with open in
new tab.

missing window-handling for initial requests

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812442#comment-13812442
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

if there are special requirements for testing, you need a special handling for 
testing (e.g. based on the project-stage - therefore we have project-stages at 
all).

exactly - allowing different modes was my suggestion to ed back then. so you 
can provide special modes for testing or to activate other more advanced 
approaches (like the one we have in deltaspike).

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812450#comment-13812450
 ] 

Gerhard Petracek commented on MYFACES-3816:
---

can you please provide the concrete tck test/s - then i'll file a tck issue 
(for not using project-stages) or file it yourself

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3816) missing window-handling for initial requests

2013-11-03 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812450#comment-13812450
 ] 

Gerhard Petracek edited comment on MYFACES-3816 at 11/3/13 7:07 PM:


please provide the concrete tck test/s - then i'll file a tck issue (for not 
using project-stages) or file it yourself


was (Author: gpetracek):
can you please provide the concrete tck test/s - then i'll file a tck issue 
(for not using project-stages) or file it yourself

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TRINIDAD-2422) repo out of sync

2013-10-30 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809717#comment-13809717
 ] 

Gerhard Petracek commented on TRINIDAD-2422:


i'm fine with both (as long as it's consistent).

 repo out of sync
 

 Key: TRINIDAD-2422
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2422
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Reporter: Gerhard Petracek
Assignee: Jeanne Waldman
Priority: Critical
 Attachments: TRINIDAD-2422.patch


 http://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ is out of sync 
 and therefore http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ fails 
 to build



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (TRINIDAD-2422) repo out of sync

2013-10-28 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created TRINIDAD-2422:
--

 Summary: repo out of sync
 Key: TRINIDAD-2422
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2422
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Reporter: Gerhard Petracek
Assignee: Jeanne Waldman
Priority: Critical


http://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ is out of sync 
and therefore http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ fails to 
build



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TRINIDAD-2422) repo out of sync

2013-10-28 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated TRINIDAD-2422:
---

Status: Patch Available  (was: Open)

 repo out of sync
 

 Key: TRINIDAD-2422
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2422
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Reporter: Gerhard Petracek
Assignee: Jeanne Waldman
Priority: Critical

 http://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ is out of sync 
 and therefore http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ fails 
 to build



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (MYFACES-3805) check handling of serializable converters and validators

2013-10-18 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3805:
-

 Summary: check handling of serializable converters and validators
 Key: MYFACES-3805
 URL: https://issues.apache.org/jira/browse/MYFACES-3805
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


it doesn't work as specified in paragraph 7.8.1.
once we change something here, we also have to handle it for MYFACES-3797.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3805) check handling of serializable converters and validators

2013-10-18 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799462#comment-13799462
 ] 

Gerhard Petracek commented on MYFACES-3805:
---

in case of (cdi based) injection it's actually easier.
for serializable converters and validators we could just skip our current 
adapter.
since you mentioned them during the discussion for MYFACES-3797, i tested it as 
well and saw that they done get restored at all (std. mode - without 
injection).

 check handling of serializable converters and validators
 

 Key: MYFACES-3805
 URL: https://issues.apache.org/jira/browse/MYFACES-3805
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 it doesn't work as specified in paragraph 7.8.1.
 once we change something here, we also have to handle it for MYFACES-3797.



--
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)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794977#comment-13794977
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

trying something only makes sense if you aren't sure about the result.
we know the result already - so trying something with obvious flaws doesn't 
make a lot of sense.

if you would like to try something, then we can try a #5.
all proper cdi scopes use some kind of entry to bind the instance together with 
the CreationalContext.
(please remember what you copied from deltaspike (see 
ContextualInstanceInfo)...)
in those cases the storage is clear - it's the context itself.
here we don't implement a context, but we can just use the same concept since 
the basic issue is the same:

{code}
public class BeanEntry
{
private final Object instance;
private MapString, Object metaData = new HashMapString, Object();

public BeanEntry(Object instance)
{
this.instance = instance;
}

public Object getInstance()
{
return instance;
}

public MapString, Object getMetaData()
{
return metaData;
}
}

public abstract class InjectionProvider
{
public abstract void inject(BeanEntry entry) throws 
InjectionProviderException;

public abstract void postConstruct(BeanEntry entry) throws 
InjectionProviderException;

public abstract void preDestroy(BeanEntry entry) throws 
InjectionProviderException;

//...
}
{code}

also here we have to store the BeanEntry in the target-scope.
it's the only approach for the current need for which you don't have to create 
a key to find the meta-data (like the CreationalContext) for a given object. 
for what we need right now the impact is smaller than it might sound. there is 
no change for the jsf-artifacts, you just create an additional entry for them 
in a list (instead of a map). during the shutdown you iterate through the whole 
list and pass the entries to InjectionProvider#preDestroy.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795077#comment-13795077
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

see the patch of the first draft

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795144#comment-13795144
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

@dora:
for now we don't have to listen to scope changes since those jsf-artifacts 
dependent to the application.
- on a shutdown they get disposed (as before).

if we would have to support e.g. request-scoped jsf-artifacts in the future, we 
just store the corresponding bean-entries (in case of #5) in the request-scope 
and the cleanup logic is the same (at the end of the request we iterate through 
the bean-entry-storage in the jsf-request-map and call #preDestroy).

the same is true for every scoped artifact manually managed by jsf itself 
(instead of cdi).
- with MYFACES-3797 validators and converters are now managed by the cdi 
container - we don't have to handle them the same way.

we don't have to care about custom cdi scopes, since they have to handle all 
those topics internally.
(yes javax.enterprise.* is the package of cdi)

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795158#comment-13795158
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

the clear advantage of #5 (vs #1-#4) is that we don't need an unique id per 
instance to find the meta-data later on (in #preDestroy).
that's way more solid.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795185#comment-13795185
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

agreed - if we have to guarantee the order.
i just kept it simple for this first draft. such internals can be changed at 
any time.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795212#comment-13795212
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

again: cdi can't do it if you need to manage instances externally - that's the 
point i tried to explain in the previous comments over and over again.
if you bypass the cdi context-management, you have to do the equivalent on your 
own.

#1 and #5 are very similar (what you have to do with the result is the same: 
store it in the same scope the instance gets stored).
it's more a matter of taste if you force an implementation to return 
*something* and manage it or pass in a data-structure to store additional 
meta-data.
#5 just allows to extend it later on without breaking backward compatibility 
(you just add properties to bean-entry once they are needed, instead of 
changing the parameters).

i can also provide a patch for #1, there isn't a lot to change for it.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795249#comment-13795249
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

no - that's not correct in case of the mandatory cleanup. you have to follow 
the cdi spec., if you do something manually. forget a ri which is broken in 
that part (if it really ignores it). there is no rule that we have to do the 
same mistakes.
(i'll provide the patch for #1 in some min.)

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  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)

2013-10-15 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795249#comment-13795249
]

Gerhard Petracek edited comment on MYFACES-3786 at 10/15/13 2:59 PM:
-

@leo:
no - that's not correct in case of the mandatory cleanup. you have to follow
the cdi spec., if you do something manually. forget a ri which is broken in
that part (if it really ignores it). there is no rule that we have to do the
same mistakes.
(i'll provide the patch for #1 in some min.)

was (Author: gpetracek):
no - that's not correct in case of the mandatory cleanup. you have to follow
the cdi spec., if you do something manually. forget a ri which is broken in
that part (if it really ignores it). there is no rule that we have to do the
same mistakes.
(i'll provide the patch for #1 in some min.)

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
Fix For: 2.2.0

Attachments: cdiELresolverWeb.zip, cdiELResolver.zip,
cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch,
cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch,
cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch,
MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch

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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795281#comment-13795281
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

then you again have the issue with the need for an unique id, duplicated 
scope-handling, hardcoded support of specific scopes and all the issues i 
listed before.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, 
 MYFACES-3786_internal_bean-entry_draft.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795283#comment-13795283
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

the latest patch is the preview for #1 (i've to double check it later on due to 
the missing type-safety of the new parameter)

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, 
 MYFACES-3786_internal_bean-entry_draft.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795299#comment-13795299
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

@leo: no and sorry, but i won't explain it over and over again

instead of moving in a circle we should pick an approach.
-
#0 (= what we have right now): -0.5 if we want to support custom scopes later 
on and we need a stable spi right now
#1 -0.5 (+1 if it's the only agreement we can get)
#2/#3 -1
#4 +0
#5: +1

+1 for the small improvement suggested by dora

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, 
 MYFACES-3786_internal_bean-entry_draft.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795268#comment-13795268
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

in a cdi specific InjectionProvider we have to follow cdi rules.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795334#comment-13795334
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

initially i said that we can change it for custom scopes once it's needed and 
you said that you don't like to change the spi later on.

however, the positive effect is that we have an approach which doesn't need 
unique-ids per instance to find the meta-data for that instance (in 
#preDestroy). that's imo the most important reason for using #1 or #5 (and not 
using #2-#4).

since we have the patches already, there is no reason to postpone it. i'll 
commit #1 soon.
we can to the internal change suggested by dora at any time.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, 
 MYFACES-3786_internal_bean-entry_draft.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795357#comment-13795357
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

there is never one ultimate api/spi style everybody can(/has to) agree with.
it's your opinion and i respect it (but i don't have to agree).
hopefully you also respect other opinions in such cases (even if you don't 
agree).

anyway, since we have a compromise, we can finish it and move on.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, 
 MYFACES-3786_internal_bean-entry_draft.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795387#comment-13795387
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

@dora: that isn't an issue - the bean-manager won't find injection points - 
nothing will happen.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, 
 MYFACES-3786_internal_bean-entry_draft.patch


  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-3797) cdi support for converters and validators

2013-10-15 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795705#comment-13795705
 ] 

Gerhard Petracek commented on MYFACES-3797:
---

hint for later:
we could test all final weld based ee7 servers, if they still have issues with 
ear-files (see CDI-129).
if they still have an issue and we would like to support them, we could 
refactor MYFACES-3797 to a mixed approach (based on MYFACES-3786).

 cdi support for converters and validators
 -

 Key: MYFACES-3797
 URL: https://issues.apache.org/jira/browse/MYFACES-3797
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-344
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 2.2.0

 Attachments: MYFACES-3797_wrapper.patch


 with
 context-param
 
 param-nameorg.apache.myfaces.CDI_MANAGED_CONVERTERS_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 and
 context-param
 
 param-nameorg.apache.myfaces.CDI_MANAGED_VALIDATORS_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 it should be possible to enable cdi support for converters/validators.
 we need the config, because it was postponed for the spec.



--
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)

2013-10-14 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794207#comment-13794207
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

@leo:
the change itself works. you would be right if the key would be e.g. the class 
(because 2+ request scoped instances of the same class would lead to the same 
key in an application scoped map). however, the key is the identity-hash-code 
which is different. the only issue is: if we will have to support other 
scopes in the future, identity-hash-code might not be strong enough + we 
could get a potential leak (if the cleanup code wouldn't work properly).

however, i thought about it already and i had the same (spi-)change in mind. i 
didn't do it, because i don't like that we would expose a detail of one 
implementation. - i planned to discuss such a change after the upcoming beta 
release.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch


  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-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

2013-10-14 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794246#comment-13794246
 ] 

Gerhard Petracek commented on MYFACES-3786:
---

yes - that's the 2nd option i had in mind as well.

and a 3rd one would be:
void inject(Object instance) //default: application-scoped
and
void inject(Object instance, String scope) //can get added once it's needed

and a 4th would be:
void inject(Object instance, Map targetStorage)

all options have at least one major disadvantage.

 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
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch


  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)

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 959 matches

Mail list logo