maven repo and 5.0-X version

[Zsolt Kúti]

Hello,

To include Rio dependencies into my project reference in maven
repo (at least in gradle) for rio-4.2 was:
'org.rioproject:rio:4.2'

The same schema does not work for the new:
'org.rioproject:rio:5.0-M3'

From here:
https://github.com/dreedyman/Rio/blob/master/pom.xml
I have seen a reference to 'main' and try to no avail.

What is the descriptor that can pull in every necessary artifacts?
It would be nice to have this info on the website for non-maveners.

Another question: 5.0-M4 is also available from the repo while on the
Rio project page refers only to M3. What version would you suggest to
use?

Thanks.

Zsolt

[Dennis Reedy]

Hi Zsolt,

It depends on what you want to depend on. In general you'll need to include org.rioproject:rio-lib:version. The examples will help you here. As for M3 vs M4, I recommend M4. I am trying to finalize that and get that out the door.

Dennis

> --
> You received this message because you are subscribed to the Google Groups "Rio Users Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rio-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Zsolt Kúti]

Hello Dennis,

On Wed, 10 Sep 2014 08:34:13 -0400
Dennis Reedy <dennis...@gmail.com> wrote:

> Hi Zsolt,

> It depends on what you want to depend on. In general you'll need to
> include org.rioproject:rio-lib:version. The examples will help you

That was what I needed.

> here. As for M3 vs M4, I recommend M4. I am trying to finalize that
> and get that out the door.

Then I need a distribution for M4, I guess. Checked the maven repo, but
under 'distribution' only the pom is available at present.

Should I use M3 temporally?


Thanks for your help.
Zsolt

[Dennis Reedy]

Hi Zsolt,

I just pushed a 5.0-M4 distribution, available here. Let me know if you have any issues/problems, etc...

Dennis

[Zsolt Kúti]

Hello Dennis,

On Wed, 10 Sep 2014 11:08:14 -0400

Dennis Reedy <dennis...@gmail.com> wrote:


> Hi Zsolt,

> I just pushed a 5.0-M4 distribution, available here. Let me know if
> you have any issues/problems, etc...

Thanks for doing it promptly.
Now that M4 distribution is used and all my dependencies and
related codes updated accordingly I could rebuild my project.

Services starts perfectly, but my (web) client throw exception in code
where ServiceDiscoveryManager instantiated:


SEVERE:
java.net.BindException: Address already in use
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at
java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:95)
at java.net.DatagramSocket.bind(DatagramSocket.java:376) at
java.net.MulticastSocket.<init>(MulticastSocket.java:172) at
java.net.MulticastSocket.<init>(MulticastSocket.java:137) at
net.jini.discovery.LookupDiscovery$AnnouncementListener.<init>(LookupDiscovery.java:1030)
at net.jini.discovery.LookupDiscovery$7.run(LookupDiscovery.java:3091)
at java.security.AccessController.doPrivileged(Native Method) at
net.jini.security.Security$5.run(Security.java:543) at
java.security.AccessController.doPrivileged(Native Method) at
net.jini.security.Security.doPrivileged(Security.java:540) at
net.jini.discovery.LookupDiscovery.beginDiscovery(LookupDiscovery.java:3089)
at net.jini.discovery.LookupDiscovery.<init>(LookupDiscovery.java:1902)


sockstat shows a few processes opened by rio that uses port 4160. Also,
with no rio running the client code does not fail.


Any idea how to resolve this much appreciated.

Zsolt

[Dennis Reedy]

Hi Zsolt,

The 4160 port is the default port that the service registrar uses. When you start a monitor, it also starts reggie. Are you using port 4160 in your web client?

Dennis

[Zsolt Kúti]

On Fri, 12 Sep 2014 07:19:51 -0400

Dennis Reedy <dennis...@gmail.com> wrote:


> Hi Zsolt,

>

> The 4160 port is the default port that the service registrar uses.
> When you start a monitor, it also starts reggie. Are you using port
> 4160 in your web client?

Yes, I am. The (web) client uses a ServiceDiscoveryManager.


Zs

[Zsolt Kúti]

On Fri, 12 Sep 2014 13:31:27 +0200
Zsolt Kúti <kuti....@prolan.hu> wrote:


> Yes, I am. The (web) client uses a ServiceDiscoveryManager.

What more, a LookupDiscovery...

Zs

[Dennis Reedy]

You are mentioning clients that are looking to connect to port 4160. Are you attempting to open a ServerSocket with the 4160 port?

[Zsolt Kúti]

On Fri, 12 Sep 2014 08:33:19 -0400
Dennis Reedy <dennis...@gmail.com> wrote:


> You are mentioning clients that are looking to connect to port 4160.
> Are you attempting to open a ServerSocket with the 4160 port?

My code does:
new LookupDiscovery(groups);

and this results in :
new MulticastSocket(Constants.discoveryPort);

in LookupDiscovery$AnnouncementListener.:

Exception is raised at this point.

