red5-server
red5-server copied to clipboard
Red5
Custom class loading problem
From @GoogleCodeExporter on March 15, 2015 16:54
What steps will reproduce the problem?
1. Connect to deep scope ('youarpp/room1/room2')
2. Create persistent SharedObject in this scope
3. Send custom class (AMF3) instance via RPC and push this instance into
SharedObject (in ArrayList or just one as parameter)
public synchronized void addRectangle(TRectangle rect) {
IScope s = Red5.getConnectionLocal().getScope();
ISharedObject sharedObject = sharedObjects.get(s);
List<Object> elementsList = elementsLists.get(s);
sharedObject.beginUpdate();
elementsList.add(rect);
sharedObject.setAttribute("elementsList", elementsList);
sharedObject.endUpdate();
}
4. In client you can see that SharedObject synchronized and contains list of
your custom instances (red5 RC1) or is empty (red5 rev 4290), on server
everything is ok
5. Disconnect your clients, shutdown your red5, you can check persisted
SharedObject file, it should be ok
6. Restart red5 and connect a client
7a. Red5 cannot deserialize SharedObject because it fails to load your custom
class (red5 rev 4290)
[ERROR] [NioProcessor-2] org.red5.io.amf.Input - Error loading class:
eu.gromar.whiteboard.red5.externalizable.TRectangle
7b Red5 cannot deserialize SharedObject because it seems it wants to read it as
AMF0 (red5 RC1) - it uses readObject method from org.red5.io.amf.Input (and
not org.red5.io.amf3.Input) and fails right there where now you guys added at
line 562
else {
log.debug("Forced to use simple object for class {}", className);
result = readSimpleObject(deserializer);
}
which doesn't resolve the problem.
WITHOUT deep scopes, it works great in red5 RC1 (if you don't mind
IExternalizable problems) - it also can be read correctly in red5 rev 4290, but
it won't reach the client (client will get SyncEvent, SharedObject.data will
have an attribute, but it will be seen as empty)
[email protected]
Original issue reported on code.google.com by michal.przybys on 3 Nov 2011 at 9:33
- Blocked on: #151
Copied from original issue: mondain/red5#155
From @GoogleCodeExporter on March 15, 2015 16:54
it is possibly connected to issue 145
Original comment by michal.przybys on 3 Nov 2011 at 10:50
From @GoogleCodeExporter on March 15, 2015 16:54
it seems that ClassLoader that reads SharedObject in deep scope doesn't have
access to app classes
Original comment by michal.przybys on 10 Nov 2011 at 12:13
From @GoogleCodeExporter on March 15, 2015 16:54
Original comment by mondain on 15 Nov 2011 at 3:32
- Changed state: Accepted
From @GoogleCodeExporter on March 15, 2015 16:54
Original comment by mondain on 21 Nov 2011 at 3:44
From @GoogleCodeExporter on March 15, 2015 16:54
please note that custom classes can work without IExternalizable properly
working as long as you don't require any fancy serialization. the main problem
in here is ClassLoader without access to app classes. probably some .policy
tweak can resolve this problem.
Original comment by michal.przybys on 21 Nov 2011 at 3:55
From @GoogleCodeExporter on March 15, 2015 16:54
you could always set your scope to not be persistent.
Original comment by [email protected] on 22 May 2012 at 4:39
From @GoogleCodeExporter on March 15, 2015 16:54
yeah, right, why use basic features...
by the way - this can be resolved by extracting all VOs (classes you use for
data storage in SharedObject) into .jar, putting it in lib folder and adding
permission to red5 policy file
Original comment by michal.przybys on 22 May 2012 at 6:36
From @GoogleCodeExporter on March 15, 2015 16:54
Michal, is it possible to also fix this by adding your applications "classes"
directory to the policy file? If so then lets work to provide that as an
example and get this issue closed.
Original comment by mondain on 10 Nov 2012 at 5:54
- Now blocked on: #151
From @GoogleCodeExporter on March 15, 2015 16:54
probably. i exported all "shared" classes to jar which i added to policy and it
worked, so this should work the same way, i'll check it out on monday. however
i think it would be much more user-friendly if app's ClassLoader has the access
to app's classes in it's own path by default.
Original comment by michal.przybys on 10 Nov 2012 at 7:01
From @GoogleCodeExporter on March 15, 2015 16:54
I agree, but it actually should already have access. I assume its a load order
problem instead.
Original comment by mondain on 10 Nov 2012 at 7:06
From @GoogleCodeExporter on March 15, 2015 16:54
that should be it, since it breaks only in deep scopes. anyways, it's still
worth checking, because if it works fine just after it's needed how does it
differ from not working?
Original comment by michal.przybys on 10 Nov 2012 at 7:17