Hi, Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), I'm adding instructions to the JMS quickstarts to deploy them on OpenShift. The helloworld-mdb is working fine but I have an issue with the helloworld-jms one[1]. In this quick start, the Java client makes a lookup to JNDI to retrieve the JMS resources. The quickstart uses the "http-remoting://localhost:8080" as the JNDI provider URL for a local WildFly server. When I host WildFly on OpenShift, that URL should translate to http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case http-remoting://helloworldjms-jmesnil.rhcloud.com:80) However this does not work: $ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting:// helloworldjms-jmesnil.rhcloud.com:80 ... Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit> INFO: XNIO version 3.2.0.Final Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit> INFO: XNIO NIO Implementation Version 3.2.0.Final Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit> INFO: JBoss Remoting version 4.0.0.Final Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory" Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main SEVERE: Failed to connect to any server. Servers tried: [http-remoting:// helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid response code 200)] Remote naming is correctly complaining that the HTTP Upgrade handshake responded with a 200 OK instead of a 100 Continue. Indeed, the deployed WildFly server does not upgrade my connection. You can check by hand using curl: $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==' ... * Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.30.0 > Host: helloworldjms-jmesnil.rhcloud.com > Accept: */* > Connection:upgrade > Upgrade:jboss-remoting > Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A== > < HTTP/1.1 200 OK < Date: Mon, 17 Feb 2014 14:23:37 GMT * Server Wildfly 8 is not blacklisted < Server: Wildfly 8 < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT < X-Powered-By: Undertow 1 < Content-Type: text/html < Content-Length: 41708 < Vary: Accept-Encoding ... [Home Page content follows] The undertow's http-listener is the default one; <http-listener name="default" socket-binding="http" proxy-address-forwarding="true"/> I tried removing the proxy-address-forwarding attribute but that did not change anything. Has someone managed to use remote naming with WildFly on OpenShift? Am I missing something obvious to make it run? jeff [1] https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/hello... -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Just correcting the subject line. On 17/02/14 15:09, Stuart Douglas wrote: > The relevant config item should be in the remoting subsystem: > > > <http-connector name="http-remoting-connector" > connector-ref="default" security-realm="ApplicationRealm"/> > > This is the bit that registers the HTTP upgrade handler with Undertow. > > Stuart > > > On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <jmesnil(a)redhat.com > <mailto:jmesnil@redhat.com>> wrote: > > Hi, > > Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks > Farah!), I’m adding instructions to the JMS quickstarts to deploy > them on OpenShift. > > The helloworld-mdb is working fine but I have an issue with the > helloworld-jms one[1]. > > In this quick start, the Java client makes a lookup to JNDI to > retrieve the JMS resources. > > The quickstart uses the “http-remoting://localhost:8080” as the JNDI > provider URL for a local WildFly server. > > When I host WildFly on OpenShift, that URL should translate to > http-remoting://<app>-<namespace>.rhcloud.com:80 > <http://rhcloud.com:80> (in my case > http-remoting://helloworldjms-jmesnil.rhcloud.com:80 > <http://helloworldjms-jmesnil.rhcloud.com:80>) > However this does not work: > > > $ mvn clean compile exec:java > -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80 > <http://helloworldjms-jmesnil.rhcloud.com:80> > … > Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit> > INFO: XNIO version 3.2.0.Final > Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.2.0.Final > Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 4.0.0.Final > Feb 17, 2014 3:28:46 PM > org.jboss.as.quickstarts.jms.HelloWorldJMSClient main > INFO: Attempting to acquire connection factory > "jms/RemoteConnectionFactory" > Feb 17, 2014 3:28:47 PM > org.jboss.as.quickstarts.jms.HelloWorldJMSClient main > SEVERE: Failed to connect to any server. Servers tried: > [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 > <http://helloworldjms-jmesnil.rhcloud.com:80> (java.io.IOException: > Invalid response code 200)] > > Remote naming is correctly complaining that the HTTP Upgrade > handshake responded with a 200 OK instead of a 100 Continue. > Indeed, the deployed WildFly server does not upgrade my connection. > You can check by hand using curl: > > $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H > 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H > 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==' > ... > * Connected to helloworldjms-jmesnil.rhcloud.com > <http://helloworldjms-jmesnil.rhcloud.com> (50.17.25.239) port 80 (#0) >> GET / HTTP/1.1 >> User-Agent: curl/7.30.0 >> Host: helloworldjms-jmesnil.rhcloud.com > <http://helloworldjms-jmesnil.rhcloud.com> >> Accept: */* >> Connection:upgrade >> Upgrade:jboss-remoting >> Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A== >> > < HTTP/1.1 200 OK > < Date: Mon, 17 Feb 2014 14:23:37 GMT > * Server Wildfly 8 is not blacklisted > < Server: Wildfly 8 > < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT > < X-Powered-By: Undertow 1 > < Content-Type: text/html > < Content-Length: 41708 > < Vary: Accept-Encoding > … > [Home Page content follows] > > The undertow’s http-listener is the default one; > > <http-listener name="default" socket-binding="http" > proxy-address-forwarding="true”/> > > I tried removing the proxy-address-forwarding attribute but that did > not change anything. > > Has someone managed to use remote naming with WildFly on OpenShift? > Am I missing something obvious to make it run? > > jeff > > [1] > https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/hello... > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

