[JBoss JIRA] (WFLY-12013) (7.2.z) TCCL is not set to datasource module in datasource constructor
by Bartosz Spyrko (Jira)
Bartosz Spyrko created WFLY-12013:
-------------------------------------
Summary: (7.2.z) TCCL is not set to datasource module in datasource constructor
Key: WFLY-12013
URL: https://issues.jboss.org/browse/WFLY-12013
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 13.0.0.Final
Reporter: Bartosz Spyrko
Assignee: Stefano Maestri
TCCL is not set to datasource module
User has a datasource that uses ORB classes and is getting a ClassNotFound.
If a 3rd party JDBC driver implementation is using e. g. CORBA, the class loader is not set and thus the CORBA classes got loaded from the 'org.jboss.as.connector' modules class loader.
So the root cause is the Thread Context ClassLoader (TCCL) is not set to the classloader/module of the datasource driver module. The particular datasource driver is making using of ORB.init which is a JDK class that looks on the TCCL and other places to load the class specified in ORB.init, but JCA when running has not set the TCCL thus the classes cannot be found.
Having the TCCL set to the application is how JEE handles related situations to load application classes, so it would make sense that when JCA is running the datasource that it would have the TCCL set to the module of the datasource or a delegate class loader that sees both the datasource module and any other class loader that JCA might need, JBossWS does something similar.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4438) No welcome page in WildFly 17
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4438?page=com.atlassian.jira.plugi... ]
Yeray Borges commented on WFCORE-4438:
--------------------------------------
Hi [~brian.stansberry], it is completely unrelated, the reason is https://issues.jboss.org/browse/WFCORE-4363, which disables the error page for all the console modes. Looks like a simple fix is to disable the error handler only for ConsoleMode.NO_CONSOLE.
[~jmesnil] If you are not working on this issue, you can assign it to me and I would supply a fix.
> No welcome page in WildFly 17
> -----------------------------
>
> Key: WFCORE-4438
> URL: https://issues.jboss.org/browse/WFCORE-4438
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 9.0.0.Beta3
> Reporter: Jan Kasik
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: Screenshot_2019-04-23 Error.png, Screenshot_2019-04-23 Welcome to WildFly Application Server.png
>
>
> There is no welcome/error page by default in CD17 on {{http://127.0.0.1:9990}}. See screenshots comparing WildFly 17 to 16.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-12012) Fixing JDK 11 issues in EAT.
by Panagiotis Sotiropoulos (Jira)
Panagiotis Sotiropoulos created WFLY-12012:
----------------------------------------------
Summary: Fixing JDK 11 issues in EAT.
Key: WFLY-12012
URL: https://issues.jboss.org/browse/WFLY-12012
Project: WildFly
Issue Type: Task
Components: Test Suite
Reporter: Panagiotis Sotiropoulos
Assignee: Panagiotis Sotiropoulos
Fix of JDK 11 issues in EAT.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4439) No welcome page in WildFly 17
by Jan Kasik (Jira)
Jan Kasik created WFCORE-4439:
---------------------------------
Summary: No welcome page in WildFly 17
Key: WFCORE-4439
URL: https://issues.jboss.org/browse/WFCORE-4439
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 9.0.0.Beta3
Reporter: Jan Kasik
Assignee: Jeff Mesnil
There is no welcome/error page by default in CD17 on {{http://127.0.0.1:9990}}. See screenshots comparing WildFly 17 to 16.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-11956:
--------------------------------------
bq. Matěj Novotný, that's very interesting. I'm wondering, though, if that's a Weld-specific behavior. The javadoc doesn't seem to guarantee that postConstruct() will be called.
Well, {{InjectionTarget#postConstruct()}}, according to spec, _calls the @PostConstruct callback, if it exists_. It kind of makes sense to call this every time and within this method you figure whether you actually have some of those methods, or make it no-op otherwise. Cannot guarantee that other impls don't handle it differently though.
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11116) Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception)
by ziad saade (Jira)
[ https://issues.jboss.org/browse/WFLY-11116?page=com.atlassian.jira.plugin... ]
ziad saade commented on WFLY-11116:
-----------------------------------
Hi Paul
If I have the below code flow:
Method1{
Method2();
stm1;
}
Method2(){
Method3();
return;
}
Method3(){
response.sendredirect("index.html");
}
When executing Method1 the below flow should be executed:
1-Execute Method2()
2-Execute Method3()
3-Execute Stm1
4-Execute response.sendredirect("index.html");
However Wildfly is executing as feollow.
1-Execute Method2()
2-Execute Method3()
3-Execute response.sendredirect("index.html") and in parallel execute stm1
Kindly advice if there's any configuration settings to stop this behavior:
PS: Don't hesitate to contact me if you want further details.
Best Regards
(Restricted to jira-users group)
> Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11116
> URL: https://issues.jboss.org/browse/WFLY-11116
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.1.Final, 12.0.0.Final, 13.0.0.Final, 15.0.0.Final
> Reporter: ziad saade
> Assignee: Paul Ferraro
> Priority: Critical
>
> I have two Servlets Book and BookPreview the attribute is set in Book Servlet as follow:
>
> Book.java
> TestBean testBean=null;
> if(session.getAttribute("testBean")!=null)
> testBean = (TestBean)session.getAttribute("testBean");
> else{
> testBean=new TestBean();
> session.setAttribute("testBean",testBean);
> }
> testBean.setAmount("10");
>
> response.sendRedirect("BookPreview");
>
>
> The session attribute can be retrieved and the page is loaded normally and the Amount value is displayed however when submitting the form (Post Action in BookPreview.java) Null Pointer exception is generated.
>
> BookPreview.java
>
> TestBean testBean = (TestBean)session.getAttribute("testBean");
> String amount = testBean.getAmount; //Null pointer exception when submitting the form
>
> <form method="Post" action="BookPreview">
>
> </form>
>
> TestBean.java
>
> public class TestBean implements java.io.Serializable {
>
> private static final long serialVersionUID = 1L;
> private String amount;
>
> public String getAmount() {
> return amount;
> }
>
> public void setAmount(String amount) {
> this.amount = amount;
> }
> }
>
> Kindly advice how to fix the problem at the level of the server configuration.
> PS: I am not getting the exception when deploying the same application under other J EE application servers (Tomcat....)
>
> Thanks and Best Regards
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11978) EAR with 2+ JPA does not shutdown cleanly
by Darryl Miles (Jira)
[ https://issues.jboss.org/browse/WFLY-11978?page=com.atlassian.jira.plugin... ]
Darryl Miles commented on WFLY-11978:
-------------------------------------
Ok both JPA projects have persistence.xml the trigger seems to be the use of:
hibernate.cache.use_second_level_cache=true
hibernate.cache.use_query_cache=true
As in:
<persistence version="2.2"
xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://xmlns.jcp.org/xml/ns/persistence
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">
<persistence-unit name="blah-blah.jpa.project1">
<!-- ... SNIP ... -->
<properties>
<!-- ... SNIP ... -->
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
<!-- ... SNIP ... -->
Remove these 2 line and all is well on shutdown.
> EAR with 2+ JPA does not shutdown cleanly
> -----------------------------------------
>
> Key: WFLY-11978
> URL: https://issues.jboss.org/browse/WFLY-11978
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 16.0.0.Final
> Environment: Windows JDK8 WF16
> Reporter: Darryl Miles
> Assignee: Scott Marlow
> Priority: Major
> Attachments: td8948.txt
>
>
> EAR with 2+ JPA does not shutdown cleanly.
> I see in the logs each JPA project have an entry:
> WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project1'
> WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project2'
> then a few lines later:
> WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'blah....jpa.project2'
> I never see the "phase 1 of 2" entry for "jpa.project1" in the log.
> The container will wait 300 seconds and timeout.
> The management console during the time shows
> Operation: undeploy
> Execution Status: awaiting-stablility.
> The container is killed and the configuration.xml still contains the EAR deployment info, as undeploy did not complete.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11978) EAR with 2+ JPA does not shutdown cleanly
by Darryl Miles (Jira)
[ https://issues.jboss.org/browse/WFLY-11978?page=com.atlassian.jira.plugin... ]
Darryl Miles updated WFLY-11978:
--------------------------------
Attachment: td8948.txt
> EAR with 2+ JPA does not shutdown cleanly
> -----------------------------------------
>
> Key: WFLY-11978
> URL: https://issues.jboss.org/browse/WFLY-11978
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 16.0.0.Final
> Environment: Windows JDK8 WF16
> Reporter: Darryl Miles
> Assignee: Scott Marlow
> Priority: Major
> Attachments: td8948.txt
>
>
> EAR with 2+ JPA does not shutdown cleanly.
> I see in the logs each JPA project have an entry:
> WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project1'
> WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project2'
> then a few lines later:
> WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'blah....jpa.project2'
> I never see the "phase 1 of 2" entry for "jpa.project1" in the log.
> The container will wait 300 seconds and timeout.
> The management console during the time shows
> Operation: undeploy
> Execution Status: awaiting-stablility.
> The container is killed and the configuration.xml still contains the EAR deployment info, as undeploy did not complete.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11978) EAR with 2+ JPA does not shutdown cleanly
by Darryl Miles (Jira)
[ https://issues.jboss.org/browse/WFLY-11978?page=com.atlassian.jira.plugin... ]
Darryl Miles commented on WFLY-11978:
-------------------------------------
Just to say I have the results from these 2 commands.
I need to work out how to sanitize the output to be able to send the svcdump.txt but I think I can see the stack track of the problem in thread dump.
See attached thread dump.
"ServerService Thread Pool -- 96" #274 prio=5 os_prio=0 tid=0x000000002e24f800 nid=0x20cc in Object.wait() [0x000000004d89e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:359)
- locked <0x00000005c61cee50> (a org.infinispan.factories.InternalCacheFactory$1)
at org.infinispan.cache.impl.SimpleCacheImpl.stop(SimpleCacheImpl.java:173)
at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520)
at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520)
at org.infinispan.hibernate.cache.v53.impl.BaseRegionImpl.destroy(BaseRegionImpl.java:74)
at org.infinispan.hibernate.cache.v53.impl.QueryResultsRegionImpl.destroy(QueryResultsRegionImpl.java:17)
at org.hibernate.cache.internal.EnabledCaching.close(EnabledCaching.java:546)
at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:803)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2$1.run(PersistenceUnitServiceImpl.java:259)
- locked <0x000000071a88c298> (a org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2$1)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2$1.run(PersistenceUnitServiceImpl.java:236)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:649)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2.run(PersistenceUnitServiceImpl.java:290)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
I say it is when 2 JPAs are in the EAR as when I remove one from the project EAR build and comment out @PersistenceContext usage to make it start up. I can shutdown Wildfly ok with either JPA running individually.
> EAR with 2+ JPA does not shutdown cleanly
> -----------------------------------------
>
> Key: WFLY-11978
> URL: https://issues.jboss.org/browse/WFLY-11978
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 16.0.0.Final
> Environment: Windows JDK8 WF16
> Reporter: Darryl Miles
> Assignee: Scott Marlow
> Priority: Major
>
> EAR with 2+ JPA does not shutdown cleanly.
> I see in the logs each JPA project have an entry:
> WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project1'
> WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project2'
> then a few lines later:
> WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'blah....jpa.project2'
> I never see the "phase 1 of 2" entry for "jpa.project1" in the log.
> The container will wait 300 seconds and timeout.
> The management console during the time shows
> Operation: undeploy
> Execution Status: awaiting-stablility.
> The container is killed and the configuration.xml still contains the EAR deployment info, as undeploy did not complete.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3015) [DMN Designer] Prohibit parallel item definition edition
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-3015?page=com.atlassian.jira.plugi... ]
Guilherme Gomes reassigned DROOLS-3015:
---------------------------------------
Assignee: Daniel José dos Santos (was: Guilherme Gomes)
> [DMN Designer] Prohibit parallel item definition edition
> --------------------------------------------------------
>
> Key: DROOLS-3015
> URL: https://issues.jboss.org/browse/DROOLS-3015
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn, Screenshot from 2018-09-24 13-00-45.png
>
>
> We should prohibit parallel edit operation of item definitions in managa custom data type dialog. It brings troubles in different scenarios:
> h2. Save parent item
> # Open attached dmn model
> # Invoke manage custom data type dialog
> # Expand *tProfile* item
> # Click on edit next to *tProfile (Structure)*
> # Click on edit next to *Name (string)*
> # Change *Name* to *Name_updated*
> # Change *tProfile* to *tProfile_updated*
> # Click *Save* next *tProfile_updated*
> # Save button for *Name_updated* will disappear
> # Changes saved just for parent item *tProfile_updated*
> h2. Save referred items
> # Open attached dmn model
> # Invoke manage custom data type dialog
> # Click on edit next to *tGender (string)*
> # Click on edit next to *tGenders (tGender)*
> # Rename *tGender* to *tGender_updated*
> # Click *Save* next *tGender_updated*
> # The data type select box for *tGenders* will disappear, see
> ## !Screenshot from 2018-09-24 13-00-45.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months