[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Gail Badner commented on WFLY-10520:
------------------------------------
[~smarlow], regarding {{setFirstResult( -1 )}}, I'd like to clarify what I've done and why.
If (untransformed) {{org.hibernate.Query#setFirstResult( int )}} is called with a negative argument...
In 5.1,
* {{org.hibernate.Query#getFirstResult( )}} will return the same negative value;
* when the query is executed, the first result retrieved will be at position 0 of the query results.
In 5.3,
* {{IllegalArgumentException}} is thrown as specified by JPA.
I could not restore both 5.1 behaviors in 5.3 (at least not without an overly complicated fix). I was able to restore the more important behavior (IMO) by calling {{setHibernateFirstResult( 0 )}}. By doing that, when the query is executed, the first result retrieved will be at position 0 of the query results.
I did this because I didn't think it should be necessary for an application to be modified because it calls {{org.hibernate.Query#setFirstResult( int )}} with a negative argument, when it is easy for the transformer to do the right thing with respect to pagination.
After transforming, pagination will work the same as in 5.1, but {{org.hibernate.Query#getFirstResult()}} will return 0, instead of the negative value the application used when it called {{org.hibernate.Query#setFirstResult( int )}}.
I think it is unlikely that an application would even call {{org.hibernate.Query#getFirstResult()}}, but if it does, it will get an unexpected result, (0).
IMO, this can be handled by documenting this point {org.hibernate.Query#setHibernateFirstResult}} in the migration guide, as well as in the transformer documentation. It is already documented in the Javadoc. I suppose that Hibernate could also log an INFO or WARNING message when {{setHibernateFirstResult}} is called with a negative value.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
> # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int) which will be added soon to ORM 5.3.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2652) [DMN Designer] Different icons for different connector types
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2652?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2652:
----------------------------------------
[~uxdlc] Hi, could I please ask UX for some PNGs for the toolbox icons for the different connector types.
Their appearance can be seen in https://www.omg.org/spec/DMN/1.1/PDF (page 30, "Association", "Information Requirement", "Knowledge Requirement" and "Authority Requirement"). They'll only be used as icons on the toolbox (see screenshot attached). Could you please also remind me of the BAPL(?) for the new "Node" SVGs (I'll need to make PNGs of those too for the same "toolbox" purpose.. unless UX have a tool to convert SVG to PNG?)
> [DMN Designer] Different icons for different connector types
> ------------------------------------------------------------
>
> Key: DROOLS-2652
> URL: https://issues.jboss.org/browse/DROOLS-2652
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> The toolbox shows icons for the different connection types available from a given node.
> At the moment they are all the same icon and it is difficult to know which toolbox icon represents which connection type. Until https://issues.jboss.org/browse/DROOLS-1944 a short-term fix is to simply ensure each connection type has an icon more correctly representing its type.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Gail Badner commented on WFLY-10520:
------------------------------------
I've added a comment for Sande regarding documentation on JBEAP-14854:
https://issues.jboss.org/browse/JBEAP-14854?focusedCommentId=13597328&pag...
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
> # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int) which will be added soon to ORM 5.3.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2654) [DMN Designer] Automatically show (Name) edit control when adding new ContextEntries
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2654?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2654:
-------------------------------------
[~tari_manga] A few questions:
* The jira mentions "context entries" is this solution only for Boxed Context tables or any decision logic table type?
* By "text field editor" do you mean an inline text field input box or something else?
* Is the first editable cell in any given new row the "name" cell?
* Why is the default label called "MyName" versus something either more generic like "Name" or specific to the type like "key name."
Sorry for all the questions, just want to make sure I'm understanding...
> [DMN Designer] Automatically show (Name) edit control when adding new ContextEntries
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-2654
> URL: https://issues.jboss.org/browse/DROOLS-2654
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> When a new {{ContextEntry}} is added the User must double click on the {{Name}} cell to change the default value.
> [~tari_manga] suggested it would be good if the {{Name}} editor was automatically shown and focused when the User creates a new {{ContextEntry}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3039:
------------------------------------------
I think the problem probably relates to the fact that OperationContext.deregisterCapabilityRequirement does not expose an 'attributeName' param so when the undefine-attribute removes the requirement it can get messed up. See CapabilityRegistry.removeRequirement. However, before anything can even be done with that, RequirementRegistration.registrationPoints is a Map<PathAddress, RegistrationPoint> so if 2 attributes for the same resource register, there will only be one entry in the map.
> Capability requirement can be lost if two attributes on same resource reference the same capability
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3039
> URL: https://issues.jboss.org/browse/WFCORE-3039
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Radovan Netuka
>
> With the following three commands the server becomes unable to boot due to a missing dependency: -
> {noformat}
> /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
> /subsystem=elytron:undefine-attribute(name=final-providers)
> /subsystem=elytron/aggregate-providers=combined-providers:remove
> {noformat}
> If however I execute :reload after the first two commands, the final command will fail correctly.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities:
> capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'",
> "rolled-back" => true
> }
> {noformat}
> I am only listing the 'Domain Management' component as I believe the security example is just the reproducer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3039:
------------------------------------------
The code at your [1] is calling an API that per the issue that added it -- WFCORE-3683 -- is meant to "Allow a resource to declares capability requirements without binding it to an attribute." So I think null is the appropriate param.
The javadoc for IMRR.getRequirements() could/should be better.
> Capability requirement can be lost if two attributes on same resource reference the same capability
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3039
> URL: https://issues.jboss.org/browse/WFCORE-3039
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Radovan Netuka
>
> With the following three commands the server becomes unable to boot due to a missing dependency: -
> {noformat}
> /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
> /subsystem=elytron:undefine-attribute(name=final-providers)
> /subsystem=elytron/aggregate-providers=combined-providers:remove
> {noformat}
> If however I execute :reload after the first two commands, the final command will fail correctly.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities:
> capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'",
> "rolled-back" => true
> }
> {noformat}
> I am only listing the 'Domain Management' component as I believe the security example is just the reproducer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2654) [DMN Designer] Automatically show (Name) edit control when adding new ContextEntries
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2654?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-2654:
----------------------------------------
I'll try easier with steps first, if required I can try a video.
1. the user click on "add new row"
2. the system add the new row above/below as expected
3. the textfield editor for the context entry text is automatically selected, in focus, and ready to edit the name
Currently the default is "My Name", hence means as soon as the new row is added, the user by typing on the keyboard can change the name
> [DMN Designer] Automatically show (Name) edit control when adding new ContextEntries
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-2654
> URL: https://issues.jboss.org/browse/DROOLS-2654
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> When a new {{ContextEntry}} is added the User must double click on the {{Name}} cell to change the default value.
> [~tari_manga] suggested it would be good if the {{Name}} editor was automatically shown and focused when the User creates a new {{ContextEntry}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years