[JBoss JIRA] (WFLY-4208) Migrate Quickstarts to JDK 7
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-4208:
-------------------------------------
Summary: Migrate Quickstarts to JDK 7
Key: WFLY-4208
URL: https://issues.jboss.org/browse/WFLY-4208
Project: WildFly
Issue Type: Sub-task
Reporter: Eduardo Martins
Assignee: Eduardo Martins
WildFly Quickstarts are compatible with JDK 7, but still not fully taking advantage of its new language features.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4207) Migrate Quickstarts to Java EE 7
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-4207:
-------------------------------------
Summary: Migrate Quickstarts to Java EE 7
Key: WFLY-4207
URL: https://issues.jboss.org/browse/WFLY-4207
Project: WildFly
Issue Type: Sub-task
Reporter: Eduardo Martins
Assignee: Eduardo Martins
Update WildFly Quickstart's code to take advantage of the technologies with major updates on Java EE 7, for instance JAX-RS and JMS.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Philippe Marschall commented on WFLY-1598:
------------------------------------------
[Let’s Encrypt|https://letsencrypt.org/] may be an option to automatically get the certificates.
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 9.0.0.Beta1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4206) jboss-javaee-7.0-with-resteasy bom exposes JUnit as dependency
by James Bodkin (JIRA)
James Bodkin created WFLY-4206:
----------------------------------
Summary: jboss-javaee-7.0-with-resteasy bom exposes JUnit as dependency
Key: WFLY-4206
URL: https://issues.jboss.org/browse/WFLY-4206
Project: WildFly
Issue Type: Bug
Components: REST
Affects Versions: 8.2.0.Final
Reporter: James Bodkin
Assignee: Stuart Douglas
Priority: Minor
The jboss-javaee-7.0-with-resteasy bom includes the JUnit dependency, I believe this should be included with the jboss-javaee-7.0-with-tools bom instead. (It seems to already be included in tools as well)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4006) Java EE 7 with all BOM lacks JAX-RS 2.0 API dependency
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4006?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-4006:
---------------------------------------
{{org.wildfly.bom:jboss-javaee-7.0-with-all}} transitively imports dependencies from {{org.jboss.resteasy:resteasy-bom}}, JBoss Resteasy project own BOM, which includes JAX-RS 2.0 API through artifact {{org.jboss.resteasy:jaxrs-api}}. We could exclude that artifact and import {{org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec}}, but IMHO that should be done only in next major version release, other projects (e.g. WildFly Quickstarts) rely on {{org.jboss.resteasy:jaxrs-api}}, and who knows what's out there in the community.
> Java EE 7 with all BOM lacks JAX-RS 2.0 API dependency
> ------------------------------------------------------
>
> Key: WFLY-4006
> URL: https://issues.jboss.org/browse/WFLY-4006
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final
> Reporter: Vineet Reynolds
> Assignee: Tomaz Cerar
>
> Adding the {{org.wildfly.bom:jboss-javaee-7.0-with-all}} BOM to a Maven project does not pull in the {{org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec}} dependency.
> Hence, users of this BOM are required to add the JAX-RS 2.0 API, specifying the version explicitly, to consume the JAX-RS APIs in their projects.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-1421) Listing JNDI tree from container when an entry is not available causes exception
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1421?page=com.atlassian.jira.plugin.... ]
Eduardo Martins resolved WFLY-1421.
-----------------------------------
Fix Version/s: (was: Awaiting Volunteers)
Resolution: Rejected
Context#list() is the JNDI API equivalent to the JNDI View management op. With respect to Context#listBindings(), the exception must be thrown, its result requires the concrete bound objects to be retrieved.
> Listing JNDI tree from container when an entry is not available causes exception
> --------------------------------------------------------------------------------
>
> Key: WFLY-1421
> URL: https://issues.jboss.org/browse/WFLY-1421
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jan Martiska
> Assignee: Eduardo Martins
>
> When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
> How to reproduce:
> Bind a federated JNDI context, like so:
> {noformat}
> /subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
> {noformat}
> then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
> *Other option* - as a simpler reproducer, you may just add any invalid URL in the java.naming.provider.url property, then it will fail always.
> After that, do this in a deployed application:
> {noformat}
> InitialContext ctx = new InitialContext();
> ctx.listBindings("java:global");
> {noformat}
> it will throw a NamingException after the connection attempt times out.
> {noformat}
> javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
> at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
> at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
> at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 39 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
> at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> ... 40 more
> Caused by: javax.naming.CommunicationException: ldap.cz:3890 [Root exception is java.net.ConnectException: Connection timed out]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
> ... 47 more
> Caused by: java.net.ConnectException: Connection timed out
> at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
> ... 60 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-1421) Listing JNDI tree from container when an entry is not available causes exception
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1421?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-1421:
-------------------------------------
Assignee: Eduardo Martins
> Listing JNDI tree from container when an entry is not available causes exception
> --------------------------------------------------------------------------------
>
> Key: WFLY-1421
> URL: https://issues.jboss.org/browse/WFLY-1421
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jan Martiska
> Assignee: Eduardo Martins
> Fix For: Awaiting Volunteers
>
>
> When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
> How to reproduce:
> Bind a federated JNDI context, like so:
> {noformat}
> /subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
> {noformat}
> then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
> *Other option* - as a simpler reproducer, you may just add any invalid URL in the java.naming.provider.url property, then it will fail always.
> After that, do this in a deployed application:
> {noformat}
> InitialContext ctx = new InitialContext();
> ctx.listBindings("java:global");
> {noformat}
> it will throw a NamingException after the connection attempt times out.
> {noformat}
> javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
> at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
> at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
> at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 39 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
> at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> ... 40 more
> Caused by: javax.naming.CommunicationException: ldap.cz:3890 [Root exception is java.net.ConnectException: Connection timed out]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
> ... 47 more
> Caused by: java.net.ConnectException: Connection timed out
> at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
> ... 60 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-261) Add way to properly parse JNDI urls in AS codebase
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins closed WFLY-261.
--------------------------------
Resolution: Out of Date
> Add way to properly parse JNDI urls in AS codebase
> --------------------------------------------------
>
> Key: WFLY-261
> URL: https://issues.jboss.org/browse/WFLY-261
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 9.0.0.Beta1
>
>
> This is a followup of AS7-2138. Original code, in case no URL context threw NamingException. The AS7-2138 introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4196.
----------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Rejected
This is not really a bug, however I am updating Undertow to use setContentLength instead of setContentLengthLong where possible (which should be pretty much all cases).
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 9.0.0.Beta1
>
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
