[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1800:
-------------------------------------
Description:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
-Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
/path=invalid:read-attribute(name=name)
-
(Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
was:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
-Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
{code}
/path=invalid:read-attribute(name=name)
{code}-
(Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
> Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1800
> URL: https://issues.jboss.org/browse/WFCORE-1800
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: James Perkins
> Attachments: WFCORE-1800.patch
>
>
> If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
> -Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
> /path=invalid:read-attribute(name=name)
> -
> (Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
> For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1800:
-------------------------------------
Description:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
-Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.-
/path=invalid:read-attribute(name=name)
(Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
was:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
-Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
/path=invalid:read-attribute(name=name)
-
(Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
> Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1800
> URL: https://issues.jboss.org/browse/WFCORE-1800
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: James Perkins
> Attachments: WFCORE-1800.patch
>
>
> If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
> -Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.-
> /path=invalid:read-attribute(name=name)
> (Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
> For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1800:
-------------------------------------
Description:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
-Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
{code}
/path=invalid:read-attribute(name=name)
{code}-
(Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
was:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
{code}
/path=invalid:read-attribute(name=name)
{code}
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
> Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1800
> URL: https://issues.jboss.org/browse/WFCORE-1800
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: James Perkins
> Attachments: WFCORE-1800.patch
>
>
> If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
> -Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
> {code}
> /path=invalid:read-attribute(name=name)
> {code}-
> (Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
> For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1800:
-------------------------------------
Description:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
{code}
/path=invalid:read-attribute(name=name)
{code}
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
was:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
{code}
/path=invalid(name=name)
{code}
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
> Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1800
> URL: https://issues.jboss.org/browse/WFCORE-1800
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: James Perkins
> Attachments: WFCORE-1800.patch
>
>
> If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
> Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
> {code}
> /path=invalid:read-attribute(name=name)
> {code}
> For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10730) Scan for entities in persistence root when using unmanaged JPA persistence unit
by Stephen Fikes (JIRA)
[ https://issues.jboss.org/browse/WFLY-10730?page=com.atlassian.jira.plugin... ]
Stephen Fikes commented on WFLY-10730:
--------------------------------------
The test can be built running {{'mvn clean package'}} and run by copying {{./javaee-ear/target/javaee-ear-1.0-SNAPSHOT.ear}} to {{<WFLY_HOME>/standalone/deployments}}.
The issue can be seen with the {{'managedUnit'}} on the console:
{code}
... SEVERE [support.jboss.ejb.session.SessionBean] (ServerService Thread Pool -- 89) Failure accessing unit 'managedUnit': org.hibernate.hql.internal.ast.QuerySyntaxException: Employee is not mapped [from Employee e]
{code}
> Scan for entities in persistence root when using unmanaged JPA persistence unit
> -------------------------------------------------------------------------------
>
> Key: WFLY-10730
> URL: https://issues.jboss.org/browse/WFLY-10730
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 13.0.0.Final
> Reporter: Stephen Fikes
> Assignee: Scott Marlow
> Attachments: testcase.zip
>
>
> Per the [JPA specification|http://download.oracle.com/otn-pub/jcp/persistence-2_2-mrel...], entities in the root should not need to be explicitly specified (they should be automatically discovered). This works in a managed scenario (using injected entity manager) but doesn't work in an un-managed case (entity manager factory / entity manager created explicitly in application code) when using the same persistence unit.
> Also attempted to work around the limitation by declaring an explicit scanner ({{hibernate.archive.scanner=org.jboss.as.jpa.hibernate5.HibernateArchiveScanner}}) but this requires disabling managed JPA for the unit ({{jboss.as.jpa.managed=false}}) so a single unit cannot be used in both managed and un-managed scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10730) Scan for entities in persistence root when using unmanaged JPA persistence unit
by Stephen Fikes (JIRA)
Stephen Fikes created WFLY-10730:
------------------------------------
Summary: Scan for entities in persistence root when using unmanaged JPA persistence unit
Key: WFLY-10730
URL: https://issues.jboss.org/browse/WFLY-10730
Project: WildFly
Issue Type: Enhancement
Components: JPA / Hibernate
Affects Versions: 13.0.0.Final
Reporter: Stephen Fikes
Assignee: Scott Marlow
Attachments: testcase.zip
Per the [JPA specification|http://download.oracle.com/otn-pub/jcp/persistence-2_2-mrel...], entities in the root should not need to be explicitly specified (they should be automatically discovered). This works in a managed scenario (using injected entity manager) but doesn't work in an un-managed case (entity manager factory / entity manager created explicitly in application code) when using the same persistence unit.
Also attempted to work around the limitation by declaring an explicit scanner ({{hibernate.archive.scanner=org.jboss.as.jpa.hibernate5.HibernateArchiveScanner}}) but this requires disabling managed JPA for the unit ({{jboss.as.jpa.managed=false}}) so a single unit cannot be used in both managed and un-managed scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months