[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-5966?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-5966:
----------------------------------------
[~yersan] Can this be resolved and then closed?
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.redhat.com/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 18.0.0.Beta1, 18.0.0.Final
>
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> -feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
> -jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml-
> -jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml-
> -jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml-
> -jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml-
> -jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml-
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13305) Bootable jar for Wildfly
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13305?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13305:
------------------------------------
Fix Version/s: 21.0.0.Beta1
> Bootable jar for Wildfly
> ------------------------
>
> Key: WFLY-13305
> URL: https://issues.redhat.com/browse/WFLY-13305
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> Provides support for running MicroService apps without the need archive it as a deployment and without the need to deploy it in a running application server.
> Provides support for ability to run MicroService apps on the Operating Systems command line as a bootable jar.
> Provides support for developing and running the app. "java -jar app.jar" and maven command line interface.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13295) REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13295?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13295:
------------------------------------
Fix Version/s: 20.0.0.Final
[~ochaloup] I put a 20.0.0.Final Fix Version on this just because I assume the linked PR is in the version now in master and it sounded like you've written the intended test case.
> REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13295
> URL: https://issues.redhat.com/browse/WFLY-13295
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 19.0.0.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 20.0.0.Final
>
>
> The REST-AT inbound bridge is activated per deployment. It's activated for a deployment which contains a REST endpoint identified with `@Path` annotation where in the same class has to be included either annotation `@Transactional` or `@TransactionAttribute`.
> The point is to activate the inbound bridge for deployments which contain a transactional managed method (CDI or EJB) which can receive the txn context, ie. possibly a context of REST-AT transaction as well.
> The issue is that EJB beans are transactional by default. The EJB bean class does not need to specify any `@TransactionalAttribute` to be already container managed (from txn perspective) with attribute `REQUIRED`. Which means taking incoming txn context and will work with it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13065) Options for reverse-proxy max-request-time and connection-idle-timeout are specified as seconds
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13065?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13065:
------------------------------------
Fix Version/s: 20.0.0.Final
> Options for reverse-proxy max-request-time and connection-idle-timeout are specified as seconds
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-13065
> URL: https://issues.redhat.com/browse/WFLY-13065
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
> Fix For: 20.0.0.Final
>
>
> In the reverse-proxy configuration the options {{max-request-time}} and {{connection-idle-timeout}} are specified and managed as seconds in CLI, when they are really milliseconds in undertow.
> {noformat}
> /subsystem=undertow/configuration=handler/reverse-proxy=LBProxy:read-resource-description
> ...
> "connection-idle-timeout" => {
> "type" => INT,
> "description" => "The amount of time a connection can be idle before it will be closed. Connections will not time out
> once the pool size is down to the configured minimum (as configured by cached-connections-per-thread)",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => 60L,
> "unit" => "SECONDS",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...
> "max-request-time" => {
> "type" => INT,
> "description" => "The maximum time that a proxy request can be active for, before being killed",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => -1,
> "unit" => "SECONDS",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...
> {noformat}
> The class [ReverseProxyHandler|https://github.com/wildfly/wildfly/blob/master/undert...] just passes the value (no modification) to undertow and it's clearly millis in undertow, for example the [max-request-time|https://github.com/undertow-io/undertow/blob/master/core...].
> I has suffered this confusion myself doing some tests, I set 60 as the max request time, and it was too short in my env (because they are millis instead of seconds).
> We need to change description to millis to respect current configurations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months