sample webpack angular4 application throwing errors - angular2-webpack-starter

I am trying to create a sample angular-webpack application instucted in https://angular.io/docs/ts/latest/guide/webpack.html but it is throwing me about 26 errors. Even after changing typescript version to "~2.2.1", these errors are coming.
can anyone help me to fix these errors please?
[at-loader] Checking finished with 26 errors chunk {0} vendor.js
(vendor) 2.64 MB {2} [initial] [rendered]
chunk {1} app.js, app.css (app) 3.57 kB {0} [initial] [rendered]
chunk {2} polyfills.js (polyfills) 577 kB [entry] [rendered]
WARNING in ./~/#angular/core/#angular/core.es5.js
5870:15-36 Critical dependency: the request of a dependency is an expression
WARNING in ./~/#angular/core/#angular/core.es5.js
5886:15-102 Critical dependency: the request of a dependency is an expression
ERROR in [at-loader] ./node_modules/#angular/common/src/platform_id.d.ts:8:42
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/common/src/platform_id.d.ts:9:41
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/common/src/platform_id.d.ts:10:45
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/common/src/platform_id.d.ts:11:44
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/compiler/src/util.d.ts:8:36
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/src/animation/animation_metadata_wrapped.d.ts:12:33
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/src/animation/dsl.d.ts:34:33
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/src/errors.d.ts:9:33
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/src/errors.d.ts:10:43
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/src/errors.d.ts:11:42
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/src/errors.d.ts:12:43
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/src/errors.d.ts:13:35
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/core/testing/src/before_each.d.ts:1:59
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/http/src/backends/browser_jsonp.d.ts:1:33
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/platform-browser/src/dom/dom_renderer.d.ts:14:41
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./node_modules/#angular/router/src/shared.d.ts:15:37
TS1039: Initializers are not allowed in ambient contexts.
ERROR in [at-loader] ./src/app/app.component.spec.ts:3:1
TS2304: Cannot find name 'describe'.
ERROR in [at-loader] ./src/app/app.component.spec.ts:4:3
TS2304: Cannot find name 'beforeEach'.
ERROR in [at-loader] ./src/app/app.component.spec.ts:7:3
TS2304: Cannot find name 'it'.
ERROR in [at-loader] ./src/app/app.component.spec.ts:9:5
TS2304: Cannot find name 'expect'.
ERROR in [at-loader] ./src/app/app.component.ts:5:13
TS2304: Cannot find name 'require'.
ERROR in [at-loader] ./src/app/app.component.ts:6:12
TS2304: Cannot find name 'require'.
ERROR in [at-loader] ./src/main.ts:4:5
TS2304: Cannot find name 'process'.
ERROR in [at-loader] ./src/polyfills.ts:3:1
TS2304: Cannot find name 'require'.
ERROR in [at-loader] ./src/polyfills.ts:5:5
TS2304: Cannot find name 'process'.
ERROR in [at-loader] ./src/polyfills.ts:10:3
TS2304: Cannot find name 'require'.
Child html-webpack-plugin for "index.html":
chunk {0} index.html 325 bytes [entry] [rendered]
Child extract-text-webpack-plugin:
chunk {0} extract-text-webpack-plugin-output-filename 1.92 kB [entry] [rendered]
webpack: Failed to compile.

The TSXXX errors seems definitely related to using a TypeScript prior to version 2.1 as explained
for example here and here.
Please verify:
the TypeScript version declared in you package.json file ("typescript": "~2.2.1" will be OK)
the TypeScript version that you are effectively using to compile the project. You can verify that from the output of the npm start command. You should see something like this [at-loader] Using typescript#2.0.10 from typescript and "tsconfig.json" from /usr/src/ng2-projects/angular-webpack/src/tsconfig.json; the typescript# part will show the version used for compilation.
The TS2304 errors seems linked to a misconfiguration of the required type declarations. See here for a clear explanation of how configure them.

I ran into this problem as well.. after spending 2 days and with some assistance i was able to get it to work. Actually I can't take full credit for the fix, someone else did help out a lot.
check the typescript version installed on your system.
compare the version you have in the package.json.
I can't remember if i update the typescript or not but at the time it was 2.2.2 so i updated the package.json to reflect the version installed on my system.
worked for me.

Maybe it will help someone:
I had a lot of different errors regarding typescript. I moved my tsconfig.json to root folder and errors gone.

I had the same issue. I changed to typescript 2.3 ("typescript": "~2.3" in package.json) and now I don't get the errors anymore.

Related

Liferay File upload issue

I am currently doing code about file upload in Liferay and
I am getting an error like below.
2019-12-18 07:26:08.392 ERROR [fileinstall-D:/Users/1604556/Downloads/liferay-ce
-portal-7.2.0-ga1/osgi/modules][LogService:93] Error while starting bundle: file
:/D:/Users/1604556/Downloads/liferay-ce-portal-7.2.0-ga1/osgi/modules/Liferay.up
load.file.jar
org.osgi.framework.BundleException: Could not resolve module: Liferay.upload.fil
e [1098]_ Unresolved requirement: Import-Package: org.apache.commons.io; versio
n="[1.4.0,2.0.0)"_ [Sanitized]
at org.eclipse.osgi.container.Module.start(Module.java:444)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle
.java:428)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(Di
rectoryWatcher.java:1264)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(D
irectoryWatcher.java:1237)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(Dire
ctoryWatcher.java:520)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(Direct
oryWatcher.java:365)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryW
atcher.java:316)
It states org.apache.commons.io; version="[1.4.0,2.0.0) and means you need ..commons.io version 1.4.0 up to 2.0.0 but you defined a dependency for 2.5.
So either your bnd.bnd is wrong or your maven/gradle setup is wrong.