The relevant config item should be in the remoting subsystem: <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> This is the bit that registers the HTTP upgrade handler with Undertow. Stuart On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > Hi, > > Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks > Farah!), I’m adding instructions to the JMS quickstarts to deploy them on > OpenShift. > > The helloworld-mdb is working fine but I have an issue with the > helloworld-jms one[1]. > > In this quick start, the Java client makes a lookup to JNDI to retrieve > the JMS resources. > > The quickstart uses the “http-remoting://localhost:8080” as the JNDI > provider URL for a local WildFly server. > > When I host WildFly on OpenShift, that URL should translate to > http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case > http-remoting://helloworldjms-jmesnil.rhcloud.com:80) > However this does not work: > > > $ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting:// > helloworldjms-jmesnil.rhcloud.com:80 > … > Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit> > INFO: XNIO version 3.2.0.Final > Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.2.0.Final > Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 4.0.0.Final > Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient > main > INFO: Attempting to acquire connection factory > "jms/RemoteConnectionFactory" > Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient > main > SEVERE: Failed to connect to any server. Servers tried: [http-remoting:// > helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid > response code 200)] > > Remote naming is correctly complaining that the HTTP Upgrade handshake > responded with a 200 OK instead of a 100 Continue. > Indeed, the deployed WildFly server does not upgrade my connection. You > can check by hand using curl: > > $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H > 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: > Xj8ZjttC3aixB1bAZ9w39A==' > ... > * Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 > (#0) > > GET / HTTP/1.1 > > User-Agent: curl/7.30.0 > > Host: helloworldjms-jmesnil.rhcloud.com > > Accept: */* > > Connection:upgrade > > Upgrade:jboss-remoting > > Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A== > > > < HTTP/1.1 200 OK > < Date: Mon, 17 Feb 2014 14:23:37 GMT > * Server Wildfly 8 is not blacklisted > < Server: Wildfly 8 > < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT > < X-Powered-By: Undertow 1 > < Content-Type: text/html > < Content-Length: 41708 > < Vary: Accept-Encoding > … > [Home Page content follows] > > The undertow’s http-listener is the default one; > > <http-listener name="default" socket-binding="http" > proxy-address-forwarding="true”/> > > I tried removing the proxy-address-forwarding attribute but that did not > change anything. > > Has someone managed to use remote naming with WildFly on OpenShift? > Am I missing something obvious to make it run? > > jeff > > [1] > https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/hello... > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