Zs

[Zsolt Kúti]

Hello Dennis,

It seems Rio has not changed with respect to its reggie usage, neither
has my code to its LookupDiscovery usage.
Exception is thrown in the client code at
AbstractPalinDatagramSocketImplbind0(lport, laddr) (coming from new
MulticastSocket(4160)) where laddr is a wildcard address.

If it has any relevance: River was updated from 2.2.1 to 2.2.2 and jdk7
is used instead of jdk6.

This issue especially tantalizing as it prevents me from working.

Zsolt

[Zsolt Kúti]

On Fri, 12 Sep 2014 10:45:18 +0200
Zsolt Kúti <kuti....@prolan.hu> wrote:


> On Wed, 10 Sep 2014 11:08:14 -0400
> Dennis Reedy <dennis...@gmail.com> wrote:

> > I just pushed a 5.0-M4 distribution, available here. Let me know
> > if you have any issues/problems, etc...

> SEVERE:
> java.net.BindException: Address already in use
> at java.net.PlainDatagramSocketImpl.bind0(Native Method)
> at
> java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:95)
> at java.net.DatagramSocket.bind(DatagramSocket.java:376) at
> java.net.MulticastSocket.<init>(MulticastSocket.java:172) at
> java.net.MulticastSocket.<init>(MulticastSocket.java:137) at
> net.jini.discovery.LookupDiscovery$AnnouncementListener.<init>(LookupDiscovery.java:1030)

It revealed this was a java related quirk.

I first set java.net.preferIPv4Stack property directly for Rio, later
put it into <jre>/lib/net.properties file to make it global, just as
http.proxyHost/Port. Due to other changes made parallel I only realized
a bit later that this property is NOT set for some reason for jvms.
After directly setting it for both Rio and Tomcat the problem had gone.



At this point another issue came up during discovery of services in the
client. A ServiceDiscoveryManager instance is using a LookupDiscovery
that produces:

Sep 17, 2014 9:00:57 AM
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask run INFO:
exception occurred during unicast discovery to 193.91.83.22:4160 with
constraints InvocationConstraints[reqs: {}, prefs: {}]
java.net.MalformedURLException: unknown protocol: artifact at
java.net.URL.<init>(URL.java:592) at java.net.URL.<init>(URL.java:482)
at java.net.URL.<init>(URL.java:431) at
sun.rmi.server.LoaderHandler.pathToURLs(LoaderHandler.java:769) at
sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:167)

(For full log see the attachment.)

If it matters, for starting services the same opstring used as with
4.2 and files are under Rio's deploy dir, no artifact based deployment
is used.

Should I change something in my config to get it work with Rio5?

Thanks
Zsolt

[Dennis Reedy]

Hi Zsolt,

Your client must add the following system property:

-Djava.protocol.handler.pkgs=org.rioproject.url

HTH

Dennis

> --
> You received this message because you are subscribed to the Google Groups "Rio Users Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rio-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

> <rio.log>

[Zsolt Kúti]

On Wed, 17 Sep 2014 08:06:36 -0400
Dennis Reedy <dennis...@gmail.com> wrote:


> Hi Zsolt,

> Your client must add the following system property:
> -Djava.protocol.handler.pkgs=org.rioproject.url

Thanks Dennis,

I tried this in two ways:
1. passed it to Tomcat on command line
2. in a static block checked the property, and added to pkgs string so
that existing values were kept, e.g.: javax.net.ssl|org.rioproject.url

Regardless of the above it throws the same exception.

Zsolt

[Dennis Reedy]

Zsolt,

I'm not sure how Tomcat handles this, you may try this:

/* If the artifact URL has not been configured, set it up */

import org.rioproject.url.artifact.ArtifactURLStreamHandlerFactory;

try {
new URL("artifact:foo");
} catch (MalformedURLException e) {
URL.setURLStreamHandlerFactory(new ArtifactURLStreamHandlerFactory());
}

Dennis

[Zsolt Kúti]

Hello Dennis,

On Wed, 17 Sep 2014 10:59:46 -0400
Dennis Reedy <dennis...@gmail.com> wrote:


> Zsolt,

> I'm not sure how Tomcat handles this, you may try this:

> /* If the artifact URL has not been configured, set it up */
> import org.rioproject.url.artifact.ArtifactURLStreamHandlerFactory;

> try {
> new URL("artifact:foo");
> } catch (MalformedURLException e) {
> URL.setURLStreamHandlerFactory(new
> ArtifactURLStreamHandlerFactory());
> }

Things are a bit getting complicated in a servlet environment it seems.

Tomcat sets its own URLStreamHandlerFactory (for jndi lookups) and
setting that factory cannot be done once again.

To trick TC by setting this factory to Rio's via reflection does
not work, just as the canonical way of adding new Handler [*]. In
order TC could use this handler classes/jars should be put under TC's
'endorsed' directory.

[*] -Djava.protocol.handler.pkgs=org.rioproject.url passed to TC
http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html
http://jcifs.samba.org/src/docs/faq.html#ukproto