How to fix Guice error, "An illegal reflective access operation has occurred"

I've a Kotlin project which uses Guice for DI and has recently been updated from JDK 8 -> 11. It now emits the following error at runtime:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/Users/matt/.gradle/caches/modules-2/files-2.1/com.google.inject/guice/4.2.2/6dacbe18e5eaa7f6c9c36db33b42e7985e94ce77/guice-4.2.2.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
How should this warning be addressed?
The issue is due to how Guice internally accesses Java objects, which is unsafe under the new (Java 9+) Java Module System.
Also, starting with Java 16, this warning becomes an error, and the execution flag --illegal-access=permit must be specified manually to reproduce the behaviour of Java 9-15.
There is not much you can do to fix it; the best option is to upgrade to Guice 5.0.1, which has been patched to avoid illegal accesses. Your warning will disappear, and your application will work on Java 16+ with the default JVM behaviour.
As mentioned, it's better you just upgrade to Guice 5 where this is updated.
BUT ... just in case you are stuck with Guice 4 until you can make the upgrade, just start java with these extra parameters:
java --illegal-access=permit --add-opens java.base/java.lang=ALL-UNNAMED ...
and you are good to go !!

Apache Ignite IllegalAccessException from GridUnsafe when using Ignite object

This is all I have in my code. It's just the typical way of using Ignite:
Ignite ignite = Ignition.ignite();
The error message I saw is:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.ignite.internal.util.GridUnsafe$2 (file:/C:/Users/.../.m2/repository/org/apache/ignite/ignite-core/2.7.0/ignite-core-2.7.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.apache.ignite.internal.util.IgniteUtils.<clinit>(IgniteUtils.java:795)
at org.apache.ignite.internal.IgnitionEx.<clinit>(IgnitionEx.java:209)
at org.apache.ignite.Ignition.ignite(Ignition.java:489)
at distributedjobexecutor.App.<init>(App.java:19)
at distributedjobexecutor.App.main(App.java:39)
Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class is unavailable.
at org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453)
at org.apache.ignite.internal.util.GridUnsafe.<clinit>(GridUnsafe.java:112)
... 5 more
Caused by: java.lang.IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe cannot access class jdk.internal.misc.SharedSecrets (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module #2ac273d3
at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360)
at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589)
at java.base/java.lang.reflect.Method.invoke(Method.java:556)
at org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450)
... 6 more
Why am I getting this message, and how can I fix this? I am using Java jdk-10.0.1.
This problem comes from the module access control system, introduced in Java 9.
To workaround it, use the following JVM parameters:
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED
Add the following arguments to the VM of module
Refer this Running-apache-ignite-on-openjdk-15,-16-and-17
--add-opens=java.base/jdk.internal.misc=ALL-UNNAMED
--add-opens=java.base/sun.nio.ch=ALL-UNNAMED
--add-opens=java.base/sun.nio.ch=ALL-UNNAMED
--add-opens=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED
--add-opens=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
--add-opens=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.nio=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
This answer is intended as an addendum to Denis' excellent answer.
In short, when you see this warning for any Java software (not just Apache Ignite):
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.ignite.internal.util.GridUnsafe$2 (file:/C:/Users/.../.m2/repository/org/apache/ignite/ignite-core/2.7.0/ignite-core-2.7.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Add JVM arg: --illegal-access=warn
Restart the JVM and watch for illegal access warnings.
For each specific warning about a class, e.g., java.nio.Buffer, find the Java module, e.g., java.base, then add a JVM arg for the module & package: --add-opens=java.base/java.nio=ALL-UNNAMED
Rinse and repeat and until all warnings are removed.
Optionally, remove JVM arg --illegal-access=warn
For Java libraries that make extensive use of "unsafe" Java code (off-heap tricks), you might need to add more than 10 of these JVM args!

an internal error occurred during: "Generating NED Documentation..."

When I tried to generate the Veins NED documentation. I got this error
"an internal error occurred during: "Generating NED Documentation..."."
java.lang.RuntimeException: unknown tag code 43, cannot create object
to represent it.
Even after I reinstalled omnetpp and veins, still have the same error. How can I fix it?

JRebel caused WELD-001414 Bean name is ambiguous

We created a multi-module maven project but is currently encountering the error in the title on deploy.
Here's the setup (those with parenthesis rebel means there is a jrebel configuration in that project):
-MainProject:
--Model (rebel)
--ProjectA
---Web (rebel)
---EJB (rebel)
---Config (rebel)
The weird thing is, if I removed the rebel configuration in EJB it deploys successfully.
The error:
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name bayadDunningInputHistoryBean resolves to beans [Managed Bean [class xxx.yyy.ClassBean] with qualifiers [#Any #Default #Named], Managed Bean [class xxx.yyy.ClassBean] with qualifiers [#Any #Default #Named]]
Base on the error, could it be that the same class is loaded twice?
The solution was to downgrade from JBoss7.2 to JBoss7.1.3. Fortunately we were really not dependent on anything from 7.2 version but still I wonder what changed could be something about class loading.