[JBoss JIRA] (WFLY-8997) @RunAsIdentity should cause authentication part to be skipped
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-8997?page=com.atlassian.jira.plugin.... ]
Yeray Borges reassigned WFLY-8997:
----------------------------------
Assignee: Yeray Borges (was: Stefan Guilhen)
> @RunAsIdentity should cause authentication part to be skipped
> -------------------------------------------------------------
>
> Key: WFLY-8997
> URL: https://issues.jboss.org/browse/WFLY-8997
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jörg Bäsner
> Assignee: Yeray Borges
>
> The issue [WFLY-140|https://issues.jboss.org/browse/WFLY-140] introduced a change in behavior.
> Before this change, the SecurityContextInterceptor would just invoke the push() method on SimpleSecurityManager and that method would internally create a new security context and authenticate the incoming principal if needed. In that implementation the presence of a RunAsIdentity would cause authentication part to be skipped.
> With the changes in the above issue, the security context establishment and the authentication parts were separated and while push() still checks for a RunAsIdentity, the authenticate() implementation does not, which ends up triggering the authentication process even if a RunAsIdentity is available. There is another check in place to avoid authentication if a valid authenticated subject already exists and the security domains match but this should also be the case if the security domains do not match.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3070) Found multiple secret keys sharing same CKA_LABEL
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3070?page=com.atlassian.jira.plugi... ]
Peter Skopek moved JBEAP-12175 to WFCORE-3070:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3070 (was: JBEAP-12175)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: (was: 7.1.0.ER1)
> Found multiple secret keys sharing same CKA_LABEL
> -------------------------------------------------
>
> Key: WFCORE-3070
> URL: https://issues.jboss.org/browse/WFCORE-3070
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Peter Skopek
> Assignee: Peter Skopek
> Priority: Blocker
> Labels: eap7.1-rfe-failure
>
> When multiple PKCS11 keystores are configured in domain [1][2]. And PKCS11 store contains secret key. Then this exception is thrown on startup intermittently (but very often, cca 50%).
> {code:server.log}
> [Host Controller] 10:15:05,526 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.key-store.oneWayKS: org.jboss.msc.service.StartException in service org.wildfly.security.key-store.oneWayKS: WFLYELY00004: Unable to start the service.
> [Host Controller] at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:146)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: java.io.IOException: load failed
> [Host Controller] at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:763)
> [Host Controller] at java.security.KeyStore.load(KeyStore.java:1445)
> [Host Controller] at org.wildfly.security.keystore.AtomicLoadKeyStoreSpi.engineLoad(AtomicLoadKeyStoreSpi.java:55)
> [Host Controller] at java.security.KeyStore.load(KeyStore.java:1445)
> [Host Controller] at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:137)
> [Host Controller] ... 5 more
> [Host Controller] Caused by: java.security.KeyStoreException: invalid KeyStore state: found multiple secret keys sharing same CKA_LABEL [my-key]
> [Host Controller] at sun.security.pkcs11.P11KeyStore.mapLabels(P11KeyStore.java:2408)
> [Host Controller] at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:755)
> [Host Controller] ... 9 more
> {code}
> Storing secret key into PKCS11 store is necessary for FIPS Credential store implementation.
> {code:java|title=sun.security.pkcs11.P11KeyStore.java}
> for (long handle : handles) {
> attrs = new CK_ATTRIBUTE[] { new CK_ATTRIBUTE(CKA_LABEL) };
> token.p11.C_GetAttributeValue(session.id(), handle, attrs);
> if (attrs[0].pValue != null) {
> // there is a CKA_LABEL
> String cka_label = new String(attrs[0].getCharArray());
> if (sKeyMap.get(cka_label) == null) {
> sKeyMap.put(cka_label, new AliasInfo(cka_label));
> } else {
> throw new KeyStoreException("invalid KeyStore state: " +
> "found multiple secret keys sharing same " +
> "CKA_LABEL [" +
> cka_label +
> "]");
> }
> }
> }
> {code}
> It seems to me problem will be PKCS11 store (system wide) is loaded concurrently multiple times and therefore sometimes JDK check triggers false positive alarm [3].
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-security/blob/...
> [2] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-security/blob/...
> [3] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9094) Trivial fixes in appclient.sh and jdr.sh
by Jan Stourac (JIRA)
Jan Stourac created WFLY-9094:
---------------------------------
Summary: Trivial fixes in appclient.sh and jdr.sh
Key: WFLY-9094
URL: https://issues.jboss.org/browse/WFLY-9094
Project: WildFly
Issue Type: Bug
Components: Scripts
Affects Versions: 11.0.0.Alpha1
Reporter: Jan Stourac
Assignee: Tomaz Cerar
Priority: Trivial
Minor changes in bin/appclient.sh and bin/jdr.sh:
* appclient:
** fix of HAS_OPENJDK variable name
** use || instead of -o as it is better defined
* jdr:
** used simplier syntax for if statement condition
** fix of assignment statement "cygwin = true" -> "cygwin=true"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9093) Upgrade JBeret to version 1.2.4.Final
by James Perkins (JIRA)
James Perkins created WFLY-9093:
-----------------------------------
Summary: Upgrade JBeret to version 1.2.4.Final
Key: WFLY-9093
URL: https://issues.jboss.org/browse/WFLY-9093
Project: WildFly
Issue Type: Component Upgrade
Components: Batch
Reporter: James Perkins
Assignee: James Perkins
Fix For: 11.0.0.Beta1
JBeret needs to be upgraded to version 1.2.4.Final to fix JBEAP-11818. There is also a fix for WFLY-3424 and possibly one needed for WFLY-8942.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-7987.
-------------------------------
Fix Version/s: 11.0.0.CR1
Resolution: Done
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Tomaz Cerar
> Fix For: 11.0.0.CR1
>
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (LOGTOOL-101) Exception transformation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-101:
----------------------------------
Fix Version/s: 2.1.0.Beta2
(was: 2.1.0.Beta1)
> Exception transformation
> ------------------------
>
> Key: LOGTOOL-101
> URL: https://issues.jboss.org/browse/LOGTOOL-101
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 2.1.0.Beta2
>
>
> I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine.
> Something like this:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause)
> {code}
> This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string.
> Note that I can almost do this now, except that there's no way to copy the exception stack:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause)
> {code}
> An alternative approach is to add an annotation for copying the stack trace:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause)
> {code}
> Note that in this case the original exception message is lost. The next variant would preserve the message:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2)
> {code}
> And now to eliminate the duplication:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause)
> {code}
> Note that I don't recall if @Pos is 1- or 0-based, so I guessed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HIBERNATE-157) InvocationTargetException when opening hibernate structure
by Amenel Voglozin (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-157?page=com.atlassian.jira.plu... ]
Amenel Voglozin commented on HIBERNATE-157:
-------------------------------------------
{quote}Now the Hibernate runtime ignores persistence unit definitions if the specified persistence provider on the unit is not the Hibernate persistence provider.
{quote}
I have only now returned to the project on which I had this error. This is just to let you know that the specified provider is not ignored in Eclipse Oxygen with Hibernate Tools 5.1.4.v20170413-1729. Maybe that it is in the next version.
I'll keep the line {{<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>}} out of the file as it is the solution, like you said. And yes, I'd vote for a more explicit error message.
Many many thanks.
> InvocationTargetException when opening hibernate structure
> ----------------------------------------------------------
>
> Key: HIBERNATE-157
> URL: https://issues.jboss.org/browse/HIBERNATE-157
> Project: Hibernate Integration
> Issue Type: Bug
> Environment: MacOS10.11.6(El Capitan), Eclipse4.6.0(Neon)
> Reporter: Yasuyuki Inoue
> Assignee: Koen Aers
> Attachments: hibernate-157.zip
>
>
> InvocationTargetException occured when opening existing Hibernate structure.
> !ENTRY org.hibernate.eclipse.console 4 2 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !SUBENTRY 1 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !STACK 0
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> ... 12 more
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> ... 17 more
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !STACK 0
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> ... 12 more
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> ... 17 more
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.reflect.InvocationTargetException: <no message>
> !STACK 0
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> ... 17 more
> Root exception:
> java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.NullPointerException: <no message>
> !STACK 0
> java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months