[JBoss JIRA] (WFLY-12300) Convert to Jakarta EE 8 specification APIs
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-12300:
-------------------------------------
[~cfang]
{quote}
So shall we use the upstream javadoc settings, and override the jboss-parent ones? I think we didn't modify the api substantially enough to warrant our own copyright declaration, and using the original Jakarta one is more suitable.
{quote}
As part of forking, we should use the copyright declaration that Jakarta is using, as I think anything else would violate their copyright. Thanks for catching this important point. :-)
As far as the *how* we do this, your idea of overriding the jboss-parent settings, makes sense. I haven't tried this myself. Please let us know if that works for you, so we can follow your example.
For source files, we should also use the copyright declaration that Jakarta is using.
> Convert to Jakarta EE 8 specification APIs
> ------------------------------------------
>
> Key: WFLY-12300
> URL: https://issues.jboss.org/browse/WFLY-12300
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: 18.0.0.Final
>
>
> This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
> The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
> I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
> The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
> For each JBoss specification API fork that existed in EAP 7.2, a designated owner for that API jar has been determined. The task for each owner consists of:
> # Create/update a jboss.org Jakarta fork.
> # Track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
> # For the fork, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
> Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
> _Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
> _In fact, doing this is strongly encouraged as it allows us to further verify the fork._
> Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
> For artifacts that will not involve a fork (e.g. JPA), the component owner should plan to file a PR moving to the Jakarta artifact (e.g. jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta is available in maven central (after Jakarta EE 8 final release).
> Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
> ||API||Owner||
> |jakarta.annotation:jakarta.annotation-api|Yeray Borges|
> |jakarta.batch:jakarta.batch-api|Cheng Fang|
> |jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
> |jakarta.el:jakarta.el-api|Scott Marlow|
> |jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
> |jakarta.faces:jakarta.faces-api|Farah Juma|
> |jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
> |jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
> |jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
> |jakarta.resource:jakarta.resource-api|Stefano Maestri|
> |jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
> |jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
> |jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
> |jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
> |jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
> |jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
> |jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
> |jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
> |jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
> |jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
> |jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12364) Reference for EJB NodeSelector should be able to use the default implementations of ejb-client DeploymentNodeSelector and VlusterNodeSelector
by Wolf-Dieter Fink (Jira)
[ https://issues.jboss.org/browse/WFLY-12364?page=com.atlassian.jira.plugin... ]
Wolf-Dieter Fink commented on WFLY-12364:
-----------------------------------------
Enhancement for ejb-client configuration.
The static implementations in the DeploymentNodeSelector or ClusterNodeSelector can be used inside of jboss-ejb-client.xml by simply configure the field name like
DeploymentNodeSelector "FIRST", "RANDOM", "ROUND_ROBIN", "RANDOM_PREFER_LOCAL" (default)
ClusterNodeSelector "RANDOM", "RANDOM_PREFER_LOCAL", "ROUND_ROBIN", "DEFAULT_PREFER_LOCAL" (default)
DEFAULT_PREFER_LOCAL will try to connect up to 5 random nodes if less nodes are connected from that cluster.
> Reference for EJB NodeSelector should be able to use the default implementations of ejb-client DeploymentNodeSelector and VlusterNodeSelector
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12364
> URL: https://issues.jboss.org/browse/WFLY-12364
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Priority: Major
>
> The Interfaces DeploymentNodeSelector and ClusterNodeSelector contains static implementations of several useful implementations.
> But it is not possible to use this as the configuration files does not allow it.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-7297) It is not possible to explode and browse deployments within deployment
by Michal Petrov (Jira)
[ https://issues.jboss.org/browse/WFLY-7297?page=com.atlassian.jira.plugin.... ]
Michal Petrov commented on WFLY-7297:
-------------------------------------
Do we want "explode subdeployment X" rather than "explode all subdeployments"? What I've tried works fairly well except we cannot tell that the subdeployments are exploded, so the option is always visible. (What we can do is tell the user they are already exploded based on the error code.) I don't know if there is a way to keep track of that on client side.
> It is not possible to explode and browse deployments within deployment
> ----------------------------------------------------------------------
>
> Key: WFLY-7297
> URL: https://issues.jboss.org/browse/WFLY-7297
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jan Štefl
> Assignee: Harald Pehl
> Priority: Major
> Attachments: jboss-kitchensink-ear.ear
>
>
> It is possible to explode and browse content of top level deployment but there is no possibility for such operation with deployment.
> Attaching test deployent for experiments.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ELY-1859) Add configuration to allow control of ACC capture
by Darran Lofthouse (Jira)
Darran Lofthouse created ELY-1859:
-------------------------------------
Summary: Add configuration to allow control of ACC capture
Key: ELY-1859
URL: https://issues.jboss.org/browse/ELY-1859
Project: WildFly Elytron
Issue Type: Feature Request
Components: Authentication Client
Reporter: Darran Lofthouse
ELY-1854 added a system property to switch off the capturing of the AccessControlContext, this would be a good candidate to also expose directly through the configuration.
We capture it for some specific mechanisms so it may be desirable to configure this on a per configuration basis as needed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ELY-1851) Elytron ldaps realm fails if a referral is returned inside a search
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1851?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1851:
----------------------------------
Fix Version/s: 1.6.4.CR1
> Elytron ldaps realm fails if a referral is returned inside a search
> -------------------------------------------------------------------
>
> Key: ELY-1851
> URL: https://issues.jboss.org/browse/ELY-1851
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.6.3.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Fix For: 1.6.4.CR1
>
>
> Elytron LdapRealm fails to follow a referral when ldaps is used (the {{ThreadLocalSSLSocketFactory}} is not set).
> With a configuration similar to this one ({{memberOf}} is used to locate groups):
> {code:xml}
> <ldap-realm name="ldap-realm" dir-context="ldap-dir-context" direct-verification="true">
> <identity-mapping rdn-identifier="sAMAccountName" use-recursive-search="true" search-base-dn="DC=redhat,DC=com">
> <attribute-mapping>
> <attribute reference="memberOf" from="cn" to="Roles" role-recursion="3"/>
> </attribute-mapping>
> </identity-mapping>
> </ldap-realm>
> ...
> <dir-context name="ldap-dir-context" url="ldaps://ldap.redhat.com:636" principal="cn=Administrator,cn=Users,DC=redhat,DC=com" referral-mode="FOLLOW" ssl-context="ldaps-context">
> <credential-reference store="credstore" alias="ldap_password"/>
> </dir-context>
> {code}
> If we have a group (or user) which contains a {{memberOf}} of another ldap, something like the following:
> {noformat}
> dn: CN=group-with-external-members,OU=Groups,DC=redhat,DC=com
> ...
> memberOf: CN=group-in-another-domain,OU=Groups,DC=lab,DC=redhat,DC=com
> {noformat}
> The following exception is thrown when a referral is returned for a group that is inside another ldapserver of the forest:
> {noformat}
> TRACE [org.jboss.remoting.remote.server] (management task-1) Server sending authentication rejected: java.lang.RuntimeException: ELY01079: ldap-realm realm failed to obtain attributes for entry [CN=group-with-external-members,OU=Groups,DC=redhat,DC=com]
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributesFromSearch(LdapSecurityRealm.java:808)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$4(LdapSecurityRealm.java:768)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.forEachAttributeValue(LdapSecurityRealm.java:841)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:766)
> at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1321)
> at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:828)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:754)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAttributes(LdapSecurityRealm.java:516)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAuthorizationIdentity(LdapSecurityRealm.java:497)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1923)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1952)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:509)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:489)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:872)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:60)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:146)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:942)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: ldap-realm realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1141)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributesFromSearch(LdapSecurityRealm.java:797)
> ... 46 more
> Caused by: javax.naming.CommunicationException: ldap.lab.redhat.com:636 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without ThreadLocalSSLSocketFactory thread local setting]
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:96)
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:151)
> at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1861)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:335)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.searchWithPagination(LdapSecurityRealm.java:1161)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1038)
> ... 47 more
> Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without ThreadLocalSSLSocketFactory thread local setting
> at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:296)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:215)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1609)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
> at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
> at org.jboss.as.naming.context.ObjectFactoryBuilder$ReferenceUrlContextFactoryWrapper.getObjectInstance(ObjectFactoryBuilder.java:293)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:119)
> ... 58 more
> {noformat}
> The reason seems to be that the {{ThreadLocalSSLSocketFactory}} is not set when doing a search, so, if a referral is returned the new search created inside the current one has no access to the {{SSLSocketFactory}} in the thread local.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months