Re: [uportal-dev] RuntimeException with export-preferences.crn
Tuy,
Could you post a diff of your current export-preferences.crn file?
One thought for the change Drew suggested is there is already a
${PORTAL_CONTEXT} variable defined for all of the import/export/delete
scripts so that long line could probably be:
with-attribute key=portletEntities
value=${groovy(PORTAL_CONTEXT.getBean('portletEntityPreferenceHandler').getEntityPreferences(USER_ID.intValue()))}
Also if you can get a diff we can try it in a few other environments and
see if we can get a patch in for 3.0.1
-Eric
Tuyhang Ly wrote:
Thanks Drew!
This change works fine.
Tuy.
Drew Wills wrote:
Tuy,
That's too bad -- based on what I had read, I thought Groovy would
happily convert a BigDecimal to an int in this case.
I believe we can still use intValue(), as you originally suggested.
For this approach, change line 36 () to the following:
with-attribute key=portletEntities
value=${groovy(org.jasig.portal.spring.PortalApplicationContextLocator.getApplicationContext().getBean('portletEntityPreferenceHandler').getEntityPreferences(USER_ID.intValue()))}
drew wills
Tuyhang Ly wrote:
Hi Drew,
We use Oracle 10g and I've tried using your new version of this
file, but it failed with this exception:
Caused by: groovy.lang.MissingMethodException: No signature of
method:
org.jasig.portal.io.support.PortletEntityPreferenceHandler.getEntityPreferences()
is applicable for argument types: (java.math.BigDecimal) values: {-5}
at
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:572)
at
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:450)
at
org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:119)
at
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:111)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:187)
at Script17.run(Script17.groovy:1)
at
com.sun.script.groovy.GroovyScriptEngine.eval(GroovyScriptEngine.java:244)
... 102 more
Thanks,
Tuy.
Drew Wills wrote:
Tuyhang,
What RDBMS are you using? My local HSQLDB instance indicates a
TYPE_NAME of INTEGER for the up_user.user_id field, and the
export-preferences.crn XML works for me as-is.
The fix you suggested...
parameter value=${jexl(USER_ID.intValue())} /
would work perfectly as far as I'm aware, thanks in part to the
magic of duck-typing (i.e. it will work both for instances of
BigDecimal Integer).
But here's another suggestion: in looking at this file it seemed
to me it could benefit from some refactoring. Here's a new version
of the file, plus a .patch file that highlights the changes. I
didn't count, but I think it trims ~15 or so lines of noise.
Again -- it works on my DB. Let me know how it works for you.
drew wills
Tuyhang Ly wrote:
Hi,
When using the export-preferences.crn script in uP3, we
encountered the following RuntimeException:
Unable to locate method 'getEntityPreferences' on object of class
'org.jasig.portal.io.support.PortletEntityPreferenceHandler'
(argument types follow):
arg type=java.math.BigDecimal
The USER_ID column type is NUMBER and the JDBC mapping is
BigDecimal. Hence, we have to explicitly convert it to integer,
the expected argument type for the getEntityPreferences() method,
such as on line 45 of this script,
* should it be: parameter
value=${jexl(USER_ID.intValue())} /
* instead of:
parameter value=${USER_ID} /
Thanks,
Tuy.
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
[EMAIL PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
[EMAIL PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [uportal-dev] RuntimeException with export-preferences.crn
Eric,
Attached is the patch for the export-preferences.crn file.
Tuy.
Eric Dalquist wrote:
Tuy,
Could you post a diff of your current export-preferences.crn file?
One thought for the change Drew suggested is there is already a
${PORTAL_CONTEXT} variable defined for all of the import/export/delete
scripts so that long line could probably be:
with-attribute key=portletEntities
value=${groovy(PORTAL_CONTEXT.getBean('portletEntityPreferenceHandler').getEntityPreferences(USER_ID.intValue()))}
Also if you can get a diff we can try it in a few other environments
and see if we can get a patch in for 3.0.1
-Eric
Tuyhang Ly wrote:
Thanks Drew!
This change works fine.
Tuy.
Drew Wills wrote:
Tuy,
That's too bad -- based on what I had read, I thought Groovy would
happily convert a BigDecimal to an int in this case.
I believe we can still use intValue(), as you originally suggested.
For this approach, change line 36 () to the following:
with-attribute key=portletEntities
value=${groovy(org.jasig.portal.spring.PortalApplicationContextLocator.getApplicationContext().getBean('portletEntityPreferenceHandler').getEntityPreferences(USER_ID.intValue()))}
drew wills
Tuyhang Ly wrote:
Hi Drew,
We use Oracle 10g and I've tried using your new version of this
file, but it failed with this exception:
Caused by: groovy.lang.MissingMethodException: No signature of
method:
org.jasig.portal.io.support.PortletEntityPreferenceHandler.getEntityPreferences()
is applicable for argument types: (java.math.BigDecimal) values: {-5}
at
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:572)
at
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:450)
at
org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:119)
at
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:111)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:187)
at Script17.run(Script17.groovy:1)
at
com.sun.script.groovy.GroovyScriptEngine.eval(GroovyScriptEngine.java:244)
... 102 more
Thanks,
Tuy.
Drew Wills wrote:
Tuyhang,
What RDBMS are you using? My local HSQLDB instance indicates a
TYPE_NAME of INTEGER for the up_user.user_id field, and the
export-preferences.crn XML works for me as-is.
The fix you suggested...
parameter value=${jexl(USER_ID.intValue())} /
would work perfectly as far as I'm aware, thanks in part to the
magic of duck-typing (i.e. it will work both for instances of
BigDecimal Integer).
But here's another suggestion: in looking at this file it seemed
to me it could benefit from some refactoring. Here's a new
version of the file, plus a .patch file that highlights the
changes. I didn't count, but I think it trims ~15 or so lines of
noise.
Again -- it works on my DB. Let me know how it works for you.
drew wills
Tuyhang Ly wrote:
Hi,
When using the export-preferences.crn script in uP3, we
encountered the following RuntimeException:
Unable to locate method 'getEntityPreferences' on object of
class
'org.jasig.portal.io.support.PortletEntityPreferenceHandler'
(argument types follow):
arg type=java.math.BigDecimal
The USER_ID column type is NUMBER and the JDBC mapping is
BigDecimal. Hence, we have to explicitly convert it to integer,
the expected argument type for the getEntityPreferences() method,
such as on line 45 of this script,
* should it be: parameter
value=${jexl(USER_ID.intValue())} /
* instead of:
parameter value=${USER_ID} /
Thanks,
Tuy.
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
[EMAIL PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
[EMAIL PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-devIndex:
C:/opt/eclipse/workspace/uPortal_trunk/uportal-impl/src/main/resources/org/jasig/portal/io/export-preferences.crn
===
---
C:/opt/eclipse/workspace/uPortal_trunk/uportal-impl/src/main/resources/org/jasig/portal/io/export-preferences.crn
(revision 43765)
+++
C:/opt/eclipse/workspace/uPortal_trunk/uportal-impl/src/main/resources/org/jasig/portal/io/export-preferences.crn
(working copy)
@@ -1,16 +1,16 @@
with-attribute key=Attributes.NODE value=${newDoc(preferences)}
groovy
-!--
+!--
| Values in the column
Re: [uportal-dev] Zip files on Windows
I'm comfortable with it. Cris J H Eric Dalquist wrote: I'm working on getting 3.0.1 ready for release. Are we all comfortable with removing the .zip distributions? -Eric Andrew Petro wrote: Cris, I think that what you propose is a very good idea, especially if accompanied by good documentation/hints/links in the download area of the website along the lines of Why is there no .zip file? How do I open this files that are here? This would also help address the downsides of use of .zip formats on platforms that would benefit by formats that retain permissions flags on the extracted files, by simply preventing the use of the less-rich .zip format. One quick band-aid we could apply would be to slap a red warning box on the download page warning folks about naively opening the .zip distros in Windows. http://www.uportal.org/download.html However, I'd want to hear and give great weight to Eric Dalquist's perspective, since he's most recently been closely involved in the distribution build process automation. Andrew Cris J Holdorph wrote: This is something I see all the time in addition to the number of times it comes up on the list. What do people think about the advantages/disadvantages of changing our distribution format. I know just about any other format would require someone to install a tool they probably don't have on their box. But isn't that the crux of the current problem? That they are trying to unarchive without installing a new tool? So, what extra work would we really be adding? By way of suggestion, what about either .tar.gz or 7-zip formats? 7-zip is a free and open source solution available for both windows, linux and mac os. .tar.gz is also available quite easily on mac os x and linux. I think 7-zip or winzip (shareware) will open .tar.gz files. The other solution, that most other apps seem to take, is building self-extracting archives (or install programs), so that the download is either a .exe or .msi file. Cris J H Eric Dalquist wrote: One thing to keep in mind on Window is that the unzipping program included in Window does not handle path names longer than 255 characters and therefor cannot be used to unzip uPortal. You will need to find another unzip tool such as WinZip to extract uPortal on Windows. '-Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Zip files on Windows
On Jun 3, 2008, at 12:04 PM, Andrew Petro wrote: +1. Distributing .zips causes more trouble than it's worth. +1 Jason -- Jason Shao Director of Open Source Solutions CampusEAI Consortium 1940 East 6th Street, 11th Floor Cleveland, OH 44114 Tel: 216.589.9626x249 Fax: 216.589.9639 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] RuntimeException with export-preferences.crn
Eric Dalquist wrote:
Tuy,
Could you post a diff of your current export-preferences.crn file?
One thought for the change Drew suggested is there is already a
${PORTAL_CONTEXT} variable defined for all of the import/export/delete
scripts so that long line could probably be:
with-attribute key=portletEntities
value=${groovy(PORTAL_CONTEXT.getBean('portletEntityPreferenceHandler').getEntityPreferences(USER_ID.intValue()))}
Thanks Eric, that's helpful.
drew wills
--
Andrew Wills
UNICON, Inc.
Office: (480) 558-2476
http://code.google.com/p/cernunnos/
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