From: "Jason Greene" <jason.greene(a)redhat.com&gt; To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com&gt; Cc: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt;, "WildFly Dev" <wildfly-dev(a)lists.jboss.org&gt;, "Farah Juma" <fjuma(a)redhat.com&gt; Sent: Tuesday, February 18, 2014 3:58:49 PM Subject: Re: [wildfly-dev] Issue with HTTP upgrade for remote naming on OpenShit? Farah mentions port forwards in here blog. I suppose this is the only solution currently. https://community.jboss.org/people/fjuma/blog/2014/02/14/wildfly-8-final-... On Feb 18, 2014, at 2:40 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com&gt; wrote: > Looks like this is issue with openshift itself. > > there is proxy in front of gear and that proxy does not know how to do http > upgrade. > For web sockets there is special exception to make this work on different > port. > > see: > https://www.openshift.com/content/at-least-one-port-for-external-use-excl... > https://www.openshift.com/blogs/paas-websockets > https://www.openshift.com/content/websockets-on-port-80-and-443 > https://bugzilla.redhat.com/show_bug.cgi?id=978597 > > I will do some more digging to see if we can use some hack/workaround to > make it work. > > -- > tomaz > > > > On Mon, Feb 17, 2014 at 4:09 PM, Stuart Douglas > <stuart.w.douglas(a)gmail.com&gt; wrote: > The relevant config item should be in the remoting subsystem: > > > <http-connector name="http-remoting-connector" > connector-ref="default" security-realm="ApplicationRealm"/> > > This is the bit that registers the HTTP upgrade handler with Undertow. > > Stuart > > > On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > Hi, > > Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), > I’m adding instructions to the JMS quickstarts to deploy them on > OpenShift. > > The helloworld-mdb is working fine but I have an issue with the > helloworld-jms one[1]. > > In this quick start, the Java client makes a lookup to JNDI to retrieve the > JMS resources. > > The quickstart uses the “http-remoting://localhost:8080” as the JNDI > provider URL for a local WildFly server. > > When I host WildFly on OpenShift, that URL should translate to > http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case > http-remoting://helloworldjms-jmesnil.rhcloud.com:80) > However this does not work: > > > $ mvn clean compile exec:java > -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80 > … > Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit> > INFO: XNIO version 3.2.0.Final > Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.2.0.Final > Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 4.0.0.Final > Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient > main > INFO: Attempting to acquire connection factory > "jms/RemoteConnectionFactory" > Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient > main > SEVERE: Failed to connect to any server. Servers tried: > [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 > (java.io.IOException: Invalid response code 200)] > > Remote naming is correctly complaining that the HTTP Upgrade handshake > responded with a 200 OK instead of a 100 Continue. > Indeed, the deployed WildFly server does not upgrade my connection. You can > check by hand using curl: > > $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' > -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: > Xj8ZjttC3aixB1bAZ9w39A==' > ... > * Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 > (#0) > > GET / HTTP/1.1 > > User-Agent: curl/7.30.0 > > Host: helloworldjms-jmesnil.rhcloud.com > > Accept: */* > > Connection:upgrade > > Upgrade:jboss-remoting > > Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A== > > > < HTTP/1.1 200 OK > < Date: Mon, 17 Feb 2014 14:23:37 GMT > * Server Wildfly 8 is not blacklisted > < Server: Wildfly 8 > < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT > < X-Powered-By: Undertow 1 > < Content-Type: text/html > < Content-Length: 41708 > < Vary: Accept-Encoding > … > [Home Page content follows] > > The undertow’s http-listener is the default one; > > <http-listener name="default" socket-binding="http" > proxy-address-forwarding="true”/> > > I tried removing the proxy-address-forwarding attribute but that did not > change anything. > > Has someone managed to use remote naming with WildFly on OpenShift? > Am I missing something obvious to make it run? > > jeff > > [1] > https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/hello... > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

