[JBoss JIRA] (AS7-1509) JSP subsystem configurations lost during marshalling
by no boundaries ! (JIRA)
[ https://issues.jboss.org/browse/AS7-1509?page=com.atlassian.jira.plugin.s... ]
no boundaries ! commented on AS7-1509:
--------------------------------------
$JBOSS_HOME$\standalone\configuration\standalone.xml
> JSP subsystem configurations lost during marshalling
> -----------------------------------------------------
>
> Key: AS7-1509
> URL: https://issues.jboss.org/browse/AS7-1509
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Environment: AS7 upstream
> Reporter: jaikiran pai
> Assignee: jaikiran pai
> Fix For: 7.0.1.Final
>
>
> If the web subsystem is configured with the jsp configuration:
> {code}
> <configuration>
> <jsp-configuration development="true"/>
> </configuration>
> {code}
> and some management operation is carried out like deploying some application, the entire "configuration" element is lost from the xml file during marshalling.
> Please see the referenced forum thread for details
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3137) logging errors in destroying a requestscoped entitymanager
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3137?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3137:
--------------------------------------
The entity manager is a container managed transaction scoped entity manager, calling close will result in an error.
All you really need is:
@PersistenceContext(unitName = mydatasource)
@Produces
@MyEm
private EntityManager em;
The EM is automatically closed at transaction commit/rollback time.
> logging errors in destroying a requestscoped entitymanager
> ----------------------------------------------------------
>
> Key: WFLY-3137
> URL: https://issues.jboss.org/browse/WFLY-3137
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: window 7 64bits, javaee 1.7
> Reporter: Richard Yang
> Assignee: Stuart Douglas
>
> I have a simple producer for a requestscoped entitymanager:
> @PersistenceContext(unitName = mydatasource)
> private EntityManager em;
> @Produces
> @myEM
> @RequestScoped
> protected EntityManager createEntityManager() {
> return em;
> }
> protected void closeEntityManager(
> @Disposes @myEM EntityManager entityManager) {
> if (entityManager.isOpen()) {
> entityManager.close();
> }
> }
> I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
> WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager@7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3137) logging errors in destroying a requestscoped entitymanager
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3137?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3137.
----------------------------------
Resolution: Rejected
> logging errors in destroying a requestscoped entitymanager
> ----------------------------------------------------------
>
> Key: WFLY-3137
> URL: https://issues.jboss.org/browse/WFLY-3137
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: window 7 64bits, javaee 1.7
> Reporter: Richard Yang
> Assignee: Stuart Douglas
>
> I have a simple producer for a requestscoped entitymanager:
> @PersistenceContext(unitName = mydatasource)
> private EntityManager em;
> @Produces
> @myEM
> @RequestScoped
> protected EntityManager createEntityManager() {
> return em;
> }
> protected void closeEntityManager(
> @Disposes @myEM EntityManager entityManager) {
> if (entityManager.isOpen()) {
> entityManager.close();
> }
> }
> I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
> WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager@7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2751.
----------------------------------
Resolution: Out of Date
This should have been fixed by CDI lazy conversation activation.
> h:inputFile and max-file-size
> -----------------------------
>
> Key: WFLY-2751
> URL: https://issues.jboss.org/browse/WFLY-2751
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: Open JDK 7, Cent OS
> Reporter: Andre Pankraz
> Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> <servlet>
> <servlet-name>Faces Servlet</servlet-name>
> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> <multipart-config>
> <location>/tmp</location>
> <max-file-size>1000</max-file-size>
> <max-request-size>2000</max-request-size>
> <file-size-threshold>500</file-size-threshold>
> </multipart-config>
> </servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> ... 37 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3105) Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3105:
------------------------------------
Hmm, sounds like a bug in [https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...] and [https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...]
>From 7.6.1 Persistence Context Synchronization Type XPC can also be UNSYNCHRONIZED:
{quote}
By default, a container-managed persistence context is of type SynchronizationType.SYNCHRONIZED. Such a persistence context is automatically joined to the current JTA transaction, and updates made to the persistence context are propagated to the underlying resource manager.
A container-managed persistence context may be specified to be of type SynchronizationType.UNSYNCHRONIZED. A persistence context of type SynchronizationType.UNSYNCHRONIZED is not enlisted in any JTA transaction unless explicitly joined to that transaction by the application. A persistence context of type SynchronizationType.UNSYNCHRONIZED is enlisted in a JTA transaction and registered for subsequent transaction notifications against that transaction by the invocation of the EntityManager joinTransaction method. The persistence context remains joined to the transaction until the transaction commits or rolls back. After the transaction commits or rolls back, the persistence context will not be joined to any subsequent transaction unless the joinTransaction method is invoked in the scope of that subsequent transaction.
A persistence context of type SynchronizationType.UNSYNCHRONIZED must not be flushed to the database unless it is joined to a transaction. The application's use of queries with pessimistic locks, bulk update or delete queries, etc. result in the provider throwing the TransactionRequiredException. After the persistence context has been joined to the JTA transaction, these operations are again allowed.
The application is permitted to invoke the persist, merge, remove, and refresh entity lifecycle operations on an entity manager of type SynchronizationType.UNSYNCHRONIZED independent of whether the persistence context is joined to the current transaction. After the persistence context has been joined to a transaction, changes in a persistence context can be flushed to the database either explicitly by the application or by the provider. If the flush method is not explicitly invoked, the persistence provider may defer flushing until commit time depending on the operations invoked and the flush mode setting in effect.
If an extended persistence context of type SynchronizationType.UNSYNCHRONIZED has not been joined to the current JTA transaction, rollback of the JTA transaction will have no effect upon the persistence context. In general, it is recommended that a non-JTA datasource be specified for use by the persistence provider for a persistence context of type SynchronizationType.UNSYNCHRONIZED that has not been joined to a JTA transaction in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back.
If a persistence context of type SynchronizationType.UNSYNCHRONIZED has been joined to the JTA transaction, transaction rollback will cause the persistence context to be cleared and all pre-existing managed and removed instances to become detached. (See section 3.3.3.)
When a JTA transaction exists, a persistence context of type SynchronizationType.UNSYNCHRONIZED is propagated with that transaction according to the rules in section 7.6.4.1 regardless of whether the persistence context has been joined to that transaction.
{quote}
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3105
> URL: https://issues.jboss.org/browse/WFLY-3105
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Final
> Reporter: Christian Bauer
> Assignee: Scott Marlow
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/s...
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break.
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months