cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X

unable to access DEFAULT_END_TIMESTAMP

ptc-4668818
12-Amethyst

unable to access DEFAULT_END_TIMESTAMP

I implemented a version of the Groovy script shown on the MobileLocation API Reference page as a Custom Object on the Axeda Platform.  I get the following exception when I run this script:

 

Access to property DEFAULT_END_TIMESTAMP of class com.axeda.drm.services.mobilelocation.MobileLocationImpl not allowed

 

What is the proper reference to the DEFAULT_END_TIMESTAMP property?

ACCEPTED SOLUTION

Accepted Solutions

It appears that a workaround is available for this issue.  You don't need "lake" access if you know that DEFAULT_END_TIMESTAMP = 4136677158944L.

View solution in original post

8 REPLIES 8
ckaminski
14-Alexandrite
(To:ptc-4668818)

That API is located in the 6.8 Code Access Policy (CAP) level "lake."  By default all new instances in the On-Demand Center are provisioned in "pond."  "Lake" and "Sea" are progressively more permissive depending on your application requirements. 

I recommend opening a support case to have your CAP level altered to lake. 

-Chris Kaminski

PTC Customer Support

It appears that a workaround is available for this issue.  You don't need "lake" access if you know that DEFAULT_END_TIMESTAMP = 4136677158944L.

ckaminski
14-Alexandrite
(To:ptc-4668818)

I almost posted that very answer - for while this is true, I'm always leery of recommending someone rely on implementation details like this.

Regards,

-Chris Kaminski

PTC Customer Support

I agree.  How about making a constant like this, one that may be needed for correct script implementation, "public"?

I think the fact that it is not is an oversight, not intentional.  Appreciate you bringing it to our attention John.

ckaminski
14-Alexandrite
(To:ptc-4668818)

As noted earlier that feature is allowed in code access policy level "lake", which your instance can be adjusted to with a support case.  So it is public, but I believe that this belongs in level "pond", the default.   I've already started a process internally to review why this particular restriction is in place.  

-Chris Kaminski

PTC Customer Support

Chris, is this another example of the same issue?  If so, how to I work around it?

Access to property STRING of class com.axeda.drm.services.device.DataItemType not allowed

at com.axeda.groovy.sandbox.access.v1.CodeAccessPolicyImpl.accessViolation(CodeAccessPolicyImpl.java:506)

at com.axeda.groovy.sandbox.SandboxControllerImpl.accessViolation(SandboxControllerImpl.java:225)

at com.axeda.groovy.sandbox.SandboxControllerImpl.isPropertyAccessAllowedFast(SandboxControllerImpl.java:162)

at com.axeda.groovy.sandbox.GroovySandboxController$isPropertyAccessAllowedFast.call(Unknown Source)

at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)

at com.axeda.drm.services.customobject.groovy$_run_closure1_closure2.doCall(com.axeda.drm.services.customobject.groovy.GroovyAction:97)

.

.

.

ckaminski
14-Alexandrite
(To:ptc-4668818)

com.axeda.drm.services.device.DataItemType is also located in "lake". 


I'll PM you directly, we can address this for you.


-Chris Kaminski

PTC Customer Support

Announcements


Top Tags