[Glen Ihrig]

I had a successfully activated copy of ME4S that had gone through updates since 8.1. When it recently began acting up I decided to delete and reinstall.

I deleted /genuitec/* and ‘/Applications/Development/DevelopmentFolders/Genuitec/MyEclipse for Spring 9.app/*’

I installed using the custom installer for Mac from: http://www.myeclipseide.com/index.php?name=Recommend_Us&req=Download&version=ME4S.

Details:

– The Activation dialog appears shortly after each start up (the activation must be
repeated with each application start).
– Activation proceeds as expected and completes with a success message.
– ~/.myeclipse.properties file is updated with a current time stamp, contents look OK.
– MyEclipse > Subscription Information shows expected, valid information.
– I have tried four activation methods (Automatic, Web Based, Already Have Code and
Update License > enter Subscription Code), the results are the same – The activation
works, but is neglected on the next start.
– Finally, I renamed ~/.myeclipse.properties, restarted, entered my subscription
information and activated (Automatic). This procedure completed successfully, but
failed after a restart, as above. I compared old and new ~/.myeclipse.properties files,
a new ~/.myeclipse.properties file is created, but it contains no ‘ACTIVATION_KEY’
element.

Any suggestions on what to do next would be appreciated.

Best,

-Glen

Installation Details:

*** Date:
Tuesday, September 6, 2011 9:03:40 PM PDT

** System properties:
OS=MacOSX
OS version=10.5.8
Java version=1.6.0_26

*** MyEclipse details:
MyEclipse Enterprise Workbench
Version: 9.1
Build id: 9.1-20110701

*** Eclipse details:
MyEclipse for Spring

Version: 9.1.0

Build ID: 9.1.0 Build 10 (110630_1845)

Eclipse startup command=-os
macosx
-ws
cocoa
-arch
x86_64
-showsplash
-launcher
/Applications/Development/DevelopmentFolders/Genuitec/MyEclipse for Spring 9.app/Contents/Profile/myeclipseforspring.app/Contents/MacOS/myeclipseforspring
-name
Myeclipseforspring
–launcher.library
/Applications/Development/DevelopmentFolders/Genuitec/MyEclipse for Spring 9.app/Contents/Profile/myeclipseforspring.app/Contents/MacOS//../../../../../../Common/plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.1.R36x_v20100810/eclipse_1309.so
-startup
/Applications/Development/DevelopmentFolders/Genuitec/MyEclipse for Spring 9.app/Contents/Profile/myeclipseforspring.app/Contents/MacOS/../../../../../../Common/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
-install
/Applications/Development/DevelopmentFolders/Genuitec/MyEclipse for Spring 9.app/Contents/Profile
-configuration
/Applications/Development/DevelopmentFolders/Genuitec/MyEclipse for Spring 9.app/Contents/Profile/configuration
-keyring
/Users/glen/.eclipse_keyring
-showlocation
-vm
/System/Library/Frameworks/JavaVM.framework

[Brian Fernandes]

Glen,

Finally, I renamed ~/.myeclipse.properties, restarted, entered my subscription
information and activated (Automatic). This procedure completed successfully, but
failed after a restart, as above. I compared old and new ~/.myeclipse.properties files,
a new ~/.myeclipse.properties file is created, but it contains no ‘ACTIVATION_KEY’
element.

1) Could you clarify if you had the ACTIVATION_KEY property in either of those property files – the old file or the new one that was created by MyEclipse?
2) After successfully activating MyEclipse using any technique, can you please open the property file while MyEclipse is running – do you see the ACTIVATION_KEY property there now? If yes, close the property file and shut down MyEclipse – is it still present? If yes again, does it disappear if you start MyEclipse?
3) If you complete the web activation process, you get the activation code. You can add the ACTIVATION_KEY=<code> as the third property in the property file by editing the file yourself, does this help? (This should never be necessary, but just troubleshooting)
4) Are you running different versions of MyEclipse – perhaps a 64bit / 32bit or Cocoa or Carbon version at the same time (not necessarily simultaneously, but one after the other?)
5) If you keep attempting Web activation for subsequent sessions of MyEclipse – are you getting different activation codes each time?

[Glen Ihrig]

Hi Brian,

I have performed a detailed inspection of the myeclipse.properties file as you suggested.
The end result seems to be that the problem with the missing ACTIVATION_KEY has vanished.
The myeclipse.properties file now appears to be properly maintained.

But the original problem of the Activation Manager dialog appearing on each startup still remains.

=======
Details
=======

1) Could you clarify if you had the ACTIVATION_KEY property in either of those property files – the old file or the new one that was created by MyEclipse?

The old file, created with MyEclipse 7.0 (I think) and upgraded over the years, most recently ME4S 9.1 32 bit (Carbon?) as updated through the MyEclipse Configuration Center. This file _does_ have the ACTIVATION_KEY property, including a message describing that the ACTIVATION_KEY is machine specific.

The new file has _only_ two comments identifying the file and its creation date, and two properties: LICENSE_KEY and LICENSEE.

2) After successfully activating MyEclipse using any technique, can you please open the property file while MyEclipse is running – do you see the ACTIVATION_KEY property there now? If yes, close the property file and shut down MyEclipse – is it still present? If yes again, does it disappear if you start MyEclipse?

0. Deleted ~/.myeclipse.properties
1. ME4S running in 30 day trial mode 
   - properties file does _not_ exist.
2. Register through MyEclipse > Subscription Information
   - Enter User ID and Subscription Code.
   - Subscription Detail: Product Id: E3MS (MyEclipse for Spring Subscription)
     License version: 3.0
3. Web activation
   - Works as expected.
   - Properties file is created _including_ ACTIVATION_KEY property and its value.
   - ACTIVATION_KEY property value is _different_ between the new and old properties file.
   - Closed properties file, closed ME4S - properties file exists and ACTIVATION_KEY
     _is_ present.
4. Restart ME4S - Remain in 30 day demo mode
   - Closed Properties file, Restart ME4S - Properties file exists, contains ACTIVATION_KEY.
     License manager dialog appears (2 days remaining for activation)
   - Selected 'Continue' in License Manager dialog.
   - Closed properties file, Closed ME4S - Properties file still exists, has ACTIVATION_KEY.
5. Restart ME4S - Performed re-activation
   - Closed Properties file, Restart ME4S - Properties file exists, contains ACTIVATION_KEY.
     License manager dialog appears (2 days remaining for activation)
   - Selected 'Activate' in License Manager dialog, Automated activation completed successfully.
   - Closed properties file, Closed ME4S - Properties file still exists, has ACTIVATION_KEY.
   - ACTIVATION_KEY property value is different after each activation.

3) If you complete the web activation process, you get the activation code. You can add the ACTIVATION_KEY=<code> as the third property in the property file by editing the file yourself, does this help? (This should never be necessary, but just troubleshooting)

Now, after running through the registration and activation process a few times, I’m getting a ‘fully formed’ properties file. The condition with the missing ACTIVATION_KEY no longer applies, don’t know why it changed.

4) Are you running different versions of MyEclipse – perhaps a 64bit / 32bit or Cocoa or Carbon version at the same time (not necessarily simultaneously, but one after the other?)

This user installation has existed since MyEclipse version 7. It has gone through several machine and OS upgrades and has had MyEclipse then ME4S upgrades installed shortly after each new release.

At present there is only one install, ME4S 9.1 64 bit Cocoa. This is the first 64 bit installation, performed after deleting the previous install of ME4S 32 bit Carbon.

5) If you keep attempting Web activation for subsequent sessions of MyEclipse – are you getting different activation codes each time?

Yes, the ACTIVATION_KEY property value is different after each activation.

[Brian Fernandes]

Glen,

Just to be absolutely sure on this – start ME4S 9.1, activate (you can use automatic), observe key; restart (use File > Restart) – you are prompted for activation again and new key is generated? Just wanted this very simple case clarified with you so we know there are no other variables in the process.

Is there any hardware or configuration on your machine that could be changing between starts?

To help us figure out what part is actually changing, can you please try the web activation in subsequent restarts and save the system ID and ACTIVATION_KEY that is being generated for each session? Send that to me via PM here on the forums or to support@genuitec.com ATTN Brian with a link to this thread so I can analyze this further.

Sorry for the inconvenience caused.

[Glen Ihrig]

Hi Brian,

As you requested…

start ME4S 9.1

Shortly after the License Manger dialog appeared, a ‘Problem Occurred’ dialog appeared with

An internal error occurred during: “Initializing TargetCfg”.
java.util.ConcurrentModificationException

This is the first time I have seen this error.

activate (you can use automatic)

Successfully completed.

observe key;

ACTIVATION_KEY ends with 990582eed3142e739

restart (use File > Restart) –
you are prompted for activation again and new key is generated?

Yes, License Manger appears, prompting for activation.
No ‘TargetCfg’ error this time.
Activated Automatically

ACTIVATION_KEY ends with 73226799258d48fdd

Just wanted this very simple case clarified with you so we know there are no other variables in the process.

Is there any hardware or configuration on your machine that could be changing between starts?

Not to my knowledge. This is a fairly straight-forward install of OS X, to the best of my knowledge.

To help us figure out what part is actually changing, can you please try the web activation in
subsequent restarts and save the system ID and ACTIVATION_KEY that is being generated for each
session? Send that to me via PM here on the forums or to support@genuitec.com

ATTN Brian with
a link to this thread so I can analyze this further.

Details sent via PM

Examining the Error Log view

The only error is an ‘Unhandled event loop exception’, that occurs on each start and includes:

com.genuitec.eclipse.core.activation.SystemIdFactory.Ä„(Unknown Source)

Could be relevant?

        !ENTRY org.eclipse.ui 4 0 2011-09-09 17:09:52.644
        !MESSAGE Unhandled event loop exception
        !STACK 0
        org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.UnsatisfiedLinkError: Cannot load native JNIWrapper library (libjniwrap.jnilib).)
            at org.eclipse.swt.SWT.error(SWT.java:4083)
            at org.eclipse.swt.SWT.error(SWT.java:3998)
            at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137)
            at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3586)
            at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3279)
            at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
            at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
            at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
            at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
            at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
            at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
            at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
            at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
            at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
            at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
            at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
            at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
            at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
            at java.lang.reflect.Method.invoke(Method.java:597)
            at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
            at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
            at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
        Caused by: java.lang.UnsatisfiedLinkError: Cannot load native JNIWrapper library (libjniwrap.jnilib).
            at com.jniwrapper.Library.loadNativeCode(SourceFile:174)
            at com.jniwrapper.Library.loadNativeCode(SourceFile:199)
            at com.jniwrapper.Library.ensureNativeCode(SourceFile:209)
            at com.jniwrapper.Library.load(SourceFile:218)
            at com.jniwrapper.util.FunctionCache.b(SourceFile:89)
            at com.jniwrapper.util.FunctionCache.getFunction(SourceFile:114)
            at com.jniwrapper.util.ProcessorInfo.c(SourceFile:299)
            at com.jniwrapper.util.ProcessorInfo.a(SourceFile:102)
            at com.jniwrapper.util.ProcessorInfo.getInstance(SourceFile:89)
            at com.genuitec.eclipse.core.activation.SystemIdFactory.Ä„(Unknown Source)
            at com.genuitec.eclipse.core.activation.SystemIdFactory.create(Unknown Source)
            at com.genuitec.eclipse.core.activation.SystemIdFactory.matches(Unknown Source)
            at com.genuitec.eclipse.core.ActivationValidator.�(Unknown Source)
            at com.genuitec.eclipse.core.ActivationValidator.<init>(Unknown Source)
            at com.genuitec.eclipse.core.LicenseUtil.�(Unknown Source)
            at com.genuitec.eclipse.core.LicenseUtil.ÄŠ(Unknown Source)
            at com.genuitec.eclipse.core.LicenseUtil.�(Unknown Source)
            at com.genuitec.eclipse.core.LicenseUtil.getCurrentLicensee(Unknown Source)
            at com.genuitec.eclipse.core.ViperCore.Ä…(Unknown Source)
            at com.genuitec.eclipse.core.ViperCore.�(Unknown Source)
            at com.genuitec.eclipse.core.ViperCore.isLicenseValid(Unknown Source)
            at com.genuitec.eclipse.core.vU.�(Unknown Source)
            at com.genuitec.eclipse.core.vU.A__111164asdfae2342fa(Unknown Source)
            at com.genuitec.myeclipse.perspective.PerspectivePlugin$1.run(PerspectivePlugin.java:108)
            at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
            at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
            ... 22 more

There are also a few warnings about Keybinding conflicts.

I have attached the full error log.

Attachments:

You must be logged in to view attached files.

[Glen Ihrig]

After completing the above exercise, things have changed, again.

Now the License Manager dialog is no longer appearing shortly after start up. But the problem is still not resolved.

Opening MyEclipse > Subscription Information shows what looks like complete subscription information,
including a correct subscription expiration date, several months in the future.

However, the Activation status section shows a message, in red text:

Product activation must be completed today.

Activation (Automatic method) competes successfully and the Activation status message changes to:

Product Activated.

After a File > Restart, the message has changed back to the red warning. Maybe this is expected due to the activation grace period expiring soon?

[Brian Fernandes]

Glen,

Thanks for the extremely detailed investigation.

1) There is one component of your system Id that appears to be changing – your system id should be constant unless you make a significant change in your system configuration. This change is causing your current activation code to be invalid (because it was based on the previous system Id) and you are therefore being prompted to activate each time. I’m going to look into this further.

2) The stack trace you mentioned is very significant as it is responsible for the generation of your System Id. If you clear your error log (just to avoid confusion) and restart MyEclipse, do you still see the

org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.UnsatisfiedLinkError: Cannot load native JNIWrapper library (libjniwrap.jnilib).)

error each time you start MyEclipse?

3) Can you go to Help > About > Installation Details > Plug-ins and confirm that the version of the com.genuitec.eclipse.core plugin is 9.1.0.me201106292137? This is just a sanity check to ensure that you have the latest version of the core plugin, 9.0 would not activate on OS X 64-bit, but 9.1 will.

[Scott Anderson]

Glen,

I’ve been researching this on my Mac and the root cause of this issue is exactly what you thought it was in one of your prior posts:

Could be relevant?

Caused by: java.lang.UnsatisfiedLinkError: Cannot load native JNIWrapper library (libjniwrap.jnilib).
at com.jniwrapper.Library.loadNativeCode(SourceFile:174)
…

So, for some reason on your machine one of our native libraries is failing to load and this is causing the requirement to reactivate since that native library helps out in the validation of the existing activation code.

Now that we know what the cause is we need to figure out why this is happening. The most obvious cause would be that your configuration somehow has a very old version of one of our plugins that does not contain the correct native library in it. To see if this is the case I need you to go look in your Common directory and tell me what versions of a particular plugin exist there. The Common directory is normally stored in: /Applications/MyEclipse/Common

Within /Applications/MyEclipse/Common/plugins there will be one or more plugins whose name will have the form:
com.genuitec.eclipse.jniwrapper_XXXXX.jar

Can you please tell me how many of these you have and all the values for XXXX in each version that you’ve got. The latest version for MyEclipse 9.1 should be called:
com.genuitec.eclipse.jniwrapper_9.0.0.me201105051700.jar

So, what versions do you have installed?

Now I need you to check on the configuration within your actual MyEclipse application. If you right-click on the .app file and select “Show Package Contents” you’ll see a Finder window. Navigate to and open the bundles.info file with a text editor. The file is at: Contents/Profile/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
Now search for “jniwrapper” and see which version is referenced. Which is it?

With this info we should be able to get you up and running quickly.

[Glen Ihrig]

Hi Scott,

Thanks for you efforts on this issues.

Can you please tell me how many of these you have and all the values for XXXX in each version that
you’ve got. The latest version for MyEclipse 9.1 should be called:
com.genuitec.eclipse.jniwrapper_9.0.0.me201105051700.jar

A spotlight search confirms the version you referenced is the only one, though my path is custom:

/Applications/Development/DevelopmentFolders/Genuitec/Common/plugins/com.genuitec.eclipse.jniwrapper_9.0.0.me201105051700.jar

Now I need you to check on the configuration within your actual MyEclipse application.

com.genuitec.eclipse.jniwrapper,9.0.0.me201105051700,file:/Applications/Development/DevelopmentFolders/Genuitec/Common/plugins/com.genuitec.eclipse.jniwrapper_9.0.0.me201105051700.jar,4,false

Both paths match and are correct, I have confirmed this in the terminal with the command: ls -l (path).

The file is owned by user glen (me) and group admin.
Permissions are set to 644 rw-r-r.
I am able to open the .jar file and browse it’s contents using a zip utility.
Just to be sure it’s not corrupt, here is the md5 checksum:

MD5 (/Applications/Development/DevelopmentFolders/Genuitec/Common/plugins/com.genuitec.eclipse.jniwrapper_9.0.0.me201105051700.jar) = 656ef1df04f5276bcfe5f3bd4305faa3

Incidentally, now that the activation grace period has come and gone, the Activation Manager dialog once
again appears on start up, so I guess that previous change was of no consequence.

Is it possible that the custom install path is causing the problem?

Best regards,

-Glen

[Scott Anderson]

Glen,

First, thank you very much for going through these steps to verify your installation and configuration. You’ve reported exactly what we needed to know to ensure that you have the correct jar available and it is correctly referenced in your installation. That’s a few possible issues we can cross off the list and we now know your library isn’t failing to load because it is missing; it is failing to load even though it is correct and present.

And I believe I know why we’re seeing this failure to load. It’s exactly as you surmised in your prior post — your custom installation location is the issue. I did some research to determine why this would be the case and found the answer in Apple Technical Note TN2147 – JNI Development on Mac OS X. Here’s the issue:

Native libraries must be placed in a loadable library path. Possible paths include:

– The Java Resources subdirectory of your application bundle (e.g. YourApp.app/Contents/Resources/Java)
– The working directory at launch time (i.e. user.dir)
– A Java extension directory listed in Technical Q&A QA1170, ‘Important Java Directories on Mac OS X’
– The Mac OS X dynamic library search path explained in Dynamic Library Usage Guidelines
– You can also set the java.library.path system property at application launch time to specify an alternate installation path.

Our default install location under the Application directory satisfies the requirements for where a native library can be loaded from. Your custom application location does not, so the library fails to load.

I can think of two ways to fix this:
1) Modify the application startup arguments to include a java.library.path system property that adds your alternate location correctly. If you’d like to try this, please note that the default setting of java.library.path won’t be empty so just adding a single path to it won’t work either. For more information on this topic, here’s a link to more Apple technical resources (See #5)
2) Uninstall and Reinstall under the /Applications directory as Apple expects. 🙂

Of the two options, I think #2 would be faster and more reliable.

[Glen Ihrig]

Hi Scott,

Thanks for the detailed research and in-depth explanation, it’s very much appreciated.

I don’t have a big problem with reinstalling, particularly if the current location may cause other issues. So far, other features I have worked with have operated as expected.

The location used here was chosen to better facilitate menu organization within Path Finder’s menu bar shortcuts (I’m using version 4.8.4).
I would like to maintain that functionality, Even if I move the installation location I probably can do this using an alias for the MyEclipse for Spring .app bundle.

I am curious about the installation path and why this problem is new in 9.1.

1. In previous versions, 8.x, using the Pulse installer, there were two installation paths.
One path contained Pulse and the Common directory, this was located by default at /Library/Genuitec. I left this path unchanged in previous installations.

The second path contained MyEclipse for Spring and defaulted to /Library/Genuitec/Myeclipse (if I recall correctly). I altered this path the one you see here
/Applications/Development/DevelopmentFolders/Genuitec.

As mentioned this worked in recent versions, including 9.0 as updated from 8.6.

2. In this current installation, which is the first ‘clean’ install I have done since 8.0, There is only one installation path, which I believe defaulted to /Library/Genuitec.

In the past I downloaded the ‘off-line’ all in one installer, the current 9.1 install was done with the ‘on-line’ custom installer. The off-line installer’s estimated down load time settled out to be around 12 hours, even with a modern broad band internet connection.
I was not very confident that this download would complete successfully… The online version downloaded and installed in about 30 minutes.

The question is, did the separate install paths of 8.x get replaced with a single path in 9.x, or did I miss that due to my choice of installer?

Thanks again for your help.

Best regards,

-Glen

[Scott Anderson]

Glen,

Thanks for the detailed research and in-depth explanation, it’s very much appreciated.

No worries. That’s why we’re here. It was definitely an interesting scenario that we’re going to document in our activation FAQ for others.

I don’t have a big problem with reinstalling, particularly if the current location may cause other issues. So far, other features I have worked with have operated as expected.

We don’t use native libraries a ton, but we do some, so the breaks may be quite spread out and difficult to find.

The location used here was chosen to better facilitate menu organization within Path Finder’s menu bar shortcuts (I’m using version 4.8.4).
I would like to maintain that functionality, Even if I move the installation location I probably can do this using an alias for the MyEclipse for Spring .app bundle.

An alias is likely the best bet. Perhaps just a symbolic link on the file system will do the trick after the reinstall.

I am curious about the installation path and why this problem is new in 9.1.

This issue is new because the type of product activation that we use the native code for is new for MyEclipse 9.0. Different mechanisms were used in 8.x and prior.

1. In previous versions, 8.x, using the Pulse installer, there were two installation paths.

<elided>

2. In this current installation, which is the first ‘clean’ install I have done since 8.0, There is only one installation path, which I believe defaulted to /Library/Genuitec.

<elided>

The question is, did the separate install paths of 8.x get replaced with a single path in 9.x, or did I miss that due to my choice of installer?

The version 9.0 installer only has a single user-configurable installation path. The older mechanism was confusing for folks and was really only required as a byproduct of the generation of our installer technology we were using at the time. MyEclipse 9.0 users a much newer installer (OneInstall) so the dual configuration is no longer required. Both the offline and online installers work the same way.

[Glen Ihrig]

Well, Still no joy,

details follow.

Our default install location under the Application directory satisfies the requirements for where
a native library can be loaded from. Your custom application location does not, so the library
fails to load.

I can think of two ways to fix this:
1) Modify the application startup arguments …
2) Uninstall and Reinstall under the /Applications directory as Apple expects. 🙂

I reinstalled ME4S in the default location and this made no difference. The License Manager still
appears on each start up.

In keeping with

Native libraries must be placed in a loadable library path. Possible paths include:

– The Java Resources subdirectory of your application bundle (e.g. YourApp.app/Contents/Resources/Java) …

I placed a copy of the jni wrapper jar in:

/Applications/MyEclipse for Spring/MyEclipse for Spring 9.app/Contents/Resources/Java/com.genuitec.eclipse.jniwrapper_9.0.0.me201105051700.jar

and when that did not work:

/Applications/MyEclipse for Spring/MyEclipse for Spring 9.app/Contents/Profile/myeclipseforspring.app/Contents/Resources/Java/com.genuitec.eclipse.jniwrapper_9.0.0.me201105051700.jar

That did not work either. The second change caused ME4S to fail to start altogether, it did not recover after removing the copies, so I removed the installation.

– Executed Uninstall MyEclipse for Spring 9.app
– Deleted /Applications/Genuitec
– Deleted ~/Workspace
– Deleted ~/.eclipse_keyring
– Deleted ~/.myeclipse.properties
– Deleted ~/.myeclipse folder
– Deleted ~/.eclipse folder
– Created new empty workspace folder
– Emptied trash
– Rebooted computer
– Performed a default install

Deleting all of the above restarted the Subscription/Activation process, giving the appearance of a fresh new installation, but just as before,
the activation did not ‘stick’ over a restart and the error “Cannot load native JNIWrapper library” still appears in the error log.

For what it may be worth, here are details of the most recent install.

Installation Details:
———————
See attached file: Installation_details_9-14.txt

Error log from first start up and registration/activation/restart – In a new, empty workspace:
——————–
See attached file: log_first_start_register_activate_restart_9-14.txt

Notice that the log file still shows the error: “Cannot load native JNIWrapper library”

I appreciate your hanging in here with this…

Best regards,

-Glen

.

Attachments:

You must be logged in to view attached files.

[Scott Anderson]

Glen,

Darn! I was so sure that was the likely culprit.

However, while we were documenting the issue for the FAQ another of our support guys (Tony) tried to replicate the issue you’re seeing so he could be 100% positive of the fix and guess what — he couldn’t replicate the issue no matter where he installed!

We brainstormed a bit and realized that he’s testing on OS/X 10.6.x, I’m on 10.7.x and your on 10.5.x. There could definitely be a difference in the way your older version of OS/X treats 64-bit Java applications than the later releases we’re using. One way to check that is to see if you can install the 32-bit Cocoa or 32-bit Carbon versions of MyEclipse and see if those behave differently. You can install all of them at the same time without issue, although activation WILL change if you go back and forth between them. So, to test you’ll need to install one of the other versions and run just it several times and see if you get prompted to reactivate that new install. If you don’t, the issue is an OS interaction difference with 64-bit Java on 10.5.x.

Another thing I noticed about your detailed reply is that one of the files you didn’t list that you deleted was .pulse2.locator in your home directory. Can you look at the contents of that file and ensure it points at your new install location and not your old one? If it still points at your old one then the reinstall simply put everything back where it was so it wasn’t a valid test. Our uninstaller should remove that file so I anticipate that this isn’t the issue, but it’s worth a check.

One final thing that Tony mentioned was to see if you could create a new user account and try the install under that user account. This would tell us if there was something odd with the way your current user is set up that is causing the issue as well.

Naturally, I’d try these options in the order I listed them as they’re the most likely to the least.

[Glen Ihrig]

install the 32-bit Cocoa or 32-bit Carbon versions of MyEclipse

That’s it!

32 bit Cocoa version installed, works right ‘out of the box’. Previous activation (created
with 64 bit version) is valid as-is.

However… This installation creates 10 ‘Bad version number’ errors while creating and
scaffolding a JEE 6 app using the ClassicCars.Employees database. So far, these errors
don’t seem to be causing any real problem, just cluttering the error log, but I’m still
suspicious. The application does run error free.

Internal Error
    java.lang.UnsupportedClassVersionError: Bad version number in .class 
    file at java.lang.ClassLoader.defineClass1(Native Method)

I suspect these errors are the result of running MyEclipse under Java 1.5 while my project
runs under Java 1.6. This happens because there is no 32 bit Java 1.6 under OS X 10.5,
so MyEclipse 32 bit must run under Java 1.5.

Further, there are no errors generated when an identical project is scaffolded using using
JEE 5.

There also are no errors generated when using ME4S 64 bit to scaffold an identical JEE 6
app.

After all of this, we have learned two things:

1. MyEclipse activation detection fails under the combination of MyEclipse 9.1 64 bit and Mac
OS X 10.5.8. This error condition does not apply to Mac OS X 10.6 or 10.7.

2. While MyEclipse 9.1 32 bit Cocoa version does not exhibit the activation
detection problem, it does generate many (possibly benign) class version errors
when the Java versions do not match between MyEclipse (Java 1.5) and a JEE 6
project.

This problem does not appear when MyEclipse 64 bit is running under Java 1.6 and
generates a JEE 5 (or JEE 6) project.

I now have enough options and understanding to get my work done without concern of
being locked out by a licensing error.

Thanks for your efforts, I hope this experience will help to make MyEclipse a better product.

I have attached installation details and an error log for ME4S 32 bit Cocoa and JEE 6, in
case that may be helpful should you decide to review item 2 above.

Best regards,

-Glen
.

Attachments:

You must be logged in to view attached files.

[Author]

Posts