[JBoss JIRA] (WFCORE-2048) attributes of BYTES unit should not allow negative values
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2048?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-2048:
-------------------------------------
Default validator for unit type Bytes should be written to enforce only positive values
> attributes of BYTES unit should not allow negative values
> ---------------------------------------------------------
>
> Key: WFCORE-2048
> URL: https://issues.jboss.org/browse/WFCORE-2048
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> For {{http-listener}}, {{https-listener}} and {{mod-cluster}} filter in Undertow subsystem, there are some http2 related attributes:
> {code}
> "http2-header-table-size" => {
> "type" => INT,
> "description" => "The size of the header table used for HPACK compression, in bytes. This amount of memory will be allocated per connection for compression. Larger values use more memory but may give better compression.",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-initial-window-size" => {
> "type" => INT,
> "description" => "The flow control window size that controls how quickly the client can send data to the server",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-concurrent-streams" => {
> "type" => INT,
> "description" => "The maximum number of HTTP/2 streams that can be active at any time on a single connection",
> "expressions-allowed" => true,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-frame-size" => {
> "type" => INT,
> "description" => "The max HTTP/2 frame size",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-header-list-size" => {
> "type" => INT,
> "description" => "The maximum size of request headers the server is prepared to accept",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> {code}
> As unit of these attributes is used {{BYTES}} we should not allow user to input negative numbers there. Currently I can simply put negative number and server does not protest anyhow (I guess that server simply interpret given negative number as actual unsigned number of integer internally?). We should inform user that we expect only positive numbers for these attributes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2048) attributes of BYTES unit should not allow negative values
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2048?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved WFLY-7684 to WFCORE-2048:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2048 (was: WFLY-7684)
Issue Type: Enhancement (was: Bug)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: (was: 10.1.0.Final)
> attributes of BYTES unit should not allow negative values
> ---------------------------------------------------------
>
> Key: WFCORE-2048
> URL: https://issues.jboss.org/browse/WFCORE-2048
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> For {{http-listener}}, {{https-listener}} and {{mod-cluster}} filter in Undertow subsystem, there are some http2 related attributes:
> {code}
> "http2-header-table-size" => {
> "type" => INT,
> "description" => "The size of the header table used for HPACK compression, in bytes. This amount of memory will be allocated per connection for compression. Larger values use more memory but may give better compression.",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-initial-window-size" => {
> "type" => INT,
> "description" => "The flow control window size that controls how quickly the client can send data to the server",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-concurrent-streams" => {
> "type" => INT,
> "description" => "The maximum number of HTTP/2 streams that can be active at any time on a single connection",
> "expressions-allowed" => true,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-frame-size" => {
> "type" => INT,
> "description" => "The max HTTP/2 frame size",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-header-list-size" => {
> "type" => INT,
> "description" => "The maximum size of request headers the server is prepared to accept",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> {code}
> As unit of these attributes is used {{BYTES}} we should not allow user to input negative numbers there. Currently I can simply put negative number and server does not protest anyhow (I guess that server simply interpret given negative number as actual unsigned number of integer internally?). We should inform user that we expect only positive numbers for these attributes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7684) attributes of BYTES unit should not allow negative values
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-7684?page=com.atlassian.jira.plugin.... ]
Chao Wang moved JBEAP-7528 to WFLY-7684:
----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7684 (was: JBEAP-7528)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 10.1.0.Final
(was: 7.1.0.DR7)
> attributes of BYTES unit should not allow negative values
> ---------------------------------------------------------
>
> Key: WFLY-7684
> URL: https://issues.jboss.org/browse/WFLY-7684
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> For {{http-listener}}, {{https-listener}} and {{mod-cluster}} filter in Undertow subsystem, there are some http2 related attributes:
> {code}
> "http2-header-table-size" => {
> "type" => INT,
> "description" => "The size of the header table used for HPACK compression, in bytes. This amount of memory will be allocated per connection for compression. Larger values use more memory but may give better compression.",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-initial-window-size" => {
> "type" => INT,
> "description" => "The flow control window size that controls how quickly the client can send data to the server",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-concurrent-streams" => {
> "type" => INT,
> "description" => "The maximum number of HTTP/2 streams that can be active at any time on a single connection",
> "expressions-allowed" => true,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-frame-size" => {
> "type" => INT,
> "description" => "The max HTTP/2 frame size",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "http2-max-header-list-size" => {
> "type" => INT,
> "description" => "The maximum size of request headers the server is prepared to accept",
> "expressions-allowed" => true,
> "nillable" => true,
> "unit" => "BYTES",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> {code}
> As unit of these attributes is used {{BYTES}} we should not allow user to input negative numbers there. Currently I can simply put negative number and server does not protest anyhow (I guess that server simply interpret given negative number as actual unsigned number of integer internally?). We should inform user that we expect only positive numbers for these attributes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-797) Ldap security realm does not close DirContext properly
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-797?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-797:
---------------------------
Comment: was deleted
(was: Note: getCredentialAcquireSupport does not use DirContext anymore (works offline))
> Ldap security realm does not close DirContext properly
> ------------------------------------------------------
>
> Key: ELY-797
> URL: https://issues.jboss.org/browse/ELY-797
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
>
> There are methods in Elytron {{LdapSecurityRealm}} class which create/get DirContext, but does not close him in finally block.
> In some circumstances could cause context resource leak.
> * LdapSecurityRealm
> ** getEvidenceVerifySupport
> ** getCredentialAcquireSupport
> ** getCredential
> ** setCredentials
> * LdapRealmIdentity
> ** setCredentials
> In same class there are examples of properly closed contexts:
> * LdapRealmIdentity
> ** getCredential
> ** getEvidenceVerifySupport
> ** verifyEvidence
> ** getIdentity
> ** create
> ** setAttributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-797) Ldap security realm does not close DirContext properly
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-797?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-797:
--------------------------------
Note: getCredentialAcquireSupport does not use DirContext anymore (works offline)
> Ldap security realm does not close DirContext properly
> ------------------------------------------------------
>
> Key: ELY-797
> URL: https://issues.jboss.org/browse/ELY-797
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
>
> There are methods in Elytron {{LdapSecurityRealm}} class which create/get DirContext, but does not close him in finally block.
> In some circumstances could cause context resource leak.
> * LdapSecurityRealm
> ** getEvidenceVerifySupport
> ** getCredentialAcquireSupport
> ** getCredential
> ** setCredentials
> * LdapRealmIdentity
> ** setCredentials
> In same class there are examples of properly closed contexts:
> * LdapRealmIdentity
> ** getCredential
> ** getEvidenceVerifySupport
> ** verifyEvidence
> ** getIdentity
> ** create
> ** setAttributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-797) Ldap security realm does not close DirContext properly
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-797?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina reassigned ELY-797:
------------------------------
Assignee: Jan Kalina
> Ldap security realm does not close DirContext properly
> ------------------------------------------------------
>
> Key: ELY-797
> URL: https://issues.jboss.org/browse/ELY-797
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
>
> There are methods in Elytron {{LdapSecurityRealm}} class which create/get DirContext, but does not close him in finally block.
> In some circumstances could cause context resource leak.
> * LdapSecurityRealm
> ** getEvidenceVerifySupport
> ** getCredentialAcquireSupport
> ** getCredential
> ** setCredentials
> * LdapRealmIdentity
> ** setCredentials
> In same class there are examples of properly closed contexts:
> * LdapRealmIdentity
> ** getCredential
> ** getEvidenceVerifySupport
> ** verifyEvidence
> ** getIdentity
> ** create
> ** setAttributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-797) Ldap security realm does not close DirContext properly
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-797?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7613 to ELY-797:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-797 (was: WFLY-7613)
Component/s: Realms
(was: Security)
Target Release: (was: 7.1.0.GA)
Affects Version/s: (was: 11.0.0.Alpha1)
> Ldap security realm does not close DirContext properly
> ------------------------------------------------------
>
> Key: ELY-797
> URL: https://issues.jboss.org/browse/ELY-797
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Reporter: Martin Choma
> Priority: Blocker
>
> There are methods in Elytron {{LdapSecurityRealm}} class which create/get DirContext, but does not close him in finally block.
> In some circumstances could cause context resource leak.
> * LdapSecurityRealm
> ** getEvidenceVerifySupport
> ** getCredentialAcquireSupport
> ** getCredential
> ** setCredentials
> * LdapRealmIdentity
> ** setCredentials
> In same class there are examples of properly closed contexts:
> * LdapRealmIdentity
> ** getCredential
> ** getEvidenceVerifySupport
> ** verifyEvidence
> ** getIdentity
> ** create
> ** setAttributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 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 edited comment on HIBERNATE-157 at 11/26/16 2:37 PM:
---------------------------------------------------------------------
[^hibernate-157.zip]
I have attached a project (created on Windows 8.1) that I've derived from my current project, which I was working on when I encountered the exception and opened the SO question. The attached project contains the minimum elements to trigger this issue.
Steps to reproduce:
* Import the project as a Maven project into Red Hat JBoss Developer Studio (10.1.0.GA or 10.2.0.AM3).
* In the Hibernate Configurations view, add a configuration.
* In the Edit Configuration dialog box: select `JPA` as *Type* and select the provided *Project*, *Property file* and *Persistence unit* (there's no need to select anything else, for instance, *Database dialect* on the *Options* tab).
* Click *OK* to close the dialog.
* Click the expand/collapse button next to the configuration that has just been created.
* The exception occurs in vanilla 10.2.0.AM3 (no plugins added and no preferences set or changed).
Many thanks in advance for your efforts on this. I hope this attachment will help solve the issue.
was (Author: amenel):
[^hibernate-157.zip]
I have attached a project (created on Windows 8.1) that I've derived from my current project, which I was working on when I encountered the exception and opened the SO question. The attached project contains the minimum elements to trigger this issue.
Steps to reproduce:
* Import the project as a Maven project into Red Hat JBoss Developer Studio (10.1.0.GA or 10.2.0.AM3).
* In the Hibernate Configurations view, add a configuration.
* In the Edit Configuration dialog box: select `JPA` as *Type* and select the provided *Project*, *Property file* and *Persistence unit* (there's no need to select anything else, for instance, *Database dialect* on the *Options* tab.
* Click *OK* to close the dialog.
* Click the expand/collapse button next to the configuration that has just been created.
* The exception occurs in vanilla 10.2.0.AM3 (no plugins added and no preferences set or changed).
Many thanks in advance for your efforts on this. I hope this attachment will help solve the issue.
> 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)
9 years, 5 months