February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14433) WildFly 22. Compile JSP error. JBWEB004062

by Jose Gracia (Jira)

Jose Gracia created WFLY-14433: ---------------------------------- Summary: WildFly 22. Compile JSP error. JBWEB004062 Key: WFLY-14433 URL: https://issues.redhat.com/browse/WFLY-14433 Project: WildFly Issue Type: Bug Affects Versions: 22.0.1.Final Reporter: Jose Gracia Assignee: Brian Stansberry Hello, When I try to run an application on WildFly 22.0.1 server, I get the following error: --------------------------------------------------------- Stacktrace: INFO JBWEB004062: Unable to compile class for JSP: JBWEB004060: An error occurred at line: 12 in the jsp file: /jsps/global/error.jsp Syntax error on tokens, delete these tokens 9: <% 10: // Introducing the exception in the User container 11: UserContainer userContainer = (UserContainer)session.getAttribute(StrutsKeys.SES_USER_CONTAINER); 12: if(exception┬áinstanceof┬ájava.net.SocketException){ 13: }else{ 14: if (userContainer == null) { 15: userContainer = new UserContainer(); --------------------------------------------------------- Best regards. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14424) Add EJB client test case for interacting with two non-overlapping clusters

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-14424?page=com.atlassian.jira.plugi... ] Richard Achmatowicz updated WFLY-14424: --------------------------------------- Description: Write a test case which shows: * how to configure two non-overlapping clusters * how to specify the cluster affinity value which will be generated by the cluster for use in topology updates * the creation of EJB client proxies which can interact with those clusters via the cluster affinity value * creation of proxies using EJBClient API and JNDI lookup for both stateful and stateless bean deployments was: Write a test case which shows: * how to configure two non-overlapping clusters * how to specify the cluster affinity value which will be generated by the cluster for use in topology updates * the creation of EJB client proxies which can interact with those clusters via the cluster specification * creation of proxies using EJBClient API and JNDI lookup for both stateful and stateless bean deployments > Add EJB client test case for interacting with two non-overlapping clusters > --------------------------------------------------------------------------- > > Key: WFLY-14424 > URL: https://issues.redhat.com/browse/WFLY-14424 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 22.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 23.0.0.Beta1 > > > Write a test case which shows: > * how to configure two non-overlapping clusters > * how to specify the cluster affinity value which will be generated by the cluster for use in topology updates > * the creation of EJB client proxies which can interact with those clusters via the cluster affinity value > * creation of proxies using EJBClient API and JNDI lookup for both stateful and stateless bean deployments -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-10612) Include EJB's IIOP Binding when EJB is deployed logging

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-10612?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty updated WFLY-10612: --------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13238 > Include EJB's IIOP Binding when EJB is deployed logging > ------------------------------------------------------- > > Key: WFLY-10612 > URL: https://issues.redhat.com/browse/WFLY-10612 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 12.0.0.Final > Reporter: Brad Maxwell > Assignee: Ranabir Chakraborty > Priority: Major > Fix For: 20.0.0.Beta1, 20.0.0.Final > > Attachments: WFLY-10612.jar, java.policy > > > It would be useful when EJBs configured with IIOP enabled or when enabled by default for all, that it log the binding for the IIOP interface as it is different from the JNDI bindings. > <iiop enable-by-default="true" use-qualified-name="true"/> > {code} > INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: > java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean > java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean > java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean > java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:jboss/exported/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > java:jboss/exported/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > {code} > Something like this when use-qualified-name="true" > {code} > IIOP bindings for for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: > iiop-eap7/HelloSessionBean > {code} > or use-qualified-name="false" > {code} > IIOP bindings for for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: > HelloSessionBean > {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-6023) DMN inline memoization of FEEL temporal literal constants

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-6023: -------------------------------------- Summary: DMN inline memoization of FEEL temporal literal constants Key: DROOLS-6023 URL: https://issues.redhat.com/browse/DROOLS-6023 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14432) Add migrate operations for MP Health and MP Metrics subsystems

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14432?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-14432: ------------------------------------ Description: Add 'migrate' operations to the root resource of the MP Health and Metrics subsystems. These allow people running configs without the new base health and metrics subsystems to add them. Operation should: 1) See if the capability provided by their corresponding 'base' subsystem is present. If yes, exit. If no, the process must be in admin-only mode or the resource running the op could not exist due to the missing capability. 2) See if the base subsystem's extension is installed; if not add it. 3) Add the base subsystem using the config values its own config. 4) Clear from its own config any setting moved to the base. was: Add 'migrate' operations to the root resource of the MP Health and Metrics subsystems. Operation should: 1) See if the capability provided by their corresponding 'base' subsystem is present. If yes, exit. (If no, the process must be in admin-only mode or the resource running the op could not exist due to the missing capability). 2) See if the base subsystem's extension is installed; if not add it. 3) Add the base subsystem using the config values its own config. 4) Clear from its own config any setting moved to the base. > Add migrate operations for MP Health and MP Metrics subsystems > -------------------------------------------------------------- > > Key: WFLY-14432 > URL: https://issues.redhat.com/browse/WFLY-14432 > Project: WildFly > Issue Type: Feature Request > Components: MP Health, MP Metrics > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 23.0.0.Beta1 > > > Add 'migrate' operations to the root resource of the MP Health and Metrics subsystems. These allow people running configs without the new base health and metrics subsystems to add them. > Operation should: > 1) See if the capability provided by their corresponding 'base' subsystem is present. If yes, exit. If no, the process must be in admin-only mode or the resource running the op could not exist due to the missing capability. > 2) See if the base subsystem's extension is installed; if not add it. > 3) Add the base subsystem using the config values its own config. > 4) Clear from its own config any setting moved to the base. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14432) Add migrate operations for MP Health and MP Metrics subsystems

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14432: --------------------------------------- Summary: Add migrate operations for MP Health and MP Metrics subsystems Key: WFLY-14432 URL: https://issues.redhat.com/browse/WFLY-14432 Project: WildFly Issue Type: Feature Request Components: MP Health, MP Metrics Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 23.0.0.Beta1 Add 'migrate' operations to the root resource of the MP Health and Metrics subsystems. Operation should: 1) See if the capability provided by their corresponding 'base' subsystem is present. If yes, exit. (If no, the process must be in admin-only mode or the resource running the op could not exist due to the missing capability). 2) See if the base subsystem's extension is installed; if not add it. 3) Add the base subsystem using the config values its own config. 4) Clear from its own config any setting moved to the base. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (JBMETA-421) org.jboss.metadata.ejb.parser.jboss.ejb3.Namespace needs to account for Jakarta

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/JBMETA-421?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved JBMETA-421. ------------------------------------- Resolution: Won't Do I'm resolving this as a Won't Do for now. If others see this and feel it's a good thing to do, please feel free to re-open. The uses of these Namespace enum values are in parsers for jboss-specific deployment descriptors that incorporate elements from the EE spec namespaces. Supporting parsing documents that use the jboss-specific xsds but pull in the Jakarta namespace instead the JCP one that the jboss xsd specifies is an enhancement for (possible) convenience, not a requirement. I'm putting Won't Do on this mostly because I'm not willing to invest the time to think through whether changes are the right thing to do. I won't do it myself and don't want to leave this open encouraging others to take on something that seems trivial but perhaps isn't. > org.jboss.metadata.ejb.parser.jboss.ejb3.Namespace needs to account for Jakarta > ------------------------------------------------------------------------------- > > Key: JBMETA-421 > URL: https://issues.redhat.com/browse/JBMETA-421 > Project: JBoss Metadata > Issue Type: Enhancement > Components: ejb > Reporter: Brian Stansberry > Priority: Major > Labels: EE9 > > https://github.com/jboss/metadata/blob/master/ejb/src/main/java/org/jboss... looks like it needs an entry for https://jakarta.ee/xml/ns/jakartaee > And then all code that uses that enum should be adapted. > Edit: also org.jboss.metadata.ear.parser.jboss.Namespace. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (JBMETA-421) org.jboss.metadata.ejb.parser.jboss.ejb3.Namespace needs to account for Jakarta

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/JBMETA-421?page=com.atlassian.jira.plugi... ] Brian Stansberry updated JBMETA-421: ------------------------------------ Issue Type: Enhancement (was: Task) > org.jboss.metadata.ejb.parser.jboss.ejb3.Namespace needs to account for Jakarta > ------------------------------------------------------------------------------- > > Key: JBMETA-421 > URL: https://issues.redhat.com/browse/JBMETA-421 > Project: JBoss Metadata > Issue Type: Enhancement > Components: ejb > Reporter: Brian Stansberry > Priority: Major > Labels: EE9 > > https://github.com/jboss/metadata/blob/master/ejb/src/main/java/org/jboss... looks like it needs an entry for https://jakarta.ee/xml/ns/jakartaee > And then all code that uses that enum should be adapted. > Edit: also org.jboss.metadata.ear.parser.jboss.Namespace. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (JBMETA-420) Add the EE 9 xsds

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/JBMETA-420?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on JBMETA-420: ----------------------------------------- I have updated with the final files and pushed a PR. Note that the added files were all obtained from https://jakarta.ee/xml/ns/jakartaee/#9. Note also that the following xsds available from there were not added as JBoss Metadata did not previously package those xsds: https://jakarta.ee/xml/ns/jakartaee/jakartaee_web_services_metadata_handl... https://jakarta.ee/xml/ns/jakartaee/batchXML_2_0.xsd https://jakarta.ee/xml/ns/jakartaee/beans_3_0.xsd https://jakarta.ee/xml/ns/jakartaee/jobXML_2_0.xsd https://jakarta.ee/xml/ns/jakartaee/connector_2_0.xsd https://jakarta.ee/xml/ns/jaxb/bindingschema_3_0.xsd https://jakarta.ee/xml/ns/jaxws/wsdl_customizationschema_3_0.xsdhttps://j... https://jakarta.ee/xml/ns/persistence/orm/orm_3_0.xsd https://jakarta.ee/xml/ns/validation/validation-mapping-3.0.xsd https://jakarta.ee/xml/ns/validation/validation-configuration-3.0.xsd > Add the EE 9 xsds > ----------------- > > Key: JBMETA-420 > URL: https://issues.redhat.com/browse/JBMETA-420 > Project: JBoss Metadata > Issue Type: Enhancement > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > Follow up on JBMETA-419 by adding the relevant EE 9 xsd documents. > They're not final yet so I figure it's better to add them separately from the JBMETA-419 parsing enhancement, which isn't particularly reliant on the exact schema files. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14431) Do not use WildFly Core dependency management for dependencies that are test-only in core

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14431: --------------------------------------- Summary: Do not use WildFly Core dependency management for dependencies that are test-only in core Key: WFLY-14431 URL: https://issues.redhat.com/browse/WFLY-14431 Project: WildFly Issue Type: Task Components: Build System Reporter: Brian Stansberry Assignee: Brian Stansberry The root WF pom's dependencyManagement depends on the root WF Core pom, with import scope. The result is the WF Core dependencyManagement is pulled into full WF, eliminating the need to duplicate entries. In general this is a good thing, as it produces alignment between core and full. The downside to it is it is easy to change versions in core without thinking about their use in full WF, e.g. without pinging the leads for the affected components in full. The tradeoff here is generally worth it IMHO, but where it is not is for libs that are used only for testing in core but are used in production in full WF. There we should explicitly declare the version and dep in full WF and not rely on the import. Apache Commons IO is the specific case that led to this issue; there may be others. Note that it's ok to me to let core control test dependencies for truly test libraries where we want alignment on how testing works. Related to this I want to work out a way to get such dependencies out of the main dependencyManagement in WF Core. That will help prevent problems popping up in the future, plus may make it easier to control test-only deps in core without fearing that what's done in core would impact full WF. Netty is a good example where that's currently a problem in core. Some test frameworks use it, and I'm reluctant to control the version in core's dependencyManagment for fear of getting tangled up with the far more important use in full WF. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2021