[jira] [Created] (DELTASPIKE-887) ds:windowId should initialize the windowhandler script
Thomas Andraschko created DELTASPIKE-887: Summary: ds:windowId should initialize the windowhandler script Key: DELTASPIKE-887 URL: https://issues.apache.org/jira/browse/DELTASPIKE-887 Project: DeltaSpike Issue Type: Bug Affects Versions: 1.3.0 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Currently the windowhandler will be initialized with window.onload but if the user defined an onload attribute on the body, the js version will be ignored. This requires an bigger refactoring on the client side, therefore i will fix in the future when developing the new mixed mode between LAZY/CLIENT_WINDOW. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-830) Now active ViewAccessScoped context during restore view phase
[ https://issues.apache.org/jira/browse/DELTASPIKE-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14520973#comment-14520973 ] Nuno G. de M commented on DELTASPIKE-830: - Hi, Currently we ware not using the LAZY configuration mode precisely because of this problem. We've refactored the application to work with the request paramater based dswid, where if we mess up and have the wrong delta spike windowid in the request URL we suffer a double page loading triggered by the ds:widnowId javascript. I think this is called CLIENT mode. And therefore, we still have in our application window.logcation.href = 'someUrl' where we are forced to add the the approriate windowId to the request url to avoid the double page loading phenomena. This is something to be refactored out of the code in the future, but requires time. In any case. I do not agree with closing the issue, it is preferable to leave the issue open rather than closed and unresolved. As for the onload event problem, I can offer some suggestions: http://www.htmlgoodies.com/beyond/javascript/article.php/3724571/Using-Multiple-JavaScript-Onload-Functions.htm On this URL there is at the bottom some javascript that goes long the lines of what I was thinking, where they create a wrapper function to run their own logic and also call the old logic. But probably it could also work having an DOM element at the bottom of the HTML body that has its own span onload=myDeltaSpikeLazyJavascript() / And this way you would not affect global properties of the dom that may be used by the application itself, you have your own indenpendet dom elements to do your magic. Now active ViewAccessScoped context during restore view phase - Key: DELTASPIKE-830 URL: https://issues.apache.org/jira/browse/DELTASPIKE-830 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.2.1 Environment: Glassfish 3.1.2.2 and Weblogic 12.1.2.2 Reporter: Nuno G. de M Assignee: Thomas Andraschko Fix For: 1.3.1 While testing delta-spike in clientview mode, coming from CODI, we have one view that is giving problems trying to access ViewAccessScoped beans during the restored view phase. Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.ViewAccessScoped Namely the exception we get in our page is the following: Caused By: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.ViewAccessScoped at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:590) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79) at com.corp.whatever.component.ui.web.CR100Bean$Proxy$_$$_WeldClientProxy.getPageIds(CR100Bean$Proxy$_$$_WeldClientProxy.java) at sun.reflect.GeneratedMethodAccessor1663.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at javax.el.BeanELResolver.getValue(BeanELResolver.java:305) at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) at com.sun.el.parser.AstValue.getValue(AstValue.java:138) at com.sun.el.parser.AstValue.getValue(AstValue.java:183) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:99) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) at com.sun.faces.facelets.tag.jstl.core.SetHandler.apply(SetHandler.java:163) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) at
[jira] [Resolved] (DELTASPIKE-886) Add ignoreCase() to the criteria API
[ https://issues.apache.org/jira/browse/DELTASPIKE-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Hug resolved DELTASPIKE-886. --- Resolution: Fixed Add ignoreCase() to the criteria API Key: DELTASPIKE-886 URL: https://issues.apache.org/jira/browse/DELTASPIKE-886 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 1.3.0 Reporter: Peter Ranegger Assignee: Thomas Hug ignoreCase has recently been added for method expressions but for the criteria API it is still missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Unify internal configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi again, here's my proposal for a solution to the slight conf. API mess: https://github.com/rsmeral/deltaspike/commit/d270ac0cb6d5ed47a5912365f95 9145b12da0e99 Main change: a new type-safe fluent API for typed config resolution Connection conn = ConfigResolver.resolve(db.connection) .as(Connection.class, new ConnectionConverter()) .parameterizedBy(db.vendor) .withCurrentProjectStage(true) .strictly() .withDefault(whatever) .getValue(); or simply String conn = ConfigResolver.resolve(db.connection).getValue(); This would obsolete TypedConfig since ConfigResolver would be implicitly type-aware and it brings the type conversion functions from DefaultConfigPropertyProducer and TypedConfig into ConfigResolver. We would also mark the dynamic configurations with some interface (currently DeltaSpikeConfig), mark the static ones with another (e.g. DeltaSpikeBaseConfig). Check out the commit (and also DELTASPIKE-885) for more details. Thanks for any comments, reviews and suggestions :) R. On 28.4.2015 12:33, Ron Smeral wrote: Thanks for the clarification. I'll try to answer my own question then, please comment if anything is not right: * why does PropertyFileConfig implement DeltaSpikeConfig? Doesn't make sense to me, given the purpose of DeltaSpikeConfig. I guess this was not intentional and is a bug. I'll file an issue for this. * is there any reason why the ones from the first category (TransactionConfig and JsfModuleConfig) couldn't be implemented using the second way (TypedConfig)? They couldn't, synce TypedConfig is for static boot-time configuration . * if none of the above is applicable, then: shouldn't the TypedConfig ones (CoreBaseConfig, ...) implement DeltaSpikeConfig as well? I understand that we'd like to keep DeltaSpikeConfig as the marker for all dynamic configuration, i.e. the way it's used now. Maybe we could introduce a new interface to expose the TypedConfig-based interfaces, sth. like DeltaSpikeBaseConfig. R. On 27.4.2015 21:36, Mark Struberg wrote: Hi! Sorry for brevity. Like to quickly sum up what we discussed on irc: .) DeltaSpikeConfig is merely a marker interface for interfaces/classes which can be used to define the behaviour of certain DeltaSpike features at runtimy. Since this is a class it can return different values for each invocation. This is e.g. useful for the LocaleResoler configuration (each user request could result in another Locale). Otoh this configuration mechanism is only available once the CDI container finally got booted. So it can NOT be used to e.g. configure CDI Extensions itself. .) ConfigResolver based configuration. The TypeConfig is basically a object which contains the config-key + code to access the value. This mechanism is purely JavaSE and thus can also be used to configure Extensions itself as well. It’s also more the kind of a ’static’ configuration. LieGrue, strub Am 27.04.2015 um 19:38 schrieb Ron Smeral rsme...@apache.org: Hi, DeltaSpike itself is currently configured in at least 2 different ways: * using interfaces extending DeltaSpikeConfig: ** org.apache.deltaspike.jpa.api.transaction.TransactionConfig ** org.apache.deltaspike.jsf.api.config.JsfModuleConfig (** PropertyFileConfig (Why? It does not configure just DS itself.)) * using interfaces with static TypedConfig instances: ** org.apache.deltaspike.testcontrol.impl.jsf.MyFacesTestBaseConfig ** org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig ** org.apache.deltaspike.scheduler.impl.SchedulerBaseConfig ** org.apache.deltaspike.jsf.api.config.base.JsfBaseConfig ** org.apache.deltaspike.core.api.config.base.CoreBaseConfig My questions are: * why does PropertyFileConfig implement DeltaSpikeConfig? Doesn't make sense to me, given the purpose of DeltaSpikeConfig. * is there any reason why the ones from the first category (TransactionConfig and JsfModuleConfig) couldn't be implemented using the second way (TypedConfig)? * if none of the above is applicable, then: shouldn't the TypedConfig ones (CoreBaseConfig, ...) implement DeltaSpikeConfig as well? I hacked up a quick suggestion of how this could look: https://github.com/rsmeral/deltaspike/commit/b5be1c79b67d6a15b30036ed 9 0a 7b90fba9b5e00 Currently, having two ways of configuration defies the purpose of DeltaSpikeConfig -- that is allowing to find DS configuration points easily. WDYT? Regards, Ron - -- Ron Smeral JBoss Quality Engineer Brno -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVQiyEAAoJEJr1g28gQ1chuRAP/i+gtqFmLjeg17zQrPolUK/o 0/ZlGHonIHmMR8+ePWDpJIKMLgXRmj1pOk62sFbpGWDApfj2BLCfn/Lxz1L+6Zqp srsOrlQ3dYyy2kwHaPytClx6KNFcaBbK3p+BK5BR1IS2X2mtrRGhCZ7yWDRe6KKI JS0veh39NFfojhT/O7cImRqKRzsf6e1FoSRxCH/mFXOO5GBE3g/yPs+5j9kXwWjO DQffBl5II4lw4JHIvZeQW/JNC3hfq5Sgmxn3v6DtFnsurjqwkFpvwyD5kJDG6N2V
Re: Unify internal configuration
i've to check some details, however, basically +1 regards, gerhard 2015-04-30 15:22 GMT+02:00 Ron Smeral rsme...@apache.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi again, here's my proposal for a solution to the slight conf. API mess: https://github.com/rsmeral/deltaspike/commit/d270ac0cb6d5ed47a5912365f95 9145b12da0e99 Main change: a new type-safe fluent API for typed config resolution Connection conn = ConfigResolver.resolve(db.connection) .as(Connection.class, new ConnectionConverter()) .parameterizedBy(db.vendor) .withCurrentProjectStage(true) .strictly() .withDefault(whatever) .getValue(); or simply String conn = ConfigResolver.resolve(db.connection).getValue(); This would obsolete TypedConfig since ConfigResolver would be implicitly type-aware and it brings the type conversion functions from DefaultConfigPropertyProducer and TypedConfig into ConfigResolver. We would also mark the dynamic configurations with some interface (currently DeltaSpikeConfig), mark the static ones with another (e.g. DeltaSpikeBaseConfig). Check out the commit (and also DELTASPIKE-885) for more details. Thanks for any comments, reviews and suggestions :) R. On 28.4.2015 12:33, Ron Smeral wrote: Thanks for the clarification. I'll try to answer my own question then, please comment if anything is not right: * why does PropertyFileConfig implement DeltaSpikeConfig? Doesn't make sense to me, given the purpose of DeltaSpikeConfig. I guess this was not intentional and is a bug. I'll file an issue for this. * is there any reason why the ones from the first category (TransactionConfig and JsfModuleConfig) couldn't be implemented using the second way (TypedConfig)? They couldn't, synce TypedConfig is for static boot-time configuration . * if none of the above is applicable, then: shouldn't the TypedConfig ones (CoreBaseConfig, ...) implement DeltaSpikeConfig as well? I understand that we'd like to keep DeltaSpikeConfig as the marker for all dynamic configuration, i.e. the way it's used now. Maybe we could introduce a new interface to expose the TypedConfig-based interfaces, sth. like DeltaSpikeBaseConfig. R. On 27.4.2015 21:36, Mark Struberg wrote: Hi! Sorry for brevity. Like to quickly sum up what we discussed on irc: .) DeltaSpikeConfig is merely a marker interface for interfaces/classes which can be used to define the behaviour of certain DeltaSpike features at runtimy. Since this is a class it can return different values for each invocation. This is e.g. useful for the LocaleResoler configuration (each user request could result in another Locale). Otoh this configuration mechanism is only available once the CDI container finally got booted. So it can NOT be used to e.g. configure CDI Extensions itself. .) ConfigResolver based configuration. The TypeConfig is basically a object which contains the config-key + code to access the value. This mechanism is purely JavaSE and thus can also be used to configure Extensions itself as well. It’s also more the kind of a ’static’ configuration. LieGrue, strub Am 27.04.2015 um 19:38 schrieb Ron Smeral rsme...@apache.org: Hi, DeltaSpike itself is currently configured in at least 2 different ways: * using interfaces extending DeltaSpikeConfig: ** org.apache.deltaspike.jpa.api.transaction.TransactionConfig ** org.apache.deltaspike.jsf.api.config.JsfModuleConfig (** PropertyFileConfig (Why? It does not configure just DS itself.)) * using interfaces with static TypedConfig instances: ** org.apache.deltaspike.testcontrol.impl.jsf.MyFacesTestBaseConfig ** org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig ** org.apache.deltaspike.scheduler.impl.SchedulerBaseConfig ** org.apache.deltaspike.jsf.api.config.base.JsfBaseConfig ** org.apache.deltaspike.core.api.config.base.CoreBaseConfig My questions are: * why does PropertyFileConfig implement DeltaSpikeConfig? Doesn't make sense to me, given the purpose of DeltaSpikeConfig. * is there any reason why the ones from the first category (TransactionConfig and JsfModuleConfig) couldn't be implemented using the second way (TypedConfig)? * if none of the above is applicable, then: shouldn't the TypedConfig ones (CoreBaseConfig, ...) implement DeltaSpikeConfig as well? I hacked up a quick suggestion of how this could look: https://github.com/rsmeral/deltaspike/commit/b5be1c79b67d6a15b30036ed 9 0a 7b90fba9b5e00 Currently, having two ways of configuration defies the purpose of DeltaSpikeConfig -- that is allowing to find DS configuration points easily. WDYT? Regards, Ron - -- Ron Smeral JBoss Quality Engineer Brno -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVQiyEAAoJEJr1g28gQ1chuRAP/i+gtqFmLjeg17zQrPolUK/o 0/ZlGHonIHmMR8+ePWDpJIKMLgXRmj1pOk62sFbpGWDApfj2BLCfn/Lxz1L+6Zqp
[jira] [Commented] (DELTASPIKE-885) Static DeltaSpike configuration should be easy to find in code base
[
https://issues.apache.org/jira/browse/DELTASPIKE-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521478#comment-14521478
]
Ron Smeral commented on DELTASPIKE-885:
---
https://github.com/rsmeral/deltaspike/commit/371ef896322edf2575c7c6458a6d2b31b1577766
Static DeltaSpike configuration should be easy to find in code base
---
Key: DELTASPIKE-885
URL: https://issues.apache.org/jira/browse/DELTASPIKE-885
Project: DeltaSpike
Issue Type: Bug
Components: Core
Reporter: Ron Smeral
Assignee: Ron Smeral
Priority: Minor
Currently the following interfaces are used for static configuration of
DeltaSpike itself:
* org.apache.deltaspike.testcontrol.impl.jsf.MyFacesTestBaseConfig
* org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig
* org.apache.deltaspike.scheduler.impl.SchedulerBaseConfig
* org.apache.deltaspike.jsf.api.config.base.JsfBaseConfig
* org.apache.deltaspike.core.api.config.base.CoreBaseConfig
They all use {{TypedConfig}} but that doesn't seem like a sufficient
identifier of DeltaSpike configuration.
I suggest the following:
* make all of the above mentioned interface implement a new marker interface
{{DeltaSpikeBaseConfig}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-884) PropertyFileConfig shouldn't implement DeltaSpikeConfig
[
https://issues.apache.org/jira/browse/DELTASPIKE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521477#comment-14521477
]
Ron Smeral commented on DELTASPIKE-884:
---
https://github.com/rsmeral/deltaspike/commit/bff862b721bbef3e4ffc9cd12829bbd59a8070a8
PropertyFileConfig shouldn't implement DeltaSpikeConfig
---
Key: DELTASPIKE-884
URL: https://issues.apache.org/jira/browse/DELTASPIKE-884
Project: DeltaSpike
Issue Type: Bug
Components: Core
Reporter: Ron Smeral
Assignee: Ron Smeral
Priority: Minor
{{DeltaSpikeConfig}} is Marker interface for all classes used for
configuration of DeltaSpike itself. while {{PropertyFileConfig}} is an
interfaces for registration of property files as config sources.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-888) Add support for delete a job from the Scheduler
Daniel Cunha created DELTASPIKE-888: --- Summary: Add support for delete a job from the Scheduler Key: DELTASPIKE-888 URL: https://issues.apache.org/jira/browse/DELTASPIKE-888 Project: DeltaSpike Issue Type: Improvement Components: Scheduler Reporter: Daniel Cunha Priority: Minor Delete the identified Job from the Scheduler - and any associated Triggers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-888) Add support for delete a job from the Scheduler
[ https://issues.apache.org/jira/browse/DELTASPIKE-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Cunha updated DELTASPIKE-888: Attachment: DELTASPIKE-888.patch Add support for delete a job from the Scheduler --- Key: DELTASPIKE-888 URL: https://issues.apache.org/jira/browse/DELTASPIKE-888 Project: DeltaSpike Issue Type: Improvement Components: Scheduler Reporter: Daniel Cunha Priority: Minor Attachments: DELTASPIKE-888.patch Delete the identified Job from the Scheduler - and any associated Triggers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-830) Now active ViewAccessScoped context during restore view phase
[ https://issues.apache.org/jira/browse/DELTASPIKE-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521908#comment-14521908 ] Nuno G. de M commented on DELTASPIKE-830: - Hi Thomas, I did not say that I did not like it. It makes perfect sense to me that it happens - I am not complaining about it. When it happens I interpret as a problem in our code not in yours. The only thing i said I do not agree with is closing an issue that is not closed - If there isn't a fix for something yet i think it is better to keep the issue open and revisit some time later in the future. If gets closed it gets forgotten. Kindest regards, Nuno. Now active ViewAccessScoped context during restore view phase - Key: DELTASPIKE-830 URL: https://issues.apache.org/jira/browse/DELTASPIKE-830 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.2.1 Environment: Glassfish 3.1.2.2 and Weblogic 12.1.2.2 Reporter: Nuno G. de M Assignee: Thomas Andraschko Fix For: 1.3.1 While testing delta-spike in clientview mode, coming from CODI, we have one view that is giving problems trying to access ViewAccessScoped beans during the restored view phase. Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.ViewAccessScoped Namely the exception we get in our page is the following: Caused By: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.ViewAccessScoped at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:590) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79) at com.corp.whatever.component.ui.web.CR100Bean$Proxy$_$$_WeldClientProxy.getPageIds(CR100Bean$Proxy$_$$_WeldClientProxy.java) at sun.reflect.GeneratedMethodAccessor1663.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at javax.el.BeanELResolver.getValue(BeanELResolver.java:305) at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) at com.sun.el.parser.AstValue.getValue(AstValue.java:138) at com.sun.el.parser.AstValue.getValue(AstValue.java:183) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:99) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) at com.sun.faces.facelets.tag.jstl.core.SetHandler.apply(SetHandler.java:163) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:188) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358) at
[jira] [Updated] (DELTASPIKE-873) show error-message on the same page
[ https://issues.apache.org/jira/browse/DELTASPIKE-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-873: Attachment: (was: DELTASPIKE-873.patch) show error-message on the same page --- Key: DELTASPIKE-873 URL: https://issues.apache.org/jira/browse/DELTASPIKE-873 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module, Security-Module Affects Versions: 1.3.0 Reporter: Rafael Assignee: Gerhard Petracek Fix For: 1.3.1 currently it just works if a default-error-view is configured -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DELTASPIKE-888) Add support for delete a job from the Scheduler
[ https://issues.apache.org/jira/browse/DELTASPIKE-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-888: --- Assignee: Gerhard Petracek Add support for delete a job from the Scheduler --- Key: DELTASPIKE-888 URL: https://issues.apache.org/jira/browse/DELTASPIKE-888 Project: DeltaSpike Issue Type: Improvement Components: Scheduler Reporter: Daniel Cunha Assignee: Gerhard Petracek Priority: Minor Attachments: DELTASPIKE-888.patch Delete the identified Job from the Scheduler - and any associated Triggers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-888) Add support for delete a job from the Scheduler
[ https://issues.apache.org/jira/browse/DELTASPIKE-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-888: Issue Type: New Feature (was: Improvement) Add support for delete a job from the Scheduler --- Key: DELTASPIKE-888 URL: https://issues.apache.org/jira/browse/DELTASPIKE-888 Project: DeltaSpike Issue Type: New Feature Components: Scheduler Reporter: Daniel Cunha Assignee: Gerhard Petracek Priority: Minor Attachments: DELTASPIKE-888.patch Delete the identified Job from the Scheduler - and any associated Triggers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-873) show error-message on the same page
[ https://issues.apache.org/jira/browse/DELTASPIKE-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-873: Attachment: DELTASPIKE-873.patch show error-message on the same page --- Key: DELTASPIKE-873 URL: https://issues.apache.org/jira/browse/DELTASPIKE-873 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module, Security-Module Affects Versions: 1.3.0 Reporter: Rafael Assignee: Gerhard Petracek Fix For: 1.3.1 Attachments: DELTASPIKE-873.patch currently it just works if a default-error-view is configured -- This message was sent by Atlassian JIRA (v6.3.4#6332)