This does help getting rid of 'unknow protocol' message, but induces
NoClassDefFoundErrors (see below). I tried to put all Rio libs to
under endorsed and in a next step the jsk ones () too. Did not help.
Putting Rio libs under TC's 'lib' revives the 'unknown protocol' error.

Has anbody succeeded to make Rio 5.x work in a servlet environment?
I wonder how 4.2 does it differently.

Zsolt


java.lang.NoClassDefFoundError: Could not initialize class
java.rmi.server.RMIClassLoader at
net.jini.loader.ClassLoading.loadClass(ClassLoading.java:138) at
net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:296)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at
net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358) at
com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:394)
at net.jini.discovery.LookupDiscovery$13.run(LookupDiscovery.java:3393)
at java.security.AccessController.doPrivileged(Native Method) at
net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3390)
at
net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3421)
at
net.jini.discovery.LookupDiscovery.access$4000(LookupDiscovery.java:696)
at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.doRun(LookupDiscovery.java:1762)
at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.access$3700(LookupDiscovery.java:1713)
at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask$1.run(LookupDiscovery.java:1730)
at java.security.AccessController.doPrivileged(Native Method) at
net.jini.security.Security$4.run(Security.java:509) at
java.security.AccessController.doPrivileged(Native Method) at
net.jini.security.Security.doPrivileged(Security.java:507) at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.run(LookupDiscovery.java:1728)
at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)

[Dennis Reedy]

Zsolt,

Okay, one more thing to try:

-Djava.rmi.server.RMIClassLoaderSpi=org.rioproject.rmi.ResolvingLoader

I'll try and recreate what you have as well

Dennis

[Zsolt Kúti]

Hello Dennis,

On Fri, 19 Sep 2014 07:41:42 -0400

Dennis Reedy <dennis...@gmail.com> wrote:


> Zsolt,

> Okay, one more thing to try:

> -Djava.rmi.server.RMIClassLoaderSpi=org.rioproject.rmi.ResolvingLoader

It takes me a bit further. Various NoClassDefFoundErrors keep popping
up. First started with slf4j stuff, then it logged a missing RIO_HOME
setting, giving it to TC complained NCDFE for groovy, then came an NPE:

java.lang.NullPointerException
at
org.codehaus.groovy.reflection.GeneratedMetaMethod$DgmMethodRecord.loadDgmInfo(GeneratedMetaMethod.java:163)
at
org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.registerMethods(MetaClassRegistryImpl.java:183)
at
org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:93)
at
org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:71)
at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:33) at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:162)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:192)
at
org.rioproject.resolver.ProjectModuleResolver.$getStaticMetaClass(ProjectModuleResolver.groovy)
at
org.rioproject.resolver.ProjectModuleResolver.<init>(ProjectModuleResolver.groovy)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at
java.lang.Class.newInstance(Class.java:374) at
java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373) at
java.util.ServiceLoader$1.next(ServiceLoader.java:445) at
org.rioproject.resolver.ResolverHelper.doGetResolver(ResolverHelper.java:236)
at
org.rioproject.resolver.ResolverHelper.getResolver(ResolverHelper.java:205)

I am here now, but has to leave at this point.

Currently the content of 'endorsed':
groovy-all-2.2.1.jar
jsk-resources-2.2.2.jar
resolver-project-5.0-M4.jar
rio-platform-5.0-M4.jar
jsk-lib-2.2.2.jar
resolver-aether-5.0-M4.jar
rio-lib-5.0-M4.jar
slf4j-api-1.7.5.jar
jsk-platform-2.2.2.jar resolver-api-5.0-M4.jar
rio-logging-support-5.0-M4.jar

> I'll try and recreate what you have as well

Thank you for your effort and support.
I'll be back on monday.

Zsolt

[Zsolt Kúti]

On Fri, 19 Sep 2014 07:41:42 -0400

Dennis Reedy <dennis...@gmail.com> wrote:


> Zsolt,

> Okay, one more thing to try:
> -Djava.rmi.server.RMIClassLoaderSpi=org.rioproject.rmi.ResolvingLoader
> I'll try and recreate what you have as well

Hello Dennis,

A little ping, any update on this?
I did not have time to further investigate the case, but I am not in
a hurry to switch to 5.x.

Thanks!
Zsolt

[Dennis Reedy]

Hi Zsolt,

I haven't been able to make any progress on this. What would help is if you had an example you could post. Maybe put something on GitHub, or send a reproducable test case?

Thanks

Dennis

[Zsolt Kúti]

On Tue, 14 Oct 2014 08:45:21 -0400
Dennis Reedy <dennis...@gmail.com> wrote:


> Hi Zsolt,

>

> I haven't been able to make any progress on this. What would help is
> if you had an example you could post. Maybe put something on GitHub,
> or send a reproducable test case?

I still have to postpone this until I can find some time. I'll back
with this then.

Zsolt