[Red Hat JIRA] (WFLY-14188) Update Apache avro 1.10.1
by Yoann Rodière (Jira)
[ https://issues.redhat.com/browse/WFLY-14188?page=com.atlassian.jira.plugi... ]
Yoann Rodière edited comment on WFLY-14188 at 12/8/20 2:45 AM:
---------------------------------------------------------------
[~xf01213] [~smarlow] I can tell you for a fact that upgrading Avro will break Hibernate Search, unless we patch it too and upgrade it in WildFly. Patching Hibernate Search should be doable, but tests in this area are sparse.
So it's all a matter of backward compatibility and whether we're ready to take the risk of breaking existing applications. Last we talked about this, we decided not to upgrade.
EDIT: To clarify, I'm not aware of any reason the upgrade would break backward compatibility. I'm just mentioning this as it's a (manageable) risk that comes will all software upgrades. It's possible there are benefits that outweigh these risks.
was (Author: y.rodiere):
[~xf01213] [~smarlow] I can tell you for a fact that upgrading Avro will break Hibernate Search, unless we patch it too and upgrade it in WildFly. Patching Hibernate Search should be doable, but tests in this area are sparse.
So it's all a matter of backward compatibility and whether we're ready to take the risk of breaking existing applications. Last we talked about this, we decided not to upgrade.
> Update Apache avro 1.10.1
> -------------------------
>
> Key: WFLY-14188
> URL: https://issues.redhat.com/browse/WFLY-14188
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Server
> Affects Versions: 22.0.0.Alpha1
> Reporter: Boris Unckel
> Assignee: Brian Stansberry
> Priority: Major
>
> Update [Apache avro 1.10.1|https://mvnrepository.com/artifact/org.apache.avro/avro/1.10.1] ([released 2020-12-03|https://avro.apache.org/releases.html])
> 2020-12-07: Release Note generation is outdated
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14143) Can not inject bean from module
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-14143?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski reassigned WFLY-14143:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Matěj Novotný)
> Can not inject bean from module
> -------------------------------
>
> Key: WFLY-14143
> URL: https://issues.redhat.com/browse/WFLY-14143
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading
> Affects Versions: 21.0.1.Final
> Reporter: Mariusz Kulig
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: mymodule.zip, reproduce_sample.zip
>
>
> Bean from module cannot be injected to bean in deployment. It works properly on Wildfly 20.0.1.Final but does not work on Wildlfy 21.0.1.Final.
> I registered module which contains @ApplicationScoped CDI bean. I tried do deploy WAR archive that contains library that depends on this module. The library contains proper entry in Dependencies section in MANIFEST.MF file.
> I get exception:
>
> {code:java}
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type HelloService with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject com.example.mylib.MyLib.helloService
> at com.example.mylib.MyLib.helloService(MyLib.java:0)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
> {code}
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14132) jboss-ejb3.xml is ignored for exploded deployments
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-14132?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-14132:
-----------------------------------
While it is better to use {{deploymentUnit.getName()}} to determine the deployment type, the [deployment scanner|https://github.com/wildfly/wildfly-core/blob/master/deployment-sc...] seems to assume the exploded directories always ends with certain extensions (.jar, .war, .ear, .rar, .sar). By looking at docs and examples, they all use such directories with proper extensions.
> jboss-ejb3.xml is ignored for exploded deployments
> --------------------------------------------------
>
> Key: WFLY-14132
> URL: https://issues.redhat.com/browse/WFLY-14132
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 14.0.1.Final, JBoss AS7 7.1.1.Final, 21.0.1.Final
> Reporter: Jan-Willem Gmelig Meyling
> Assignee: Cheng Fang
> Priority: Major
> Labels: ejb-jar.xml, jboss-ejb3.xml
>
> {{EjbJarParsingDeploymentUnitProcessor}} distinguishes between a WAR and JAR deployment based on the file extension of the name of the deployment root. For exploded deployments however, this deployment root may be a folder without any file extension. As a result the logic fails to detect either a JAR or WAR file and the {{ejb-jar.xml}} and {{jboss-ejb3.xml}} files are ignored. A better way could be to determine the extension from the name of {{DeploymentUnit}} instead.
> Code from: [https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...]
> {code:java}
> private static VirtualFile getDescriptor(final VirtualFile deploymentRoot, final String descriptorName) {
> // Locate the descriptor
> final VirtualFile descriptor;
> // EJB 3.1 FR 20.4 Enterprise Beans Packaged in a .war
> if (isWar(deploymentRoot)) {
> // it's a .war file, so look for the ejb-jar.xml in WEB-INF
> descriptor = deploymentRoot.getChild(WEB_INF + "/" + descriptorName);
> } else if (deploymentRoot.getName().toLowerCase(Locale.ENGLISH).endsWith(JAR_FILE_EXTENSION)) {
> descriptor = deploymentRoot.getChild(META_INF + "/" + descriptorName);
> } else {
> // neither a .jar nor a .war. Return
> return null;
> }
> if (descriptor == null || !descriptor.exists()) {
> // no descriptor found, nothing to do!
> return null;
> }
> return descriptor;
> }
> {code}
>
> I encountered this issue on WildFly 14.0.1.Final, but the code is also present in the current master and goes back to versions as early as 7.1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14114) Class loader leaks when JDBC driver as jar deployment is undeloyed
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14114?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-14114:
---------------------------------------
Assignee: Tomasz Adamski (was: Brian Stansberry)
> Class loader leaks when JDBC driver as jar deployment is undeloyed
> ------------------------------------------------------------------
>
> Key: WFLY-14114
> URL: https://issues.redhat.com/browse/WFLY-14114
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Lin Gao
> Assignee: Tomasz Adamski
> Priority: Major
> Labels: downstream_dependency
> Fix For: 22.0.0.Beta1
>
>
> Class loader leaks when JDBC driver as jar deployment is undeloyed. It will eventually leads to Metaspace out of memory error when "-XX:MaxMetaspaceSize" option is specified.
>
> Normally JDBC driver is not undeloyed or redeployed by user frequently, but configuration reload command, which is regularly used, also triggers JDBC driver redeployment and cause class loader leak.
> JDBC driver should be deregistered while undeloying.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14114) Class loader leaks when JDBC driver as jar deployment is undeloyed
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14114?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-14114:
---------------------------------------
Assignee: Brian Stansberry (was: Tomasz Adamski)
> Class loader leaks when JDBC driver as jar deployment is undeloyed
> ------------------------------------------------------------------
>
> Key: WFLY-14114
> URL: https://issues.redhat.com/browse/WFLY-14114
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Lin Gao
> Assignee: Brian Stansberry
> Priority: Major
> Labels: downstream_dependency
> Fix For: 22.0.0.Beta1
>
>
> Class loader leaks when JDBC driver as jar deployment is undeloyed. It will eventually leads to Metaspace out of memory error when "-XX:MaxMetaspaceSize" option is specified.
>
> Normally JDBC driver is not undeloyed or redeployed by user frequently, but configuration reload command, which is regularly used, also triggers JDBC driver redeployment and cause class loader leak.
> JDBC driver should be deregistered while undeloying.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months