Tag: Eclipse

After a UML-to-Java transformation, Boolean getters begin with “is” rather than “get”

IBM Customer Leave a comment
In IBM Rational Software Architect Designer (RSAD), if you generate Java code from the UML-to-Java transformation the name of the methods begins with **is** instead of **get** for fields whose types are either **boolean** or **Boolean**. This occurs even when the **com.ibm.xtools.transform.java.extensions.customGetterSetter** transformation configuration setting is active.

The following steps reproduce the problem:

1. Create a UML project & model

2. Apply the **Java Transformation** profile to the model

3. Create a Java project

4. Add a UML-to-Java transformation configuration to the UML project with the model as the **Source** and the Java project as the **Target**. (Make sure that the **Extensions > com.ibm.xtools.transform.java.extensions.customGetterSetter** setting is selected as well.)

5. Add a package to the model

6. Add a class to the package

7. Add an attribute to the class

8. Give it the attribute the **boolean** type

9. Save all changes and run the transformation

10. Examine the resulting Java code

**EXPECTED RESULT**: The getter method for the **boolean** attribute is called **getAttribute1()**

**ACTUAL RESULT**: The getter method for the **boolean** attribute is called **isAttribute1()**

Related:

Are RDi and Spring Tools able to co-exist in the same install?

IBM Customer Leave a comment
I have a question about installing Spring tools into Rational Developer for i 9.6
I tried to install Spring Tools using the Eclipse Marketplace. It reported that it could not and was “trying alternate installs” when I canceled.

Are RDi and Spring Tools able to co-exist in the same install?

Related:

Connect SDK to Eclipse/Pydev?

IBM Customer Leave a comment
The instructions at [Developing apps in Eclipse][1] list some nice instructions for setting up an app in the Eclipse/Pydev environment. However, it doesn’t much discuss how to run it there.

Is there a way to run an app in the Flask framework provided by the SDK so that it can be attached to the Eclipse/Pydev debugger? (There should be….) This would make it a lot easier to debug apps.

[1]: https://www.ibm.com/support/knowledgecenter/SS42VS_7.3.0/com.ibm.appfw.doc/t_appframework_Eclipse.html

Related:

What’s new in z/OS Explorer Aqua – Eclipse versions

IBM Customer Leave a comment
The last update notice I saw for z/OS Explorer Aqua Eclipse v4.4 was at the end of September. Since then I’ve seen a couple of notices for the Eclipse v4.6 version. Does this imply that the 4.4 version is effectively dead and I should switch to the 4.6 version to stay current?

Related:

Where can I get an older zosexplorer aqua p2 install file?

IBM Customer Leave a comment
I need a version of z/OS Connect EE API Editor Feature that is compatible with RDZ 2015.1.13.201342. See below for the dependency issues when using version 2.0.406.201707250428.

I know version 2.0.403.201702170001 works.

Can you provide a link to the zosexplorer aqua P2 file containing this version?

Using 2.0.406 we get dependency errors.
Cannot complete the install because of a conflicting dependency.
Software being installed: IBM z/OS Connect EE API Editor Feature 2.0.406.201707250428 (com.ibm.zosconnect.ui.feature.feature.group 2.0.406.201707250428)
Software currently installed: IBM Software Delivery Platform2 2015.1.13.201342 (IBM Software Delivery Platform2 com.ibm.sdp.eclipse.ide 2015.1.13.201342)
Only one of the following can be installed at once:
Standard Widget Toolkit 3.100.2.v20130514-2326 (org.eclipse.swt 3.100.2.v20130514-2326)
Standard Widget Toolkit 3.6.3.v3659f (org.eclipse.swt 3.6.3.v3659f)
Standard Widget Toolkit 3.103.2.v20150203-1313 (org.eclipse.swt 3.103.2.v20150203-1313)
Cannot satisfy dependency:
From: IBM Software Delivery Platform2 2015.1.13.201342 (IBM Software Delivery Platform2 com.ibm.sdp.eclipse.ide 2015.1.13.201342)
To: org.eclipse.e4.rcp.R422patch.feature.group [1.0.14]
Cannot satisfy dependency:
From: IBM Software Delivery Platform2 2015.1.13.201342 (IBM Software Delivery Platform2 com.ibm.sdp.eclipse.ide 2015.1.13.201342)
To: org.eclipse.e4.rcp.feature.group [1.1.2.v20130130-191718-91FUvGP7GIX2Kgz-z-gvjMvXV1NS]
Cannot satisfy dependency:
From: IBM ZOS Connect UI Common 2.0.406.201707250428 (com.ibm.zosconnect.ui.common 2.0.406.201707250428)
To: bundle org.eclipse.jface.text 3.9.2
Cannot satisfy dependency:
From: IBM z/OS Connect EE API Editor Feature 2.0.406.201707250428 (com.ibm.zosconnect.ui.feature.feature.group 2.0.406.201707250428)
To: com.ibm.zosconnect.ui.common [2.0.406.201707250428]
Cannot satisfy dependency:
From: JFace Text 3.9.2.v20141003-1326 (org.eclipse.jface.text 3.9.2.v20141003-1326)
To: bundle org.eclipse.swt [3.103.0,4.0.0)
Cannot satisfy dependency:
From Patch: org.eclipse.e4.rcp.R422patch.feature.group 1.0.14 Eclipse e4 Rich Client Platform 1.1.2.v20130130-191718-91FUvGP7GIX2Kgz-z-gvjMvXV1NS (org.eclipse.e4.rcp.feature.group 1.1.2.v20130130-191718-91FUvGP7GIX2Kgz-z-gvjMvXV1NS)
To: org.eclipse.swt [3.100.2.v20130514-2326]

