Third party maven repositories is against Fdroid inclusion

[paroj]

Regarding publication in Fdroid: the application requires libraries from third party maven repo http://4thline.org/m2. Third party maven repositories is against Fdroid inclusion policy and the maintainers made it clear to get rid of 4thline repo (https://gitlab.com/fdroid/fdroiddata/-/merge_requests/3501). The required libs (cling and cling-support) aren't on maven central. There is a supported fork of cling - jupnp (https://github.com/jupnp/jupnp) but I failed to build the app with fresh versions of fork and old versions are not available on maven central. So, that's the problem to solve.

Originally posted by @norohind in #5 (comment)

[paroj]

the version published on fdroid has some workarounds in place not to require those repos:
https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/github.daneren2005.dsub.yml#L211

the general issue is that we depend on unmaintained libs though

[norohind]

Just updating progress: I succeeded in running the app with jupnp instead of cling. Going to test dlna functionality thoroughly and submit a PR in next couple days.

Also, running with kryo from maven central instead of local binary seems to be fine.

[norohind]

Updating progress, I tested dlna functionality with jupnp lib and it hardly works, sometimes it really plays media, but controls doesn't work. I managed to get logging of jupnp lib to work, but those logs didn't clarified the situation. Basically, the server (a remote player) responds with 500 internal error code to any control command. I'm taking a pause in debugging this problem. I have all changes in my fork here if somebody want to try: https://github.com/norohind/DSub2000/tree/cling2jupnp

[norohind]

Pause wasn't long. Basically, it is jupnp reuses a pre-created pool of platform specific implementation of javax.xml.parsers.DocumentBuilder, which are created with a platform specific implementation of javax.xml.parsers.DocumentBuilderFactory. Key moment here that for instance of a factory method .setNamespaceAware(true) is being called. It tells factory to create instances of DocumentBuilder which are namespace aware.
After every use of an instance of DocumentBuilder and before returning it to the pool, the jupnp calls a .reset() method on the instance.

On my physical phone, this platform specific implementation is org.apache.harmony.xml.parsers. In this particular implementation, on method .reset() it unconditionally sets internal flag namespaceAware of a specific instance to false.

Jupnp ends up putting this not anymore namespace aware DocumentBuilder back to pool. Eventually (after 20 message parsed messages, this is pool size) not namespace aware builder parses a message and in this condition jupnp gets s:Envelope getUnprefixedNodeName(envelopeElement) as return value of the call, throws RuntimeException line below, it is being caught somewhere above, somewhere any
failure with jupnp (ex. cling) is being wrapped up in it's 500 internal server error log message, hence why I initially thought it's a remote player responds to any command with 500 http code.

I'm not really sure what to do next, on apache harmony website it says Apache Harmony is retired at the Apache Software Foundation since Nov 16, 2011, so reporting to them isn't an option. I'm not sure why anything deprecated since 2011 is present on my phone. Also, I'm still figuring if this thing is a runtime component of android or DSub have it included, and we are able to replace it with something else. In JDK17 it uses com.sun.org.apache.xerces.internal.jaxp implementation and that's work just fine.

Why it wasn't a problem with cling? Because this pool based mechanism was introduced exclusivly to jupnp fork.

UPD: Checked classes in DSub apk, the org.apache.harmony.xml.parsers isn't there. I guess it is part of system runtime then.

[norohind]

I submitted an issue to jupnp: jupnp/jupnp#232, maybe they can figure something. I'm also concerned it wasn't a problem for another android application utilizing jupnp: aos-AVP, nova-video-player/aos-AVP#74.

[paroj]

I submitted an issue to jupnp:

thats what I was about to suggest. Maybe the know where the harmony stuff is coming from..