jexposecvu / vosao

Automatically exported from code.google.com/p/vosao
GNU Lesser General Public License v2.1
0 stars 0 forks source link

Custom Plugin based on Register plugin ERROR #523

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

I've created a new plugin which I based on Register Plugin and everything works 
fine until yesterday where its now throws Nullpointer Exception and sometimes 
Can't connect to server. Error 593 element 0. 

The hard thing is that sometimes it works fine.

thanks in advance.

Original issue reported on code.google.com by mikemyer...@gmail.com on 16 Oct 2011 at 7:54

GoogleCodeExporter commented 8 years ago
I'm getting this to. Trying to debug it, but because it's a plugin it's almost 
impossible to debug in eclipse. There's no guide on how to debug plugins.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 6:07

GoogleCodeExporter commented 8 years ago
I can replicate it both on the live server and locally.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 6:08

GoogleCodeExporter commented 8 years ago
Nevermind the debug comment.. figured out how to debug it now.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 6:20

GoogleCodeExporter commented 8 years ago
Looks like it's something to do with query cache.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 6:29

GoogleCodeExporter commented 8 years ago
Line 103 of CacheServiceImpl:

result.putAll(cache.getAll(memcacheKeys));

cache.getAll(memcacheKeys) returns null and consequently breaks everything.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 6:51

GoogleCodeExporter commented 8 years ago
To make a long story short, I think the fix is to go into the two DAO 
Implementation files in the registration plugin and remove the second argument 
(the custom table name) from the call to super's constructor.

The query cache code uses EntityUtil.getKind(Class clazz) to add the name, 
which pays no attention to the DAO's kind string member (which is the custom 
table name).

If you remove the argument, it uses the name of the class as the table name 
(which is what getKind() in EntityUtil provides. 

One place I can find the use of EntityUtil.getKind() where it shouldn't be used 
is in QueryCacheImpl.getCachedQueryResult(). It should be looking up the DAO's 
kind string member variable value, but instead it is looking at the class name 
for the key it uses to store the data to memcache.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 10:45

GoogleCodeExporter commented 8 years ago
To further confirm that this only happens to the register plugin, public 
BaseDaoImpl(Class aClass, String aKind) is only ever called from the register 
plugin, when it should be just calling BaseDaoImpl(Class aClass)

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 10:49

GoogleCodeExporter commented 8 years ago
Just one more comment (I know I've posted enough already).

Automatically using a class name as the table name seems to be a bad solution 
going forward. All the DAOs in Vosao seem to be doing this.

What if someone wanted to write a Vosao plugin and use something like proguard 
to obfuscate the code? The table names would be aa ab ac ad etc.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 10:56

GoogleCodeExporter commented 8 years ago
Removing the second argument for the DAO's has worked for me. I haven't had any 
problems since migrating the tables to the new name and reinstalling a 
recompiled register plugin.

Original comment by rqu...@ebstrada.com.au on 19 Oct 2011 at 11:17

GoogleCodeExporter commented 8 years ago
The same problem as you, but I do not know how to fix. Could you provide a 
modified plugin to download?
Thanks.

Original comment by SlynkoNi...@gmail.com on 12 Feb 2012 at 7:30

GoogleCodeExporter commented 8 years ago

Original comment by kinyelo@gmail.com on 12 Feb 2012 at 8:39

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r1149.

Original comment by kinyelo@gmail.com on 12 Feb 2012 at 8:39