[JBoss JIRA] (WFCORE-1983) CLI type decision INT/STRING LONG/STRING
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1983:
------------------------------------------
I'm not sure from the description what is getting sent to the server.
If it is:
{code}
{"mynumber"=>"9999"}
{code}
instead of:
{code}
{"mynumber"=>9999}
{code}
then yes, the server will almost certainly deal with that kind of type conversion properly. The server knows the desired type of the field and will attempt simple conversion to move from what the client provides to what is specified.
> CLI type decision INT/STRING LONG/STRING
> ----------------------------------------
>
> Key: WFCORE-1983
> URL: https://issues.jboss.org/browse/WFCORE-1983
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception).
> The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed.
> I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT.
> Some server side subsystems are smart enough to call into asXXX methods and not check the type?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1983) CLI type decision INT/STRING LONG/STRING
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1983:
--------------------------------------------
Summary: CLI type decision INT/STRING LONG/STRING
Key: WFCORE-1983
URL: https://issues.jboss.org/browse/WFCORE-1983
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception).
The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed.
I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT.
Some server side subsystems are smart enough to call into asXXX methods and not check the type?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGMGR-144) Allow the # symbol to be used for expressions in a PatternFormatter
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-144?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-144:
---------------------------------
Description:
Currently in the format pattern when you want to define an expression the format pattern is {code}
%${system.property.key:default-value}
{code}
This can cause problems other applications that parse the same type of expression format like WildFly. Adding an option like the following will allow a workaround for this issue.
{code}
%#{system.property.key:default:value}
{code}
was:
Currently in the format pattern when you want to define an expression the format pattern is {code}
%${system.property.key:default-value}
{code}
This can cause problems other applications that parse the same type of expression format like WildFly. Adding an option like the following will allow a workaround for this issue.
{code{
%#{system.property.key:default:value}
{code}
> Allow the # symbol to be used for expressions in a PatternFormatter
> -------------------------------------------------------------------
>
> Key: LOGMGR-144
> URL: https://issues.jboss.org/browse/LOGMGR-144
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently in the format pattern when you want to define an expression the format pattern is {code}
> %${system.property.key:default-value}
> {code}
> This can cause problems other applications that parse the same type of expression format like WildFly. Adding an option like the following will allow a workaround for this issue.
> {code}
> %#{system.property.key:default:value}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-746) AuthenticationConfiguration.getAuthenticationConfiguration should also modify the EMPTY configuration
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-746?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse resolved ELY-746.
----------------------------------
Resolution: Done
> AuthenticationConfiguration.getAuthenticationConfiguration should also modify the EMPTY configuration
> -----------------------------------------------------------------------------------------------------
>
> Key: ELY-746
> URL: https://issues.jboss.org/browse/ELY-746
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta14
>
>
> Or we get errors like this: -
> {noformat}
> Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.023 sec <<< FAILURE! - in org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> testSequentialGroup(org.jboss.as.controller.test.TransactionalProtocolClientTestCase) Time elapsed: 0 sec <<< ERROR!
> java.lang.IllegalArgumentException: No host given in URI 'remote://127.0.0.1:32123'
> at org.jboss.remoting3.EndpointImpl.getConnection(EndpointImpl.java:410)
> at org.jboss.remoting3.UncloseableEndpoint.getConnection(UncloseableEndpoint.java:59)
> at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:105)
> at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:134)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1979) Wildfly-openssl is missing 32 bits variant.
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1979?page=com.atlassian.jira.plugi... ]
Radim Hatlapatka updated WFCORE-1979:
-------------------------------------
Description:
There is missing wildfly-openssl build for 32 bits variants resulting in this exception:
{noformat}
11:33:40,914 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("core-service" => "management"),
("security-realm" => "ApplicationRealm")
]) - failure description: {
"WFLYCTL0080: Failed services" => {"jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context" => "org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
Caused by: java.lang.reflect.InvocationTargetException
Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path"},
"WFLYCTL0412: Required services that are not installed:" => ["jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined,
"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
"Services that were unable to start:" => ["jboss.server.controller.management.security_realm.ApplicationRealm"],
"Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}
}
{noformat}
was:
There is missing wildfly-openssl build for 32 bits variants resulting in this exception:
{noformat}
2016-10-25 14:35:27,732 ERROR [stderr] (MSC service thread 1-7) java.lang.reflect.InvocationTargetException
2016-10-25 14:35:27,734 ERROR [stderr] (MSC service thread 1-7) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2016-10-25 14:35:27,735 ERROR [stderr] (MSC service thread 1-7) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
2016-10-25 14:35:27,736 ERROR [stderr] (MSC service thread 1-7) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
2016-10-25 14:35:27,737 ERROR [stderr] (MSC service thread 1-7) at java.lang.reflect.Method.invoke(Method.java:508)
2016-10-25 14:35:27,738 ERROR [stderr] (MSC service thread 1-7) at org.wildfly.openssl.SSL.init(SSL.java:73)
2016-10-25 14:35:27,738 ERROR [stderr] (MSC service thread 1-7) at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
2016-10-25 14:35:27,739 ERROR [stderr] (MSC service thread 1-7) at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
2016-10-25 14:35:27,740 ERROR [stderr] (MSC service thread 1-7) at java.lang.Class.forNameImpl(Native Method)
2016-10-25 14:35:27,741 ERROR [stderr] (MSC service thread 1-7) at java.lang.Class.forName(Class.java:348)
2016-10-25 14:35:27,742 ERROR [stderr] (MSC service thread 1-7) at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
2016-10-25 14:35:27,743 ERROR [stderr] (MSC service thread 1-7) at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
2016-10-25 14:35:27,754 ERROR [stderr] (MSC service thread 1-7) at java.security.AccessController.doPrivileged(AccessController.java:594)
2016-10-25 14:35:27,755 ERROR [stderr] (MSC service thread 1-7) at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
2016-10-25 14:35:27,756 ERROR [stderr] (MSC service thread 1-7) at java.lang.J9VMInternals.newInstanceImpl(Native Method)
2016-10-25 14:35:27,757 ERROR [stderr] (MSC service thread 1-7) at java.lang.Class.newInstance(Class.java:1899)
2016-10-25 14:35:27,758 ERROR [stderr] (MSC service thread 1-7) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:391)
2016-10-25 14:35:27,759 ERROR [stderr] (MSC service thread 1-7) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:415)
2016-10-25 14:35:27,760 ERROR [stderr] (MSC service thread 1-7) at java.util.ServiceLoader$1.next(ServiceLoader.java:491)
2016-10-25 14:35:27,776 ERROR [stderr] (MSC service thread 1-7) at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
2016-10-25 14:35:27,777 ERROR [stderr] (MSC service thread 1-7) at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
2016-10-25 14:35:27,778 ERROR [stderr] (MSC service thread 1-7) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
2016-10-25 14:35:27,779 ERROR [stderr] (MSC service thread 1-7) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
2016-10-25 14:35:27,780 ERROR [stderr] (MSC service thread 1-7) at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
2016-10-25 14:35:27,781 ERROR [stderr] (MSC service thread 1-7) at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
2016-10-25 14:35:27,782 ERROR [stderr] (MSC service thread 1-7) at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
2016-10-25 14:35:27,783 ERROR [stderr] (MSC service thread 1-7) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
2016-10-25 14:35:27,784 ERROR [stderr] (MSC service thread 1-7) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
2016-10-25 14:35:27,785 ERROR [stderr] (MSC service thread 1-7) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
2016-10-25 14:35:27,789 ERROR [stderr] (MSC service thread 1-7) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
2016-10-25 14:35:27,790 ERROR [stderr] (MSC service thread 1-7) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
2016-10-25 14:35:27,791 ERROR [stderr] (MSC service thread 1-7) at java.lang.Thread.run(Thread.java:785)
2016-10-25 14:35:27,792 ERROR [stderr] (MSC service thread 1-7) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-317723765121491548openssl/libwfssl.so (/tmp/tmp-317723765121491548openssl/libwfssl.so: wrong ELF class: ELFCLASS64)
2016-10-25 14:35:27,794 ERROR [stderr] (MSC service thread 1-7) at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1344)
2016-10-25 14:35:27,794 ERROR [stderr] (MSC service thread 1-7) at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:1304)
2016-10-25 14:35:27,795 ERROR [stderr] (MSC service thread 1-7) at java.lang.System.loadLibrary(System.java:552)
2016-10-25 14:35:27,796 ERROR [stderr] (MSC service thread 1-7) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
2016-10-25 14:35:27,797 ERROR [stderr] (MSC service thread 1-7) ... 31 more
{noformat}
> Wildfly-openssl is missing 32 bits variant.
> -------------------------------------------
>
> Key: WFCORE-1979
> URL: https://issues.jboss.org/browse/WFCORE-1979
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: wildfly-openssl
>
> There is missing wildfly-openssl build for 32 bits variants resulting in this exception:
> {noformat}
> 11:33:40,914 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("security-realm" => "ApplicationRealm")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context" => "org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> Caused by: java.lang.reflect.InvocationTargetException
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path"},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined,
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.server.controller.management.security_realm.ApplicationRealm"],
> "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (HIBERNATE-157) InvocationTargetException when opening hibernate structure
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-157?page=com.atlassian.jira.plu... ]
Scott Marlow commented on HIBERNATE-157:
----------------------------------------
Looks like a NPE in org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata() to me from the call stack. Koen?
> 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: Steve Ebersole
>
> 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)
9 years, 8 months