[JBoss JIRA] (WFCORE-2270) Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2270:
------------------------------------------
The work for this involves two PRs, the first of which is now merged:
1) Making whether a RuntimeCapability allows multiple registration points configurable via its Builder, and rejecting cases where multiple registration is attempted when not allowed.
2) Changing the default to not allow multiple registration.
A WildFly Core release will need to be done between 1) and 2) to allow uses in full to take advantage of the config option 1) provides.
> Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2270
> URL: https://issues.jboss.org/browse/WFCORE-2270
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. And the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, usually the config can only have the same cap in one place.
> There are exceptions to this rule though, so allowing more than one registration point needs to be configurable. Exceptions are basically cases where different resources can register the capability, and the authors of those know about this and have coded up the capability implementations to check for duplication and correctly deal it. For example:
> 1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check for the presence of jgroups before putting in it's impl. Both are owned by the same author (WildFly clustering team.)
> 2) On an HC, interfaces and paths can be registered in multiple locations that all end up with the same scope. But they don't have to be. The impl understands the precedence rules between those possible locations and the actual capability reflects the correct config.
> I think this latter case is why CapabilityRegistry.registerCapability still allows multiple registration points. But it's a corner case that shouldn't drive all behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2283:
-------------------------------------
Fix Version/s: (was: 3.0.0.Alpha25)
> Make 'required' attributes clearer when using tab completion within CLI
> -----------------------------------------------------------------------
>
> Key: WFCORE-2283
> URL: https://issues.jboss.org/browse/WFCORE-2283
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
>
> The following is some example output pressing tab to reveal the parameters of 'add': -
> {{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add(
> ! alias-filter credential-reference path provider-name providers relative-to required type }}
> From this is it not clear which are actually required.
> Suggestions to make it clearer: -
> * Show required / optional in different colours.
> * Add something to the required attributes e.g. '*'
> * Add something to the optional requirements e.g. {optional_arg}
> Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative.
> Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Douglas Gardim (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Douglas Gardim commented on WFLY-3858:
--------------------------------------
Using 8.2.0.Final here.
Actually I found another workaround: inside the "security" cache container, create another cache configuration (local-cache in my case) with the same name as the security-domain. So I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After observing many redeployments I noticed that, when it fails to get the configuration from the "auth-cache", it gets it from the "[security domain name]" configuration instead.
I don't know exactly how to explain this, but I noticed that the security domain actually uses a cache that is named after the security domain's own name. Maybe because it uses exactly the configuration that is defined in the infinispan subsystem it somehow gets updated when it is finally loaded.
> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
> Key: WFLY-3858
> URL: https://issues.jboss.org/browse/WFLY-3858
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Robert Tuck
> Assignee: Darran Lofthouse
> Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
> <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
> <cache-container name="security" default-cache="auth-cache" start="EAGER">
> <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
> <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration lifespan="60000"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="OAuth-Consumer" cache-type="infinispan">
> <authentication>
> <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
> module="deployment.ewb-server-ear.ear">
> <module-option name="allowedConsumerAuthFailures" value="-1"/>
> <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
> public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
> log.debugf("Creating SDC for domain=" + securityDomain);
> AuthenticationManager am = createAuthenticationManager(securityDomain);
> // create authentication cache
> if (cacheFactory instanceof EmbeddedCacheManager) {
> EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
> @SuppressWarnings("rawtypes")
> Cache cache = null;
> if (cacheManager != null) {
> // TODO override global settings with security domain specific
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
> if (baseCfg != null) {
> builder.read(baseCfg);
> }
> cacheManager.defineConfiguration(securityDomain, builder.build());
> cache = cacheManager.getCache(securityDomain);
> }
> if (cache != null && am instanceof CacheableManager) {
> @SuppressWarnings({ "unchecked", "rawtypes" })
> CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
> cm.setCache(cache);
> }
> } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
> @Override
> public Configuration getCacheConfiguration(String name) {
> Configuration configuration = configurationOverrides.get(name);
> if (configuration == null && cacheExists(name)) {
> return defaultConfiguration;
> }
> return configuration;
> }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-2283:
----------------------------------------
Assignee: Jean-Francois Denise
> Make 'required' attributes clearer when using tab completion within CLI
> -----------------------------------------------------------------------
>
> Key: WFCORE-2283
> URL: https://issues.jboss.org/browse/WFCORE-2283
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha25
>
>
> The following is some example output pressing tab to reveal the parameters of 'add': -
> {{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add(
> ! alias-filter credential-reference path provider-name providers relative-to required type }}
> From this is it not clear which are actually required.
> Suggestions to make it clearer: -
> * Show required / optional in different colours.
> * Add something to the required attributes e.g. '*'
> * Add something to the optional requirements e.g. {optional_arg}
> Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative.
> Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-2283:
----------------------------------------
Summary: Make 'required' attributes clearer when using tab completion within CLI
Key: WFCORE-2283
URL: https://issues.jboss.org/browse/WFCORE-2283
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Darran Lofthouse
Fix For: 3.0.0.Alpha25
The following is some example output pressing tab to reveal the parameters of 'add': -
{{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add(
! alias-filter credential-reference path provider-name providers relative-to required type }}
>From this is it not clear which are actually required.
Suggestions to make it clearer: -
* Show required / optional in different colours.
* Add something to the required attributes e.g. '*'
* Add something to the optional requirements e.g. {optional_arg}
Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative.
Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2282) Get rid of the clientRequestExecutor in AbstractModelControllerOperationHandlerFactoryService
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2282:
----------------------------------------
Summary: Get rid of the clientRequestExecutor in AbstractModelControllerOperationHandlerFactoryService
Key: WFCORE-2282
URL: https://issues.jboss.org/browse/WFCORE-2282
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 4.0.0.Beta1
AbstractModelControllerOperationHandlerFactoryService creates a thread pool for handling management requests, with the goal being to limit the number of concurrently executing requests to 4, with tasks for other requests being queued.
There are other ways to do this kind of limitation that do not involve a new thread pool. See Undertow's RequestLimitHandler and related RequestLimit class for the template.
This task is to implement the equivalent in org.jboss.as.controller.remote (not as public API) and then switch the execution to the ServerService Thread Pool (on a server) or the HostControllerService Thread Pool (on an HC).
It is *not* a request to move execution to the XNIO worker task thread. That should not be done without a very clear discussion.
Part of this task is to account for the thinking that went into a fix for WFCORE-1529. IOW moving work to ServerService Thread Pool / HostControllerService Thread Pool will likely affect the optimum core sizes of those pools. This AbstractModelControllerOperationHandlerFactoryService.clientRequestExecutor is what is referred to in the PR for WFCORE-1529 in its discussion of "management-handler-thread".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (HIBERNATE-157) InvocationTargetException when opening hibernate structure
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-157?page=com.atlassian.jira.plu... ]
Koen Aers commented on HIBERNATE-157:
-------------------------------------
[~amenel] Sorry for the delay on this. I was able to reproduce the problem and found that the root cause is the fact that you are using the EclipseLink persistence provider:
{{<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>}}
If you remove this line, the error disappears. This is because the Hibernate Tools use the Hibernate runtime to build up the JPA metadata that are shown in the configuration view. Now the Hibernate runtime ignores persistence unit definitions if the specified persistence provider on the unit is not the Hibernate persistence provider.
In any case, the error message is misleading and should probably be fixed.
> 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, 2 months