Related:

Websphere Liberty: cannot deploy war; hangs; then stopping hangs too

IBM Customer Leave a comment
I’m using wlp-webProfile7-java8-win-x86_64_17.0.0.2 with Eclipse Oxygen with WDT.
I’m working on a Dynamic Web Project using the Maven Nature, web-app_3_1, Java-8 with Java-7 compiler-compliance-level, Spring 4.3.11, Spring Security 4.2.1; deploying the war-file without a containing ear-file.

I had it working before. I’ve since needed to re-import the project into Eclipse and re-setup the Eclipse config for it. So, it seems the problem lies somewhere in re-creating the required Eclipse config. The remainder of the dev-team is overseas. I plan to contact them about this too.

I noticed that the war.xml file was mapping from WebContent to war-root, whereas the Maven layout has the war-contents based in src/main/webapp. So, I updated the Web Deployment Assembly config accordingly and re-tried the deployment, but it still failed.

In server.xml, I see that feature “javaee-7.0” is cited there, whereas we’re not planning to deploy as an ear-file, only as a war-file. I see that an ear-related project seems to have been created automatically in Eclipse, associated with the war-related project I’ve imported.

In server.xml, I have trace-logging enabled for certain packages, but there don’t seem to be any errors cited therein. Maybe I need trace-logging from also some other WebSphere packages.

When the deployment hangs, what I see in Process Explorer seems to indicate that the java-process reaches about 4.5 GB and stays at about 55% CPU, though the webapp is so far minimal (near the beginning of that development-phase of the project). Eclipse then reports that it couldn’t stop the app; that hangs too. So, I kill it via Process Explorer.

While configuring the newly imported project in Eclipse, I had some issues with JRE-version (installed JREs), compiler-compliance (7 vs. 8), whether or not “Dynamic Web Project” facet was supported, and whether or not web-app 3.1 was supported (the web.xml file checked in to the project cites web-app_3_1.xsd). An error-message showed, at times, in the “Run on Server” dialog, referring to one or another of the above issues. I made relevant adjustments until those error-message disappeared, but perhaps there’s still something of that sort still not configured properly.

While Eclipse was trying to deploy to Liberty and seemed to be hanging, I got a thread-dump from the cmdln (using jstack). The only Thread therein that seems relevant seems to show execution of CDI-related code. I’m not clear about whether or not that should be happening, considering the project uses Spring for dependency-injection.

Any assistance would be appreciated.

“LargeThreadPool-thread-16” daemon prio=6 tid=0x0000000014f46000 nid=0x29a8 runnable [0x0000000019c4d000]
java.lang.Thread.State: RUNNABLE
at java.lang.ClassLoader.loadClass(ClassLoader.java:437)
– locked (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.findSystemClass(ClassLoader.java:1059)
at com.ibm.ws.classloading.internal.GatewayClassLoader.loadClass(GatewayClassLoader.java:179)
at java.lang.ClassLoader.loadClass(ClassLoader.java:412)
– locked (a com.ibm.ws.classloading.internal.AppClassLoader)
at com.ibm.ws.classloading.internal.AppClassLoader.findOrDelegateLoadClass(AppClassLoader.java:477)
at com.ibm.ws.classloading.internal.AppClassLoader.loadClass(AppClassLoader.java:449)
– locked (a com.ibm.ws.classloading.internal.AppClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at com.ibm.ws.cdi.interfaces.CDIUtils.loadClass(CDIUtils.java:180)
at com.ibm.ws.cdi.interfaces.CDIUtils.loadClasses(CDIUtils.java:166)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:299)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:305)
at com.ibm.ws.cdi.impl.weld.WebSphereCDIDeploymentImpl.scan(WebSphereCDIDeploymentImpl.java:572)
at com.ibm.ws.cdi.impl.CDIContainerImpl.applicationStarting(CDIContainerImpl.java:121)
at com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:353)
at com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:29)
at com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:51)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:376)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:403)
at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:66)
at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:141)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1259)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:874)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

Related: