[JBoss JIRA] (JBVFS-207) Provide way to retrieve VirtualFile instance from VirtualFileURLConnection
by Tomas Hofman (Jira)
Tomas Hofman created JBVFS-207:
----------------------------------
Summary: Provide way to retrieve VirtualFile instance from VirtualFileURLConnection
Key: JBVFS-207
URL: https://issues.jboss.org/browse/JBVFS-207
Project: JBoss VFS
Issue Type: Enhancement
Reporter: Tomas Hofman
Assignee: Tomas Hofman
It is not possible to obtain VirtualFile (and by extensions it's physicalFile) instance wrapped in VirtualFileURLConnection without using reflection.
Code snippet from Drools [1]:
{code}
private static Object findVirtualFile( URL url ) throws IOException {
URLConnection urlConnection = url.openConnection();
try {
if ( urlConnection.getClass().getName().equals( "org.jboss.vfs.protocol.VirtualFileURLConnection" ) ) {
Field f = urlConnection.getClass().getDeclaredField( "file" );
f.setAccessible( true );
return f.get( urlConnection );
}
} catch (NoSuchFieldException | IllegalAccessException e) {
// ignored
}
return urlConnection.getContent();
}
{code}
[1] https://github.com/kiegroup/drools/commit/2a36f67a29ed06d0f980a60ff1c81fa...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3189) Add info tip to "Collection" switch
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3189?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3189:
-------------------------------------
[~stetson.robinson] OK thanks (I'm getting my scrum teams confused...) WRT copy - this is a future enhancement, but good to know that a proposal from [~karreiro] would be a good starting point when we get there.
> Add info tip to "Collection" switch
> -----------------------------------
>
> Key: DROOLS-3189
> URL: https://issues.jboss.org/browse/DROOLS-3189
> Project: Drools
> Issue Type: Sub-task
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Minor
> Labels: UX, UXTeam
>
> User could benefit from some on screen info tip help (i) for the Collection (yes/no) option. This jira is to create the copy required for the info tip bubble.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3189) Add info tip to "Collection" switch
by Stetson Robinson (Jira)
[ https://issues.jboss.org/browse/DROOLS-3189?page=com.atlassian.jira.plugi... ]
Stetson Robinson commented on DROOLS-3189:
------------------------------------------
[~uxdlc], no need for docs tag since not a doc, but pinging the assigned writer (me) like this is the way to go. And no need to involved [~74676_gaurav], since this is for the DMN editor.
[~karreiro], things will go quicker/smoother if you can propose the tip explaining what the collection setting is/does, and then I can edit accordingly.
> Add info tip to "Collection" switch
> -----------------------------------
>
> Key: DROOLS-3189
> URL: https://issues.jboss.org/browse/DROOLS-3189
> Project: Drools
> Issue Type: Sub-task
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Minor
> Labels: UX, UXTeam
>
> User could benefit from some on screen info tip help (i) for the Collection (yes/no) option. This jira is to create the copy required for the info tip bubble.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-11233:
-------------------------------------
Next attempt, is switching from a thread local, to instead use a global (per persistence unit, per application deployment) cache. We shouldn't have any leaks with this approach, as we will clear the cache during undeployment.
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
> * In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
> * If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
> * Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
> * Also ensure that SynchronizationType is respected, so we don't mix SynchronizationType.UNSYNCHRONIZED + SynchronizationType.SYNCHRONIZED types. Perhaps we need a cache slot for each SynchronizationType.
> EntityManager cache settings can be:
> * No cache (default)
> * ThreadLocal cache (only cached at the application thread level)
> * Per EntityManagerFactory cache (cache is shared between multiple threads, so make it thread safe), this would need to be proven to be leak free (especially with CDI beans). Cache size would be configurable.
> If EM leaks are a problem in the above, an alternative might be to only cache within JTA transactions, since we would then have control of the closing of the EntityManager.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3186) [DMN Designer] Remove Shape BorderSize and Font BorderSize properties
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3186?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3186:
-----------------------------------
Summary: [DMN Designer] Remove Shape BorderSize and Font BorderSize properties (was: [DMN Designer] Remove Shape and Font border properties)
> [DMN Designer] Remove Shape BorderSize and Font BorderSize properties
> ---------------------------------------------------------------------
>
> Key: DROOLS-3186
> URL: https://issues.jboss.org/browse/DROOLS-3186
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> {quote}
> Offical DMNDI (of spec DMNv1.2) has no support for Shape border size, Font border size. I will not persist this information.
> {quote}
> > Did you want these properties removed from the Editor?
> > I would say given the current deadlines the safest approach is to temporarily hide and disable them
> h2. Acceptance test
> - Build and deploy on kie-server
> - Save and reopen
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-11233:
-------------------------------------
[https://github.com/scottmarlow/wildfly/tree/WFLY-11233_emcache] contains a proof of concept threadlocal implementation that has a memory leaking flaw. The flaw is that this is a big memory leak. So, after undeployment, we need to stop the app server to clear memory of the leaked app + cache. This should be okay for evaluating whether this EM caching helps.
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
> * In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
> * If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
> * Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
> * Also ensure that SynchronizationType is respected, so we don't mix SynchronizationType.UNSYNCHRONIZED + SynchronizationType.SYNCHRONIZED types. Perhaps we need a cache slot for each SynchronizationType.
> EntityManager cache settings can be:
> * No cache (default)
> * ThreadLocal cache (only cached at the application thread level)
> * Per EntityManagerFactory cache (cache is shared between multiple threads, so make it thread safe), this would need to be proven to be leak free (especially with CDI beans). Cache size would be configurable.
> If EM leaks are a problem in the above, an alternative might be to only cache within JTA transactions, since we would then have control of the closing of the EntityManager.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3189) Add info tip to "Collection" switch
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3189?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3189:
-------------------------------------
[~stetson.robinson] [~g.dey18] I created this subtask to figure out some copy to provide to [~karreiro] when he implements the info tip for Collection. Should I add a Docs tag to the subtask, or is it not really a Docs item?
> Add info tip to "Collection" switch
> -----------------------------------
>
> Key: DROOLS-3189
> URL: https://issues.jboss.org/browse/DROOLS-3189
> Project: Drools
> Issue Type: Sub-task
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Minor
> Labels: UX, UXTeam
>
> User could benefit from some on screen info tip help (i) for the Collection (yes/no) option. This jira is to create the copy required for the info tip bubble.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3154) Minor UI improvements/bugfixes for Scenario
by Brian Dellascio (Jira)
[ https://issues.jboss.org/browse/DROOLS-3154?page=com.atlassian.jira.plugi... ]
Brian Dellascio commented on DROOLS-3154:
-----------------------------------------
Thanks for linking over to that JIRA, [~uxdlc]
> Minor UI improvements/bugfixes for Scenario
> -------------------------------------------
>
> Key: DROOLS-3154
> URL: https://issues.jboss.org/browse/DROOLS-3154
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Critical
> Labels: UX-CSS
> Attachments: test-editor-margin.png
>
>
> This item contains a list of general UI bugs to be fixed:
> - Use grey borders for all the grid and not only for the header
> - Add some padding to the cells of the grid
> - Add some padding to right panel the tab titles
> - Remove scrolling bar from right panel
> - Review expression editor component HTML/CSS (paddings, indents, etc)
> - Review right panel padding (now it is hardcoded)
> - Use text area inputs instead of text box for inline editing
> - Reduce the width of Index column
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3189) Add info tip to "Collection" switch
by Liz Clayton (Jira)
Liz Clayton created DROOLS-3189:
-----------------------------------
Summary: Add info tip to "Collection" switch
Key: DROOLS-3189
URL: https://issues.jboss.org/browse/DROOLS-3189
Project: Drools
Issue Type: Sub-task
Reporter: Liz Clayton
Assignee: Liz Clayton
User could benefit from some on screen info tip help (i) for the Collection (yes/no) option. This jira is to create the copy required for the info tip bubble.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months