On Feb 19, 2014, at 2:15 AM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > On 18 Feb 2014, at 22:19, Farah Juma <fjuma(a)redhat.com&gt; wrote: > > I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs: At this stage, port forwarding works. Thanks Farah. The remaining issue is the way HornetQ configures its connectors. HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case). The ugly ugly part of it is that the connector must know the host of the server to connect to. In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129). If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work. The HornetQ team has some features planned for the cloud. I’ll let them know about this. [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/or... -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/

The outbound-socket-binding config doesn't allow this to be configured correctly, using the correct address?

On 2/19/14, 9:19 AM, Jeff Mesnil wrote: > [changing the subject as HTTP upgrade is not part of the discussion] > > On 19 Feb 2014, at 15:52, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > >> The outbound-socket-binding config doesn't allow this to be configured >> correctly, using the correct address? > > Yes you’re right, I overlooked it. > By convenience, the messaging subsystem allows to use a socket-binding to configure the connector but the correct way is to use an outbound-socket-binding (and it lets specify the host). > (I’ve closed WFLY-2963 as we don’t need it). > > Since I am using port-forwarding around the openshift proxy issue, I configure the messaging connector with an outbound-socket to connect to 127.0.0.1 (that’s is then forwarded to the OpenShift server). > With that tweak, the quickstart works but it’s ugly. > > However, I wonder if that’ll also work when we would not need to use port-forwarding. > > In that case, I would just need to add an outbound-socket-binding with the DNS name of my app (helloworldjms2-jmesnil.rhcloud.com). > Looking at OutboundSocketBinding, its getDestinationAddress() method returns a /resolved/ InetAddress, not the name that’s set in the management model. > And the OpenShift server returns a different resolved IP address for this domain name than my local machine: > > [openshift] helloworldjms2-jmesnil.rhcloud.com -> 10.235.52.32 > [localhost] helloworldjms2-jmesnil.rhcloud.com -> 23.22.246.120 > > When my client on my local machine will try to connect to the server, it will use the 10.235.52.32 IP address that’s not reachable instead 23.22.246.120. > > For my use case to work, I would need to get the “raw” destination address (whatever the user specified in the management model) and not let the server resolve the address (the address will be resolved by the client). > Is that a valid use case or am I missing something obvious? > I think OutboundSocketBinding needs to add a getter for the unresolvedDestinationAddress string. Which getter a caller uses would depend on their use case; i.e. whether they want a locally resolved address. There are some uses that AFAIK are purely internal, e.g. org.jboss.as.clustering.infinispan.subsystem.CacheAdd, so we shouldn't abandon the resolved address getter. Plus that would be an incompatible change. I propose adding OutboundSocketBinding.getUnresolvedDestinationAddress(), deprecating the current getDestinationAddress() and adding a new getResolvedDestinationAddress(). The latter is just a clearer name for the same function.

On Mar 5, 2014, at 4:31 AM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: I’ve spent some time running WildFly on OpenShift and playing with it. * I’ve added a quickstart using WebSocket API[1] and it works fine on OpenShift. => note however that OpenShift requires to use a different port for WebSocket (8000) than for HTTP (80) even though both are mapped to WildFly’s 8080 internal port. * OpenShift does not support custom protocols for HTTP upgrade beside web socket[2][3] => all the quick starts using remote naming, EJB, JMS from external clients will not work unless port-forwarding is enabled. jeff [1] https://github.com/wildfly/quickstart/tree/master/helloworld-websocket [2] https://bugzilla.redhat.com/show_bug.cgi?id=1071862 [3] https://trello.com/c/swGjabeH jeff > On 19 Feb 2014, at 09:15, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > > >> On 18 Feb 2014, at 22:19, Farah Juma <fjuma(a)redhat.com&gt; wrote: >> >> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs: > > At this stage, port forwarding works. Thanks Farah. > > The remaining issue is the way HornetQ configures its connectors. > > HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case). > The ugly ugly part of it is that the connector must know the host of the server to connect to. > In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129). > If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work. > > The HornetQ team has some features planned for the cloud. I’ll let them know about this. > > [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/or... > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev